SPF vs DKIM vs DMARC: Email Authentication Explained

SPF, DKIM, and DMARC are three DNS-based authentication protocols that together prove an email came from whoever it claims to. SPF lists which servers can send for your domain; DKIM cryptographically signs each message; DMARC ties the two together and tells receivers what to do when they fail. Skip one and your deliverability suffers in ways that are hard to diagnose from the outside.

If you've ever wondered why one campaign landed in spam while another with the same copy, list, and send time hit the inbox cleanly, authentication is usually the answer. Google's 2024 sender requirements force bulk senders (5,000+ messages a day to Gmail) to pass SPF or DKIM alignment and publish a DMARC record, per Google's guidance; Yahoo shipped the same rules in February 2024.

Why three protocols instead of one

Email authentication is the set of DNS records and cryptographic signatures that let a receiving mailbox provider verify a message really came from the domain in the From: header. Without it, anyone can forge your domain.

Three protocols exist because each solves a different piece. SPF checks the server's IP address. DKIM checks that the message contents weren't altered. DMARC ties those results back to the domain the reader actually sees and tells receivers what policy to apply when nothing matches.

All three are retrofits, because the original SMTP spec from 1982 (RFC 821) had no authentication whatsoever; it trusted whoever connected. Everything since has been an attempt to bolt identity onto a protocol designed without it, which is also why the pieces don't fit together as cleanly as you'd like.

SPF checks the sending server

SPF (Sender Policy Framework) is a DNS TXT record listing the IP addresses and hostnames authorized to send email for your domain. When a receiving server gets a message, it looks up the SPF record of the domain in the Return-Path (the envelope sender) and checks whether the connecting IP is on that list.

If the IP matches, SPF passes. If not, it fails or soft-fails depending on how you wrote the record. Either way SPF is only a signal; on its own it doesn't decide what happens next. That's DMARC's job.

SPF is standardized in RFC 7208. A record looks like this:

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

That says: allow Google's servers, allow Mailgun's servers, treat everything else as a soft-fail (~all). Use -all for a hard fail, which tells receivers to reject anything from an IP you didn't authorize.

SPF's most common failure mode is the 10-DNS-lookup limit baked into the spec (RFC 7208 §4.6.4). Every include: directive counts against it; chain enough ESPs, analytics tools, and survey platforms and you blow past the cap, which invalidates the entire record. We see this constantly with customers who added six or seven SaaS tools over a few years and never audited the result.

The bigger structural limitation is forwarding. If a subscriber forwards your newsletter to another address, the forwarding server becomes the sender while the original From: header still points at you; SPF fails, and the forward lands in spam. That gap is exactly why DKIM exists.

Building one cleanly is a solved problem: the SPF generator handles the syntax and counts your lookups, and what is SPF goes deep on record mechanics.

DKIM signs the message

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. The sending server signs a hash of the headers and body with a private key; receivers pull the matching public key from your DNS and verify it. If the signature checks out, nothing in the message changed in transit.

Unlike SPF, DKIM mostly survives forwarding. The signature travels with the message, so as long as the forwarding server doesn't rewrite headers or body, it still verifies at the final destination.

DKIM was defined in RFC 6376 in 2011. The public key lives at selector._domainkey.yourdomain.com as a TXT record, where selector is a label you pick (google, mailneo1, s1 are typical). Rotate selectors periodically; most mature senders do it annually, or immediately after a suspected compromise.

A signature header looks like this in the raw message:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mailneo.co; s=mailneo1; t=1713345600;
    bh=KfQrEY...; h=From:To:Subject:Date;
    b=RmKoI3n...

d= is the signing domain, s= the selector, bh= the body hash, b= the signature itself. When the receiver pulls mailneo1._domainkey.mailneo.co from DNS, it gets the public key and can confirm the signature covers what it claims to.

Key length is the honest downside. M3AAWG's authentication best practices flag 1024-bit keys as insufficient and recommend 2048-bit minimum, yet plenty of older setups still ship weak keys because early DNS record size limits made 1024 the path of least resistance. If you're still on 1024, rotate. The DKIM generator defaults to 2048, and what is DKIM covers setup end to end.

Here's what DKIM does not say: it doesn't claim the signing domain is the same as the From: domain the reader sees. That gap is precisely where DMARC slots in.

DMARC ties them together with alignment and policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy layer on top of the other two. It does two things: it requires that SPF or DKIM align with the visible From: domain rather than just any domain, and it publishes a policy telling receivers what to do when nothing aligns, plus where to send reports.

Alignment is the concept SPF and DKIM can't enforce on their own. A spammer can pass SPF for sneakydomain.com while putting yourbank.com in the From: line; without DMARC the receiver sees "SPF passed" and may deliver it. With DMARC, the receiver checks whether the authenticated domain matches the visible one, and if it doesn't, the message fails regardless of how many green checkmarks preceded it.

DMARC was published as RFC 7489 in 2015. The record is one TXT entry at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=s; aspf=s;

The parts that matter:

• p= is the policy: none (monitor only), quarantine (spam folder), or reject (bounce)
• rua= is where aggregate reports go, as daily XML summaries from each major receiver
• ruf= is where forensic reports go; most providers stopped sending these for privacy reasons
• adkim= and aspf= set alignment mode, s for strict (exact match) or r for relaxed (subdomain match is fine)

Most domains start at p=none to collect reports without breaking anything, then move to quarantine, then reject once every legitimate sending source is authenticated. DMARC.org's deployment guide walks the progression.

My honest read: a large share of published DMARC records sit at p=none and stay there forever. That's the appearance of protection with none of the substance, and it's the single most common state I find when auditing a new sender's DNS. p=none is a waypoint. If you never come back to tighten it, you've published a monitoring tool and told yourself it was a defense.

The DMARC generator walks through the policy choices, and what is DMARC goes deeper on parsing the aggregate reports once they start arriving.

Side-by-side comparison

The email authentication glossary entry has quick definitions if you need to look up a term mid-setup.

How the three run in sequence

When a message arrives, the receiving server runs three checks in order. SPF validates the connecting IP against the envelope sender's authorized list. DKIM verifies the signature against the public key in DNS. DMARC then asks whether either passed with a domain that aligns with the visible From:. That last step is why SPF can pass for one domain, DKIM for a second, and DMARC still fail.

A concrete example. You send from hello@yourstore.com through a third-party tool. The tool sends from its own IP, so SPF evaluates against its return-path domain rather than yours, and DKIM gets signed with the tool's d= domain. Both pass, technically. DMARC then checks both against yourstore.com; if they point at the tool instead, alignment fails and the policy fires.

The fix, which most setup tutorials skip past, is custom return-path and custom DKIM. Your ESP has to sign with a d= matching yourstore.com, usually via a CNAME you add to DNS, and your return-path needs a subdomain of your own domain (something like bounces.yourstore.com) CNAMEd to the provider. Now both align, and DMARC passes.

Gmail's Postmaster Tools documentation explicitly flags alignment as the common failure mode for senders who have SPF and DKIM configured but still see authentication failures. When you're diagnosing a specific message, pull the raw headers and run them through the email header analyzer; it shows each check and, more usefully, which domain each one passed against.

One note on ARC (Authenticated Received Chain). When messages pass through mailing lists or forwarders that modify headers, SPF and DKIM can both break even though the original was clean. ARC, defined in RFC 8617, lets each intermediary vouch for what it saw so the final receiver can reconstruct the original result. Gmail and Microsoft both honor it. Treat it as a bridge for the forwarding edge case rather than a DMARC replacement.

The step-by-step SPF, DKIM, and DMARC setup guide covers the DNS changes per major ESP, and the deliverability guide picks up where authentication ends.

What breaks when you only do one or two

Configure just SPF and you authenticate sending IPs while leaving every message open to tampering and every forwarded copy likely to fail at the final hop. Attackers can still spoof your From: domain from their own SPF-passing servers, and you have no way to tell receivers to reject what doesn't align.

Configure SPF and DKIM but skip DMARC, and you've bolted the front door while leaving the side window open. Both checks can pass against domains that aren't yours, and receivers have no instruction about mail that claims to be from you but isn't.

Configure DMARC while SPF or DKIM stays unaligned, and you'll get reports showing your own legitimate mail failing. That's uncomfortable, but it's also how most teams discover the alignment problem in the first place, which is the entire argument for starting at p=none.

The cost of getting this wrong shows up in numbers you're already tracking. Unaligned mail gets filtered rather than bounced, so it doesn't dent your delivery rate at all; the damage lands on inbox placement instead, where it's invisible unless you're seed-testing. That's what makes authentication problems so easy to sit on for months.

Worth knowing before you decide p=none is good enough: BIMI, the spec that puts your logo beside authenticated messages in Gmail, Yahoo, and Apple Mail, requires p=quarantine or p=reject as a precondition. If you want the logo, you have to enforce. See what is BIMI for the requirements and the VMC cost trade-off.

Setup order, and whether small senders can skip this

Which one should I set up first?

SPF, then DKIM, then DMARC at p=none for monitoring. That order builds the authentication underneath before you publish a policy that references it. Move to p=quarantine and then p=reject after two to four weeks of clean aggregate reports, not before.

Can small senders ignore this?

Not anymore. Google's bulk sender rules kick in at 5,000 messages a day, but Gmail has used authentication as a ranking input for all senders for years, per Google's sender guidelines. Unauthenticated mail scores worse regardless of volume, and the setup is a single afternoon of DNS work against a permanent lift.