Self-Hosting

What DMARC Actually Protects You From (and the 2026 DMARCbis Changes)

A DMARC check confirming a From-domain matches its authentication while a lookalike domain passes untouched.

DMARC gets asked to do jobs it was never designed for. Teams reach for it as a spam filter, a phishing filter, a general trust signal. It's none of those. The protocol answers one deliberately narrow question: did the owner of the domain in the visible From address authorize this message, provable through an aligned SPF or DKIM result? That's worth answering, and it's far narrower than the reputation DMARC has picked up. A team that reaches p=reject believing they're now phishing-proof will skip every control that covers what DMARC leaves untouched, which is most of the phishing that actually lands.

This is the mechanics half: what DMARC checks, why passes and failures happen, and what changed when DMARCbis landed in May 2026. For the operational side, detecting the impersonation DMARC can't catch at your own MTA, I covered that separately in detecting spoofed email that passes every check. This piece is the protocol; that one is what you do about its blind spots.

The Currency Update: DMARC Is DMARCbis Now

Worth leading with, because most DMARC explainers online still cite the old spec. In May 2026 the IETF published DMARCbis as three Standards-Track RFCs, obsoleting the original RFC 7489 from 2015:

RFC 9989, the core protocol (policy, evaluation, alignment).
RFC 9990, aggregate reporting (the daily XML RUA reports).
RFC 9991, failure reporting.

This is the first substantive DMARC update in eleven years, and the first time DMARC has formal IETF Standards-Track status rather than the Informational, independent-submission standing the 2015 spec had.

⚠️ Practically, most of your existing DMARC record stays valid, records still start with v=DMARC1 and the p=, sp=, rua=, ruf=, adkim=, aspf=, and fo= tags keep their meaning. But three tags are now deprecated and should come out at your next DNS edit:

pct= (percentage rollout) is gone. Staged rollout now uses the new t= testing tag instead.
rf= (report format) is gone.
ri= (report interval) is gone.

⚠️ The bigger structural change: the Public Suffix List is replaced by a DNS Tree Walk for determining the organizational domain. If you rely on relaxed alignment across subdomains, the way DMARC decides "same organization" changed under you. The safe response, and RFC 9989 recommends this explicitly, is to publish an explicit DMARC record for every domain and subdomain you send from, which removes any ambiguity between how old (7489) and new (9989) receivers walk the tree. If you've been leaning on a single apex-domain record to cover subdomains, that's the thing to revisit.

How Email Proves Who Sent It

Three terms, in plain English:

SPF is a published list of servers a domain says may send its mail; a receiver checks whether the message came from one of them.
DKIM is a cryptographic signature added to the message, so a receiver confirms it genuinely came from the signing domain and wasn't altered in transit.
DMARC ties both back to one thing: the visible From address.

The From-address subtlety is the crux. Every email has two from addresses. The envelope address (like the address on a parcel) is what mail servers read to route the message; the recipient never sees it. The visible From (Your Bank <alerts@your-bank.com>) is what your mail app displays and what a human trusts. Because the two are set independently, an attacker can put your bank in the visible From while the envelope points elsewhere. SPF checks the envelope; DKIM's signature carries its own domain; DMARC exists to tie whichever one authenticated back to the visible From, so authentication lines up with the address the reader actually sees.

What the Records Look Like

All three are DNS TXT records. You don't need to memorize the syntax, just recognize the shape.

SPF, listing who may send (Google Workspace and a marketing tool here; -all means "anything else isn't us"):

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM, publishing the public half of the signing key:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...AB"

DMARC, tying it together and telling receivers what to do on failure:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:reports@example.com"

⚠️ Under DMARCbis, if you're building a new record, drop pct= and use t=y for a testing/monitoring posture instead. An old record carrying pct= won't break (receivers ignore deprecated tags), but it's dead weight, and a pct= value below 100 behaves inconsistently across receivers even under the old spec, which is exactly why it was removed.

How a Pass Is Decided

DMARC sits on top of SPF and DKIM and evaluates them independently. Two separate paths to a pass:

SPF passes for the envelope domain and that domain aligns with the visible From domain, or
A DKIM signature validates and its signing domain aligns with the visible From domain.

If either aligned path succeeds, DMARC passes. If neither does, it fails.

Alignment is the part most explanations skip, and it's where "SPF pass, DMARC fail" comes from. DMARC has two alignment modes:

Relaxed (the default): the two domains only need the same organizational domain, so a DKIM signature from mail.example.com aligns with a From of example.com.
Strict: they must be identical, and that same signature would fail.

So "SPF pass but DMARC fail" normally means SPF confirmed the envelope domain successfully, but that domain didn't match the visible From closely enough to align. ⚠️ And note the DMARCbis Tree Walk changes how "same organizational domain" is computed, which is the current-spec reason to publish explicit subdomain records rather than trust the alignment logic to guess.

Notice what the check never inspects: the body, the links, the attachments, or the sender's intent. It's a check on provenance, not content. That single sentence is the whole reason the "where it falls short" list below exists.

Where DMARC Genuinely Helps

The case it was built for is exact-domain spoofing. If someone puts your-bank.com in the From without an aligned SPF or DKIM result, p=reject asks participating receivers to reject the message (the receiver keeps final say and may apply local policy). For this specific attack, the protection is real and strong.

It also gives you aggregate reports (RFC 9990) revealing the systems receivers have observed sending as your domain, which is how you find the forgotten marketing tool or misconfigured relay before an attacker does. That visibility is arguably as valuable as the enforcement itself, and it's the reason to deploy DMARC at p=none first even if you never intend to enforce: you learn who's sending as you.

Where It Falls Short

Everything in this list passes or evades DMARC while still being an attack. This is the part the "DMARC stops phishing" marketing omits:

Lookalike domains. An attacker registers your-bank-support.com, configures valid SPF and DKIM, and passes DMARC on their own domain. Your policy has zero reach over a domain you don't own. To every receiver, that mail is fully authenticated.
Display-name impersonation. The visible name reads "Your Bank Security" while the address is alerts@some-unrelated-domain.com. DMARC validates the domain, not the friendly name most people actually read. Passes cleanly, still impersonation.
Compromised mailboxes. An attacker signs into a real account with phished credentials and sends through the legitimate provider. It passes SPF, DKIM, and DMARC because, in protocol terms, it went through authorized infrastructure. Authentication cannot tell a real user from an attacker holding that user's password.
Authenticated-but-malicious domains. Anyone can register a domain and configure flawless authentication; spammers do this routinely. A pass on totally-legit-invoices.com confirms the owner authorized the mail. It says nothing about whether the owner is honest.
Spam and inbox placement. DMARC is not a spam filter and does not decide whether mail reaches the inbox. Authenticated spam is still spam.
Forwarding and mailing lists. Legitimate intermediaries break authentication. Forwarding commonly breaks SPF (the forwarding server isn't authorized by the original domain); mailing lists modify the subject or body and invalidate DKIM. A legitimate message can fail DMARC with nobody impersonating anyone.

⚠️ That last point is why you never flip straight to p=reject. The forwarding-and-lists breakage means a blind switch to enforcement bounces legitimate mail. DMARCbis makes this explicit: the RFC 9989 guidance on p=reject is more cautious than the original, precisely because operators kept enforcing before remediating and lost real mail. The path is p=none (monitor, read your RUA reports), then remediate every legitimate sender the reports reveal, then p=quarantine, then p=reject. The ARC protocol (RFC 8617) exists specifically to preserve authentication across forwarding hops, and it's worth adopting if forwarded mail is a real part of your flow.

Authentication Is Not Trust

A DMARC pass establishes exactly one fact: the domain in the From address authorized this message, via SPF or DKIM, with alignment. That shuts down exact-domain spoofing and shows you who sends as you. It does not establish whether the message is truthful or safe to act on, those are properties of content and intent, and no authentication check reaches them.

This is the same distinction that runs through every authentication-versus-authorization-versus-validation discussion on this blog, most directly in the "authorization is not validation" analysis: a system can correctly verify that a request is authorized and still have no idea whether it's safe. DMARC verifies provenance flawlessly and tells you nothing about honesty. Any vendor implying DMARC "stops phishing" is leaving their customers exposed to every category above.

The honest deployment posture: use DMARC to reach enforcement without breaking legitimate mail, prove which senders are yours, and close down exact-domain spoofing. Everything past that, lookalike monitoring, compromised-mailbox detection, content and intent analysis, and human judgment, is a separate job. The MTA-level detection for the categories DMARC misses is in the spoofing-detection guide, and the DKIM key hygiene that underpins the whole chain matters just as much as the policy, a leaked signing key makes your perfect DMARC record worthless.

Bottom Line

DMARC answers one narrow question well: did the From domain authorize this message? At p=reject that ends exact-domain spoofing and, via aggregate reports, shows you every system sending as you. It does nothing about lookalike domains, display-name tricks, compromised accounts, authenticated spam, or malicious content, which is most of real-world phishing. Deploy it correctly (monitor at p=none, remediate from your RUA data, then enforce), update your records for DMARCbis (drop pct=/rf=/ri=, publish explicit subdomain records for the Tree Walk), and treat the pass as proof of provenance, never proof of trust. The moment you mistake one for the other, you've bought a false sense of security at p=reject.