The DMARC pct tag tells receiving mail servers what percentage of your failing messages should have your published policy applied, which lets you turn on enforcement gradually instead of flipping a switch on 100% of your traffic. The trap almost every guide gets wrong is what happens to the mail that is not selected. Receivers do not skip enforcement on it. They apply the next lower policy. So p=reject; pct=50 does not reject half your failing mail and let the rest through untouched. It rejects half and quarantines the other half.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
That downgrade behavior is the single most important thing to understand before you touch pct, because it changes how you plan a rollout and how you read the impact. Below is what the tag does, the exact ramp schedule that keeps legitimate mail flowing, and why you should treat pct as a temporary tool rather than a permanent part of your record.
What the pct tag actually does
pct is defined in RFC 7489 as an integer from 0 to 100 that sets the percentage of messages from your domain that a receiver should subject to your DMARC policy. If you omit it, the default is 100, meaning your policy applies to everything that fails. Set pct=25 and a receiver applies your policy to roughly one in four failing messages, chosen at random per message.
A complete record with the tag looks like this:
v=DMARC1; p=reject; pct=25; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1
Two things are worth stating plainly. First, pct only affects messages that already fail DMARC. Mail that passes SPF or DKIM with alignment is never touched, no matter what you set here. Second, pct never changes your reporting. Aggregate (rua) reports still cover 100% of your mail, so you keep full visibility into every source even while you enforce on a slice. That is what makes a phased rollout safe: you see everything, you act on part of it.
If you are still deciding between policy levels themselves, read DMARC policy: none vs quarantine vs reject first, then come back to pacing the enforcement.
The downgrade rule that trips everyone up
Here is the sentence from RFC 7489 that most blog posts leave out. When a message is not selected by the pct sampling, the receiver applies the next policy down from the one you published. Reject becomes quarantine. Quarantine becomes none.
Walk through the two real cases:
p=reject; pct=50means 50% of failing mail is rejected and the other 50% is quarantined. None of it is delivered normally to the inbox.p=quarantine; pct=50means 50% of failing mail is quarantined and the other 50% gets no action, so it lands in the inbox.
This matters enormously for planning. People assume pct=10 on a reject policy means "block 10%, deliver 90% as before." It does not. It means "reject 10%, quarantine 90%." If any of your legitimate senders are failing alignment, that 90% is going to the spam folder, not the inbox. So a low pct on p=reject is still aggressive. The safest way to introduce hard enforcement is to reach p=quarantine; pct=100 cleanly first, confirm your reports are clean, and only then move to reject.
A week-by-week enforcement ramp
Assuming you have already sat at p=none long enough to identify and fix your legitimate senders, here is a ramp that moves you to full enforcement over roughly four to six weeks. Each step is gated on reading reports, not on the calendar alone. If a step surfaces a broken source, you stop, fix it, and hold before advancing.
Weeks 1 to 2: quarantine at low percentage
Publish p=quarantine; pct=10. Now 10% of failing mail is quarantined and 90% is untouched, so the blast radius is small. Read a full week of aggregate reports. You are looking for any source that fails both SPF alignment and DKIM alignment but is clearly yours: a billing platform, a help-desk tool, a marketing sender you forgot about.
Week 2 to 3: raise to 25, then 50
If reports are clean, move to pct=25, wait a few days, then pct=50. At 50% you are quarantining half of all failing mail, which is enough volume that any remaining broken source will show up loudly in complaints or in your report data. This is the checkpoint where forwarding-related failures often appear, because a forwarded message can break SPF. If you see those, understand the cause in why email forwarding breaks SPF before you assume a sender is misconfigured.
Week 3 to 4: quarantine at 100
Set p=quarantine; pct=100 and hold for at least a week. Every failing message is now quarantined. If your legitimate mail is authenticating correctly, your delivery is unaffected because passing mail is never subject to policy. A clean week here is your green light for reject.
Week 4 onward: reject at 100
Go straight to p=reject; pct=100. Do not bother with a low pct on reject, because as shown above it only demotes the remainder to quarantine, which you have already been running at 100% for a week. There is little to gain and the semantics confuse operators. Jumping to full reject after a clean quarantine week is the standard, safe finish. For the full policy-transition playbook, see how to move DMARC from none to reject.
How to read reports before each step
The ramp is only as safe as your report review. Each aggregate report is XML from a receiver summarizing how your mail authenticated over a day. Before advancing a step, confirm three things: every high-volume sending IP resolves to a source you recognize, each of those sources passes SPF alignment or DKIM alignment (ideally both), and the count of failing-but-legitimate mail is trending to zero.
If a source you own is failing, fix the underlying authentication rather than lowering pct to hide it. Lowering the percentage does not fix a broken sender, it just delays the day it breaks. Our walkthrough on how to read a DMARC aggregate report covers exactly which XML fields to check and how to map an IP back to a service.
The core reason to gate on reports is that pct protects you from your own blind spots, not from attackers. Attackers spoofing your domain will fail DMARC regardless. The percentage exists so that when one of your own senders is misconfigured in a way your reports have not yet revealed, only a fraction of that mail is affected while you catch it.
DMARCbis deprecates pct: future-proof your record
DMARCbis, the updated DMARC specification published in 2026 as RFC 9989, removes the pct tag. It is replaced by a single t (test mode) tag, where t=y signals a testing posture rather than a probabilistic percentage. The working group dropped pct because the downgrade behavior described above was widely misunderstood and inconsistently implemented across receivers, and because values other than 0 and 100 rarely produced predictable results at scale.
Practically, this means two things. Keep using pct today if you need a gradual rollout, because current receivers still honor it. But do not build long-term process around it. Treat it as scaffolding you remove once you reach p=reject; pct=100. A finished record should carry no pct tag at all, which is both the RFC 7489 default of 100 and the direction DMARCbis is standardizing. If you are publishing a fresh record from scratch, our DMARC setup guide shows the clean, durable form.
Frequently asked questions
Does pct=50 with p=reject let half my mail through?
No. It rejects 50% of failing mail and quarantines the other 50%. None of your failing mail is delivered normally to the inbox. The unselected portion drops to the next lower policy, which for reject is quarantine, not none.
Should I use a low pct when I move to reject?
No. Because the remainder of a reject policy is demoted to quarantine, a low pct on p=reject behaves almost identically to p=quarantine; pct=100. Reach a clean quarantine at 100% first, then jump straight to p=reject; pct=100.
Will pct reduce the DMARC reports I receive?
No. The pct tag only affects policy enforcement on failing mail. Aggregate reports still cover 100% of your traffic, so you keep full visibility into every sending source throughout the ramp.
If DMARCbis deprecates pct, should I stop using it now?
You can still use it for a phased rollout, since current receivers honor it. Just remove it once you reach full reject. A finished record needs no pct tag, which matches both the RFC 7489 default and the DMARCbis direction.