A message can pass DMARC and still fail a mailbox provider's sender requirements. That is not necessarily a contradiction. DMARC answers a specific identity question; a receiver may also require functioning mechanisms, secure transport, suitable message construction and responsible sending behavior.
Start with the protocol decision
References: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, published in May 2026, obsoletes legacy RFCs 7489 and 9091. Under its section 4.1, DMARC passes when a policy record exists for the Author Domain and that domain aligns with an authenticated identifier from the message. The aligned-pass principle remains: at least one supported authentication mechanism must pass with alignment to the visible From domain. For SPF within DMARC, the relevant identity is the SMTP MAIL FROM domain under RFC 9989 §4.4.2; a standalone HELO-based SPF result is not a substitute for that DMARC identity. For DKIM, it is the d= domain of a valid signature. A successful mechanism without the required alignment does not contribute a DMARC pass. RFC 9989 sections 3.2.10 and 4.1–4.3.
Alignment has strict and relaxed modes. Strict compares the applicable domains exactly; relaxed uses their organizational-domain relationship. RFC 9989 section 4.10 defines DNS Tree Walk discovery rather than the legacy public-suffix-list approach. Verify the receiver or evaluator's implemented version before assuming its discovery behavior. Do not implement relaxed alignment by checking whether one domain string merely ends with another. A deceptive suffix or an incorrect organizational-domain calculation can produce the wrong result.
Add the provider requirements as a separate layer
Microsoft's consumer high-volume support guidance requires both SPF and DKIM to pass, plus DMARC. Yahoo's bulk requirements call for both mechanisms and passing DMARC. These are operational gates in addition to the protocol's either-aligned-mechanism logic. Review the current source for the destination rather than infer a universal rule from one provider. Microsoft support and Yahoo requirements.
Create one column for the DMARC result and separate columns for required authentication, DNS, transport, formatting and unsubscribe controls. An overall green indicator without those columns makes it difficult to tell whether the software is evaluating the protocol, a provider checklist or only published DNS syntax.
Use a truth table to expose the difference
References: RFC 9989 §5.3.5.
The private review package includes a two-case synthetic fixture. First, SPF and DKIM both pass but neither aligns: DMARC fails. Second, SPF fails while DKIM passes and aligns: DMARC passes. The second case can still fail a provider gate that independently requires SPF success.
These inputs are deliberately simple booleans, not an implementation of DNS Tree Walk discovery, legacy public-suffix-based discovery, SPF evaluation or DKIM cryptography. Both cases assume an applicable DMARC policy record exists. They make the logical distinction reproducible without pretending to test a provider. In a real investigation, replace each boolean with a trusted observed result and its evaluated identity.
Do not confuse publication with evaluation
References: RFC 9989 §5.4.
Publishing p=none establishes a requested monitoring policy, not a successful message authentication result. Publishing a DKIM public key does not sign outgoing mail. Adding an SPF record does not prove the actual connection used an authorized address. Each configuration artifact needs a corresponding observation from the intended sending route.
Similarly, moving from p=none to p=reject does not repair alignment. It changes the domain owner's requested handling for failures. Inventory legitimate routes before changing enforcement, preserve a rollback plan and evaluate the effect on indirect flows. The receiver still applies its own local disposition policy; a requested DMARC action is not a delivery guarantee.
Build a useful closure record
References: RFC 8601 §5.
For every investigated sample, retain From, envelope sender, connecting IP, DKIM signer and selector, mechanism results, alignment mode and final receiving response. Identify the trusted source of those results. Do not accept arbitrary copied headers as authoritative merely because they contain the word “pass.”
Close the protocol finding and the provider-compliance finding separately. This makes it possible to say accurately that DMARC passed while another requirement remained unresolved, and to assign the correction to the right owner without weakening unrelated controls.