Three DNS records decide whether your mail arrives with a green tick or a red flag. None of them are complicated on their own. All three have to agree, and all three have to be set up in the right order. This is the order, and this is what each one actually proves.
What SPF proves
SPF (Sender Policy Framework) is a single DNS TXT record on your domain that lists the IP addresses and hostnames allowed to send mail on its behalf. When a receiving server gets a message claiming to be from you@yourdomain.com, it looks up your SPF record, compares the sending IP, and returns pass, fail, or softfail.
SPF proves one thing only: that the sending server is on your allowlist. It does not prove the message is unaltered. It does not prove the visible From header matches the envelope sender. SPF catches spoofers using random IPs, and nothing more.
Three pitfalls that kill most SPF records
- More than ten DNS lookups. SPF resolvers are required to stop at ten lookups and treat anything beyond as a failure. Nested include: statements add up fast. ESP plus CRM plus support desk plus marketing platform, and you are already close.
- Including the wrong sending host for an ESP. Every provider publishes theirs. Most senders forget to update when they add a second provider.
- Using ~all when you meant -all. Softfail is a suggestion. Hardfail is a rule. Receivers treat them very differently.
What DKIM proves
DKIM (DomainKeys Identified Mail) is a cryptographic signature on every outgoing message. The sender signs a canonical version of the headers and body with a private key. The receiver fetches the public key from DNS at a known location (typically selector._domainkey.yourdomain.com) and verifies.
DKIM proves two things SPF cannot:
- The message has not been modified in transit. If a forwarder rewrites the subject line or the body, the signature breaks.
- The message was signed by something with access to your private key. Which should be a very short list.
Rotate, do not delete
DKIM keys should be rotated quarterly, and immediately any time an ESP relationship ends. An unrotated key sitting with a former vendor is a signing credential waiting to be misused.
The clean rotation pattern is selector rotation, not key deletion: publish a new selector with a new key, start signing with the new selector, leave the old selector in DNS for a week while in-flight mail with the old signature finishes delivering, then remove it.
Use 2048-bit keys. 1024-bit keys are tolerated by most receivers but flagged as weak by some, and they will eventually be phased out. Generate at 2048 from the start.
What DMARC tells providers to do
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It ties SPF and DKIM to the From header the recipient actually sees, and it tells the receiving server what to do when either fails.
A DMARC record specifies three things:
- The policy to apply on failure: p=none, p=quarantine, or p=reject.
- An aggregate reporting address (rua=) so receivers can tell you what they are seeing from your domain.
- Optionally, a forensic reporting address (ruf=) for individual failures, when you want the message-level detail.
The policies in plain English
- p=none. Do nothing different, but send me reports about what is failing. This is the monitor phase.
- p=quarantine. Send failing mail to the spam folder.
- p=reject. Bounce failing mail at the gate.
DMARC also enforces alignment. SPF and DKIM each have to pass against a domain that matches, or is a subdomain of, the From header. A message that passes SPF on a third-party domain but uses your From header fails DMARC, which is the whole point. It closes the spoofing gap that SPF alone leaves open.
SPF says where you sent it from. DKIM says it has not been tampered with. DMARC says whether the receiver should trust the first two, and what to do if they disagree.Postelist field notes
Rolling it out without breaking existing mail
The only safe rollout order is SPF first, DKIM second, DMARC in monitor mode third.
- Set SPF, verify it passes. Test from every sending source you know about.
- Set DKIM, verify it passes. Sign from every sending source. Each provider has its own DKIM setup flow.
- Publish DMARC at p=none. Point rua= at a DMARC aggregator you trust. Without an aggregator you will drown in raw XML reports.
- Run monitor mode for at least thirty days. Read the reports. They will surface every sending source you forgot about.
- Fix each failing source, then move to p=quarantine. Watch for another two to four weeks.
- Move to p=reject once the reports show only aligned pass across everything that should be sending as you.
Every team that has moved straight to p=reject at scale has the same story. A forgotten sending source, customers not receiving invoices for a week, an angry audit. Spend the month in monitor.