The email DNS worksheet
One printable page to fill in before a domain sends anything: the literal shape of each record, the order to add them in, and the command that proves each one landed.
Five records decide whether a domain can receive mail and be believed when it sends: MX, SPF, DKIM, DMARC, and, only if your platform asks for one, a tracking CNAME. This worksheet is the single page we fill in before a new domain sends anything. Every record has its literal shape with blanks, the trap that most often breaks it, and one command that proves it landed.
Use it if you are pointing a fresh domain at a mail host, adding a second domain for the newsletter, or auditing a domain that has been sending for two years and has never had its records read aloud. That last case is the one that surprises people. Our own business email setup guide covers the surrounding decisions; this sheet is just the DNS.
Fill it in this order
| Step | Record | Why it goes here |
|---|---|---|
| 1 | MX | Receiving comes first. Domain verification codes, DMARC reports, and every reply need a working inbox to land in. |
| 2 | SPF | Names the servers allowed to send for the domain. Your platform gives you the include. |
| 3 | DKIM | Your provider's setup screen hands you the selector and key. Publish before you send, not after. |
| 4 | DMARC at p=none | Publishing enforcement before SPF and DKIM are correct means quarantining your own mail. |
| 5 | Tracking CNAME | Optional. Only if the platform tracks clicks on a hostname of yours. |
The worksheet
MX. Two rows for most hosts, one priority each, lowest number tried first.
Type: MX Name: @ Priority: ____ Value: _______________________________
Type: MX Name: @ Priority: ____ Value: _______________________________
TTL: ______ Old host's MX records deleted? [ ] yes
The trap: leaving the previous host's MX records in place next to the new ones. Mail then splits across two systems by priority and by luck, and half your inbox is somewhere you are not looking.
SPF. Exactly one TXT record at the root.
Type: TXT Name: @
Value: "v=spf1 include:______________ include:______________ ~all"
DNS lookups used: ____ of 10 Second SPF record on this domain? [ ] confirmed none
Three traps live in that one line. Two SPF records on a domain is a permanent error, not a merge, and receivers treat the error as a failure. Each include, a, mx, exists and redirect costs a DNS lookup against a hard ceiling of 10, and every provider you add spends more of that budget than the single term suggests. A single quoted string caps at 255 characters. Publish ~all and let DMARC do the enforcing; the reasoning is in our SPF reference.
DKIM. A TXT record holding a key, or a CNAME delegating it to your provider.
Type: TXT / CNAME Name: ____________._domainkey
Value: _______________________________________________________
Selector recorded here: ____________ Key length: [ ] 2048 [ ] 1024
Write the selector down. Six months later you cannot check the key without it, and the name is arbitrary: Google Workspace uses google, Microsoft 365 uses selector1 and selector2, plenty of relays use s1. Two senders can sign for the same domain at the same time as long as they use different selectors, which is exactly why selectors exist.
DMARC. One TXT record at the _dmarc label, starting permissive.
Type: TXT Name: _dmarc
Value: "v=DMARC1; p=none; rua=mailto:__________@______________"
Published on: __________ Reports reviewed on: __________
Move to p=quarantine on: __________ Then p=reject on: __________
Start at p=none. It satisfies Gmail's February 2024 bulk-sender requirement and Microsoft's May 2025 one while you read reports and find the sender you forgot about. The dates on that block are the point of the whole record: a DMARC policy nobody escalates is a policy that stops nothing.
Tracking CNAME (optional).
Type: CNAME Name: ____________ (link. / email. / mail.)
Value: _______________________________________________________
Only some platforms use one. It matters because campaign links should resolve on a hostname of yours rather than a shortener, which is a rule our own send templates keep.
Prove each record landed
| Record | Command | Healthy output |
|---|---|---|
| MX | dig +short MX example.com | Your mail host's names, with priorities |
| SPF | dig +short TXT example.com | Exactly one string starting v=spf1 |
| DKIM | dig +short TXT s1._domainkey.example.com | A long p= value (roughly 390 characters means 2048-bit) |
| DMARC | dig +short TXT _dmarc.example.com | v=DMARC1; p=none; rua=... |
| CNAME | dig +short CNAME link.example.com | Your platform's tracking host |
On Windows without dig, nslookup -type=TXT _dmarc.example.com does the same job. With no terminal at all, any web DNS lookup tool reads the same public records. Two habits worth keeping: query a public resolver directly (dig +short TXT example.com @1.1.1.1) so you see what the internet sees rather than what your office router cached, and remember that a record you just replaced can persist for the length of the old TTL. Fifteen minutes of patience beats an hour of debugging a value that is already correct.
How to use it
Print one sheet per domain. Copy the values from your provider's setup screen while it is open, never from memory, then paste them into the registrar in the order above. Wait out the TTL, run the five commands, and only then send a first message: to yourself, opened with the full headers showing, checking that SPF, DKIM and DMARC all say pass. A free scoring tool such as mail-tester.com is a reasonable second opinion before any real send.
Then file the sheet. When mail misbehaves eight months from now, the first question is what changed in DNS, and a dated page with the original values answers it in seconds. When the domain is ready to actually send at volume, the next two sheets are the pre-send checklist and the 28-day warm-up schedule.