SPF, DKIM and DMARC: the three records that decide whether your email arrives

The problem all three solve

SMTP, the protocol carrying your email, has no notion of identity. Any machine on the internet can open a connection and claim to be sending on behalf of your domain, and nothing in the original protocol contradicts it. Every anti-spoofing mechanism in email is a later layer bolted on to fix that, which is why there are three of them rather than one.

They answer different questions. SPF answers "was this sent from a machine the domain owner authorised?" DKIM answers "was this message signed by someone holding the domain's private key, and has it been altered since?" DMARC answers "do the answers to those two questions refer to the same domain the reader sees in the From line, and what should I do if not?"

You need all three. Two of them passing while the third fails is the single most common reason a technically correct setup still lands in spam.

SPF: which servers may send

SPF is one TXT record on your domain listing the servers allowed to send mail for it. A receiving server looks it up and checks whether the connecting machine is on the list.

example.com.  IN  TXT  "v=spf1 include:amazonses.com -all"

The mechanisms matter. include: delegates to another domain's SPF record, which is how you authorise a provider without knowing their IP addresses. The final qualifier is the policy: -all means "anything not listed above is a hard fail", ~all means soft fail, and ?all means neutral, which is close to having no policy at all. Use -all once you are confident the list is complete.

Two limitations catch people out. First, SPF is checked against the envelope sender, the address in the SMTP MAIL FROM command, not the From header your reader sees. Those are frequently different domains, which is exactly the gap DMARC exists to close. Second, SPF breaks on forwarding: when a mailing list or a corporate forward relays your message, the connecting server is now theirs and is not in your record, so SPF fails through no fault of yours.

DKIM: the signature that survives forwarding

DKIM signs the message with a private key held by the sending system and publishes the matching public key in DNS. The signature covers the body and a named set of headers, so a receiver can verify both that the signer held the key and that nothing signed has been modified in transit.

The public key lives at a selector-scoped hostname, which is what lets one domain authorise several senders independently:

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

The signature itself rides in a DKIM-Signature header on the message, and includes d= (the signing domain), s= (the selector, telling the receiver which key to fetch) and bh= (a hash of the body). The d= value is the one that matters for DMARC, and it is also the identity most mailbox providers attach reputation to.

Because the signature travels with the message rather than depending on the connecting IP, DKIM survives forwarding. That makes it the more robust of the two, and it is the reason a DMARC policy that relies on DKIM alignment causes far fewer false failures than one relying on SPF.

DMARC: alignment, and what to do on failure

DMARC does two jobs. It requires that a passing SPF or DKIM check refer to the same domain as the visible From header, which is called alignment, and it publishes what a receiver should do when neither aligned check passes.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r"

Alignment is the part people miss. You can have a perfectly valid SPF record that passes and a perfectly valid DKIM signature that verifies, and still fail DMARC, because the domain that passed was your provider's rather than yours. If your envelope sender is bounces@provider.net and your DKIM d= is provider.net, both checks pass and neither aligns with a From address at example.com. Nothing is broken; nothing is authenticated either.

The fix is to have your provider sign with your own domain, which is what a verified sending domain means in practice: their key, published under a selector on your DNS, signing as d=example.com. adkim and aspf control how strict the match must be, with r for relaxed, which permits subdomains, and s for strict, which does not. Relaxed is the right default.

The order to do this in

1. 1Publish DKIM for every service that sends as your domain, signing with d= set to your domain rather than theirs. This is the single highest-value step.
2. 2Publish or fix SPF, listing every sending service, and check you are under the ten-lookup limit.
3. 3Publish DMARC at p=none with an rua address, and give it two to four weeks.
4. 4Read the aggregate reports. Every source that is legitimate but failing alignment needs fixing at the source, not exempting.
5. 5Move to p=quarantine, watch for a couple of weeks, then to p=reject.

If you send bulk and transactional mail from the same domain, consider whether bulk should move to a subdomain such as mail.example.com. Reputation is scored largely per domain, so isolating the mail most likely to attract complaints protects the mail you cannot afford to have filtered. That is a judgement call rather than a rule, and we have written about the trade-off separately.

What the mailbox providers now require

In February 2024 Gmail and Yahoo turned what had been best practice into an entry requirement for bulk senders, defined as roughly 5,000 messages a day or more to their users. The requirements are SPF and DKIM on all mail, a DMARC record at minimum p=none, alignment between the From domain and one of the passing checks, a spam complaint rate kept below 0.3%, and one-click unsubscribe in the RFC 8058 sense on marketing mail.

The complaint-rate threshold deserves attention because it is the one that is not a configuration task. 0.3% is three complaints in a thousand delivered messages, which a poorly targeted send to a stale list can exceed easily. Authentication gets you admitted; complaint rate is what keeps you there.

How day3 handles it

Connect a domain hosted on Cloudflare and day3 publishes the DKIM, SPF and DMARC records for you, then rechecks until the domain verifies rather than asking you to confirm you did it. On any other DNS host you get the exact records to paste. Either way the DKIM key signs with d= set to your domain, so alignment works rather than merely appearing to.

The DMARC record day3 publishes starts at p=none deliberately, for the reason above. Tightening it is your call and your timing, because we cannot see what else sends as your domain and you can.