SPF, DKIM, and DMARC: what each one does
Email authentication is boring in the same way a seat belt is boring: it matters most when something is trying to break. SPF, DKIM, and DMARC are the three records that tell receiving mail servers whether a message is allowed to speak for your domain, whether it was altered in transit, and what to do when a message fails those checks.
If you want the vendor definitions, start with the official references from RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. If you just want the useful version, keep reading.
Why these records affect deliverability
Mailbox providers do not trust a message because it sounds professional. They trust it because the infrastructure checks out. Google’s SPF guidance and Microsoft’s DMARC configuration docs both point to the same ugly truth: if your domain has no authentication, or has it configured badly, mail can land in spam, get rewritten, or get rejected outright.
That hurts password resets, invoices, contact forms, and any email from your business that needs to be seen as real. In other words, the stuff you actually care about.
SPF: which servers are allowed to send
SPF is the permission list. It tells the world which mail servers are allowed to send on behalf of your domain. If a server is not on the list, the check can fail.
- Use SPF to authorize your mail provider and any other approved sender.
- Keep the record short and accurate.
- Do not add random services “just in case.” That is how people create a future problem for themselves.
Most setup guides start with the domain registrar or DNS host. If you need a plain-English reminder of where these records live, the Domains & DNS page explains the control point, and Website Hosting covers the basic hosting side of the house.
DKIM: proving the message was not tampered with
DKIM signs outgoing mail with a cryptographic signature. Receivers check the signature against the public key in DNS. If the message was altered after signing, the signature no longer matches. That is the point.
DKIM is one of the cleanest ways to prove the message really came through the path you intended. It is also the step most people skip until a deliverability problem becomes impossible to ignore.
- Create the DKIM key in your mail system or hosting control panel.
- Publish the public key in DNS exactly as your provider specifies.
- Send a test message and confirm the signature passes.
If you need help finding the right menu, use the Control Panel rather than guessing your way through six different admin screens like a trapped archaeologist.
DMARC: the policy layer
DMARC ties SPF and DKIM together. It tells receiving servers what to do when authentication fails: monitor, quarantine, or reject. It also gives you reporting so you can see who is sending mail using your domain.
Start gently. A DMARC policy of p=none lets you collect reports without blocking messages while you clean up SPF and DKIM. Once the legitimate senders are aligned, move toward quarantine and then reject if the reports stay clean.
For domain-level policy and reputation hygiene, Cloudflare’s DMARC record guide is a practical reference.
A simple setup order that does not waste your afternoon
- Inventory every sender. List your website forms, mailboxes, newsletters, ticketing tools, and any app that sends on your behalf.
- Set SPF first. Authorize only the senders you actually use.
- Enable DKIM. Turn on signing for each legitimate sender.
- Add DMARC in monitoring mode. Start with reports, not punishment.
- Review reports. Fix the senders that are failing or missing.
- Tighten the policy. Move from none to quarantine, then reject when the reports are stable.
This is the first diagnostic step I would run before changing anything else: identify every system that sends mail from your domain. Most broken email setups are not broken by one protocol. They are broken by an unloved app nobody remembered existed.
Common mistakes that cause the usual mess
| Problem | What it looks like | What to check |
|---|---|---|
| Too many SPF lookups | SPF fails even though the sender is legitimate | Shorten the record and remove unnecessary includes |
| Multiple SPF records | Validation fails or behaves unpredictably | Keep one SPF record per domain |
| DKIM not aligned | Mail signs but still fails DMARC | Check the From domain and signing domain |
| DMARC set too strict too early | Legit messages disappear or get quarantined | Start with monitoring and review reports first |
| Forgotten third-party sender | A CRM or newsletter platform suddenly stops working | Audit every app that sends as your domain |
Troubleshooting when mail still misbehaves
If delivery still looks shaky after setup, rule out the boring things first:
- Does the DNS record exist at the correct domain?
- Did you publish the exact value your provider generated?
- Is the sending service still using the old domain or IP?
- Are you testing with a mailbox provider that actually shows authentication results?
- Did you wait long enough for DNS changes to propagate?
For support when the symptoms are unclear, use Support before you start editing DNS in a panic. Panic is not a configuration strategy.
If you need hands-on help with a hosting plan or domain setup, Contact is the direct path.
Bottom line
SPF answers who may send. DKIM answers whether the message was altered. DMARC tells receivers what to do when the first two checks fail. Put them together, test carefully, and keep your sender list under control. That is how you stop mail from wandering into spam with the confidence of a lost tourist.
Manage hosting email the right way and keep your business messages readable, authenticated, and less embarrassing.