Why Are Google and Microsoft Ignoring Your DMARC pct Tag?

You’ve done everything by the book. To begin your DMARC enforcement, you published a new policy: `p=quarantine; pct=10;`. The goal is simple and cautious: send just 10% of messages that fail DMARC to the spam folder, giving you a chance to monitor for problems without disrupting the entire mail flow. A day later, you check your RUA aggregate reports and your blood runs cold. Microsoft 365 isn’t quarantining 10% of failures. It’s quarantining 100%.

What gives? You check the syntax of your TXT record. It's perfect. You re-read the spec. You're sure you understand it. Yet, the real-world results defy the logic you so carefully implemented.

This isn’t a mistake on your end. It’s a brutal lesson in the gap between an RFC specification and the operational reality of how massive, independent mail systems interpret those rules. The `pct` tag isn't the precise dial you think it is; for some receivers, it's a button they choose to ignore.

The RFC Spec: A Recommendation, Not a Commandment

Before blaming the mailbox providers, let’s go to the source. RFC 7489 defines the `pct` (percentage) tag as a way for domain owners to stage the deployment of their DMARC policy. The idea is to apply the policy to a subset of mail to test the waters before going all-in.

The 'pct' tag (plain-text; OPTIONAL; default is "100") is an integer from 0 to 100, inclusive. It specifies the percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. — RFC 7489, Section 6.3

The key phrase here is "is to be applied." This language provides guidance to receivers, but it doesn't strictly command them. The RFC is a framework for interoperability, not a piece of code with enforceable logic. Receivers have final say on mail disposition. They can choose to honor the `pct` tag precisely, interpret it probabilistically, or, in some cases, completely disregard it in favor of a simpler, more absolute security posture. The `pct` tag is a request from your domain, not a binding contract.

Google Workspace's Probabilistic Game

Google's implementation of the `pct` tag is one of the most misunderstood aspects of DMARC enforcement. Many admins assume that if they set `pct=20`, Google will count failing messages and apply the policy to the first 20 out of every 100. This is not how it works.

pct as a Roll of the Dice

Google treats the `pct` value as a probability for each individual message. When an email arrives and fails DMARC, Gmail essentially rolls a digital die. If your policy is `pct=20`, that email has a 20% chance of having the policy (`quarantine` or `reject`) applied to it. The other 80% of the time, the policy is not applied, even though the message failed DMARC.

This means for small volumes of mail, the results can look erratic. You might send 10 failing messages and see 5 of them quarantined, or you might see none. Over millions of messages, the statistics will converge on your desired percentage. But for the SOC analyst trying to test a fix for a specific partner's mail flow, this randomness is maddening. You can't be sure if your fix worked or if you just got lucky on the last few test emails.

Operational Impact for Triage

This probabilistic approach makes targeted testing difficult. If you're debugging why a specific automated system's emails are failing DMARC, you can't rely on a handful of tests to confirm behavior. You need to look at aggregate RUA data over a day or two to see the true percentage of messages being acted upon. It's a system designed for large-scale statistical accuracy, not small-scale deterministic testing.

Microsoft 365's All-or-Nothing Quarantine

If Google's approach is statistically nuanced, Microsoft's is brutally simple, and it's the source of most of the confusion around the `dmarc pct tag ignored` problem. Our triage experience shows that when a domain's policy is `p=quarantine`, Microsoft 365 often applies that policy to 100% of failing messages, regardless of the `pct` value.

So, your carefully crafted `p=quarantine; pct=5;` policy is treated as if it were `p=quarantine; pct=100;`. All failing mail goes to the Junk Email folder. Why? The most likely reason is operational simplicity. Implementing a probabilistic filter across a massive, multi-tenant infrastructure like Exchange Online Protection (EOP) is computationally expensive and complex. It's far easier to enforce a binary rule: if DMARC fails and the policy is quarantine, then quarantine it. It’s a trade-off of RFC fidelity for performance and security simplicity.

Authentication-Results: spf=fail (sender IP is 198.51.100.24) smtp.mailfrom=yourdomain.com; dkim=fail (body hash did not verify) header.d=yourdomain.com; dmarc=fail (p=quarantine sp=none pct=10) action=quarantine header.from=yourdomain.com

This `Authentication-Results` header is the smoking gun. The receiver logs that it saw your `pct=10` policy, but in the same breath, it declares `action=quarantine`. The action speaks louder than the policy it acknowledged. For domain owners, this means using `pct` with `p=quarantine` is an unreliable method for gradual rollout if a significant portion of your mail goes to Microsoft 365.

How Email Forwarding Breaks Everything

Forwarding has always been the Achilles' heel of email authentication. When a message is forwarded, the chain of custody gets messy, and it can cause legitimate mail to fail DMARC, putting it at the mercy of the receiving server's interpretation of your policy.

Imagine a calendar invite sent from a vendor. Your company's mail server receives it, and you forward it from your work address to your personal Gmail account. The final receiver, Google, sees the email as coming from your company's mail server IP, not the original vendor's. This breaks SPF, as your company's IP is not in the vendor's SPF record (RFC 7208). If your mail server also added a footer like "This email was forwarded from...", it likely broke the DKIM signature (RFC 6376) by modifying the body hash.

Now Google receives a message that appears to be from the vendor but fails both SPF and DKIM checks. It looks up the vendor's DMARC record and sees `p=reject; pct=50;`. What should it do? The Authenticated Received Chain (ARC), defined in RFC 8617, is designed to solve this by preserving the initial authentication results. But ARC adoption is not yet universal. In its absence, the receiver has a choice: honor the `pct=50` for this broken-looking message or apply the `reject` policy to protect its user? Most will choose the latter. The `pct` tag is often the first casualty when a receiver's own threat heuristics kick in.

Your Triage Playbook: Use RUA Reports as Ground Truth

You can't fix what you can't see. Stop guessing how receivers are treating your policy and start using your DMARC aggregate (RUA) reports to get empirical evidence. These XML reports contain explicit feedback from receivers about what they did with your mail.

Find the 'disposition' Tag

Inside each RUA report, within the `<record>` section, you'll find a `<policy_evaluated>` block. This block contains a `<disposition>` tag, which can be `none`, `quarantine`, or `reject`. This tag tells you the final action the receiver took on that group of messages. This is critically different from the `<p>` and `<sp>` tags in the same block, which simply echo the policy *you* published. The `disposition` tag is the receiver telling you, "Here is what I actually did."

Correlating Policy with Reality

The playbook is straightforward. First, parse your RUA reports and group the data by receiver. Then, for each major receiver like Google or Microsoft, filter for all messages that failed DMARC. Finally, compare the total count of failing messages to the count of messages where the `disposition` was `quarantine` or `reject`. This will give you the *effective* percentage. If you see 1,000 DMARC failures from `outlook.com` and 1,000 of them have a disposition of `quarantine`, you know Microsoft is ignoring your `pct=10` tag. This data is your leverage for making informed decisions.

The Better Strategy: Ramp 'pct' Under p=reject

Given the wild inconsistency in how `p=quarantine` and `pct` interact, using it as your primary tool for gradual enforcement is fraught with risk and unpredictability. You end up with some receivers junking everything while others sample correctly, creating a chaotic and confusing situation for your users and legitimate senders.

A far more reliable and controlled strategy is to separate the phases. First, use `p=quarantine; pct=100;` to get all your legitimate mail flows identified and fixed. Stay at this level until your RUA reports show that almost all of your valid business email is passing DMARC. You're using quarantine as an extended monitoring phase, not a final destination.

Once you're confident, make the switch to `p=reject`, but start small: `p=reject; pct=1;`. Because outright rejecting mail is a much more destructive action than quarantining it, our analysis shows that mailbox providers tend to honor the `pct` tag more faithfully under a reject policy. They are more careful when the stakes are higher. From there, you can slowly and predictably increase the percentage: `pct=5`, `pct=10`, `pct=25`, `pct=50`, and finally `pct=100`. This method provides a predictable, auditable path to full enforcement, minimizing the chances of a catastrophic surprise.

The takeaway

The DMARC `pct` tag is a dial, but the markings on that dial are drawn differently by every engineer at every major mailbox provider. Stop treating it as a precision instrument, because it isn't one—especially when paired with `p=quarantine`. The only ground truth is what you see in your RUA reports, which reflect the actions receivers are actually taking.

If you want a predictable journey to DMARC enforcement, use `pct` to ramp up a `p=reject` policy, not a `p=quarantine` one. Parsing thousands of individual RUA XML reports to track this receiver behavior is the kind of tedious work that platforms like MailSleuth.AI were built to automate, allowing you to focus on the policy decision, not the data wrangling. Move from monitoring to enforcement with data, not hope.