Summary

  • A DMARC pass validates authorized use of the Author Domain; it says nothing about a message's truth, safety, intent or value.
  • p=reject is a Domain Owner's handling preference. RFC 9989 leaves final disposition with the Mail Receiver and expects an accountable override reason when the receiver departs from it.

Imagine two messages at the same receiving edge. The first passes DMARC but contains content the receiver's abuse systems regard as dangerous. The second fails because a legitimate mailing list altered its path and headers, while local history supports delivery. A rule that equates pass with “safe” and fail with “fraud” gets both cases wrong.

RFC 9989, published in May 2026 on the IETF Standards Track, makes the distinction explicit. Its publication record, Datatracker history and errata surface establish the specification's identity, not anyone's deployment result. The document obsoletes RFCs 7489 and 9091.

DMARC begins with two narrower mechanisms. SPF can establish that an SMTP source is authorized for an SPF identity. DKIM can validate a signature associated with a signing domain. RFC 9989 then asks whether at least one authenticated identifier aligns, strictly or organizationally, with the RFC5322.From Author Domain. One aligned pass produces DMARC pass; no aligned authenticated identifier produces fail.

That is an identity result, not a content judgment. RFC 9989 says a pass indicates only that use of the Author Domain was validated as authorized by its owner. It carries no value assertion about the message or the owner. A receiver may still reject or quarantine it. Conversely, a fail does not prove fraud. RFC 7960 documents how forwarding, aliases and mailing lists can break the authentication or alignment path of legitimate mail.

The DNS policy record adds another object. The IANA DMARC registry records the protocol's parameters, including the assessment-policy vocabulary. p=none expresses no handling preference; quarantine marks failed mail as suspicious; reject expresses the owner's strongest assessment. Those values are useful because the owner knows which uses of its domain it intends. They remain preferences because the owner does not operate the receiving system, serve its recipient or possess all of its local evidence.

Sections 5.3.6 and 5.4 therefore keep disposition local. Failed messages are handled under the receiver's policies, which may consider the published assessment at the receiver's discretion. Final handling is always the receiver's decision. RFC 9989 even advises against rejecting solely because p=reject was published; other knowledge can prevent damage to legitimate indirect flows and mailing lists. The opposite choice also has a cost: accepting a failure can admit abuse.

DNS uncertainty produces a third state, not a convenient fail. If required queries end in temporary or permanent errors, DMARC cannot classify the message as pass or fail and the domain policy cannot be applied. The receiver still must decide whether to defer, accept or otherwise handle the message. A pipeline that silently converts “unknown” into fail destroys the evidence RFC 9989 preserved.

Accountability is the bridge. When a receiver departs from the Domain Owner's preference, RFC 9989 says it should disclose the fact and reason through the PolicyOverride feature of the aggregate report defined by RFC 9990. When it delivers failed mail, it should preserve the result in the Authentication-Results field. RFC 9991 separately governs optional detailed failure reports; disclosure is not disposition authority.

The evidence chain should remain visible: SPF and DKIM inputs, aligned identifier, discovered policy and DNS status, local reputation and abuse signals, override reason, final SMTP action, and later recipient or feedback evidence. Each record has a different owner and clock.

Heng Lu's minimum initial specification explains why a shared signal can coordinate action without centralizing the future decision. His account of reality layers warns against granting symbolic state the powers of execution. Running-code primacy asks whether the receiver actually applied, overrode or failed to retrieve the declared policy.

The honest status line is therefore not “DMARC decided.” It is: this evidence produced this alignment result; this domain expressed this preference; this receiver made this disposition for these recorded reasons.