SPF, DKIM and DMARC Explained: Fix Email Deliverability in One Afternoon

The short answer

SPF, DKIM and DMARC are three DNS records that together prove an email really came from your domain. SPF lists which servers are allowed to send as you. DKIM signs each message with a private key so the receiver can verify it wasn't altered. DMARC ties the two to the address your recipients actually see, and tells inboxes what to do when neither one lines up. You need all three — SPF and DKIM on their own prove very little, because neither checks the From: address a human reads.

All three are published as TXT records in your domain's DNS. There is no software to install and no cost. An afternoon is genuinely enough.

What each record actually does

• SPF (Sender Policy Framework) — a single TXT record at your root domain naming the servers permitted to send mail for it. The receiving server compares the sending IP against that list. SPF checks the hidden envelope sender (the Return-Path), not the visible From: address.
• DKIM (DomainKeys Identified Mail) — your mail provider signs every outgoing message with a private key and publishes the matching public key in DNS under a selector. The receiver fetches the key and verifies the signature, which proves both who sent the message and that the body and headers weren't modified in transit.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — a policy record at _dmarc.yourdomain.com that does two things SPF and DKIM can't: it requires the domain that passed SPF or DKIM to match the visible From: address (this is called alignment), and it tells the receiver what to do when nothing matches — nothing, quarantine, or reject.

Alignment is the part that makes DMARC worth doing. Without it, a spammer can send from a domain they control, pass their own SPF and DKIM perfectly, and still put your brand in the From: field. DMARC is what closes that gap.

The records, ready to copy

Replace the placeholders and publish each one as a TXT record at your DNS host. SPF and DMARC are yours to write; DKIM is generated by your mail provider, so you copy rather than compose it.

Why Gmail and Yahoo made this urgent

Since February 2024, Gmail and Yahoo have required anyone sending more than 5,000 messages a day to personal accounts to authenticate with SPF, DKIM and DMARC, keep their spam complaint rate below 0.3%, and offer one-click unsubscribe (RFC 8058) in marketing mail. Microsoft applied effectively the same rules to Outlook.com, Hotmail and Live from 5 May 2025.

Two things about that threshold get misread. First, it counts messages to personal mailboxes on that provider, not your total send. Second, the requirements below the threshold are softer, not absent — unauthenticated mail from a small domain still lands in spam far more often, it just isn't rejected outright. If you send any transactional mail at all, treat the bulk rules as the standard.

The rollout: none → quarantine → reject

Do not publish p=reject on day one. DMARC enforcement applies to every system that sends as your domain, and almost every organisation has forgotten one — an invoicing tool, a CRM, a help desk, an old marketing platform nobody logs into. Jumping straight to reject makes that mail vanish silently.

The sequence that works: publish p=none with a rua address and collect aggregate reports for two to four weeks. Those XML reports name every IP sending as you, so use them to find the systems you forgot and add each to SPF or DKIM. When the reports show your legitimate mail passing and aligning, move to p=quarantine — failures go to spam, where you can still retrieve them. Sit there for another few weeks, confirm nothing legitimate is landing in the quarantine bucket, then move to p=reject. The pct tag lets you apply a new policy to a fraction of mail first (p=quarantine; pct=25) if you want an even gentler ramp.

When SPF and DKIM pass but DMARC still fails

This is the single most confusing failure mode, and the answer is always alignment. DMARC doesn't ask "did SPF pass?" — it asks "did SPF pass for the same domain as the visible From: address?"

The usual culprit is an email service provider that sends on your behalf using its own bounce domain. SPF passes, because the envelope sender is the ESP's domain and the ESP's IP is in the ESP's SPF record — but the From: header says your domain, so the two don't align and DMARC fails. The fix is to set up a custom return-path (sometimes called a custom bounce domain or CNAME sending domain) with that provider, and to enable DKIM signing with your own domain in the d= tag. DKIM alignment is generally the more reliable of the two to rely on, because it survives forwarding — SPF usually doesn't, since the forwarding server's IP was never on your list.

How to verify it works

Send a message to a Gmail address you control, open it, and use "Show original". The header panel lists SPF, DKIM and DMARC with a PASS or FAIL for each — that is the receiving server's own verdict, which makes it more trustworthy than any simulation. Check the d= value in the DKIM line matches your domain, not your provider's.

For the DNS side, confirm the records resolve before you blame the mail flow: a DNS lookup on your domain's TXT records will show your SPF record and, at _dmarc.yourdomain.com, your policy. Propagation is usually minutes but can take up to the TTL you set. And if authentication is passing but delivery is still poor, the problem has moved downstream — check that the sending IP's reverse DNS resolves to a matching hostname, which most large receivers treat as a baseline requirement alongside DMARC.

Check what your domain publishes right now

CheckSEO's Email Deliverability Checker queries your live DNS for SPF, DKIM and DMARC in one pass and tells you which of the three is missing, which is present but weak, and what the policy is currently set to — the fastest way to find out whether your afternoon of work is actually live.