A DMARC pass answers an identity question. It does not certify that a recipient wanted the message, that its content is safe, or that the receiving service placed it in the inbox. Treating authentication as a delivery guarantee sends investigations toward the wrong controls.
State what passed
DMARC evaluates alignment between the author domain and an authenticated identifier from SPF or DKIM. A passing result requires an applicable aligned authentication success, not necessarily success of both mechanisms. For deployment, RFC 9989 sections 7.4 and 8 require domains publishing p=reject to apply valid DKIM signatures and not rely solely on SPF. That obligation is separate from the message-level pass rule. Inspect the receiving system's trusted results and the identifiers involved. A copied Authentication-Results header supplied by a sender is not by itself reliable evidence. DMARC specification.
Record the final recipient-side sample when available, its observation time and the sending route. Forwarding and message modification can make a test at an earlier hop differ from the result at the destination. Do not call a DNS record lookup a message-level DMARC pass.
Locate the delivery stage
Keep submission, remote SMTP acceptance and mailbox placement distinct. SMTP acceptance transfers responsibility under the protocol but does not promise an inbox folder. A message can pass authentication and still encounter recipient policy or unwanted-mail filtering. Google's sender guidance describes authentication alongside reputation, spam complaints and mailing practices. Google sender guidelines.
Ask for the actual symptom: a rejection, repeated temporary deferral, spam-folder observation or absence of a user interaction. Each needs different evidence. A tracking pixel that did not load cannot prove that SMTP delivery failed.
Compare a stable cohort without claiming causation
Consider four hypothetical messages with trusted aligned DKIM passes at their final receiver. Two have confirmed inbox observations, one has a confirmed spam-folder observation, and one has only final SMTP acceptance with placement unknown. Authentication is established for all four in this teaching assumption, but confirmed inbox placement is established for only two.
The observed-folder subset is two inbox messages out of three observations. The entire cohort has two confirmed inbox cases out of four, with one unresolved placement; neither denominator turns that unknown into spam. No signatures were verified or mailboxes inspected for this example. Its purpose is to show which evidence remains missing, not to measure a causal effect of authentication.
Repair the observed problem
For a rejection, preserve the exact remote response and address it using the receiving provider's current guidance. For a confirmed spam-folder sample, review wanted-mail practices, audience expectations and route reputation alongside any genuine authentication defects. For missing evidence, collect a controlled authorized sample rather than changing policy speculatively.
Close the case with separate fields for authentication, transport and placement, including unknowns. Do not weaken DMARC or rotate identities to escape complaints. Authentication remains valuable even when it is not the cause of the delivery incident.
For operational reporting, give each field an evidence reference rather than a single green status. An administrator can attach a trusted receiving result to authentication, a queue identifier to transport and a controlled mailbox observation to placement. If the recipient cannot provide a sample, leave placement unknown. This prevents a well-supported authentication conclusion from silently expanding into an unsupported assurance about the customer's experience.
Record a defensible next step
Record authentication, transport and placement separately; a pass at one stage cannot fill an unknown at another. Name the owner, the evidence still missing and the condition that will close the investigation. Leave unsupported outcomes unknown.