> Some software companies seem to not send emails to custom domains. As someone who operates a SaaS that does auto-block some account registrations based on em

> Some software companies seem to not send emails to custom domains. As someone who operates a SaaS that does auto-block some account registrations based on email address, I feel like I should speak to this. We're actually fine with custom domains — and I imagine this is true for most SaaS companies. All our business customers use custom domains; and we're not about to blow holes in our funnel by making it harder to acquire new business customers. There's no logic in our codebase that especially favors the big email providers; no whitelist with gmail/outlook/etc. on it. (And we haven't found that any of the lifecycle-mail sending services we've tried have had trouble with custom domains, either.) Instead, what we're mostly trying to stop is registrations using what you might call vanity or proxy domains — domains created by people who are only trying to obscure their real email address, but who aren't willing to invest the effort to make their domain into a "real" domain that has working email deliverability in both directions and maybe a web presence to go along with it. Businesses almost always have such "real" domains; but people registering for illicit purposes (spamming, ban evasion, etc) almost never do, instead only bothering to set up e.g. an SMTP forwarding proxy that has no ability to originate mail. (Often they get such a service as a value add from their domain registrar; though there are independent services for this as well.) To detect these, we check things like: - Is your domain a known temporary email provider? (Immediate fail) - Is your domain's MX record shared with one used by known temporary email providers? (Also an immediate fail; and zero false positives from this, surprisingly) - Does your domain have SPF and DKIM records? (Good) - Do your MX record hostname(s) resolve to the IP ranges of some skeezy VPS host, or to an IaaS's ephemeral-allocation IP ranges? (Bad) - Does your NS record, or your MX record's NS record, point to a domain registrar that's well-known to be used for discovering + acquiring short nonsense domain names in bulk? (Bad) - Does your domain have an apex A record? (Good) Is there a website there? (Good) Is that website a domain-parking page? (Very, very bad) - How recently does your WHOIS record say that your domain was last transferred/acquired? Last 14 days? (Somewhat bad, but not as bad as the other things) I would guess that if you're having problems, it's with one of these heuristics, or one in a similar vein. If you jump through all the same hoops a business would jump through to make your custom domain "real", then any heuristics SaaS companies come up with to differentiate business domains from spam domains, should work out in your favor. (My own custom domain — which truly is just a vanity domain — passes all these tests easily; mostly by just doing the default stuff Google Workspace recommended I do when I set it up. Because that's all businesses are doing, too.)