Moving a domain to a DMARC policy of quarantine or reject is the point at which DMARC starts to protect you, and also the point at which a forgotten sender gets its mail thrown away. The pct tag was designed for this moment. It lets you say "apply my policy to only some of the failing messages", so that a mistake affects a fraction of the mail instead of all of it. It sounds like the perfect safety net, and in many guides it is presented as the standard way to roll out DMARC. The reality is more nuanced. The tag works as intended at some receivers, is applied unevenly at others, interacts with the policy in a way that surprises people, and does not replace the thing that actually makes enforcement safe: reading your reports and fixing every legitimate sender. This guide explains exactly what pct does, shows how the fallback behaviour works, gives a stepwise rollout plan, and lists the limits and mistakes so that you can use the tag with realistic expectations.
What pct does
The DMARC record can include pct= followed by a number from 0 to 100. It is optional, and when it is omitted the value is 100, which means the policy applies to all messages that fail DMARC. When you set a lower value, the receiver applies the policy to roughly that share of the failing messages and applies a weaker treatment to the others. The tag works on the messages that fail DMARC, not on all mail. Passing messages are unaffected. RFC 7489 describes it as the percentage of messages subjected to filtering, and says the sampling is up to the receiver; there is no promise about exact proportions or about which messages are chosen.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"This record says: for mail that fails DMARC, put about a quarter of it in quarantine, and treat the remainder as if the policy were none. The remainder is delivered normally, but still reported.
How the fallback works
| Record | Share of failing mail | Treatment of that share | Treatment of the rest |
|---|---|---|---|
p=quarantine; pct=25 | 25% | Quarantine (usually spam folder) | Delivered as with p=none |
p=quarantine; pct=100 | 100% | Quarantine | None left |
p=reject; pct=25 | 25% | Reject | Quarantine (the next weaker policy) |
p=reject; pct=50 | 50% | Reject | Quarantine |
p=reject; pct=0 | 0% | Nothing is rejected | Quarantine, according to the standard |
p=none; pct=10 | Irrelevant | No effect | No effect |
Pay attention to the p=reject rows. When you use pct below 100 with reject, the messages not selected for rejection are not delivered unharmed: the standard says they should be treated as quarantined. That makes p=reject; pct=25 much stricter than people assume, because the remaining 75 per cent of failing mail goes to spam folders. Only p=quarantine with a low percentage leaves the unselected messages untouched. Whether a receiver follows this exactly is another matter, as the next section explains.
Limits of pct
- Uneven support. Receivers implement
pctin different ways. Some honour it faithfully, some round it, some treat anything other than 0 or 100 as all-or-nothing, and some ignore it. You cannot count on a precise fraction at every receiver. - Random, not targeted. The selection of messages is random. You cannot choose to apply the policy only to one sender, one stream or one receiving domain. If a vendor fails DMARC, a share of its mail is affected, at random, at the receivers that support the tag.
- It reduces harm, it does not find problems. A failing legitimate sender is still failing; the tag only makes it fail less often. You still need reports to find it. A rollout where you do nothing between steps teaches you little.
- Partial protection against spoofing. While pct is low, most spoofed mail also gets through. You get the full protection only at 100.
- The standard is evolving. Work on the next version of DMARC has proposed replacing
pctwith a simpler testing flag, because the percentage model has been inconsistent in practice. Check the current state of the specification and the documentation of the receivers that matter to you, because the guidance on this tag may change.
A safe rollout plan
Use pct as one part of a longer plan, not as the plan. The sequence below keeps the risk low and uses each step to learn.
- Collect data with p=none. Publish a record with
p=noneand aruaaddress. Read the aggregate reports for several weeks, including month-end and any seasonal sends. See DMARC aggregate reports and moving to reject. - Fix every legitimate failing source. For each service that sends as your domain, complete domain authentication so that DKIM signs with your domain, and align the return path if you can. Use managing several vendors on one domain to organise the work.
- Start enforcement small. Change to
p=quarantine; pct=5orpct=10. At this level the effect of an overlooked sender is small and visible in the reports. - Watch for a defined period. A week or two is typical. Check the reports for new failing sources, and ask the teams that send mail whether anyone saw missing messages.
- Raise the share. Move to 25, 50 and 100 per cent in steps, with a pause and a check at each.
- Reach p=quarantine; pct=100. Hold here until the reports show consistent passing for all legitimate mail.
- Move to reject. Use
p=reject; pct=10or a similar small share first, remembering the fallback to quarantine for the rest, then raise it in steps to 100. Alternatively, move to reject at 100 directly if your reports are clean and your mail volume is simple. - Remove the tag. Once you are at 100, delete
pctto keep the record clean; 100 is the default.
For subdomains, remember that the policy for a subdomain without its own record is inherited from the parent; see DMARC subdomain policy. A rollout on the main domain can break a sending subdomain that has not been prepared.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
Believing pct=50 with reject delivers the other half | The remainder is quarantined, so most failing mail still goes to spam | Plan for the fallback; test with quarantine first |
Leaving pct=10 in place for years | Weak protection; spoofed mail mostly gets through | Set a date and keep moving to 100 |
| Raising pct with no look at reports | You learn about a failing sender from angry users | Check reports and ask teams before each step |
Setting pct outside 0 to 100, or with a decimal | Invalid; may be ignored or the record rejected | Use whole numbers from 0 to 100 |
| Putting pct before v= or omitting the semicolon | The record is ignored | Start with v=DMARC1; and separate tags with semicolons |
| Expecting pct to apply to passing mail | It does not; only failures are affected | Fix the failures |
| Using pct with p=none | No effect | Use pct only with quarantine or reject |
Check the syntax with the SPF, DKIM and DMARC checker and read DMARC record syntax for the other tags. For the meaning of the three policies, see DMARC policy: none, quarantine, reject.
What to do when a legitimate sender starts failing
The sign is a report row showing a source IP address or service with a high failure count, or a complaint from a team that mail is going to spam. First find which service it is, using the sending IP and the DKIM domain in the report. Then fix its authentication: publish its DKIM record, set a custom return path, or both. While you do this, you may lower pct to reduce the impact, or return to p=none for a short time if the damage is serious. Note what changed, and wait for the next reports to confirm that the failures have stopped before you increase the share again. If the message reaches the inbox at some receivers and fails at others, see rejected due to DMARC policy for the diagnosis.
Reach DMARC enforcement with confidence Authenticate every sender with aligned DKIM and return-path records, then move to quarantine and reject step by step.
References and further reading
Frequently asked questions
What does the DMARC pct tag do?
It sets the percentage of messages that fail DMARC to which the policy is applied. The default is 100. The remainder is handled under the next weaker policy.
What happens to the rest when pct is below 100 with p=reject?
According to the standard, they are treated as quarantined, not delivered normally. Only p=quarantine with a low pct leaves the unselected failing mail untouched.
Do all receivers honour the pct tag?
No. Support varies, so you cannot rely on an exact fraction. Use pct to limit risk, not as a precise control.
How long should I keep pct below 100?
Only as long as you are validating senders. Set a schedule, review reports at each step and aim to reach 100 within weeks, not years.
Should I use pct instead of reading DMARC reports?
No. pct limits the damage from a missed sender, but only the aggregate reports show you which senders are failing.