Understanding SPF, DKIM & DMARC

Email authentication is the single biggest lever for inbox placement. Three DNS-based standards work together to prove a message is legitimately from your domain. Get them right and you've earned the receiver's trust before they even open the body. Get them wrong and you're starting every message at a deficit.

SPF — who is allowed to send

A Sender Policy Framework record is a TXT record at your domain root. It enumerates the IPs and hostnames authorized to send mail for your domain. When a receiver gets a message, it does a DNS lookup on the envelope-sender's domain (the Return-Path) and compares the connecting IP against your record. A match passes; a mismatch returns one of softfail, hardfail, or permerror.

Three mistakes account for 90% of broken SPF in the wild:

• Too many lookups. RFC 7208 caps total DNS lookups at 10. Every include:, a:, mx:, exists:, ptr: and redirect= mechanism counts, and nested includes count too. Most large stacks blow past this without realising it. The fix is to remove providers you no longer use and consider an SPF flattener.
• Wrong policy strength. ?all (neutral) and +all (allow everything) are useless and actively harmful. Use -all once you're confident every legitimate sender is covered; ~all (softfail) is fine while you're discovering senders.
• Stale providers. That ESP you stopped using three years ago is still in your record and possibly compromised. Audit it annually.

DKIM — was the message tampered with

DomainKeys Identified Mail signs the headers and body with a private key your mail server holds. The matching public key is published in DNS at <selector>._domainkey.<domain>. Receivers fetch the public key and verify the signature on every incoming message.

A DKIM signature has three things to get right:

• Selector. A label that lets you publish multiple keys (e.g. s2026q1). Always use a fresh selector when rotating.
• Key size. 2048-bit RSA is the modern standard. 1024 still works but is increasingly considered weak. Below 1024 fails outright.
• Headers signed. The h= tag in the signature lists which headers were signed. From, Date, Subject and Message-ID should always be in there.

Rotate keys at least once a year. Use a new selector and publish the new key alongside the old one before you cut over — this avoids dropping signatures during the transition.

DMARC — what to do when checks fail

DMARC sits on top of SPF and DKIM. It does two things: tells receivers what to do when authentication fails, and asks them to send aggregate reports. The policy is published at _dmarc.<domain>.

The critical concept is alignment. DMARC requires that the From-header domain align with EITHER the SPF authenticated domain OR the DKIM signing domain. Either passing is enough. This is why a forwarded message can fail SPF but still pass DMARC if the DKIM signature survived.

The canonical rollout:

1. Publish p=none and a rua= reporting address. Wait two weeks.
2. Read the aggregate reports. Identify every legitimate sender.
3. Fix any senders that aren't aligning.
4. Move to p=quarantine. Wait two weeks.
5. Move to p=reject.

How WillItInbox helps

We run all three checks against your test message and break out the failure reasons — wrong selector, missing alignment, soft vs hard fail — so you know exactly what to change. The recommendations panel sorts authentication issues to the top because, dollar for minute of work, they're the highest-leverage fix you can make.

If you only do one thing

Publish DMARC at p=none with a rua= address today. Even without enforcement, the reports will show you exactly who is sending as your domain — including the spammers and forgotten SaaS accounts you didn't know about.