Custom Domain Setup

EQ Admin

EQ Forum Admin
Staff member
I don't like the current setup for custom domains. I have two primacy concerns:
  1. It's too hard to get started
  2. The process is out of order
For #1, don't force a user to update their DNS to get started. Let them provision the domain and then the system can start a timer i the background. Make it easy for users to get started adding a domain and creating users. It's correct to prompt for billing if they want to add more domains than allowed for a free account, but don't stop them at a verification process that might require 3rd party DNS support and discourage them from using the system and/or having to start over every time they hope the DNS change is ready. Make sure the SCRYPTmail system doesn't try to deliver local until the MX points to SCRYPTmail. Why the timer? Google Apps had a problem with spammers provisioning domains they didn't own, effectively blocking the real domain owners from being able to provision their domains in GA. Add a background check that monitors for the TXT record getting created and maintain a warning on the settings screen for that domain until the verification process is complete. If they don't complete the DNS verification within a reasonable amount of time, such as 1 week, suspend the access, and eventually remove it from the system. Maybe the background check happens when the user clicks into their custom domain settings and the verification process hasn't been completed yet. Maybe let them extend it for 3 days every time they login and it's not done yet? Give them a fair chance so any work a real user out into creating accounts isn't lost.

For #2, the current process works for a new domain that doesn't have email associated with it, but it's the wrong order for a domain that's being migrated. For consistency, update MX records should always be the last step. I suggest switching steps 2 & 4. A step in the middle about adding users & aliases is missing?

I'm working through this process now for a test domain.

I suspect my next concern will be mapping a custom domain to a folder instead of the inbox.

I'm also wondering if the custom domain will have it's own set of accounts & forwards, and not simply a 1-1 domain alias mapping to my primary account and aliases.
 

SCRYPTmail

Email Service Provider
That is legit concerns.
Initial Custom Domain (CD) roll was in fact to see feedback from users on the process. However DNS check is necessary, for at least to create aliases. When you create alias, system adds this address into email pool, and there are chance third party able to create alias without legally owning domain.

I agree steps after domain ownership validation should be skipped and I will do that in next version. I would be happy to hear more on how to handle custom domain aliases and administration panel.

Usually forwards are used when you don't have control over email domain, so instead to notify everyone about email address change you do forwarding, if this is a case custom domain don't have such restriction. But if I miss other situation, where having separate forwarding would be necessary, we may implement it.
 
Top