Postmortem: How p=reject pct=10 Let a CEO Spoof Through

The alert was textbook. A high-priority Business Email Compromise flag on an email from the CEO to the finance department, asking for an urgent wire transfer to a 'new vendor.' The pretext was plausible, the timing was perfect—end of quarter. But something felt off. Our initial DNS query for the company's DMARC record came back with `p=reject`. The SOC analyst who caught it was stumped. How could a direct spoof from the CEO's actual domain get through a rejection policy?

It's a question we see more often than you'd think. The assumption that `p=reject` is an impenetrable shield is a dangerous one. In this case, the attacker didn't need to find a zero-day or compromise a legitimate mail server. They just needed to understand one small, often-misunderstood tag in the DMARC record: `pct`.

This incident is a perfect case study in how a partially implemented security control can be worse than no control at all, creating a false sense of security that both analysts and automated systems can misinterpret. The evidence was right there in the email headers, waiting for someone to connect the DNS record to the final mail-handling verdict.

The Alert: A Direct Spoof Against a 'Protected' Domain

The initial triage began with the usual checklist for a BEC attempt. First, we checked for lookalike domains—was the `l` in the company name actually a capital `I`? Were there subtle Unicode shenanigans at play? Nope. The `header.from` address was `ceo@theirdomain.com`, character for character. It was the real thing.

The next logical step was to check the authentication posture of `theirdomain.com`. A quick `dig txt _dmarc.theirdomain.com` in the terminal produced the following:

v=DMARC1; p=reject; rua=mailto:aggrep@dmarc.forensics.com; pct=10;

This is where the confusion started. The analyst saw `p=reject`—the strictest possible policy, defined in RFC 7489 as the domain owner's request to receivers to refuse delivery of unauthenticated mail. So why was this email sitting in an inbox instead of being bounced at the gateway? The SOC team's working theory was that a misconfigured forwarder or a mailing list must have broken the authentication chain, maybe stripping a DKIM signature. But the headers told a simpler, more alarming story.

The `pct` Fallacy: How Receivers Probabilistically Apply Your Policy

The `pct` tag is one of the most misused and misunderstood components of the DMARC standard. Many admins believe `pct=10` means that 10% of *all* failing email will be rejected. This is incorrect. The reality is far more favorable to an attacker.

A Tool for Staged Rollouts, Not a Filter

RFC 7489 defines the `pct` (percent) tag as a way for domain owners to stage the deployment of their DMARC policy. It instructs receiving mail transfer agents (MTAs) to apply the `p=quarantine` or `p=reject` policy to a certain percentage of emails that *fail* the DMARC evaluation. For the remaining `100 - pct` portion of failing emails, the receiver is instructed to take no action, effectively overriding the stricter policy with `p=none`.

So, with a `pct=10` policy, an attacker who sends 10 spoofed emails isn't guaranteed to have one delivered. They know that for every email they send, there's a 90% chance the recipient's mail server will see the `p=reject` policy, see the `pct=10` tag, roll a figurative 100-sided die, and if the result is higher than 10, it will ignore the reject policy and deliver the email. It's a numbers game, and the odds are heavily in their favor.

The Receiver's Perspective

Imagine you're the receiving MTA. An email arrives claiming to be from `ceo@theirdomain.com`. You perform the DMARC checks. SPF fails alignment because the source IP isn't in their SPF record (RFC 7208). DKIM fails alignment because there's no valid signature (RFC 6376) from `theirdomain.com`. The overall DMARC result is a clear `fail`.

Now, what do you do with it? You look at the DMARC policy: `p=reject`. But wait, there's also `pct=10`. Your job as a compliant MTA is to honor that request. You generate a random number between 0 and 99. If it's less than 10, you apply the `reject` policy. If it's 10 or greater, you apply `none`. The attacker just has to send a few messages to get one that benefits from this statistical override.

Forensic Analysis: Finding the `action=none` Override

Theory is one thing, but proof lives in the headers. The 'smoking gun' for a `pct`-based bypass isn't just the DMARC record in DNS; it's the `Authentication-Results` header field in the delivered email. This header, standardized by RFC 8601, is where the inbound mail gateway stamps its verdict for all to see.

When we pulled the raw source of the CEO spoof, we found this exact line, added by the organization's own cloud email provider:

Authentication-Results: mta.bigcloudprovider.com; dmarc=fail (p=reject sp=reject pct=10) reason="policy_override" action=none header.from=theirdomain.com

Let's break this down piece by piece. `dmarc=fail` is the evaluation result; the email is not authentic. `(p=reject sp=reject pct=10)` is the MTA reporting the policy it found in DNS. And here's the critical part: `action=none`. This is the final disposition—what the MTA actually *did*. The inclusion of `reason="policy_override"` by some providers makes it even more explicit. The policy was `reject`, but the applied action was `none`, thanks entirely to the `pct` tag.

Why the SOC Missed It: Signal Interpretation Failure

This incident highlights a major cognitive bias in security analysis. We're trained to pattern-match, and the `p=reject` pattern often gets mentally filed under 'problem solved.' The nuance of the `pct` tag is easily missed if you're not specifically looking for it.

The Peril of the 'Paper Tiger' Policy

A DMARC policy with `pct<100` is effectively a paper tiger. It looks intimidating, but it has no real teeth. Even worse, it sends a clear signal to any semi-competent attacker: this domain owner is in the middle of a DMARC rollout and likely has unauthenticated mail streams they haven't fixed yet. They are broadcasting their own weakness.

Threat actors don't guess. They can, and do, script DNS lookups to actively hunt for domains with `p=reject` or `p=quarantine` combined with `pct<100`. These are prime targets for simple, direct-spoof BEC attacks because the actor knows their fraudulent emails have a high probability of delivery.

Furthermore, many security tools and SIEMs are guilty of oversimplification. An alert might just say 'DMARC Failed' without surfacing the crucial difference between the published policy (`p=reject`) and the applied action (`action=none`). Without this context, an analyst is flying blind, and might waste hours chasing complex forwarding scenarios when the answer is a simple, probabilistic bypass.

The Triage Workflow: Distinguishing a Bypass from a Pass

For the frontline analyst, this means the triage workflow for a suspected spoof needs an extra step. It’s not enough to see that DMARC failed.

Correlate DNS with Header Results

First, ingest the full, raw email headers. Don't rely on the summary view in your mail client or a security gateway dashboard. You need the complete `Authentication-Results` chain. Second, perform a live DNS lookup for the `_dmarc` record of the purported sending domain. Now, compare the two.

Does the `p=` value in DNS match the `action=` in the header? If your DNS query shows `p=reject` but the header shows `action=none`, you've found a policy override. The `pct` tag is the most common cause. This is a fundamentally different incident than one where DMARC passes. A `pass` on a malicious email implies a compromised account or application that is a legitimate sender for the domain. A `pct` bypass implies a simple spoof from an attacker's server. The containment and remediation paths are completely different.

Closing the Gap: The Operational Peril of Lingering at `pct<100`

The `pct` tag is a valuable tool for a specific, temporary purpose: to safely gather data on your email streams before going to full enforcement. The idea is to start at `p=none`, move to `p=quarantine pct=5` or `pct=10`, analyze the RUA reports for legitimate services that are failing authentication, fix them, and gradually increase the percentage to 100.

The danger is 'rollout fatigue.' Teams get to `pct=10` or `pct=20`, fix the big, noisy failures from their main corporate email and marketing platforms, and then declare victory. The `pct` tag is left in place for months, sometimes years. It becomes a permanent fixture.

This state of perpetual rollout is a critical vulnerability. It's an open invitation for exactly the kind of attack this postmortem describes. It tells the world you know you have a problem but haven't fully committed to fixing it. The only secure state for DMARC is 100% enforcement. Anything less is a gamble.

The takeaway

The `pct` tag isn't a design flaw in DMARC. The flaw is organizational—it's the habit of stopping a critical security project halfway. A `p=reject pct=10` policy isn't 10% protection; it's a 90% chance of failure for every single spoofed email, an open door masquerading as a brick wall.

Hunting through raw headers and correlating DNS policies to `Authentication-Results` verdicts is the core work of email threat analysis. It’s tedious but necessary to find the root cause. This is precisely why tools like MailSleuth.AI exist—to automate that correlation, flagging the specific `pct` override so analysts can immediately distinguish a probabilistic bypass from a more complex account compromise. Don't let your DMARC rollout become another vulnerability.