DMARC vs SPF vs DKIM Key Differences Explained

Three protocols, one goal: stop email spoofing. Here's exactly what each one does, where they overlap, and how to deploy all three correctly.

Protocol What it checks DNS record type Published at
SPF Sending IP address authorized? TXT example.com
DKIM Message cryptographically signed? TXT selector._domainkey.example.com
DMARC Policy + alignment enforcement TXT _dmarc.example.com

SPF: Authorize Your Sending IPs

SPF (Sender Policy Framework) is a DNS record that lists every IP address and hostname authorized to send email on behalf of your domain. When a receiving mail server gets a message from you, it checks the sending IP against your SPF record. If the IP isn't listed, SPF fails.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all

Breaking this down:

  • v=spf1 — declares this is an SPF record
  • include: — imports SPF records from third-party providers
  • ip4: — authorizes a specific IPv4 address
  • -all — hard fail: reject everything not listed. Use ~all (soft fail) during testing.

Critical limit: SPF allows a maximum of 10 DNS lookups during evaluation. Each include:, a:, and mx: mechanism costs one lookup. Exceed 10 and you get a PermError — SPF fails permanently, regardless of policy. Organizations using Google Workspace + Salesforce + SendGrid + HubSpot routinely hit this limit.

SPF's key weakness: It only checks the envelope From (Return-Path), not the From header that users see in their email client. An attacker can spoof the visible From address while using a domain they control for the envelope From. SPF passes, but the user sees your domain name. This is why SPF alone doesn't prevent phishing.

→ Check your SPF record with our free SPF checker

DKIM: Cryptographic Email Signatures

DKIM (DomainKeys Identified Mail) signs each outgoing email with a private key held by your mail server. The corresponding public key is published in DNS. Receiving servers retrieve the public key and verify the signature, confirming two things: the email came from a server with your private key, and the message body and headers weren't altered in transit.

Your DKIM DNS record looks like this:


google._domainkey.example.com  TXT


v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

The selector (google in this example) lets a domain publish multiple DKIM keys — one per sending service. Each service adds a DKIM-Signature header to outgoing mail specifying which selector to use for verification.

DKIM's key strength: It survives email forwarding. When a server forwards your email, SPF fails (the forwarder's IP isn't in your SPF record). But DKIM's signature is in the message headers and travels with the email intact. This is why DMARC needs both SPF and DKIM — they complement each other's weaknesses.

DKIM's key weakness: It doesn't prevent spoofing on its own. A receiver can verify a DKIM signature from d=evil.com even if the From header says From: [email protected]. DMARC alignment closes this gap by requiring the DKIM d= domain to match the From header domain.

→ Check your DKIM record with our free DKIM checker

DMARC: Policy + Alignment + Reporting

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of SPF and DKIM. It does three things that SPF and DKIM can't do alone:

  1. Alignment: Checks that the domain in SPF or DKIM matches the From header domain that users see. This closes the spoofing gap that SPF and DKIM leave open individually.
  2. Policy enforcement: Tells receivers what to do with messages that fail alignment — none (monitor), quarantine (spam), or reject (block).
  3. Reporting: Sends daily aggregate reports (RUA) showing which servers sent email claiming to be from your domain and whether they passed authentication.

A minimal DMARC record:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

A full enforcement record:

v=DMARC1; p=reject; pct=100; adkim=r; aspf=r;
rua=mailto:[email protected];
ruf=mailto:[email protected]; fo=1

→ Validate your DMARC record with our free DMARC checker

How They Work Together

When a receiving server processes an email from From: [email protected]:

  1. SPF check: Is the sending IP listed in example.com's SPF record? Pass/Fail.
  2. DKIM check: Is the DKIM-Signature header valid? Does the d= domain's public key verify the signature? Pass/Fail.
  3. DMARC alignment: Does the SPF-authenticated domain or the DKIM d= domain align with example.com? At least one must.
  4. DMARC policy applied: If alignment fails, apply p=none/quarantine/reject.
  5. Report generated: Add this message to the daily aggregate report sent to the rua address.

DMARC passes if:

  • SPF passes AND the SPF-authenticated domain aligns with the From domain, OR
  • DKIM passes AND the DKIM d= domain aligns with the From domain

Implementation Order

Always implement in this sequence:

  1. SPF first. Enumerate every service that sends email for your domain (Google Workspace, Microsoft 365, Mailchimp, Salesforce, etc.). Publish a single SPF record with all of them. Stay under 10 DNS lookups — flatten includes if needed.
  2. DKIM second. Enable DKIM signing in each sending service. Each service generates its own key pair and provides the TXT record to publish. Verify signatures are passing before moving on.
  3. DMARC last. Start with p=none and a rua address. Analyze reports for 2–4 weeks. Fix any legitimate senders that fail. Then move to p=quarantine and eventually p=reject.

Validate your email security records

FAQ

What is the difference between SPF, DKIM, and DMARC? ▸
SPF authorizes which IP addresses can send email for your domain. DKIM cryptographically signs emails so receivers can verify authenticity and integrity. DMARC builds on both by defining what to do when SPF or DKIM fails, and sends you reports about authentication results. SPF and DKIM authenticate; DMARC enforces and reports.
Do I need all three: SPF, DKIM, and DMARC? ▸
Yes. SPF alone can be bypassed because it only checks the envelope sender, not the From header users see. DKIM alone doesn't prevent spoofing of the From address. DMARC ties them together with alignment checks and enforces what happens when they fail. Without DMARC, SPF and DKIM don't prevent domain spoofing in phishing attacks.
Can DMARC pass if SPF fails? ▸
Yes. DMARC passes if either SPF or DKIM passes and aligns. If your email is forwarded (which breaks SPF), DKIM can still pass DMARC. This redundancy is exactly why implementing both SPF and DKIM is critical — they cover each other's failure cases.
What is the 10 DNS lookup limit in SPF? ▸
SPF allows a maximum of 10 DNS lookups during evaluation. Each include:, a:, and mx: mechanism counts as one. Exceeding 10 results in a PermError — SPF fails permanently. Organizations using multiple email services (Google Workspace, Salesforce, SendGrid, HubSpot) routinely hit this limit and must flatten their SPF record.
Does DKIM survive email forwarding? ▸
Usually yes. DKIM signs the message body and selected headers. Forwarding preserves both, so the signature remains valid. However, mailing lists that modify the subject line or body (e.g., adding [LIST NAME] prefixes) break the DKIM signature. SPF almost always fails on forwarded mail because the forwarder's IP isn't in the original SPF record.
In what order should I implement SPF, DKIM, and DMARC? ▸
Always: SPF first, DKIM second, DMARC last. SPF and DKIM must be passing and aligned before you enforce DMARC. Start DMARC with p=none to monitor without affecting delivery, analyze reports for 2–4 weeks, fix any legitimate senders that fail, then gradually move to p=quarantine and p=reject.