SPF vs DKIM vs DMARC: Email Authentication Explained

SPF, DKIM, and DMARC are three DNS-based authentication protocols that work together to prove an email actually came from who it claims to. SPF lists which servers can send for your domain; DKIM cryptographically signs each message; DMARC tells receivers what to do when SPF or DKIM fail. Skip one and your deliverability suffers.

If you've ever wondered why one of your campaigns landed in spam while another one (same copy, same list, same send time) hit the inbox cleanly, authentication is usually the answer. Google's 2024 sender requirements now force bulk senders (5,000+ messages a day to Gmail) to pass SPF or DKIM alignment and publish a DMARC record, per Google's official guidance. Yahoo rolled out the same rules in February 2024. And according to Valimail's 2024 email fraud research, only about 33% of the world's domains with a DMARC record have it set to enforce (quarantine or reject), meaning the other two-thirds are publishing authentication records that don't actually do anything yet.

This guide walks through each protocol on its own, then shows how they stack. By the end you'll know which record lives where, what each one protects against, and why running just one or two leaves gaps an attacker can drive a truck through.

What is email authentication, and why do you need three protocols?

Email authentication is the set of DNS records (and cryptographic signatures) that let a receiving mailbox provider verify that a message really came from the domain in the From: header. Without it, anyone can forge your domain; with it, spoofed mail gets rejected before it ever reaches a recipient.

You need three protocols (not one) because each solves a different piece of the problem. SPF checks the server's IP address; DKIM checks the message contents haven't been altered; DMARC ties the two together and tells receivers what policy to apply when something looks off. One without the others leaves a gap.

The original SMTP spec from 1982 (RFC 821) had no authentication at all. It trusted whoever connected. That's why phishing became trivial; all three of these standards were retrofits, added over two decades, to patch what SMTP never had. The Anti-Phishing Working Group's Q4 2023 trends report counted 1,077,501 phishing attacks in a single quarter (the second-highest ever recorded), and most of them relied on spoofing a domain the victim trusted. If that domain had a strict DMARC policy, the phish would've been dropped at the gateway.

[ORIGINAL DATA: percentage of Mailneo customer domains with all three configured correctly when they onboard vs. after our setup wizard runs]

What is SPF and how does it work?

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

If the IP matches, SPF passes. If not, SPF fails (or soft-fails, depending on how you wrote the record). The receiver then uses that result as one signal; on its own, SPF doesn't decide what happens next. That's DMARC's job.

SPF was standardized in RFC 7208 (updated as RFC 7208 in 2014, replacing the original RFC 4408). 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, and treat everything else as a soft-fail (~all). You can use -all for a hard-fail, which tells receivers to reject anything from an IP you didn't authorize.

SPF's biggest limitation is the 10-DNS-lookup limit baked into the spec (RFC 7208 §4.6.4). Every include: directive counts; chain too many ESPs, analytics tools, and survey platforms and you blow past the cap, which invalidates the whole record. We see this constantly with Mailneo customers who've added six or seven SaaS tools over a few years without auditing.

The other limitation (bigger, honestly) is that SPF breaks when messages are forwarded. If someone on your list forwards your newsletter to a different address, the forwarding server becomes the sender, but the original From: header still points at you. SPF fails; the forward ends up in spam. That's one reason DKIM exists.

Need to build one cleanly? The Mailneo SPF generator handles the syntax and checks your lookup count, and what is SPF goes deep on the record mechanics.

What is DKIM and how does it work?

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 the signature. If the signature checks out, nothing in the message was altered in transit.

Unlike SPF, DKIM survives forwarding (mostly). The signature travels with the message; as long as the forwarding server doesn't rewrite headers or body, DKIM still verifies at the final destination. That's its superpower.

DKIM was defined in RFC 6376 back in 2011. The public key lives at selector._domainkey.yourdomain.com as a TXT record, where selector is a label you choose (typical ones: google, mailneo1, s1). You can (and should) rotate selectors periodically; most mature senders rotate annually or after a suspected compromise.

A DKIM 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...

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

DKIM's honest downside: key length matters. M3AAWG's 2019 sender best practices flagged 1024-bit keys as insufficient and recommended 2048-bit minimum; a lot of older setups still ship weak keys because the original DNS record size limits made 1024 the easy default. If you're still running 1024-bit, rotate. Our DKIM generator defaults to 2048, and what is DKIM covers the setup flow end-to-end.

DKIM says "this message wasn't tampered with and the signing domain vouches for it." It doesn't say the signing domain is the same as the From: domain the reader sees. That gap is exactly where DMARC slots in.

What is DMARC and how does it tie SPF and DKIM together?

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

Alignment is the concept SPF and DKIM can't enforce on their own. A spammer can pass SPF for sneakydomain.com and put yourbank.com in the From: line; without DMARC, the receiver sees "SPF passed" and might deliver it. With DMARC, the receiver checks whether the SPF-authenticated domain matches the visible From: domain, and if it doesn't, the message fails DMARC regardless.

DMARC was published as RFC 7489 in 2015. The record is a single 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 important bits:

• p= is the policy: none (monitor only), quarantine (spam folder), or reject (bounce)
• rua= is where aggregate reports go (XML files, daily summaries from each major receiver)
• ruf= is where forensic reports go (per-message samples; most providers don't send these anymore for privacy reasons)
• adkim= and aspf= set alignment mode: s for strict (exact match), r for relaxed (subdomain match OK)

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

Here's the honest part: DMARC is only as strong as the policy you publish. A record at p=none sends reports but doesn't block anything; according to Valimail's 2024 report, roughly 66% of DMARC records worldwide are stuck at p=none, meaning the domains publishing them are getting visibility but no protection. That's the default deployment path (monitor first, enforce second); it becomes a problem when teams set p=none and then never come back to tighten it.

[MY EXPERIENCE: describe a Mailneo customer who had only SPF/DKIM configured, got spoofed, and the DMARC policy move that fixed it — include the spoof volume they were seeing and how quickly it dropped after moving from p=none to p=quarantine]

Our DMARC generator walks you through the policy choices, and what is DMARC goes deeper on parsing the reports.

SPF vs DKIM vs DMARC: side-by-side comparison

Here's the short version in a table. Read across the rows to compare what each protocol actually does.

Dimension	SPF	DKIM	DMARC
What it checks	IP address of the sending server against an authorized list	Cryptographic signature on headers and body	Alignment of SPF/DKIM results with the visible From: domain, plus policy
What it protects against	Unauthorized servers sending as your domain	In-transit tampering and unsigned forgery	Direct-domain spoofing of your From: address
Where the record lives	DNS TXT at the root domain (yourdomain.com)	DNS TXT at selector._domainkey.yourdomain.com	DNS TXT at _dmarc.yourdomain.com
Governing RFC	RFC 7208 (2014)	RFC 6376 (2011)	RFC 7489 (2015)
Survives forwarding?	No; the forwarding server's IP won't match	Usually yes, unless the forwarder rewrites headers	Relies on SPF or DKIM surviving; ARC helps bridge this
Publishes reports?	No	No	Yes; aggregate XML (rua) and forensic (ruf)
How to verify	dig TXT yourdomain.com, or MXToolbox SPF lookup	dig TXT selector._domainkey.yourdomain.com	dig TXT _dmarc.yourdomain.com, plus inspect rua reports
Biggest limitation	10 DNS lookups max; breaks on forwarding	Weak keys (1024-bit); requires rotation	Only works if you actually publish an enforcing policy

[SCREENSHOT: example MXToolbox report showing SPF+DKIM+DMARC all passing for a Mailneo-configured domain, with green checkmarks for each and the actual record values visible]

The email authentication glossary entry has quick definitions if you want to reference any of these terms in a hurry.

How do SPF, DKIM, and DMARC work together in practice?

When a message arrives, the receiving server runs three checks in sequence. SPF validates the connecting IP against the envelope sender's authorized list. DKIM verifies the cryptographic signature against the public key in DNS. DMARC then asks: did either of those pass with a domain that aligns with the visible From:? If yes, the message is authenticated; if no, the DMARC policy fires.

That sequence matters. You can have SPF pass for one domain, DKIM pass for a second domain, and DMARC still fail because neither aligned with the From: domain the user actually sees. Alignment is the whole point of layering DMARC on top.

Here's a concrete example. Say you're sending from hello@yourstore.com through a third-party tool. The tool sends from its own IP, so SPF evaluates against whatever the envelope sender is (often the tool's return-path domain, not yours). DKIM gets signed by the tool, possibly with the tool's d= domain. Both pass technically. DMARC then checks: does the SPF domain match yourstore.com? Does the DKIM d= match yourstore.com? If both are pointing at the tool's domain instead, DMARC fails alignment and the policy fires.

The fix (and this is where most setup tutorials skip ahead) is custom return-path and custom DKIM. Your ESP has to sign with a d= that matches yourstore.com, usually via a CNAME you add to DNS, and your return-path needs a subdomain of yourstore.com (like bounces.yourstore.com) that CNAMEs to the provider. Now both SPF and DKIM align with yourstore.com, 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." That's almost always alignment, not the underlying records.

A quick note on ARC (Authenticated Received Chain): when messages pass through mailing lists or forwarders that modify headers, both SPF and DKIM can break even when the original was clean. ARC, defined in RFC 8617, lets each intermediary vouch for what they saw, so the final receiver can reconstruct the original authentication result. Gmail and Microsoft both honor ARC. It's not a replacement for DMARC; it's a bridge for the forwarding edge case.

Our step-by-step SPF, DKIM, and DMARC setup guide walks through the DNS changes for each major ESP, and the deliverability guide covers what comes next once authentication is clean (warmup, list hygiene, engagement signals).

What happens if you only set up one or two?

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

If you configure SPF and DKIM but skip DMARC, you've bolted the front door but left the side window open. Both checks can pass against domains that aren't yours, and receivers have no instruction on what to do with mail that claims to be from you but isn't. The whole point of DMARC is alignment plus policy; without it, the other two are just signals receivers can ignore.

If you configure DMARC but your SPF or DKIM isn't aligned, you'll get reports showing your own legitimate mail failing, which is how most teams discover the alignment problem in the first place. (That's also why starting at p=none exists; you can see what's broken before you break anything.)

And if you publish DMARC at p=none and then stop, you get the worst of both worlds: the appearance of protection without any actual enforcement. M3AAWG's authentication best practices are blunt about this: the point of deployment is to reach p=reject. Anything less is a waypoint, not a destination.

One more consideration: BIMI (Brand Indicators for Message Identification), which puts your logo next to 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; there's no shortcut. See what is BIMI for the full requirements and the VMC cost trade-off.

Key takeaways

• SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) solve different problems; running one or two leaves measurable gaps that phishers exploit.
• Only about 33% of DMARC-publishing domains actually enforce a policy, per Valimail's 2024 research; the other 66% are monitoring without protecting.
• Alignment (DMARC's core requirement) is the step most setup tutorials skip, and it's the top reason senders see "SPF and DKIM pass" but DMARC still fails.
• Gmail and Yahoo now require DMARC for bulk senders (5,000+ messages/day to their platforms) as of 2024; non-compliance rate-limits or blocks the sender.
• Published DMARC at p=none is a starting point, not a destination; M3AAWG's guidance calls p=reject the goal.

Frequently asked questions

Do I need all three, or is one enough?

You need all three. SPF alone breaks on forwarding and doesn't protect headers; DKIM alone doesn't check alignment with the visible From: domain; DMARC alone does nothing without SPF or DKIM to evaluate. They're designed to stack.

Which one should I set up first?

SPF, then DKIM, then DMARC at p=none for monitoring. That order lets you build authentication underneath before publishing a policy that references it. Moving to p=quarantine and then p=reject should come after 2–4 weeks of clean DMARC reports.

Why does my DMARC fail even though SPF and DKIM both pass?

Almost always alignment. Your ESP is probably signing DKIM with its own domain and using its own return-path for SPF, so both pass against the ESP's domain but neither matches your visible From: domain. The fix is custom DKIM (CNAME to your provider) and custom return-path on a subdomain of your own domain.

Can small senders ignore this?

Not anymore. Google's 2024 bulk sender rules apply at 5,000 messages/day, but Gmail has been using authentication as a ranking signal for all senders for years, per Google's sender guidelines. Unauthenticated mail gets scored worse regardless of volume. Five-minute setup, meaningful lift.

How do I verify my records are working?

Run dig TXT yourdomain.com, dig TXT selector._domainkey.yourdomain.com, and dig TXT _dmarc.yourdomain.com to confirm each record resolves. Send a test to check-auth@verifier.port25.com or use MXToolbox's SuperTool; both return a pass/fail for each protocol plus alignment status.

Related resources

• What is SPF?: record syntax, lookup limits, and forwarding edge cases
• What is DKIM?: key rotation, selector strategy, and signing scope
• What is DMARC?: policy progression and how to read aggregate reports
• What is BIMI?: the logo-in-inbox spec that sits on top of DMARC enforcement
• How to set up SPF, DKIM, and DMARC: step-by-step DNS setup by ESP
• Email deliverability guide: what to fix after authentication is clean
• SPF generator, DKIM generator, DMARC generator: build records with validation
• Glossary: SPF, DKIM, DMARC, email authentication