What happens to emails that fail DMARC when pct is set to less than 100?

When an email fails DMARC and the pct tag is below 100, the receiving mail server randomly samples a percentage of those failing messages to apply the policy (quarantine or reject). The remaining failing messages are allowed through as if the policy were set to none, though all of them still generate aggregate monitoring reports.

Does the pct tag affect emails that pass SPF or DKIM alignment?

No. The pct tag has zero effect on messages that successfully pass DMARC alignment. Those messages are delivered normally regardless of whether pct is set to 10, 50, or 100.

Can I use decimal values like pct=50.5 in my DMARC record?

No, the DMARC specification requires the pct value to be a whole integer between 0 and 100. Using decimals or numbers outside this range can cause mail servers to misinterpret or ignore your policy setting.

Why is the pct tag useless when paired with p=none?

The p=none policy instructs receiving servers to take no punitive action against failing emails, only sending back diagnostic reports. Since no action is applied to failing messages anyway, a percentage limiter is unnecessary and ignored.

How long should I keep a low pct value before increasing it?

You should maintain a low pct value for at least one to two weeks, or until you have reviewed enough aggregate XML reports to confirm that all legitimate mail streams are passing authentication without unexpected drops.

Mastering DMARC pct Tag Usage: A Complete Guide

The pct tag in a DMARC record specifies the percentage of messages to which the DMARC policy (p tag) is applied. By setting a fractional value like pct=20, you can safely test a strict policy on a small slice of your email traffic before rolling it out domain-wide. This incremental rollout strategy prevents legitimate transactional or marketing emails from breaking due to misconfigured SPF or DKIM alignment.

The Core Mechanics of DMARC and the Percentage Tag

Domain-based Message Authentication, Reporting, and Conformance (DMARC) relies on SPF and DKIM to verify email authenticity. When you publish a DMARC record, receiving mail servers check whether incoming mail aligns with your domain. If authentication fails, the DMARC policy dictates what the server should do: take no action (none), quarantine the message (quarantine), or reject it outright (reject).

Without the pct tag, a policy applies to 100% of emails failing authentication immediately. For a large organization, jumping straight to p=reject can cause catastrophic delivery failures if a third-party mailing service or internal system lacks proper DKIM signatures. The pct tag acts as a safety valve, sampling a subset of failing emails while letting the rest pass through.

How Mail Servers Evaluate the pct Tag

When a receiving mail server processes an email that fails DMARC authentication, it evaluates the policy and then checks the pct value. If pct=25, the receiving server randomly selects approximately 25% of the failing messages to apply the p=quarantine or p=reject policy to. The remaining 75% of failing messages are treated as if the policy were p=none, though they still trigger aggregate (RUA) and forensic (RUF) XML reports.

It is important to understand that the sampling happens on a per-message, random basis at the receiving server. You cannot control which specific recipients or messages fall into the sampled percentage.

DMARC Record Syntax and Placement

A DMARC record is published as a DNS TXT record at the subdomain _dmarc.example.com. The record consists of several semicolon-separated tags, including v, p, rua, and optionally pct.

Here is an example of a DMARC record using the percentage tag for a partial quarantine rollout:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com;"

Breakdown of Tags in the Record

v=DMARC1: Specifies the DMARC protocol version. This must always be the first tag.
p=quarantine: Defines the target policy for failing emails. Receiving servers should send these messages to the spam folder.
pct=25: Instructs the receiving server to apply the quarantine policy to only 25% of failing messages.
rua=mailto:...: Specifies the destination email address for aggregate XML reports.

Before modifying your production DNS, you should always validate your syntax using the DMARC Checker to instantly spot typos, missing semicolons, or invalid tag values that could invalidate your policy.

Step-by-Step Guide to Implementing dmarc pct Tag Usage

Rolling out DMARC successfully requires a phased approach. Follow these steps to transition from monitoring to complete rejection safely.

Step 1: Establish Baseline Monitoring

Start with a policy of none to gather data without impacting deliverability. Ensure your rua tag points to a valid monitoring mailbox or reporting service.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;"

Monitor your reports for a few weeks until all legitimate mail streams—including marketing platforms, CRM tools, and transactional servers—show 100% SPF and DKIM alignment.

Step 2: Introduce Quarantine with a Low Percentage

Once legitimate mail is fully aligned, upgrade your policy to quarantine but restrict its impact using a low pct value, such as 10% or 20%.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc-reports@example.com;"

Query your DNS record using command-line tools to confirm the update has propagated globally:

nslookup -type=TXT _dmarc.example.com

Or use dig on Linux and macOS systems:

dig +short TXT _dmarc.example.com

Sample output:

"v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc-reports@example.com;"

Step 3: Incrementally Increase the Percentage

Analyze your aggregate reports over the next week. If users or internal teams do not report missing emails and your failure rates are understood, step the percentage up:

Week 1: pct=20
Week 2: pct=50
Week 3: pct=80

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=80; rua=mailto:dmarc-reports@example.com;"

Step 4: Remove the pct Tag and Graduate to Rejection

Once p=quarantine runs smoothly at 100% capacity (either by removing pct entirely or setting pct=100), you can repeat the process for the ultimate policy: p=reject.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@example.com;"

Gradually increase pct for the reject policy until you reach 100% full enforcement.

Comparing DMARC Rollout Strategies

| Strategy Approach | Record Example | Risk Level | Best Used For | |-------------------||------------|----------------| | Pure Monitoring | p=none; | Zero Risk | Initial setup and auditing mail sources. | | Fractional Quarantine | p=quarantine; pct=25; | Low Risk | Testing spam folder placement on a subset of unaligned mail. | | Full Quarantine | p=quarantine; | Medium Risk | Confirming zero legitimate mail is flagged before reject. | | Fractional Rejection | p=reject; pct=10; | Medium Risk | Testing hard bounces on a tiny slice of failing mail. | | Full Enforcement | p=reject; | Low (if tested) | Complete protection against spoofing and phishing. |

Common Mistakes with DMARC pct Tag Usage and How to Fix Them

Misinterpreting how the percentage tag functions often leads to unexpected email delivery drops or blind spots in monitoring.

Mistake 1: Assuming pct Applies to All Messages

The Error: Believing that pct=50 means 50% of your total outbound email volume is checked or processed.

The Reality: The pct tag only applies to messages that have already failed DMARC authentication. Messages that pass SPF or DKIM alignment are delivered normally regardless of the pct value. If 95% of your mail passes authentication, a pct=10 setting on a p=reject policy only impacts 10% of the remaining 5% failing messages.

Mistake 2: Using pct with p=none

The Error: Including pct=50 inside a record where the policy is p=none.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=50; rua=mailto:reports@example.com;"

The Reality: The p=none policy takes no action on failing messages; it only generates reports. Because no action is taken, the pct tag is entirely redundant and ignored by compliant receiving mail servers. Always omit pct when your policy is p=none.

Mistake 3: Forgetting to Remove pct After Testing

The Error: Leaving pct=20 permanently in a p=reject record, leaving 80% of spoofed, malicious emails delivered to inboxes.

The Reality: The percentage tag is meant strictly as a transitional testing mechanism. Once your systems are stable under quarantine or rejection, remove the pct tag so it defaults to 100% enforcement.

Mistake 4: Invalid Numeric Formats

The Error: Entering decimals or out-of-range numbers like pct=25.5 or pct=150.

The Reality: The pct value must be an integer between 0 and 100. Values outside this range cause mail servers to ignore the tag or default to 100% enforcement depending on the parser implementation.

Quick Checklist for DMARC pct Implementation

Verify all legitimate sending IPs and third-party tools are authenticated via SPF and DKIM.
Confirm your aggregate reporting (rua) address is active and receiving XML files.
Set an initial transitional policy such as p=quarantine; pct=10;.
Monitor aggregate reports daily for at least one full business cycle.
Step up the percentage in increments (e.g., 10% -> 25% -> 50% -> 100%).
Remove the pct tag once 100% enforcement is verified and stable.
Proceed to p=reject and repeat the fractional rollout process if desired.

Understanding the Percentage Tag (pct) in DMARC Records