A question came up recently on a Slack for email professionals: a message spoofing a domain with a DMARC policy of p=reject failed SPF and carried no DKIM signature, but Google put it in the spam folder instead of rejecting it. The Authentication-Results header read dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE). The domain owner wanted to know why their policy wasn't honored.
The policy was being read. It just wasn't being obeyed.
The reason comes down to one word in RFC 7489. The standard says that p=reject states what the domain owner "wishes" receivers to do with messages that fail DMARC.1 Receivers may depart from that when they judge the circumstances warrant it. RFC 7489 does not define the circumstances that justify departure, so that determination belongs solely to the receiver.
The dis= field in Google's Authentication-Results header is where that determination gets recorded. p= says what you asked for. dis= says what Google did. In most cases, those will be the same. But in this case dis=QUARANTINE means Google read p=reject but applied p=quarantine. The message failed every available authentication check, yet the receiver still chose to route this message to the spam folder rather than reject it.
Microsoft does the same, but handles it slightly differently. Its Authentication-Results header records the applied disposition in an action= field rather than dis=. A message that fails DMARC under a p=reject policy might show action=none if Microsoft's composite authentication signals led it to a different conclusion than outright rejection.2 The composite authentication check draws on sender reputation, recipient history, and behavioral analysis in addition to SPF and DKIM results, and its result can be seen by looking for compauth=.3
Neither mailbox provider is required to disclose how they ultimately disposed of a message4 in this or any other way, and many won't show anything at all. These are implementation choices, not standard fields. But, if you want to know what a given receiver decided, you need to know if they disclose and which field that receiver uses to disclose it.
Publishing p=reject is correct for a domain that has completed authentication alignment and confirmed its sending infrastructure. Receivers routinely honor it. But what it is not is a guarantee.
When you see dis=QUARANTINE on a message that failed authentication for your domain, your DMARC implementation did its job. The receiver read your policy and made a different call.
Your DMARC record tells receivers what you want to happen to messages that don't pass authentication. But they still get to decide what to do with it.
Footnotes
- Murray Kucherawy & Elizabeth Zwicky, Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC 7489 § 6.3 (Mar. 2015), https://datatracker.ietf.org/doc/rfc7489/ ("reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction." (emphasis added)). RFC 7489 has since been obsoleted by RFC 9989, https://www.rfc-editor.org/rfc/rfc9989. ↩︎
- Microsoft Corporation, Email Authentication in Microsoft 365, Microsoft Learn (July 7, 2025), https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about. ↩︎
- Id. ↩︎
- RFC 7489, supra note 1, § 6.7 ("At a minimum, addition of the Authentication-Results header field . . . is RECOMMENDED when delivery of failing mail is done."). ↩︎


Comments
Leave a comment