SPF, DKIM, DMARC: How Email Authentication Works

What each standard actually does

The three standards solve different parts of the same problem. Knowing what each one proves makes the rest of the configuration intuitive.

How a receiver evaluates an incoming message

When Gmail or Outlook receives a message, it runs all three checks in sequence:

1. SPF check. The receiver looks up the SPF record at the envelope sender's domain (the MAIL FROM in the SMTP transaction, not the From: header users see). It verifies the connecting IP is listed. Result: pass, fail, softfail, or none.
2. DKIM check. For every DKIM-Signature header in the message, the receiver fetches the public key from DNS at the selector specified in the signature, recomputes the hash of the headers and body, and verifies the signature. Result per signature: pass or fail.
3. DMARC check. The receiver looks up the DMARC record at the domain in the visible From: header. DMARC requires that at least one of SPF or DKIM (a) passed and (b) is aligned with the From: domain. If neither aligned-and-passed, the receiver applies the published DMARC policy: none (deliver but report), quarantine (spam folder), or reject (bounce).

The order matters because DMARC is what users actually care about — the visible From: domain is what they see. SPF and DKIM are mechanisms; DMARC is the policy that turns those mechanisms into a defensible claim about the visible sender.

Why SPF alone is not enough

SPF authenticates the envelope sender (the address used in the SMTP MAIL FROM command) — not the visible From: header that recipients see. A phisher can send a message from their own server, set MAIL FROM: bounce@attacker.com (which passes SPF for attacker.com), and put From: ceo@yourcompany.com in the visible header. SPF passes, but the recipient sees a message that appears to come from your CEO. DMARC is the standard that ties SPF's authentication to the visible From: domain.

SPF also breaks on forwarding. When a message is forwarded — through a mailing list, an alias, or a corporate forwarder — the forwarding server connects from its own IP, which is not listed in the original sender's SPF record. SPF fails. DKIM, because it travels with the message body, generally survives forwarding. This is why both are useful: when one fails due to forwarding, the other typically still passes.

Why DKIM alone is not enough

DKIM proves the message was signed by someone who controls the DKIM key for the signing domain. But DKIM places no restriction on who can sign or which servers can send on behalf of a domain — that is SPF's job. An attacker could not forge a valid DKIM signature for your domain (they do not have the private key), but they could send unsigned mail from any IP, and without SPF there is no way to say "only these IPs are authorized to send for our domain."

DKIM also has alignment issues if used in isolation. The DKIM signature can be from any domain (often the email service provider's domain like sendgrid.net), not necessarily the visible From: domain. Without DMARC requiring alignment, a recipient cannot tell whether the DKIM signing domain has any legitimate relationship to the visible sender.

What "alignment" means in DMARC

Alignment is DMARC's key contribution. It requires that the domain in the visible From: header matches (or is a subdomain of, depending on alignment mode) the domain that SPF or DKIM authenticated. Two alignment modes exist:

• Relaxed alignment (default): The Organizational Domain must match. From: news@marketing.example.com aligns with DKIM signed by example.com or mail.example.com — anything under example.com.
• Strict alignment: The full domains must match exactly. From: news@marketing.example.com only aligns with DKIM signed by marketing.example.com exactly.

Most organizations use relaxed alignment because it tolerates legitimate setups where transactional mail is signed by a subdomain (e.g., mail.example.com) but sent from a top-level address (news@example.com). Strict alignment is reserved for high-security domains that never delegate signing.

The rollout strategy that actually works

Going straight to DMARC p=reject on day one is the most common way to break legitimate mail flow. Marketing platforms, support helpdesks, billing systems, monitoring alerts, calendar invites, ATS systems, and HR tools all may send mail from your domain — and you likely do not have a complete list. A safer rollout proceeds in phases:

1. Phase 1 — Discovery (2-4 weeks): Publish v=DMARC1; p=none; rua=mailto:dmarc@example.com. The p=none means "monitor but do not enforce." Aggregate reports from receivers (Gmail, Microsoft, Yahoo, etc.) arrive daily as XML. Parse them with a tool like Postmark's DMARC monitoring or DMARC Digests to see every IP that sent claiming to be your domain.
2. Phase 2 — Align legitimate senders: For every legitimate source identified, ensure either SPF passes and aligns, or DKIM passes and aligns. For third-party services, this usually means adding their domain to your SPF include: mechanism and publishing their DKIM key in DNS.
3. Phase 3 — Quarantine (2-4 weeks): Move to p=quarantine. Failing messages go to spam folders. Continue monitoring reports for any legitimate sender you missed.
4. Phase 4 — Reject: Move to p=reject. Failing messages are bounced. Spoofed mail claiming your domain is now genuinely blocked.

This rollout typically takes two to three months for a medium-sized organization. Rushing it costs you legitimate customer mail; skipping it costs you brand safety.

What the Gmail and Yahoo 2024 requirements actually mandate

The headline requirements that landed in February 2024 apply to any sender sending more than 5,000 messages per day to Gmail or Yahoo users:

• SPF and DKIM must both pass and align for the visible From: domain.
• DMARC must be published at a minimum of p=none. A more restrictive policy is not required.
• One-click unsubscribe via the List-Unsubscribe header (RFC 8058) for marketing mail.
• Spam complaint rate under 0.3% measured over a rolling window.

The 5,000-message threshold is per sending domain to a single mailbox provider — Gmail counts your traffic to Gmail; Yahoo counts your traffic to Yahoo. Smaller senders are technically exempt but face increasing filtering pressure as the requirements normalize industry-wide.

Frequently Asked Questions

Do I need all three of SPF, DKIM, and DMARC?

Yes. As of February 2024, Gmail and Yahoo require all three for any sender exceeding 5,000 messages per day to their users. Even below that threshold, missing any one of the three significantly reduces inbox placement. SPF alone is not enough because it does not survive forwarding; DKIM alone is not enough because it does not control which servers can send for your domain; DMARC alone is meaningless without SPF or DKIM to align against.

What does DMARC do that SPF and DKIM do not?

DMARC adds two things SPF and DKIM lack: domain alignment (it requires the visible From: address to match the domain SPF/DKIM authenticated, preventing spoofed display names) and a published policy (you tell receivers what to do with failures — none, quarantine, or reject). It also enables reporting, so you get aggregate XML reports of every server claiming to send from your domain.

What happens if SPF passes but DKIM fails?

With DMARC enforcing, the message passes if either SPF or DKIM passes AND aligns with the From: domain. If SPF passes and aligns, DKIM failure is tolerated. This redundancy is why both are useful — DKIM survives forwarding (SPF does not), so a message forwarded through a mailing list often loses SPF but keeps DKIM. Either one passing and aligning is enough for DMARC.

Can I start with DMARC p=reject right away?

No. Start with p=none to receive aggregate reports without affecting delivery. Spend two to four weeks reviewing the reports to identify all legitimate sources sending from your domain (transactional providers, marketing platforms, ticketing systems, support tools). After all legitimate senders are aligned with SPF/DKIM, move to p=quarantine for a few weeks, then p=reject. Skipping to reject immediately will silently drop legitimate mail from sources you forgot about.

How long does authentication take to set up?

The DNS records themselves take 5 to 30 minutes to add and propagate. The hard part is finding every system that sends email from your domain — many organizations underestimate this by an order of magnitude. Marketing platforms, helpdesk tools, CI/CD notifications, monitoring alerts, payment processors, and HR systems all may send as your domain. Plan for two to four weeks of monitoring before tightening DMARC policy.