CUSTOM DOMAIN
A customer connects their domain to send email from your platform. It looks like it worked. Then, a week later, their invoices stop arriving at their biggest client and land in spam instead. Nobody saw an error. Nothing turned red. That is the thing about email DNS: it is the one setup where getting it slightly wrong does not fail loudly. It just quietly costs the customer their reputation.
Most custom-domain tasks are forgiving. Point a CNAME at your app, verify it, issue a certificate, done. Email is not that. Email is the highest-stakes DNS work your customers will ever ask you to do on their behalf, and it is the setup most likely to break something they already rely on.
Why email is the hard one
A working hosted email setup is not one record. It is a small system of records that have to agree with each other:
| Type | Name | What it decides |
|---|---|---|
| MX | @ | Where mail for the domain is actually delivered |
| TXT (SPF) | @ | Which servers are allowed to send as the domain |
| TXT (DKIM) | selector._domainkey | Signs outgoing mail so receivers can confirm it was not tampered with |
| TXT (DMARC) | _dmarc | What receivers do when a message fails those checks |
| CNAME | autodiscover | Lets desktop and mobile mail apps configure themselves |
That is 5 to 8 records that all have to be correct at the same time. Miss one and the symptoms are vague: some mail delivers, some does not, and the customer has no idea the DNS is the reason. When people are asked to enter this by hand, drop-off runs past half. The ones who push through are the ones you should worry about most, because a confident wrong answer here is worse than giving up.
The SPF trap, and how we avoid it
SPF has a rule that catches almost everyone: a domain is allowed to have exactly one SPF record. Not one per sender. One, total.
The single-SPF-record trap
A customer already sends mail through a major email provider for their day-to-day inbox. They now want transactional mail from your platform too. The naive move is to add a second SPF record for your servers. That second record does not add permission. It invalidates the whole thing, and the mail they were already sending starts failing checks.
Custom Domain does not add a second SPF record. It reads the existing one and merges your send permission into it, so the customer keeps every sender they already had and gains yours. One valid record, both services authorized, nothing broken. The customer never learns SPF exists, which is exactly the point. If you want to see how a one-click connection handles this, the merge happens before a single record is written.
DMARC gets the same care. When setup runs, we place the DMARC record with awareness of what is already there, so re-running the flow does not stack up duplicate policy records. Duplicate DMARC records make enforcement unpredictable, and unpredictable is the last thing you want from the record that decides whether real mail gets thrown away.
The dangerous setups are not the ones that fail. They are the ones that half-work, on a domain that was already sending mail.
A policy that protects mail on day one
There is a temptation to start DMARC at its strictest setting and reject anything that fails. On a domain with real senders, that is a way to instantly block legitimate mail from a service you simply have not authorized yet.
So the sensible starting policy is quarantine, not immediate reject. Failing mail goes to spam rather than vanishing, which gives the domain room to bring every legitimate sender into the fold before the door slams shut. It is the difference between tightening deliverability and severing it. Getting this right from the first record improves how the domain's mail is treated straight away, instead of setting a trap that springs three weeks later.
Quarantine first, reject later
Start DMARC at quarantine so failing mail goes to spam rather than vanishing. That gives the domain room to bring every legitimate sender into the fold before enforcement tightens.
Auto-discovery is the quiet win in all of this. With those records in place, the customer's mail apps configure themselves. No copying server hostnames, no guessing at port numbers, no support ticket that starts with "my email will not connect on my phone."
What the customer actually does
They click connect and approve one screen. Everything hard happens on the other side of that click.
- Detect the provider. Their DNS provider is identified automatically, no hunting for a zone editor.
- Write the full set. MX for routing, SPF merged rather than overwritten, DKIM for signing, DMARC placed without conflict and set to a safe policy, and auto-discovery so their clients set themselves up.
- Confirm it is live. The records resolve correctly, and none of the SPF or DKIM landmines were ever theirs to step on.
It takes seconds. When the DNS step disappears, email stops being the setup you dread supporting. Your customers connect a domain in one click and get mail that is authenticated and deliverable from the first message, on a domain that keeps sending everything it was already sending. The hardest task on the list becomes the one nobody has to think about, and that is what it should have been all along.
Custom domains, on autopilot
Let your customers connect their own domain in one click. We detect their DNS provider, write MX, SPF, DKIM, DMARC, and auto-discovery correctly, merge instead of overwrite, verify ownership, and issue HTTPS, while they just approve one screen.
Get started