Does a DMARC policy with quarantine and pct=0 actually do anything?
Updated on 9 Aug 2026: We updated this guide for RFC 9989, which makes pct historic and introduces t=y for testing.
Yes, but the result now depends on which DMARC specification the receiver follows. RFC 9989 made pct historic. A receiver following the current specification ignores pct=0 as an unknown tag and can apply p=quarantine to all mail that fails DMARC. A legacy receiver following RFC 7489 can still treat the same record as zero-percent quarantine. Aggregate reporting through rua can continue in either case.
Do not use p=quarantine; pct=0 as a predictable staging state now. It has split semantics during the standards transition. RFC 9989 uses t=y for testing, but older receivers can ignore that new tag. Use p=none when monitoring must have the clearest behavior across receiver generations.
- Direct answer: The record can request full quarantine or zero quarantine, depending on receiver support.
- Current receiver: It ignores historic pct=0 and applies the published quarantine policy.
- Legacy receiver: It can honor pct=0 and apply no requested quarantine action.
- Best action: Remove pct and publish an intentional monitoring or enforcement state, with any test documented separately.
The short answer
A DMARC policy tells receivers how the domain owner wants failed mail handled. A reporting address separately requests aggregate data about mail claiming to use the domain. A record with p=quarantine and pct=0 can still support DMARC monitoring when rua is valid. Its policy effect is no longer consistent because current receivers ignore the historic percentage tag while legacy receivers can honor it.
What this record says now
- Policy preference: The domain owner publishes quarantine for mail that fails DMARC.
- Current application: RFC 9989 receivers ignore pct and can apply quarantine in full.
- Legacy application: RFC 7489 receivers can reduce the requested quarantine action to zero.
- Report flow: Aggregate reports can still arrive when rua is present and the receiver sends them.
Legacy record with split receiver behaviordns
v=DMARC1; p=quarantine; pct=0; rua=mailto:dmarc@example.com
The important point is no longer that pct=0 turns quarantine off. It is that the same DNS record now has different policy effects across receivers. DMARC evaluation and reporting continue, but the requested disposition can range between no DMARC action and full quarantine.
What RFC 9989 changed
RFC 9989 replaced RFC 7489 as the current DMARC specification. It marked pct as historic because partial percentages were applied inconsistently. It kept the useful testing concept through the new t tag, which accepts y or n.
|
|
|
|---|---|---|
pct=0 | Ignores the historic tag | Can suppress policy application |
t=y | Applies one policy level lower | Can ignore the unknown tag |
p=none | Requests no DMARC disposition | Requests no DMARC disposition |
How current and legacy receivers can interpret testing tags
With p=quarantine; t=y, a current receiver applies the policy one level lower, which means none. With p=reject; t=y, it applies quarantine. Testing mode does not stop DMARC reports.
Monitoring and current testing examplesdns
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
Plan for mixed receiver support
No testing tag guarantees the same result across every current and legacy receiver. Leaving pct=0 in place can cause enforcement to increase when a receiver adopts RFC 9989. Publishing t=y can still result in full policy application at an older receiver that ignores the tag.
How pct behavior changed
Under RFC 7489, pct was a rollout control for the requested DMARC policy. Values between 0 and 100 were intended to select how much failing mail received the stricter policy. Operational experience showed inconsistent sampling, so RFC 9989 removed the tag from the active syntax. Current receivers must ignore unknown tags, which leaves the published p policy in effect.
|
|
|
|---|---|---|
p | Requested receiver policy | Required and active |
pct | Historic sampling rate | Remove from current records |
t | Current policy test mode | Defaults to n |
rua | Aggregate report destinations | Reporting can continue in test mode |
Current DMARC policy tags and their practical meaning
Current DMARC policy states
Choose a clear state and account for legacy receiver support before using the testing tag.
Monitoring
p=none
The clearest cross-version state for collecting reports without a requested disposition.
Current testing
t=y
Requests one policy level lower at receivers that support RFC 9989.
Enforcement
t=n
Applies the published policy when the test tag is omitted or set to n.
Historic sampling
pct
Has inconsistent behavior and should be removed from the policy record.
Before changing a production record, check the syntax with a DMARC checker and create a clean replacement with a record generator. A syntax mistake can cause a receiver to ignore intended tags or apply defaults.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The safest interpretation is simple: pct=0 is no longer a valid current-standard test position. Use p=none for unambiguous monitoring. Use t=y only after accounting for receivers that still implement the older specification.
Why pct=0 is no longer equivalent to none
Under legacy DMARC, p=none and p=quarantine; pct=0 often produced the same requested disposition. Under RFC 9989 they do not. The first requests no DMARC-specific handling, while the second can request full quarantine because the percentage tag is ignored.
p=none
- Main signal: The domain owner requests no DMARC disposition for failures.
- Common use: Monitoring sources before policy enforcement begins.
- Compatibility: Current and legacy receivers understand the same policy value.
p=quarantine with pct=0
- Current signal: Quarantine applies because the historic tag is ignored.
- Legacy signal: The receiver can reduce requested quarantine to zero.
- Risk: Legitimate failing mail can receive different handling by destination.
This difference matters when an automated compliance or brand requirement only checks whether the policy is non-none. A serious review checks the full record, identifies historic tags, and evaluates the effective policy under both current and legacy behavior. The same care applies when assessing p=none implications.
Legacy DMARC pct=0 behavior showing reporting continuing while quarantine waits.
Receiver handling still wins
DMARC policy is a domain owner preference, not a command. Receivers handle failed mail under local rules. quarantine means the sender wants failed mail treated as suspicious. That can mean spam folder placement or a warning inside broader filtering. It does not force every receiver to use the same mailbox or SMTP behavior.
Do not assume spam folder placement
A receiver can treat failed DMARC mail more or less strictly than the record requests, or choose a different disposition. The policy gives receivers a clear handling preference, but the receiver decides the final disposition.
- Mailbox rules: Filtering systems combine DMARC with reputation, content, user signals, and local policy.
- Forwarded mail: Receivers can soften handling when forwarding patterns make direct rejection risky.
- Testing mode: A current receiver applies one policy level lower when t=y.
- Standards transition: Historic and current tag support can produce different outcomes.
This is why p=quarantine; pct=0 should not be described as either reliable enforcement or reliable monitoring. It is an ambiguous legacy record during the transition to RFC 9989.
Current DMARC policy sequencedns
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
For broad compatibility, remain at p=none until the domain is ready for enforcement. The t=y record expresses current-standard testing, but older receivers can ignore it and apply quarantine. For complex mail flows, use a written plan to transition safely and track destination-specific effects.
BIMI and pct=0
Do not rely on p=quarantine; pct=0 for BIMI. The historic tag produces mixed enforcement behavior across receivers. Current testing through t=y also reduces p=quarantine to an effective none policy at receivers that support RFC 9989.
BIMI needs recognized enforcement
If the goal is BIMI, publish p=quarantine or p=reject without pct=0 or t=y. Confirm the requirements of each participating mailbox provider before deployment.
A shallow compliance check can see a non-none policy and miss the tag that changes its effective handling. For brand indicators, assess the full record against the actual BIMI requirements, not the p value alone.
How to migrate away from pct=0
Treat every existing pct=0 record as a migration item. Identify the intended state before editing DNS. Use p=none for clear monitoring. Use a non-none policy without testing tags when enforcement is intended. Use t=y only when current-standard testing is needed and the effect on older receivers has been assessed.
- Map senders: List every system that sends mail using the domain or its subdomains.
- Fix authentication: Make each source pass aligned SPF or aligned DKIM for the visible From domain.
- Review reports: Check aggregate data for unknown sources and forwarding effects, including subdomain gaps and legacy systems.
- Choose the state: Decide whether to remain in monitoring or move through a documented test into active enforcement.
- Remove ambiguity: Delete pct and publish only tags that match the intended state.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC workflow lets teams stage and publish policy changes without repeated manual DNS edits. Suped also shows the sources behind DMARC failures, flags configuration issues, and provides fix steps before enforcement changes.
In Suped, the migration can follow a concrete sequence: find every source, correct SPF or DKIM alignment, verify the result in aggregate reports, remove pct, and publish the intended policy. Alerts and multi-domain reporting help teams catch domains that still carry the historic tag.
Why pct=0 should be removed
There is no longer a standards-based reason to publish pct=0 in a new DMARC record. Each existing record needs an owner who documents the replacement state and review window. Keeping the tag creates ambiguity without providing a dependable percentage control.
- Mixed implementations: Current and legacy receivers can apply opposite policy outcomes.
- Unexpected enforcement: A receiver upgrade can turn an assumed test record into full quarantine.
- Audit ambiguity: A non-none policy string does not reveal the effective receiver behavior.
- Intermediary signals: The current t=y tag replaces the useful testing signal for supporting systems.
Use an explicit policy state
Use p=none for cross-version monitoring. Use t=y only for a planned current-standard test. Omit t or set t=n when the published policy should apply.
Current DMARC recordsdns
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Use the first record for monitoring, the second only for current-standard testing, and the third for quarantine enforcement. Reserve p=reject for domains where indirect mail-flow risks have been assessed. General-purpose email domains should not deploy reject without understanding indirect mail flows such as mailing lists and forwarding, and reject deployments must not rely on SPF alone.
Views from the trenches
Best practices
Remove pct from new DMARC records because RFC 9989 now classifies the tag as historic.
Use p=none when monitoring needs consistent policy behavior across receiver versions.
Review aggregate reports and aligned authentication before enabling an active policy.
Treat t=y as a planned test with a named owner and documented next state, reviewed on time.
Common pitfalls
Assuming pct=0 disables quarantine can expose legitimate mail to unexpected filtering.
Adding t=y without checking legacy behavior can still produce full policy enforcement.
Passing a shallow policy check can hide historic tags and mixed receiver outcomes.
Using reject on general mail can disrupt indirect flows such as lists and forwarding.
Expert tips
Compare report trends by receiver before and after removing an existing pct=0 tag.
Keep aligned DKIM on mail that can pass through forwarding or other indirect paths.
Document the effective current and legacy policy during every standards migration.
Use Suped alerts to find domains that retain pct after the intended migration window.
An Email Geeks marketer described pct=0 as monitoring-like under legacy DMARC while noting that it still declared a non-none preference.
2026-03-01 - Email Geeks
An Email Geeks marketer advised full DMARC enforcement for BIMI rather than relying on a pct=0 policy string.
2026-03-01 - Email Geeks
The practical answer
A DMARC record with p=quarantine; pct=0 does something, but no longer one predictable thing. A current RFC 9989 receiver ignores pct=0 and can apply full quarantine. A legacy receiver can still apply no requested quarantine action. Reporting remains available when rua is configured.
If the domain is still being assessed, use p=none and focus on source cleanup. If the domain is ready for protection, remove pct and publish the intended enforcement policy. Suped connects that decision to aggregate report data, verified sources, alerts, and hosted policy controls so each DNS change has evidence behind it.
