DMARC vs SPF vs DKIM: What’s the difference and why it matters

Estimated reading time: 6-7 minutes

SPF, DKIM, and DMARC are three email authentication protocols that protect against domain spoofing and phishing.

• SPF verifies that the sending server is authorized to send email for your domain.
• DKIM ensures the message hasn’t been tampered with in transit.
• DMARC builds on SPF and DKIM to tell receiving servers what to do if messages fail authentication.

Together, they form a layered defense for your domain reputation and email deliverability.

Every day, attackers impersonate trusted brands to steal data or trick users. According to industry reports, over 90% of cyberattacks begin with phishing or spoofed email.

By implementing SPF, DKIM, and DMARC, you can ensure only authorized senders can use your domain – protecting your brand, your customers, and your inbox reputation.

These protocols work at the Domain Name System (DNS) level, confirming whether an email truly comes from who it claims to. When all three are correctly configured, they reduce the risk of:

• Spoofed “from” addresses
• Fraudulent invoices and phishing
• Deliverability issues and spam filtering penalties

SPF (Sender Policy Framework) allows domain owners to specify which mail servers are allowed to send email on their behalf.

How it works:

• You publish an SPF record in your domain’s DNS.
• When a receiving mail server gets an email, it checks the domain in the Return-Path (envelope-from) against the SPF record to verify whether the sending IP is authorized.
• If the sending IP matches, the message passes SPF; if not, it fails.

Example SPF record:

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

Pros:

• Easy to implement.
• Effective at blocking unauthorized senders.

Limitations:

• Breaks when messages are forwarded (e.g., through mailing lists).
• Doesn’t verify the message content.

For best practice: Always combine SPF with DKIM and DMARC for full coverage.

DKIM adds a cryptographic signature to your emails to verify that the message wasn’t altered after it was sent.

How it works:

• Your mail server attaches a private-key signature to each email header.
• The receiving server uses your public key (published in DNS) to verify the signature.
• If the signature is valid, the email passes DKIM authentication.

DKIM authenticates the domain listed in the d= field of the DKIM-Signature header, which may differ from the domain visible in the From (header From) address. This distinction becomes important under DMARC, which checks that these domains align to confirm sender authenticity.

Example DKIM record:

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

Pros:

• Confirms message integrity.
• Works even when emails are forwarded.

Limitations:

• Complex to set up for multiple third-party senders.
• Keys must be rotated periodically for security.

For best practice: Use 2048-bit keys and monitor DKIM alignment in your DMARC reports.

DMARC ties SPF and DKIM together under one policy and gives domain owners control over what happens when an email fails either check.

How it works:

• You publish a DMARC record in your DNS specifying how to handle authentication failures.
• The policy can instruct mail servers to:
• Do nothing (p=none)
• Quarantine suspicious messages (p=quarantine)
• Reject failed messages outright (p=reject) - most recommended

DMARC evaluates alignment between the domain in the visible From (header From) address and the domains authenticated by SPF (Return-Path, or envelope-from) and DKIM (d= field in the DKIM-Signature header). Only when at least one of these mechanisms passes and aligns is the message considered authenticated under DMARC.

Example DMARC record:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; adkim=s; aspf=s

Pros:

• Provides visibility via reports (rua and ruf tags).
• Stops domain abuse proactively.
• Improves email trust and brand protection.

Limitations:

• Requires SPF and DKIM to be aligned.
• Full enforcement may initially block legitimate messages if configuration is incomplete.

For best practice: Start with p=none, review reports, and move gradually toward p=quarantine or p=reject.

Think of SPF, DKIM, and DMARC as layers of defense:

1. SPF confirms who’s allowed to send.
2. DKIM confirms what was sent is unchanged.
3. DMARC enforces what happens when something doesn’t match.

Without DMARC, SPF and DKIM operate independently and can be bypassed. DMARC adds the policy logic – closing the loop on sender authentication.

• Publish valid SPF, DKIM, and DMARC DNS records.
• Align sending domains for all outbound systems (e.g., CRM, marketing tools).
• Test configurations using Red Sift’s OnDMARC validator.
• Gradually move from monitoring (p=none) to enforcement (p=reject).
• Review aggregate reports regularly for anomalies.
• Educate internal stakeholders about the rollout to prevent delivery issues.

• Overly broad SPF records: Using too many “includes” can exceed DNS lookup limits (10 max).
• Mismatched DKIM selectors: Causes verification failures across vendors.
• Ignoring DMARC reports: Without analysis, you’ll miss early signs of abuse.
• Skipping enforcement: Leaving DMARC at p=none forever provides no real protection.

• SPF authorizes senders.
• DKIM secures message integrity.
• DMARC enforces policy and provides visibility.
• When deployed together, these standards prevent spoofing, protect brand trust, and improve deliverability.

• Check your DMARC, SPF & DKIM configuration for free
• What Is DMARC?
• What Is BIMI?
• Understanding SPF & DKIM
• Try OnDMARC Free

This article is part of Red Sift’s Email Security Guide series, designed to help security and IT professionals strengthen their domain posture through authentication, reporting, and brand trust frameworks.