SPF, DKIM and DMARC in plain English
29 July 2026 · 6 min read
SPF says which servers may send
A list of IP addresses allowed to send for your domain, published in DNS. The receiver checks the connecting server against it. SPF checks the envelope sender, not the From: line your recipient sees, which is why it can pass on obvious forgeries.
DKIM signs the message
Your server adds a cryptographic signature over chosen headers and the body. The receiver fetches your public key from DNS and verifies it. If either changes in transit, the signature fails.
DMARC ties them to the visible From:
This is the part people miss. DMARC asks: did SPF or DKIM pass **for the domain in the From: header the human sees**? That is called alignment. You can pass SPF and still fail DMARC, if the SPF that passed was for a different domain.
The practical consequence
- Publish all three. Two out of three leaves a gap.
- Start DMARC at p=none and read the reports before enforcing.
- Only one of SPF or DKIM needs to pass and align, which is your safety margin.
- Forwarding breaks SPF by design. DKIM is what survives, so DKIM is what matters most.
Our domain checker reads all three for any domain and tells you which are missing, including the ten-lookup SPF limit that silently breaks records nobody has counted.
More on deliverability
Why forwarded mail lands in spam
Forwarding breaks SPF every single time, by design. What keeps forwarded mail out of the spam folder is DKIM surviving the trip, and that is easy to break.
MTA-STS and TLS-RPT, and when they are worth it
SMTP encryption is opportunistic by default, which means it is trivially downgraded. These two records are the fix, and one of them is nearly free.
Why a good mail server refuses instead of bouncing
Accepting a message you cannot deliver turns you into a spam cannon aimed at whoever was forged as the sender.