An inbound message can pass domain authentication and still ask the recipient to do something dangerous. It can also fail authentication because a legitimate route broke. Treat authentication as one measured property of a message, then apply the receiving system's other controls and the organization's business verification process. Collapsing these steps produces both false reassurance and unnecessary disruption.
Identify the three decisions
The first decision is technical: did an authenticated identifier align with the author domain under the applicable DMARC rules? The second is operational: how should this receiving environment handle the message, considering policy and other signals? The third is business-specific: is the requested action legitimate and authorized? RFC 9989 defines domain-based authentication and policy; it does not turn a passing message into approval to pay an invoice. DMARC specification.
Record these decisions in separate fields. For an invoice-change request, the authentication field might be pass, the handling field quarantine pending review and the business field unverified. Those values are compatible. A receiver can use signals outside DMARC, and an employee should follow the independent approval workflow even when the mail was authenticated.
Use results from a trusted boundary
An Authentication-Results header is useful only when its provenance is understood. Attackers can insert header text into a message. The receiving organization must distinguish results produced by its trusted authentication service from untrusted assertions. RFC 8601 describes that trust boundary. Authentication Results.
Preserve the raw message and the trusted receiving system's logs. Compare the visible From domain with each verified DKIM signing domain and the SPF identity actually evaluated. Avoid treating the display name, Reply-To field or a forwarded screenshot as the authenticated author domain. If the message was forwarded, record the original evaluation point and subsequent transformations before deciding which evidence applies.
Compare three synthetic requests
Consider three hypothetical payment-change messages. The first claims brand.test but has only a passing evil.test signature and no SPF pass; the assumed sole authenticated identifier fails strict alignment. The second uses brand-pay.test in both From and its passing DKIM identity, so its modeled authentication passes despite the lookalike concern. The third uses brand.test consistently and also passes, leaving account abuse or an unauthorized request possible.
The proposed business action for each case is: hold the change and independently verify it. These are invented authentication inputs, not cryptographic or receiver results. The written cases assume the stated identities are the only available authenticated identifiers, isolate strict exact-domain matching and do not implement full DMARC discovery. No message, signature or receiver test was executed. It demonstrates why the business action cannot be computed from the authentication boolean alone.
Design handling without bypassing review
Choose authorized test messages for each control path and record whether the system rejected, quarantined, delivered or later remediated them. A vendor's feature label is not evidence of your configured behavior. Include exceptions and allow rules in the test because they can change the effective outcome. Avoid broad allowlisting merely to make a broken legitimate route pass through.
For financial requests, use a previously established contact channel. The FBI recommends independently verifying payment requests and changes to account details. Do not use contact details introduced by the suspicious message as that independent channel. FBI business email compromise guidance.
Close a review with all three decisions, the evidence for each and any unresolved issue. This allows the mail team to repair authentication while finance retains the payment hold, or security to investigate a passing but suspicious message without claiming DMARC is defective.
Source and execution boundary
RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish authentication, alignment and handling; a pass does not endorse message content. The operational decisions here are scoped recommendations and explicitly hypothetical examples, not new tests of a customer, provider or historical fixture. Any real change requires its own authorized scope, retained evidence and accountable decision.