SPF, DKIM, DMARC: the three records that decide if your email lands

Three DNS records decide if a receiving mail server trusts your email. SPF says which servers are allowed to send on your behalf. DKIM signs each message so the receiver can verify it was not tampered with in transit. DMARC tells the receiver what to do when SPF or DKIM fails, and where to send the reports.

Most senders have SPF set up. About half have DKIM. A minority have DMARC, and of those, most are stuck on p=none and never move off it. If that's you, your authentication is partial. The receiving server has no idea what to do when a spammer spoofs your domain, and your reputation drifts because of it.

This is the reference. What each one does, the exact records to publish, the order they run in at the receiver, the configuration mistakes that look like they work but do not, and the moves that take you from "delivers most of the time" to "delivers always."

SPF, who is allowed to send

SPF (Sender Policy Framework) is a TXT record at the apex of your domain that lists IP addresses and other domains permitted to send mail with your domain in the SMTP envelope sender.

Example record:

v=spf1 include:_spf.google.com include:mailgun.org ~all

Reading it left to right:

• v=spf1 declares the version. There is no SPF v2 in practice.
• include:_spf.google.com says trust whatever IPs are listed in Google's SPF record. This is how you authorize Google Workspace to send for you.
• include:mailgun.org similarly trusts the IPs in Mailgun's SPF record.
• ~all is the default for everything not covered. ~all is "softfail" (mark suspicious but accept). -all is "hardfail" (reject). ?all is "neutral" (no opinion). Use -all once you are confident the included senders cover everything you actually send.

The key constraint of SPF: each lookup the receiver performs to evaluate your record (every include:, a:, mx, redirect=) counts against a hard cap of 10 DNS lookups. Exceed it and SPF returns permerror and the entire check fails. ESPs that recommend you include their full SPF chain often blow past this limit when you also send from Google, Mailgun, and three internal services. SPF flattening (a service that resolves all the includes once and writes the IPs directly into your record) is the practical workaround.

Five SPF mistakes that look fine until they break:

1. Multiple SPF records on the same hostname. The RFC allows one. If you publish two, validators bail and treat your SPF as missing. Common pattern: someone set up Google's SPF and someone else added Mailgun's as a separate record. Combine them. 2. Including a sender you no longer use. Old SendGrid subaccounts, retired Mandrill instances, an Intercom subscription you canceled. Every retired include is a range of IPs that can spoof you cleanly. 3. Forgetting subdomains. SPF does not inherit. If you send from mail.yourdomain.com and yourdomain.com, both need SPF records, and they can be different. 4. Using +all. This authorizes anyone to send for you. It is a configuration mistake, not a permissive policy. Some open-source mail tools ship it as a default. It is just broken. 5. Trusting your DNS provider's TXT length cap. Some DNS providers silently truncate TXT records past 255 characters per string. SPF records can legally exceed that with multiple quoted strings, but some validators cannot read the truncated form. Test with dig against a public resolver, not just your provider's UI.

DKIM, this message has not been touched

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The receiver looks up your public key in DNS and verifies the signature. If the signature is valid, the message body and the listed headers were not modified in transit and were sent by something that holds your key.

You publish a TXT record at a selector under _domainkey.yourdomain.com. Selectors let you rotate keys without service interruption.

selector1._domainkey.yourdomain.com  TXT
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

Your ESP generates the key pair and gives you the public key to paste into DNS. The selector name is your choice. People use s1, mail, default, or a date-stamped name like goog20240501. Multiple selectors can coexist. Most large senders rotate keys quarterly, leave the previous selector active for a week, then retire it.

DKIM signs a set of header fields plus the body. The list of signed headers lives in the DKIM-Signature header itself. Look at any received message and you will see something like h=from:to:subject:date:message-id. Anything not in h= is not protected. A forwarder can rewrite the Subject without breaking the signature, but the From, To, Date, and Message-ID are typically signed.

Four DKIM mistakes that look fine in DNS but break verification:

1. Truncating the public key. RSA-2048 keys are too long for some DNS interfaces and get split awkwardly. Most providers handle TXT chunking correctly. If yours does not, fall back to RSA-1024 (acceptable but weaker). 2. Selector mismatch. Your ESP signs as s1 but you publish at selector1. The records exist but DKIM still fails because the receiver looks up the selector named in the signature header. 3. Misconfigured CNAMEs. Some ESPs ask you to CNAME the selector to a record they manage. If the CNAME chain breaks anywhere, no record resolves and DKIM fails silently with no useful error. Test from a different DNS resolver than your own. 4. Body modification by mailing-list software. Listservs that prepend "[List Name]" to subjects and append unsubscribe links break the body hash and invalidate DKIM. ARC (Authenticated Received Chain) is the workaround for forwarders that implement it. Not all do.

DMARC, what to do when something does not add up

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It says: when SPF or DKIM fails (or fails to align with the From address), here is what the receiver should do, and here is where to send the report.

Example record:

_dmarc.yourdomain.com  TXT
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r; sp=quarantine

The fields:

• p= is the policy. none, quarantine, or reject. None means no enforcement (monitor only). Quarantine means send to spam. Reject means refuse delivery entirely.
• pct= is the percentage of failing mail to apply the policy to. pct=10 applies the policy to 10% of failing mail and treats the other 90% as p=none. Useful for ramping up.
• rua= is where aggregate (daily roll-up) reports go. Set this. It is the entire point of DMARC for diagnostic value.
• ruf= is where forensic (per-message) reports go. Most major receivers do not send these for privacy reasons. Skip unless your compliance team specifically asks.
• aspf=r and adkim=r allow relaxed alignment. The SPF or DKIM domain has to match the organizational From domain (yourdomain.com) but can be a subdomain. s (strict) requires exact match. Use r unless you have a specific reason.
• sp= is the policy for subdomains. If you do not set it, subdomains inherit p=.

The point of DMARC is alignment. SPF can pass while DMARC fails, because the SPF check looked at the SMTP MAIL FROM (the envelope sender), not the From header recipients see. DMARC requires that one of SPF or DKIM not only pass, but also align with the visible From domain. Without alignment, a sender can pass SPF for bounce.evilsender.com and put your-bank.com in the From header, and it will look authenticated.

The order of operations at the receiver

When mail arrives at a receiving server, the checks run in roughly this order:

1. Connection-level checks: TLS negotiation, IP reputation lookup, PTR DNS, rate limits. 2. SPF check on the connecting IP against the envelope sender's domain. 3. DKIM check on the body and signed headers using the public key from DNS. 4. DMARC check: does SPF pass and align, OR does DKIM pass and align? If neither, apply the DMARC policy. 5. Content evaluation: filters, ML scoring, recipient-specific rules. 6. Delivery decision: inbox, Promotions, spam, or reject.

Authentication is necessary but not sufficient. Passing all three does not guarantee inbox delivery. Failing any of them, especially DMARC enforcement, almost guarantees the spam folder for major mailbox providers.

Where to start if you have nothing

Day 1: Publish SPF with ~all and the senders you actually use today. No more.

Day 2: Have your ESP generate DKIM keys. Publish the selector record. Send yourself a test message and look at the headers. You want to see Authentication-Results: dkim=pass.

Week 1: Publish DMARC with p=none and rua=mailto:dmarc-reports@yourdomain.com. You will start receiving aggregate reports the next day showing what is authenticating and what is not. Use a free service like dmarcian, Postmark's DMARC Digests, or Valimail's free tier to make the XML reports human-readable.

Weeks 2 to 6: Read the reports. You will find services sending as you that you forgot about. HR systems, NPS surveys, calendar invites from a SaaS app, internal Jira mailers, the marketing team's webinar tool. Add legitimate senders to SPF, configure DKIM where you can, and identify spoofers.

Week 6+: Move to p=quarantine with pct=10. Watch your reports for collateral damage. If aggregate reports show your legitimate mail authenticating cleanly, ramp pct= to 50, then 100. Then move to p=reject.

The reason most senders never move past p=none: they never schedule the time to read DMARC reports. Two hours every two weeks for two months is the entire investment.

What changed in 2024 (and why DMARC is no longer optional)

In February 2024, Google and Yahoo started enforcing DMARC for any sender pushing more than 5,000 messages per day to their consumer mailboxes (gmail.com, yahoo.com). No DMARC record at all means deferral or rejection. A p=none DMARC counts as compliant for the threshold but does not protect you from spoofing. Yahoo's enforcement is gentler than Google's. Google's is gentler than the wholesale rejection some predicted, but it is enough to crater open rates for non-compliant senders.

If you send business volume in 2026 and you do not have DMARC at p=quarantine minimum, you are gambling. The cost of getting authentication right is one engineer-week. The cost of getting it wrong is your domain reputation, which takes six months of clean sending to rebuild.

TL;DR

• SPF: which IPs can send for you. One TXT record at the apex.
• DKIM: cryptographic signature on each message. Selector record under _domainkey.
• DMARC: policy plus reports. TXT record at _dmarc. Start at p=none and graduate.
• Alignment matters more than passing. SPF can pass without aligning to the visible From domain.
• Read aggregate reports for two weeks before tightening enforcement.
• Yahoo and Google now require DMARC for senders above 5,000/day to consumer addresses.