Self-hosting
Own Your Custom-Domain Email: A Self-Hosted Setup Anyone Can Run
Owning your custom-domain email comes down to four DNS records — and, far more than anyone warns you, the order you add them. One decides where your mail lands; three decide whether the world believes your replies are really you. Add them in the wrong sequence and your own messages look like forgeries for a day while DNS catches up. Add them in the right one and the switch is invisible. Here is that sequence, timed.
You bought the domain, so the name is yours. But if you pointed it at a hosted mail service, the inbox behind the name never was — it lives on someone else's servers, under their rules, billed by the seat. Closing that gap doesn't take a server; it takes four records aimed at infrastructure in your own account. What those records contain is covered in full elsewhere — our Cloudflare email hosting guide and the multi-domain runbook write every value out. This page is about the part those guides take for granted: the sequence you add the records in, and why the wrong one costs you a day in the spam folder.
The order that keeps the switch invisible
Here is the rule the record guides skip. The three authentication records — SPF, DKIM, DMARC — describe how you send; the MX record decides where you receive. Publish them out of order and mail starts arriving at the new front door while your outbound authentication is still settling, so your first replies fail their checks and drop into spam. The fix costs nothing but patience: settle the sending side first, move the receiving side last.
Work straight down this list, and don't start a step until the one above it has propagated.
- A day ahead — lower the MX TTL. Find the MX record you'll be replacing and drop its TTL to 300 seconds. TTL is how long resolvers are allowed to cache a record; lowering it a day before the cutover means the eventual switch spreads across the internet in five minutes instead of the old value's hours. Do this, and nothing else, today.
- Publish SPF. Add the TXT record that authorizes your sending provider. Your live mail is untouched — you're still receiving at the old place — so this is safe to add and leave sitting.
- Publish DKIM. Add the provider's signing key at its selector host. Same story: it only matters once you send, and it does no harm published early.
- Publish DMARC at reporting-only. Start the
_dmarcpolicy atp=none, never quarantine. That asks receivers to report failures without acting on them, so you get a day of watching who sends as your domain and confirming your legitimate mail passes — with zero risk of your own messages being filtered. - Wait a day, and read the reports. Give the three records time to propagate and the DMARC reports time to arrive. Send one test through your provider and confirm its headers read
spf=passanddkim=pass. You can now send as the domain fully — before a single message has been routed to you. - Flip the MX last. Only now repoint the MX at your new receiving endpoint. Because you lowered the TTL yesterday the change spreads in minutes, and because sending was already proven, the first reply out of the new inbox authenticates cleanly — from the outside, nothing broke. If you have a spare domain, rehearse the sequence on it once first.
- Tighten DMARC. A few days on, once the reports show nothing legitimate failing, raise the policy to
p=quarantineand laterreject. This is the one step that belongs at the end: tighten before your mail is proven and you quietly bin your own invoices.
That's the entire trick. Every painful cutover is the same mistake — MX moved first, authentication scrambling to catch up — and every smooth one is this order: sending settled, TTL pre-lowered, MX moved last.
The four records, in one breath
You still need to know what the four are; you just don't need another full value table here, because the siblings linked above already spell every string out. In brief:
- MX, on the domain root — the single receiving record, pointed at your account's routing endpoint. It decides where mail lands.
- SPF, a TXT record on the root — the list of who may send as you.
- DKIM, a TXT or CNAME at your provider's
selector._domainkeyhost — a signature proving each message really came from you. - DMARC, a TXT record on
_dmarc— the policy that ties the other two together and reports anyone impersonating you.
One record for receiving, three for being believed — and the sequence above is simply: publish the three, prove them, then move the one.
What those records set in motion: a privacy-aware receiving walk
The MX record is also where your privacy story begins, so it's worth seeing what happens the moment mail arrives:
- Mail hits the front door. Because your MX points there, a message to any address on
example.comarrives at Email Routing in your account — in plaintext, exactly as it arrives at every mail system, because the protocol delivers readable text. - A Worker seals it. Routing hands the message to a small piece of your code, which locks it to your public key — an open padlock anyone can close, that only the private key on your device reopens — and writes the sealed result to storage.
- Storage holds ciphertext. What rests in your account is scrambled bytes, meaningless without the key that never leaves your device. The platform can't read it; neither can the software's authors.
Here is the honest limit: a message is in plaintext for the instant between landing at the MX and being sealed by the Worker. That window is brief and on infrastructure you control, but it's real — zero-access encryption protects mail at rest, not a message still in flight toward you, and no honest setup calls itself unhackable.
p=none) and let them settle, then flip the MX last so your first reply already authenticates. The MX also marks where privacy begins — mail lands in plaintext for an instant, then a Worker seals it to a key only you hold and stores ciphertext.Why the records forgive everything but order
The reassuring part: mail DNS records don't expire and aren't fragile. Once SPF, DKIM, and DMARC are right they stay right, and a domain set up correctly keeps working untouched for years. There is really only one way to make the switch hurt — doing the steps out of sequence, so that for a day the internet sees mail claiming to be you that your own authentication doesn't yet vouch for. Get the order right and there is no window for a spam filter to catch.
Replying from the exact address
A note that arrives at billing@example.com should answer as billing@example.com, not from a catch-all you'd rather nobody saw. A good setup tracks which address a message landed on and replies from that same face — and because your SPF and DKIM records vouch for the sending provider, that reply authenticates instead of looking forged. The sending still rides that provider's pipes: pushing mail onto the public internet reliably is the one job worth leaving to infrastructure built for it. You own the inbox and the key; you lean on a provider for the last hop.
Doing it once, then again in minutes
The first domain is the only one that feels like work, and even then it's four records in a dashboard, not a server to stand up. The second takes minutes: same records, new name in front, run in the same order. Adding a domain is a DNS change, not a purchase — every domain funnels into the same encrypted inbox for the same flat, low cost.
- Do I need a static server or a VPS?
- No. The receiving code runs as an edge Worker that only executes when mail arrives, so there's no always-on machine to rent, patch, or monitor.
- Can I use as many custom domains as I want?
- Yes. The design puts every domain and every address into one encrypted inbox, with no per-domain fee. Your only recurring cost is the flat, low charge Cloudflare bills for the services it runs on.
- Is my mail truly unreadable to the provider?
- At rest, yes — storage holds only ciphertext sealed to your key. The honest exception is the brief moment inbound mail is in plaintext before it's sealed, and the fact that outbound mail still passes through a sending provider.
- What happens if I lose my key or passkey?
- Because only you hold the key, only you can open the mail — which is the whole point, and also the responsibility. Keep a backup of your passkey the way you'd guard the one spare key to your house.