Multi-domain email
Email Hosting for Multiple Domains: The Per-Domain Onboarding Runbook
You just registered a domain for a new project, and you want hello@ on it to work before the excitement wears off. This is the sequence that gets you there — the exact records to add and the one way to prove each is live — written as a runbook you run once per domain and never reinvent.
Most writing about email hosting for multiple domains spends its first half convincing you that one inbox beats many. Take that as read. What follows is only the part you actually repeat: the mechanical loop of bringing a single domain online and verifying it before you trust it with real mail.
Every domain goes through the same four jobs — receive, authorize, sign, set a policy — plus one addressing choice and one round-trip test. Do them in order and a domain is live in minutes. Skip the verify lines and you find out it was broken from an annoyed customer, not from yourself.
The runbook
Copy this into the note where you track your domains and work top to bottom for each new name. Swap in your domain and the target your mail host gives you, and run the VERIFY line before moving to the next step.
PER-DOMAIN ONBOARDING RUNBOOK — run once per new domain
=========================================================
Replace example.com with your domain and mail.host with the
target your mail host gives you. Add each record at your DNS or
registrar, let it propagate, then run the VERIFY line BEFORE you
move on. Nothing is "done" until it is verified.
1 RECEIVE (MX) — point the domain's mail at your inbox
ADD MX @ 10 mail.host.
VERIFY dig +short MX example.com -> lists mail.host
(no dig? nslookup -type=mx example.com)
2 AUTHORIZE (SPF, TXT) — say which servers may send as you
ADD TXT @ "v=spf1 include:spf.mail.host -all"
VERIFY dig +short TXT example.com -> shows the v=spf1 line
then send one test; its headers read spf=pass
3 SIGN (DKIM, TXT) — stamp each message so it can't be forged
ADD TXT SEL._domainkey "v=DKIM1; k=rsa; p=PUBLICKEY"
VERIFY dig +short TXT SEL._domainkey.example.com
send a test; its headers read dkim=pass
4 SET POLICY (DMARC, TXT) — tell receivers what to enforce
ADD TXT _dmarc "v=DMARC1; p=quarantine; rua=mailto:you@example.com"
VERIFY dig +short TXT _dmarc.example.com -> shows v=DMARC1
aggregate reports begin arriving at the rua address
5 ADDRESSING — named boxes, catch-all, or both
DO create you@ billing@ support@ AND / OR
switch ON catch-all so *@example.com all lands
VERIFY mail a made-up name at example.com:
it ARRIVES (catch-all on) or BOUNCES (off) — as chosen
6 ROUND-TRIP — the only test that actually counts
VERIFY from an outside account, send TO you@example.com;
reply, and open the reply's raw headers at the far end:
spf=pass dkim=pass dmarc=pass in BOTH directions
=========================================================
LIVE when step 6 passes both ways. Save the note; reuse per domain.
The shape never changes. The first domain feels like learning; by the third you are pasting records and watching for the word pass.
What each VERIFY line is really telling you
MX (step 1) only proves mail now arrives. That is the half everyone gets right and the half that proves the least — a domain that receives but cannot send cleanly is not hosted, it is parked.
SPF (step 2) is where honesty about "self-hosting" starts. The include: names the provider that actually injects your outbound mail onto the internet; your sending leg genuinely depends on that provider's servers being in the list. If spf=pass does not show on a sent message, that handoff is misconfigured, and no amount of inbound working will fix it.
DKIM (step 3) is the signature that makes a forgery detectable. The SEL is your selector — the label that tells receivers which published key to fetch. The verify line confirming the key resolves is good; a live dkim=pass on a real message is proof.
DMARC (step 4) turns the first two into a rule. Start at p=quarantine, let the rua reports show you who is sending as your domain, then tighten to p=reject once nothing legitimate is failing. Jumping straight to reject on a new domain is how you silently bin your own invoices.
dig line proves it published; pass on a real message proves it does its job.The round-trip is the only test that counts
Steps 1 through 4 can each look perfect in DNS and still fail in practice, because deliverability is judged by the receiver, not by you. That is why the runbook ends with a round-trip: send to the domain from an outside account, then reply, and read the raw headers on both messages. Inbound proves receiving; the reply's headers prove sending. Only when both carry spf=pass dkim=pass dmarc=pass is the domain genuinely online.
Keep this habit per domain and the count stops mattering. The eleventh domain is the same six steps as the first; nothing about the runbook grows with the size of your collection.
What the host can and cannot see
A fair runbook has to be fair about privacy too. With a zero-access design like Blue Folder Mail, inbound mail routes through your own Cloudflare account and is encrypted at rest with a key only you hold, so stored messages are ciphertext the host cannot read. Two honest caveats belong next to that claim: a message arrives as plaintext at the receiving edge and is encrypted once it lands, so there is a brief in-transit window before it is sealed; and outbound mail rides a sending provider, so that leg is not zero-access in the same way storage is. This is a strong model — the host holds no key to your inbox — not a promise of invincibility. Nothing here is "unhackable," and your passkey is still the thing standing guard.
When to re-run the runbook
Multi-domain setups rot quietly. Re-run the relevant steps when:
- You add a domain — all six steps, start to finish.
- You change how you send — a new sending provider means SPF and DKIM (steps 2 and 3) need re-verifying on every domain that uses it.
- Before anything that matters — a campaign or an invoice from a rarely used domain earns a quick step-6 round trip first.
Our email authentication checker runs the step 2–4 verifies for a domain at once, and the DNS tools show exactly what each name is publishing, so the VERIFY lines take seconds rather than guesswork.
- Do I need a separate inbox for each domain?
- No. The entire point of modern multi-domain hosting is one inbox that receives for every domain and sends as any of them. Separate inboxes are the problem, not the solution.
- Will mail from my custom domains land in spam?
- Not if you authenticate. Publish SPF, DKIM, and DMARC for each domain and your mail is treated like any established sender. Skipping those records is the usual cause of spam-foldering.
- Can I add a domain later without redoing everything?
- Yes. Each domain is independent. Adding the fifth or fiftieth is the same short checklist: point MX, publish three auth records, decide on catch-all.
- Is my mail readable by whoever hosts it?
- With a zero-access design, no. Your mail is encrypted at rest with a key only you hold, so stored messages are unreadable to the host. No system can promise the impossible, but the host never holds a key to your inbox.