Summary

  • RFC 9989 defines a DMARC pass when an SPF- or DKIM-authenticated domain aligns with the domain in RFC5322.From. The result validates authorized use of that Author Domain; it does not authenticate the local part, display name, human author or message content.
  • Pass does not mean safe, and fail does not necessarily mean fraudulent. Forwarders and mailing lists can break SPF alignment or DKIM signatures even when the original message legitimately used its domain.
  • The p, sp and np values published in DNS are requested handling preferences. A receiver may reject a passing message, accept a failing one and combine DMARC with local reputation, content and abuse evidence. Final handling remains local.

A valid result with a smaller subject than the message

An authentication result normally appears beside an entire email, so it is tempting to let the result describe the entire email. RFC 9989 refuses that compression. Its subject is not “this message is trustworthy.” Its subject is the use of one domain in one header field.

The document, published on the Standards Track in May 2026, was edited by Todd M. Herr and John Levine and obsoletes RFCs 7489 and 9091. Its opening pages put the limit before the implementation detail. A pass indicates only that use of the RFC5322.From domain—the Author Domain—has been validated as authorised by that Domain Owner. The authorisation makes no value assertion about the message or the Domain Owner. It does not guarantee that inbox delivery is safe or desirable.

That wording is not a disclaimer added after the mechanism. It is the mechanism's accounting boundary. If the receiver records a larger claim, the receiver has created that claim from other evidence and should name it as such.

The two paths into alignment

SPF and DKIM authenticate different identifiers. SPF asks whether the connecting client is authorised to use a domain in the SMTP MAIL FROM identity. DKIM checks a cryptographic signature and identifies its signing domain. Either result can be valid without saying anything about the domain a reader sees after “From”. A hostile domain can authorise its own servers and sign its own mail perfectly well.

DMARC adds the missing comparison. The receiver extracts the Author Domain from RFC5322.From and asks whether at least one passing SPF or DKIM identifier aligns with it. Under strict alignment the domains are identical. Under relaxed alignment they share the same Organizational Domain. The Domain Owner chooses the alignment modes through aspf and adkim; RFC 9989 notes that relaxed alignment meets the needs of nearly all Domain Owners.

For SPF, DMARC uses the MAIL FROM domain rather than HELO. For DKIM, one valid aligned signature is enough even if another signature does not align or fails. The resulting receipt can therefore be stated precisely: this receiver, at this time, observed at least one authenticated domain that satisfied the selected alignment relation with this Author Domain.

Every word after that sentence requires another receipt.

The person, mailbox and display name remain outside

An address made from the local part chief.executive and the domain example.com contains several claims that look like one identity. DMARC handles example.com. It does not validate chief.executive, prove control of that mailbox or establish that the visible individual wrote the message. RFC 9989 explicitly says its authentication mechanisms do not validate an address local part.

The human-readable display name is outside the result too. “Accounts Payable” or the name of a real executive can be attached to an unrelated address. A visually similar domain can replace one letter with another script or add a plausible word. RFC 9989 says DMARC does not address display-name attacks or lookalike domains.

Content analysis is also out of scope. A signed and aligned domain can send a false invoice. A compromised account can distribute malware through an authorised service. A newly registered attacker-controlled domain can pass its own policy. DMARC can make the responsible domain legible for reputation and response; it cannot turn cryptographic correctness into honest intent.

This is why “DMARC passed” should never be the final sentence of an investigation. It is the first answer to a smaller question.

Why failure is not the mirror image

If pass is narrow, fail cannot be treated as its moral opposite. RFC 9989 deliberately says a failure is “not necessarily associated” with the Author Domain, because legitimate mail can lose the evidence needed for alignment.

RFC 7960 explains the common paths. A forwarder that preserves the original MAIL FROM may transmit from an IP the original SPF policy did not authorise. A forwarder that substitutes its own MAIL FROM may pass SPF for its domain but cease to align with the original RFC5322.From domain. A mailing list may add a subject tag, footer or MIME transformation and thereby invalidate an otherwise valid DKIM signature. None of these transformations proves that the original author was an impostor.

The receiver sees the message after this journey, not before it. Its DMARC result is a statement about evidence available at the final checkpoint. A fail can be operationally useful, especially when combined with a strong domain policy, but it is not a historical reconstruction of every legitimate handoff.

A policy record is a request crossing an ownership boundary

The policy part of DMARC is often described with imperative language: a domain publishes p=reject, so the receiver rejects. RFC 9989 describes a different allocation of control.

The receiver first discovers an applicable DNS record. It checks the exact Author Domain, then its Organizational Domain, then a Public Suffix Domain. Depending on where the record is found and whether the Author Domain exists, it selects p, sp or np. Those tags express the Domain Owner's requested assessment policy for messages that fail. The IANA registry labels them requested policies, not execution commands.

Final handling is always the receiver's local policy. A receiver may quarantine or reject a message that passed because other evidence is adverse. It may accept a failing message even when the published preference is reject. RFC 9989 goes further: receivers should not reject solely because of p=reject; they should use other knowledge to avoid losing legitimate indirect mail or damaging mailing lists.

DNS failure exposes the same boundary. When required queries cannot complete, the message is neither pass nor fail and the published policy cannot be applied. A receiver may fail open, temporarily defer or use another local treatment. The Domain Owner owns its publication. The receiver owns its queue and the consequences of its decision.

Heng Lu's Policy Mirror applies a scope test to shared infrastructure: preserve the small record needed for coordination without allowing that record to absorb authority over decisions borne by another operator. DMARC's own text reaches that discipline at message scale. A domain can make its preference legible; it cannot remotely operate another organisation's filter.

Reports are observations, not proof of obedience

DMARC can return aggregate observations to addresses in rua and, optionally, message-specific failure information to ruf. Aggregate reporting helps a Domain Owner find fraudulent use and gaps in its own authentication. Yet even a participating receiver is not compelled to send every requested report. Aggregate reports are recommended; failure reports are optional and are frequently redacted or withheld for privacy.

A published report destination therefore proves only a request. A report actually received proves an observation from one reporter for one period under one reporting implementation. It does not prove universal coverage, successful enforcement or the final fate of every message.

This distinction matters for governance as well as troubleshooting. If an organisation increases its policy from monitoring to enforcement, the decision should be supported by known sending sources, indirect-flow tests and received evidence—not by the existence of a DNS string alone.

Todd Herr's editorial contribution without invented sovereignty

The IETF Datatracker record captured on 1 September 2026 lists RFC 9989 under Todd Herr's public identity and shows him serving on the ART Area Review Team. The RFC identifies Herr with Valimail and John Levine with Standcore LLC as co-editors. The acknowledgements preserve the much larger history of the DMARC Working Group and the industry work behind RFC 7489.

That attribution is important because protocol documents are often personalised into authority they do not create. Herr can be profiled as an editor who helped make the limit unusually explicit. He is not the sole inventor of DMARC, the verifier of every domain, the operator of every receiver or the owner of its local policy. The document's strength lies partly in refusing to centralise those roles.

The complete receipt chain

A defensible mail decision should preserve at least six separations. First, the message bytes and the exact RFC5322.From field. Second, each SPF and DKIM result with its domain, selector, reason and time. Third, the alignment mode and the identifier that produced DMARC pass or fail. Fourth, the DNS path that selected the applicable record and p, sp or np value. Fifth, local reputation, content, indirect-flow and abuse evidence. Sixth, the actual disposition and later user outcome.

The order prevents inheritance. An aligned domain does not inherit the identity of the display name. A pass does not inherit a content verdict. A remote preference does not inherit execution. SMTP acceptance does not inherit inbox placement. Inbox placement does not inherit safety.

DMARC remains powerful after these claims are removed. It makes unauthorised exact-domain spoofing harder, gives receivers a stable domain for reputation and gives Domain Owners feedback about their mail streams. Its result becomes more useful, not less, when it is allowed to say exactly one thing well.

Sources