What Is DMARC, DKIM, and SPF (And Why They're Not Enough)?

DMARC, DKIM, and SPF are the three email authentication standards that together let receiving mail servers verify whether a message actually came from the domain it claims to come from. They are essential infrastructure for modern email. They are also not enough on their own to stop the unwanted mail problem facing knowledge worker inboxes.

This post explains each standard, how they work together, what they catch, and why a layered defense still needs more than authentication.

SPF: Authorizing Sending IPs

SPF (Sender Policy Framework) is the oldest of the three, dating to the early 2000s. The idea is straightforward: a domain owner publishes a list of IP addresses authorized to send mail on behalf of the domain. Receiving mail servers check incoming mail against the list. If the sending IP is on the list, SPF passes. If not, SPF fails.

The mechanism is a DNS TXT record at the domain. A typical record looks like:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

This record says: mail from this domain is allowed from the IP range 192.0.2.0/24 and from anything Google includes in its SPF record. Anything else fails (-all is the strict failure policy).

What SPF accomplishes: it makes it harder for a third party to send mail claiming to be from your domain, because the third party would need to be sending from an IP in your authorized list.

What SPF does not catch: any mail forwarded after authentication. Forwarding is common (mailing lists, alumni email forwarders, automated rules at corporate mail servers), and the forwarded mail looks like it is coming from the forwarder’s IP, not the original sender’s authorized IP. Forwarded mail fails SPF unless the forwarder rewrites the headers.

SPF is necessary but limited. It catches a specific class of spoofing but breaks on common legitimate flows.

DKIM: Cryptographically Signing Mail

DKIM (DomainKeys Identified Mail) addresses the forwarding problem. Instead of authorizing sending IPs, DKIM signs outgoing mail with a cryptographic signature. The signature is included as a header in the email. Receiving servers retrieve the public key from the sender’s DNS and verify the signature.

A passing DKIM signature proves two things: the mail was signed by someone with access to the sender domain’s private key, and the signed parts of the mail were not modified between signing and verification.

DKIM survives forwarding because the signature travels with the message. As long as the signed parts of the mail (typically headers and body) are not modified by the forwarder, the signature remains valid.

What DKIM accomplishes: it provides a cryptographic proof that the mail was sent by someone authorized to sign for the domain. Receiving servers can verify the signature even after the mail has been forwarded through multiple hops.

What DKIM does not catch: anything that does not require the legitimate signing key. An attacker who compromises a legitimate account at the domain can sign mail that passes DKIM. An attacker who controls a different domain can sign mail with that domain’s key, and DKIM will pass for the attacker’s domain even though the mail looks like it is from your domain in the visible From header.

DKIM is also necessary but limited. It addresses a different aspect of authentication than SPF, and the two together cover more cases than either alone.

DMARC: Tying Them Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the third standard, layered on top of SPF and DKIM. DMARC accomplishes three things SPF and DKIM cannot do alone.

Alignment. DMARC requires that the domain authenticated by SPF or DKIM match the domain in the visible From header. Without alignment, an attacker could send mail with a From header showing support@bigbank.com while authenticating with their own domain attacker.com. SPF and DKIM both pass technically (the attacker’s domain is correctly configured), but the visible From is misleading. DMARC alignment closes this loophole.

Policy. DMARC tells receiving servers what to do with mail that fails authentication. The policy options are none (do nothing, just report), quarantine (route to spam), and reject (refuse the mail outright). Domain owners configure the policy in their DMARC record.

Reporting. DMARC includes a reporting mechanism. Receiving servers send aggregate reports back to the domain owner showing how much mail purported to be from the domain, how much passed authentication, and how much failed. This visibility is what makes DMARC enforceable; without it, domain owners would have no way to know if their authentication was working.

A DMARC record looks like:

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

This record says: mail failing DMARC should be rejected, send aggregate reports to the address listed, and require strict alignment for both SPF and DKIM.

The combination of SPF, DKIM, and DMARC is the modern standard for email authentication. Most major senders implement all three. Most major receivers enforce DMARC (Gmail, Outlook, Yahoo, and others reject or quarantine mail failing DMARC for domains with strict policies).

What the Three Catch

Together, SPF, DKIM, and DMARC catch direct domain spoofing reliably. An attacker trying to send mail claiming to be from bigbank.com will fail authentication unless they have actually compromised bigbank.com’s sending infrastructure. The visible From header cannot be set to a domain the attacker does not control without DMARC failing.

This is non-trivial. Direct spoofing was the dominant phishing attack vector for years. The widespread adoption of DMARC has substantially reduced this category of attack. Industry reports show meaningful reductions in spoofing-based phishing as DMARC enforcement has spread.

What the Three Miss

The limitations are also important to understand.

Lookalike domains. An attacker registering bigbnk.com (with the “a” missing) can publish their own SPF, DKIM, and DMARC records. Mail from the lookalike domain passes all three checks for the lookalike, even though the visible domain is different from the real bank. Authentication does not protect against lookalike domain attacks, and the visual similarity is what makes the attack work.

Compromised legitimate accounts. An attacker who has compromised a real account at a real domain can send mail that authenticates correctly. The mail genuinely comes from the domain. SPF, DKIM, and DMARC all pass. The recipient is fooled because the sender, in some sense, really is the legitimate sender. The authentication infrastructure cannot distinguish “legitimate-account-controlled-by-attacker” from “legitimate-account-controlled-by-rightful-owner.”

Display-name spoofing. Some email clients show the display name prominently and the underlying address in fine print. An attacker can send from attacker@throwaway.com with the display name set to Mark Wilson, Acme CFO. The mail authenticates correctly for throwaway.com. The recipient sees “Mark Wilson, Acme CFO” and may not check the underlying address. This is a UI vulnerability rather than an authentication failure, but the practical effect is the same.

Content-clean unsolicited mail. Authentication says nothing about whether the recipient wants to receive the mail. A real domain with valid SPF, DKIM, and DMARC sending cold outreach is technically authenticated; the mail will reach the inbox the same way legitimate mail does. Authentication is not a content filter and was never designed to be one.

Why Authentication Is Not Enough

The structural limit: authentication answers “is this sender who they say they are.” It does not answer “does the recipient want to hear from this sender.” Those are two different questions, and the second one is the question most users actually care about in 2026.

The volume of unwanted mail in modern inboxes is dominated by technically-authenticated senders. Cold outreach campaigns, AI-generated solicitation, recruiter blasts, and a long tail of marketing mail from companies the user did not consciously sign up for. All of this mail passes authentication. The receiving provider accepts it. The recipient bears the triage cost.

Authentication catches the cheapest attacks, which is real and useful. The harder attacks (content-clean phishing, BEC from real domains, well-crafted cold outreach) pass authentication by design. We covered the BEC version in business email compromise survival guide for small businesses.

Where Email Paywalls Sit

A paywall like Rythm operates after authentication. Mail that fails authentication is usually rejected by Gmail or Outlook before it reaches Rythm. Mail that passes authentication is accepted by the provider, and Rythm then runs the identity-and-cost filter on it.

The paywall does not check authentication itself; the receiving provider already did that. The paywall checks the recipient’s guest list, applies the cover charge logic for unknown senders, and routes mail accordingly.

This layering is intentional. Authentication is necessary infrastructure for the email system to work at all; without it, spoofing is trivial. The paywall is a different layer that operates on the recipient’s preferences after authentication has done its job. Both are part of the modern stack.

For the related topic of how all the layers fit together, see how to defend your inbox from phishing in 2026 and what is an email paywall.

The Practical Takeaway

For senders: implement SPF, DKIM, and DMARC. The three together are necessary infrastructure for deliverability in 2026. Configuration takes a few hours and the benefits are continuous.

For domain owners not actively sending mail: still publish SPF and DMARC. A v=spf1 -all record and a v=DMARC1; p=reject record protect your domain from being spoofed by attackers. Domains that do not send mail at all should publish records that reject everything.

For recipients: authentication is mostly invisible. The receiving provider handles it. The mail you see in your inbox has already passed authentication or the provider would have rejected it. The unwanted mail problem at the recipient level is downstream of authentication, not addressable by it.

For inbox volume: structural filters that operate on identity and cost, after authentication has run, address what authentication cannot. Rythm implements this layer for Gmail and Outlook at $1.65 per month. The paywall does not replace authentication; it complements it by filling the gap authentication is structurally not designed to close.