SPF, DKIM, and DMARC Explained for Normal People
SPF, DKIM, and DMARC in plain English: what each DNS record does, the order to add them, and how to test that email authentication passes.
By Matthew Zhao · Editor, Hosted EZ
SPF, DKIM, and DMARC are the three DNS records that tell the world which servers may send email for your domain — and in 2026 the big inbox providers increasingly refuse mail that fails them. This guide explains what each record does in plain English, the order to add them, and how to test that your email authentication actually passes.
Read how to choose a web host if you are still picking the broader setup, and our guide to migrating hosts without downtime before changing live infrastructure.
Email authentication is a DNS problem
Treat email delivery as a DNS and reputation problem as well as a mailbox problem. A message can leave your site and still fail authentication, get filtered, or arrive at the wrong service.
The short version: an SPF record lists the servers allowed to send for your domain. A DKIM record publishes a key so receivers can verify a message was really signed by your domain and not altered on the way. A DMARC policy tells receivers what to do when a message fails the other two — and where to send you reports about it.
Before you edit SPF, DKIM, or DMARC records
List every sender before you edit MX, SPF, DKIM, or DMARC. That includes newsletters, forms, invoices, help desks, and staff mail. A record that fixes one sender can break another.
Set them up in order: SPF and DKIM first, then a DMARC policy of p=none while you read the reports, and only then tighten to quarantine or reject. Record the current value of anything you change — DNS has no undo.
SPF has a sharp edge worth knowing before you edit: receivers follow at most ten DNS lookups when checking the record. Every include: for a mail service costs at least one, and services that include others underneath can quietly cost several. Cross the limit and SPF stops evaluating — mail that should pass starts failing with a permanent error. If your record has accumulated years of services, count the lookups before adding another.
Test with a real message and read the headers
Test with a real message after each change and inspect the received headers. The inbox is the final result, but the headers tell you why a provider accepted or distrusted the message.
If a DNS record is involved, note the TTL and give the old answer time to expire before concluding the change failed. Send to an account at another provider rather than from your domain to itself.
When to stop and ask for help
Stop when the next action could change production mail or remove access to the account. Send support the domain, the sending service, time in UTC, and the exact record you changed, but never private keys or passwords — a DKIM private key especially.
The SMTP standard has useful background on how mail actually moves between servers. Use it to understand the terms, then return to the small, reversible next step.
A sensible maintenance habit
Keep a dated note of your sender list and the current records. Email authentication breaks quietly when someone adds a new newsletter tool and forgets the SPF record — the note is how you catch it before your invoices start landing in spam.
Keep the change auditable
Record each DNS edit with its old value, the time, and the test result. If you tighten the DMARC policy, note the date — a spike in failure reports afterward is signal, not noise.
Do not confuse the DNS dashboard with delivery. The panel accepting a record is not a mailbox accepting your message; send a real test from outside and read the headers.
If you hand the work to someone else, give them the sender list and the record history rather than a conclusion. "Email goes to spam" is hard to investigate; a dated record change and a failed header is a starting point.
One last check
After everything passes, send one message from each sender on your list — the newsletter, the contact form, the invoice system. Passing from your main mailbox proves one path; the form that silently fails SPF is the one that costs you.
Leave a useful handoff
Save the sender list, the final records, and the address that receives DMARC reports. The next person to add a sending service needs exactly that context and nothing else.
Bottom line
SPF, DKIM, and DMARC reward patience: list every sender, add the records in order, keep DMARC at p=none until the reports are clean, and test with real messages. For the wider picture, our email deliverability guide covers what happens after authentication passes.
Frequently asked questions
Do I need SPF, DKIM, and DMARC all at once?
No. Add one at a time, test with a real message, and keep the previous value until each is stable. Start with SPF and DKIM; add DMARC once both pass.
How long should DMARC stay at p=none?
Until the reports are boring. Aggregate reports arrive as XML files at the address in your record — run them through a free DMARC report viewer rather than reading them raw. A few quiet weeks covering a full billing cycle, so invoices and newsletters have all fired at least once, is a reasonable bar in 2026. Then tighten to quarantine, watch again, and only then move to reject.
What should I give support when email fails authentication?
The domain, the sending service, UTC time, the full headers of a failed message, and the records you changed. The headers usually contain the exact reason.
Should I back up DNS records before editing them?
Yes. Copy the current value of every record you touch. The old SPF record is your rollback — DNS has no undo button.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.
