tmailrDeliverability
SPF, DKIM and DMARC in plain English
29 July 2026 · 3 min read · TMailr
Three acronyms guard your domain’s name in other people’s inboxes, and most explanations of them start with the protocol rather than the problem. Start with the problem instead: anybody on the internet can open a connection to Gmail and claim to be sending as you. Nothing in the design of email prevents it. SPF, DKIM and DMARC are three separate attempts to let a receiver work out whether the claim is true.
SPF answers: was this machine allowed to send?
You publish a DNS record listing the servers permitted to send mail for your domain. The receiver looks at the IP address that connected, checks the list, and gets a pass or a fail. That is the whole idea.
The catch is which address it checks. SPF looks at the envelope sender, the address in the SMTP conversation, not the From: line a person reads. Those are frequently different and legitimately so: your marketing platform sends with its own bounce address so that bounces come back to it. SPF passes for that platform’s domain, and the reader never sees that domain at all.
The other catch is the ten-lookup limit. Every include, a, mx, ptr, exists and redirect in your record costs a DNS lookup, and so does everything inside the records they point at. Go over ten and the result is not a fail, it is a permanent error, which many receivers treat as no SPF at all. Records drift over this limit slowly, one supplier at a time, and nothing tells you the day it happens.
DKIM answers: has this message been altered?
Your sending server signs the message with a private key and publishes the public half in DNS. The receiver recomputes the signature over the headers and body it received. If they match, the message is byte-for-byte what was signed, and it was signed by somebody holding your key.
DKIM is the more useful of the two because it survives forwarding. SPF breaks the moment a message is relayed, because the relaying server is not on your list. A DKIM signature keeps validating as long as nothing rewrites the signed parts, which is exactly why a forwarder that adds a footer or rewrites links destroys the thing that was protecting the mail.
DMARC answers: do those results belong to the name I can see?
This is the part people skip, and it is the part that matters. SPF and DKIM both pass for a domain. DMARC asks whether that domain is the one in the From: header the reader actually looks at. That question is called alignment, and without it the other two prove very little: a spammer can pass SPF for their own domain all day while writing your name in the From: line.
Alignment comes in two strengths. Relaxed, the default, accepts a subdomain: bounce.example.com aligns with example.com. Strict demands an exact match. Relaxed is right for nearly everyone, and the common mistake is not choosing wrongly between them but assuming that a difference in domains means a failure, when under relaxed it usually does not.
DMARC also lets you state what a receiver should do when nothing aligns: p=none to watch, p=quarantine to send to spam, p=reject to refuse. And, more valuable than the policy itself, rua= gives you a reporting address so you can see who is sending as you before you decide.
The order to do this in
- Publish DMARC at p=none with a rua address. You learn who sends as you and break nothing.
- Read a few weeks of reports. Every legitimate sender you had forgotten shows up here.
- Fix the senders that do not align, usually by signing with DKIM on a subdomain you control.
- Move to quarantine, then reject, once the reports are clean.
What passing actually means
All three passing does not mean the message is honest, and none of them read the content. They establish that a domain took responsibility for a message. That is a smaller claim than it sounds, and it is still the foundation everything else rests on, because a receiver that cannot tell who sent something has nothing to build a reputation on.
If you want to see what your own mail looks like on arrival, send one message to a disposable address and read the Authentication-Results header the receiving server wrote. It records what a real receiver concluded, which is worth more than what your configuration says should happen.
More on deliverability
