SPF, DKIM and DMARC explained: the three records that prove your email is yours

What does each of the three actually do?

The clearest way in is a metaphor for a doorman checking guests. SPF (Sender Policy Framework) is the guest list: a DNS record publishing which servers are authorised to send mail for your domain, so a receiver can reject mail from any IP not on the list (EmailSneak, 2026). DKIM (DomainKeys Identified Mail) is a wax seal: it cryptographically signs each outgoing message with a private key, and the matching public key in your DNS lets a receiver confirm the message wasn’t altered in transit and really came from you (EmailSneak, 2026).

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy the doorman follows when something’s wrong. It builds on SPF and DKIM, tells receivers what to do when a message fails — reject, quarantine, or just monitor — and sends aggregate reports back to you showing who is sending in your name (EmailSneak, 2026). All three are DNS TXT records, and since Gmail and Yahoo’s February 2024 rules they are the baseline for reaching the inbox rather than an optional extra — which is why our pillar on whether your email reaches the inbox calls authentication the table stakes.

SPF: which servers may send as you

SPF is a single DNS TXT record listing the servers and IP addresses allowed to send for your domain, and a few rules decide whether it works. There must be exactly one SPF record per domain — two v=spf1 records at the same hostname cause an automatic failure, and the common cause is an administrator adding a new record for a service like Google Workspace instead of editing the existing one (SPFmonitor, 2026). The record is also capped at 10 DNS lookups: each include:, a:, mx: and redirect= counts as one, and exceeding the limit causes a PermError that fails SPF for every message (AI QA Monkey, 2026).

Two properties matter beyond setup. SPF ends in a qualifier — ~all (softfail) or -all (hardfail) — but in practice the difference is small, because major providers follow the DMARC policy rather than the SPF qualifier; the sensible path is ~all during setup, tightening to -all once every legitimate source is in the record (SPFmonitor, 2026). The bigger limitation is that SPF breaks on forwarding: when someone auto-forwards your email, the forwarding server isn’t in your record, so SPF fails — which is precisely why DKIM and DMARC exist to cover the gap (getsliq, 2026).

DKIM: a cryptographic seal on every message

DKIM adds a signature that travels with the message. Your sending service generates a key pair, publishes the public key as a DNS record at selector._domainkey.yourdomain.com, and signs each outgoing email with the private key; the receiver fetches the public key and verifies that the message wasn’t altered and originated from your domain (getsliq, 2026). Unlike SPF, DKIM survives forwarding intact, which makes it the sturdier of the two underlying checks (EmailSneak, 2026).

Three practices keep DKIM healthy. Use 2048-bit keys, now the recommended standard, rather than the older 1024-bit (SPFmonitor, 2026). Use a distinct selector for each sending stream — transactional, marketing, internal — so keys can coexist and a compromise is contained (Mailforge, 2026). And rotate keys once or twice a year, revoking immediately if one is compromised, because a leaked private key lets an attacker forge authenticated mail from your domain until you rotate (PowerDMARC, 2026). A frequent silent failure is publishing the DKIM record but never enabling signing in the admin console, so mail goes out unsigned despite a correct DNS record.

DMARC: tying it to the name people actually see

Here’s the piece that makes the other two count. DMARC requires that at least one of SPF or DKIM passes and that the domain which passed aligns with the visible From address (RedSift, 2026). It does not need both to pass — one aligned pass is enough (Mimecast, 2026).

Alignment is the whole game, because of a gap SPF and DKIM leave open on their own. SPF checks the domain in the hidden Return-Path header, and DKIM checks the domain in its own d= header — both of which an attacker can set to their own domain while putting your domain in the visible From line that recipients read (RedSift, 2026). So a spoofed message could pass SPF or DKIM against the attacker’s domain and still impersonate you. DMARC closes this by insisting the passing check align with the From address, in either relaxed mode (same organisational domain) or strict mode (exact match) (DMARCLY, 2026). Alignment is what turns two technical checks into actual anti-spoofing.

Why authentication can “pass” and still land in spam

The most confusing deliverability failure is the email that passes SPF and DKIM and still gets filtered, and alignment usually explains it. When you send a campaign through a third-party platform that signs and routes under its own domains, your From address can look correct while DMARC alignment quietly fails — and the message goes to spam despite both underlying checks technically passing (EmailSneak, 2026).

The fix is to authenticate every service that sends as you, on your own domain. That means adding each provider’s include: to your SPF record and setting up DKIM signing with your domain rather than accepting the platform’s default, so recipients see “signed by yourdomain.com” instead of “signed by sendgrid.net” (SPFmonitor, 2026). Every marketing tool, CRM, helpdesk and billing system that sends on your behalf is a sending source that has to align, and the ones people forget are exactly the ones that break DMARC.

The DMARC rollout: none → quarantine → reject

DMARC enforcement is a staged rollout, not a switch, and the staging exists to protect your own mail. The reason is that you almost never know every service sending as your domain until the reports tell you, so you monitor first, fix what’s broken, and only then enforce (getsliq, 2026). The stages look like this:

Stage	Policy	What it does	When to advance
1. Monitor	p=none	Collects reports, no delivery impact	After a few weeks of reports, once you’ve found and fixed every legitimate sender
2. Quarantine	p=quarantine (ramp pct 25→100)	Failing mail goes to spam	Once reports are clean at full percentage
3. Enforce	p=reject	Failing mail is dropped outright	The goal — full protection against spoofing

Two cautions frame the whole process. Going straight to p=reject is the number-one mistake, because without a monitoring period you’ll block legitimate mail from services you forgot to authenticate (getsliq, 2026). At the other extreme, leaving p=none permanently is actively dangerous: it gives you visibility with zero protection, so phishing against your domain succeeds while you sit in monitor mode (niche­advertiser, 2026). Done responsibly, the journey to p=reject takes about 90 to 120 days.

Do you need DMARC if you don’t send marketing email?

Yes, and this surprises people. Any domain without an enforced DMARC policy can be spoofed by attackers who send phishing mail that appears to come from you, damaging your standing with recipients and mailbox providers regardless of whether you run campaigns (AI QA Monkey, 2026). Attackers deliberately target domains without DMARC enforcement, because spoofed mail from an unprotected domain is more likely to reach inboxes, and domain-spoofing-based business email compromise is a multi-billion-dollar category (AI QA Monkey, 2026).

The practical implication is that even a domain sending no email should publish a DMARC record at p=reject, declaring that nothing legitimate originates from it. Authentication isn’t only a deliverability tool; it’s a way of defending the name in the From line whether or not you’re using it.

How to check it’s working, and keep it working

Verification is quick. Send a test email and inspect its Authentication-Results header, where you can confirm SPF, DKIM and DMARC each passed, and free checkers from the various providers validate your record syntax, lookup count and key strength in seconds (PowerDMARC, 2026). The ongoing work is reading your DMARC aggregate reports, which arrive as daily XML and are easiest to parse through a reporting dashboard — they reveal unknown or misconfigured senders before those become a problem (RedSift, 2026).

Then it’s maintenance. Update your SPF record every time you add or remove a sending service, since an outdated record causes legitimate mail to fail, and rotate DKIM keys on a schedule (PowerDMARC, 2026). Like the rest of email deliverability, authentication is a foundation you set correctly once and then tend, not a project you finish. It’s the first of the three factors our pillar on whether your email reaches the inbox describes, and it gates the other two: sender reputation and engagement only start to matter once your mail is trusted enough to be judged on them at all.