SPF vs DKIM vs DMARC: How Email Authentication Really Works

SPF says who is allowed to send, DKIM proves a message is authentic, and DMARC ties the two together and tells receiving servers what to do when something looks wrong. They are not the same thing and they are not competitors: they are three layers that work together, and skipping any one leaves your domain exposed to spoofing and your email at risk of landing in spam.

If you set up email for your SaaS and met all three acronyms in a single afternoon, that distinction is the thing you were missing.

SPF: Who's allowed to send from your domain?

SPF (Sender Policy Framework) is an allowlist in DNS. It tells receiving servers: "Here are the IP addresses and mail servers that I authorize to send email from my domain."

Your SPF record looks like this:

v=spf1 include:_spf.sendgrid.net include:_spf.google.com ~all

That include: directive says "trust the SPF records from sendgrid and google." The ~all means "softfail any other IP" (bounce them, but don't reject them outright).

What SPF protects: It stops someone from spoofing the envelope sender; the address that appears in the MAIL FROM command during the SMTP transaction. That's not the visible From: header you see in your email client. It's the technical Return-Path.

What SPF doesn't protect: Your visible From: header. You can pass SPF while still having a spoofed-looking From: line, because the receiving server never checks if the envelope sender and the From: header come from the same domain.

The weakness: A bad actor can send from your domain (bounce address), pass SPF because they're using an authorized IP, and then put a spoofed From: header in the message. Users see the fake From: but the servers see valid SPF. The envelope and the visible identity don't match.

That's where alignment comes in; and where DKIM and DMARC fix the problem.

DKIM: Cryptographic proof that the message is genuine

DKIM (DomainKeys Identified Mail) cryptographically signs the message. It's like putting your GPG signature in an email header.

When you enable DKIM, your mail server signs outgoing messages with a private key. The public key lives in DNS:

selector._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIGfMA0GCS...

The receiving server pulls that public key from DNS, decrypts the DKIM-Signature header in the message, and verifies that the message wasn't modified in transit.

What DKIM protects: Message integrity and authorization. If I sign a message as mail.example.com, I'm saying "example.com authorized this message." If the message is modified by a middleman after signing, the signature breaks.

What DKIM survives: Forwarding. If you forward a DKIM-signed email to someone else, the DKIM signature stays valid (as long as the forwarding server doesn't modify the body or headers). SPF breaks on forwarding because the forwarded message comes from the forwarding server's IP, not yours.

The selector: That selector._domainkey part matters. You can have multiple DKIM selectors (e.g., april2026._domainkey.example.com and may2026._domainkey.example.com) to rotate keys without breaking messages in flight. Most ESP guides will tell you which selector to use.

DMARC: Policy + alignment enforcement

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It reads the results of SPF and DKIM, checks if either one aligns with the From: header domain, and then applies a policy.

Your DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

DMARC asks: "Did SPF pass AND align with the From: domain? Did DKIM pass AND align with the From: domain?" If at least one passes AND aligns, the message is authenticated. If neither does, the policy (p=) decides what happens.

The policies:

• p=none: Monitor only. Messages that fail still get delivered. Reports arrive at your rua= address. Most people start here.
• p=quarantine: Messages that fail go to spam.
• p=reject: Messages that fail bounce entirely.

Alignment is the crucial part. SPF passes if the sending IP is authorized; but it checks the envelope sender domain, not the From: domain. DKIM passes if the signature is valid; and it can be signed by any domain. DMARC checks if the authenticated result matches the visible From: header that your users see.

Example: You use SendGrid. Your SPF includes SendGrid's servers. An attacker uses a different IP but puts your domain in the From: header. SPF fails (different IP). DKIM fails (not signed by your domain). DMARC checks: neither SPF nor DKIM aligned with the From: header. The policy applies; and with p=reject, the message bounces.

Without DMARC, that message might still reach your user if the receiving server checked SPF loosely or didn't care about the From: header mismatch.

Why you need all three

Mechanism	Checks	Protects against	Limitation
SPF	Sending IP is authorized	Spoofed envelope sender	Doesn't protect visible From: header; breaks on forwarding
DKIM	Message signature is valid and domain-signed	Message tampering, lack of authorization	Can be signed by unrelated domains; doesn't enforce alignment
DMARC	SPF/DKIM result aligns with From: header; applies policy	Spoofed visible From: header	Requires SPF and DKIM to be set up first

SPF alone means "your IP is OK, but I'm not checking the From: header."

DKIM alone means "the message is signed, but I'm not checking if the signature domain matches the From: domain."

DMARC says "the From: domain must be backed by SPF or DKIM. If not, here's what I do."

They're not competitors. They're layers.

Minimum viable setup

1. Add SPF records for every mail service you use (Resend, SendGrid, AWS SES, etc.).
2. Enable DKIM through your mail provider and add the public key to DNS.
3. Add a DMARC record with p=none pointing reports at your rua= address.

Within a few days, aggregate reports will start arriving. They'll show you if mail from any of your services is failing DMARC (misalignment, bad DKIM config, etc.). Once you're confident everything passes, move to p=quarantine and eventually p=reject.

Use the SPF Checker, Email Authentication Checker, and DMARC Record Checker to verify your setup.

For a deeper dive into aggregate reports and what to do with them, see What's in a DMARC Aggregate Report.

---

Use the Email Authentication Checker to see what your domain's SPF, DKIM, and DMARC records look like right now.