DMARC for Email: What the Check Does, and What a Pass Never Proves

Most guidance about email DMARC on the internet today describes a specification that was replaced. The IETF published RFC 9989 on 20 May 2026, and it obsoletes both RFC 7489, the original DMARC document, and RFC 9091. Three tags were removed in that revision and three were added, and the tag most rollout advice is built around is one of the removed ones.

That makes this a good moment to read the standard rather than a summary of it. What follows is what DMARC actually checks, what a DMARC result means, what the standard protects and what it does not, and which parts of the older guidance are now wrong rather than merely dated.

What the acronym covers

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a layer on top of two older mechanisms rather than a third authentication method of its own. SPF says which servers may send for a domain. DKIM attaches a signature a receiver can verify. Neither of them says anything about the address a human being reads in the From header, and DMARC exists to close that gap.

RFC 9989 calls the domain in the visible From header the Author Domain, and the whole protocol is organised around it. The owner of that domain publishes a record stating what it wants receivers to do with mail that claims the domain and fails, and asks for reports about what receivers saw.

Three things follow from that framing and they are worth holding on to, because most confusion about DMARC is one of them misunderstood.

DMARC is published by the domain owner and enforced by the receiver. Nothing you publish obliges anyone to act on it, and receivers apply their own handling on top.

DMARC evaluates one message at a time against one domain. It has no notion of your reputation, your volume, or whether a person wanted the message.

DMARC produces reports as a first-class output rather than as a side effect. The reporting half is specified separately, in RFC 9990 for aggregate reports and RFC 9991 for failure reports, and it is the half that makes the policy half decidable.

How DMARC works, step by step

DMARC authentication is often described as a third check alongside SPF and DKIM, and reading it that way is what makes the rest confusing. It runs no check of its own. The evaluation has three steps and the third is where people lose the thread.

1. Step 1Find the Author Domain

   Read the domain out of the visible From header. Everything else is measured against this name.

2. Step 2Collect authenticated identifiers

   SPF may supply the MAIL FROM domain. DKIM may supply the d= domain of each valid signature.

3. Step 3Test alignment

   Compare each authenticated identifier against the Author Domain, under relaxed or strict mode.

4. Step 4Apply policy only if nothing aligned

   One aligned pass is a DMARC pass. The published policy decides what happens only when there is no aligned pass at all.

The SPF half narrowed in the 2026 revision, and it is the change most likely to move a domain from passing to failing without anyone touching a record. SPF can validate two identities, the domain in the HELO or EHLO command and the domain in the MAIL FROM command. RFC 9989 states plainly that DMARC "relies solely on SPF validation of the MAIL FROM identity". Mail that was reaching a DMARC pass through the HELO identity alone is not reaching one now.

The DKIM half is unchanged. A message may carry several signatures, and each valid one supplies the domain in its d= tag as a candidate identifier.

Alignment is the comparison, and its two modes are set by adkim= for DKIM and aspf= for SPF. Both default to r for relaxed, which accepts a match at the organizational domain so a subdomain can satisfy a policy published on the parent. Strict mode, s, demands an exact match. The default is the forgiving one deliberately, because sending platforms routinely use a bounce subdomain for the return path and internal systems routinely send from a subdomain.

The rule that surprises people is that DMARC needs only one aligned pass. Not both. A message with a broken SPF record and a correctly aligned DKIM signature passes DMARC, which is why DKIM is the more durable half of the pair on any domain that has accumulated senders.

What a published record contains, and the value of a missing tag

The record is a DNS TXT record published at the name _dmarc in front of the domain it governs. For acme.com that is _dmarc.acme.com, and publishing at the bare domain instead is the most common setup mistake there is.

A minimal record that does something useful looks like this:

_dmarc.acme.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"

v=DMARC1 is required and has to come first. p= carries the handling preference and takes none, quarantine or reject. rua= names where aggregate reports go.

One detail in RFC 9989 is worth knowing because it changes how you read someone else's record. If the p tag is absent from an otherwise syntactically valid record, the record "is treated as if it included p=none". A record with no policy tag is a monitoring record rather than a broken one, which matters when auditing a portfolio somebody else built. The tag-by-tag reference, including the tags that arrived and departed in 2026, is in the DMARC record.

The policy also reaches further than its own name. RFC 9989 states that the policy "applies to the domain queried and to subdomains, unless the subdomain policy is explicitly described using the sp or np tags". Subdomains inherit the parent's DMARC policy while inheriting no SPF and no DKIM, and that asymmetry is the single most reliable way to break working mail by tightening a parent domain.

DMARC as a security control, stated honestly

Security scanners flag a missing or permissive DMARC policy, and the framing they use invites a reading the standard does not support. It is worth separating what enforcement buys from what it does not.

An enforcing policy protects other people from mail that claims your domain. That is the entire security benefit, and it is a real one: a domain at p=reject cannot be used to phish your own customers with a From address they recognise. The beneficiary is the recipient rather than you.

An enforcing policy does not improve the delivery of your own mail. Your legitimate mail should be passing DMARC at every policy value, including none, so tightening the policy changes nothing about how your own messages are treated except in the case where something you send is failing, and in that case tightening the policy makes it worse rather than better.

DMARC is also not a filter. It answers whether a domain may be held responsible for a message. It says nothing about whether the message is honest, since anyone can register a domain, publish a correct record, and authenticate perfectly while sending something dreadful.

A DMARC pass establishes

• An authenticated identifier aligned with the visible From domain
• The domain owner may be held accountable for this message
• One of SPF or DKIM did its job for a domain you control
• A stable identity for receivers to attach reputation to

A DMARC result says nothing about

• Whether the message reached an inbox or a spam folder
• Whether the recipient wanted it
• Whether the sending domain has a good reputation
• What happened at receivers that publish no reports

The placement gap in the second column is the one that costs people the most time. Authentication is a precondition for delivery rather than a cause of it, and a domain can pass DMARC on every message and still land in spam everywhere. That side is measured elsewhere, in Google Postmaster Tools for Gmail.

What the 2026 revision changed

Guidance written before May 2026 is not all wrong, and the parts that are wrong are concentrated in one place.

pct= is gone. Appendix A.6 of RFC 9989 is titled "Removal of the pct Tag", and the tag registry now lists pct, rf and ri with a status of historic. The tag was intended to let a domain owner apply a stricter policy to a percentage of failing mail, and the specification explains why it did not survive: operational experience showed it "was usually not accurately applied, unless the value specified was either 0 or 100", with inaccuracies varying widely between implementations. A control that some receivers honour and others discard is not a control, so a rollout plan built on stepping the percentage upward is a plan built on a tag that was removed.

t= replaced the part of it that was worth keeping. The specification introduces it "as shorthand for testing", with values y and n analogous to the old pct values of 0 and 100. Under t=y the domain owner "has an expectation that the policy applied to any failing messages will be one level below the specified policy", so quarantine behaves as none and reject behaves as quarantine. It applies one level down to everything rather than the full policy to a sample, and it does not affect report generation.

np= arrived from RFC 9091 and sets a policy for non-existent subdomains of the organizational domain. Names that were never created are a standing spoofing surface precisely because nobody publishes records for them, so this one is cheap to add and closes a real gap.

An existing record carrying pct= keeps working, because receivers ignore tags they do not recognise rather than rejecting the record. There is no urgency to strip it and no reason to build anything new around it.

What changes when outbound runs on more than one domain

DMARC is published per domain and there is no inheritance between domains you happen to own. acme.com and try-acme.com are unrelated to every receiver on the internet, even under one registrar account, so a portfolio of sending domains is a portfolio of independent records.

Three consequences follow for anyone running cold outbound.

A strict policy on the primary company domain protects nothing on the sending domains, and a permissive policy on the sending domains endangers nothing on the primary. That independence is useful rather than a problem, and it is a reason to keep outbound off the domain your contracts come from.

Every sending domain needs its own record. A sending domain with no DMARC record at all is a weaker signal than one sitting at monitoring, and unpublished records accumulate in exactly the place nobody audits, which is a set of registrar zones nobody opened after launch.

Reporting has to be designed rather than accumulated. Pointing every domain at one shared reporting mailbox is the sensible default, and it needs a cross-domain authorisation record published on each domain rather than only on the first one, which DMARC aggregate reports covers in full.

We authenticate every sending domain before it carries a message, and we run one message per campaign, so a domain that fails authentication does not get a second attempt at the same person under a different pretext. That makes the record part of provisioning rather than part of debugging, which is also why a domain with a problem is replaced rather than repaired while it is live.

If you would rather not maintain DNS records across a domain portfolio, we run the sending infrastructure as part of the engagement.

Where to go next

The decision about which policy to publish, and what staying at monitoring costs, is in DMARC policy not enabled. The choice between the two enforcement values, which comes down to whether a mistake is recoverable, is in quarantine versus reject. When mail is failing and the reason is not obvious, the six causes of DMARC failure works through them in the order that resolves most investigations fastest. And the wider set of records DMARC sits on top of is covered in email authentication.

The short version

DMARC is a policy layer that takes the authenticated identifiers SPF and DKIM produce and insists at least one of them align with the domain in the visible From header. One aligned pass is enough. The record is a TXT record at _dmarc in front of the domain, a record with no p tag is treated as p=none, and the policy covers subdomains that publish no policy of their own while SPF and DKIM do not.

The 2026 revision removed pct=, rf= and ri=, added t= for test mode and np= for non-existent subdomains, and narrowed SPF evaluation to the MAIL FROM identity with no HELO fallback. Enforcement protects your recipients from people spoofing you rather than improving your own delivery, and no DMARC result says anything at all about whether a message reached an inbox.

Specification behaviour verified as of August 2026 against RFC 9989, RFC 9990 and RFC 9991, published 20 May 2026. Verify against the current specification before making DNS changes.

Sources: RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance