close up photo of mounted shabby box

A DMARC Record Is Only a Suggestion

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, that is not a sign your DMARC implementation is broken. It is a sign that the receiver 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

  1. 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]). ↩︎
  2. Microsoft Corporation, Email Authentication in Microsoft 365, Microsoft Learn (July 7, 2025), https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about. ↩︎
  3. Id. ↩︎
  4. DMARC, supra note 1 at § 6.7 (“At a minimum, addition of the Authentication-Results header field … is RECOMMENDED when delivery of failing mail is done.”). ↩︎

About the Author

Mickey Chandler
Mickey Chandler Consultant & Attorney

Mickey Chandler is a Consultant & Attorney with over 28 years of experience in Email Deliverability & Privacy Law. He has a strong background in email authentication infrastructure (SPF, DKIM, DMARC), ISP and mailbox provider relations, anti-spam policy and compliance, CAN-SPAM and state anti-spam law gained through overseeing the Abuse & Compliance team at Salesforce Marketing Cloud, originating the ISP relations role at Informz (now part of Higher Logic), and working in the fight against spam since 1997. He holds a B.A. in Government, a B.S. in Computer Information Systems, and a J.D. from the University of Houston Law Center. He is a certified CIPP/US professional and a certified CIPM professional.