What is the pct tag in DMARC?

Understanding the DMARC pct Tag

The pct (percent) tag in DMARC records controls what percentage of messages are subject to your DMARC policy. This powerful feature allows organizations to gradually enforce DMARC policies, test policy effects without blocking all mail, and roll out authentication requirements safely.

Without pct, your DMARC policy applies to 100% of messages. The pct tag lets you apply policy to a smaller sample, enabling safe testing and gradual enforcement.

DMARC pct Tag Syntax

v=DMARC1; p=reject; pct=100

• pct=100: Apply policy to all messages (100%)
• pct=50: Apply policy to half of messages
• pct=10: Apply policy to 10% of messages
• pct=1: Apply policy to 1% of messages

Valid values: 0-100

How pct Works in Practice

Example: pct=50

When your DMARC policy is reject with pct=50:

• Receiving servers apply the reject policy to ~50% of messages
• The other ~50% pass through, even if they fail authentication
• This allows legitimate mail to get through while testing effects

In practice:

• 100 emails sent with failing authentication
• ~50 are rejected (policy applied)
• ~50 are delivered (policy not applied)
• You can identify problems while minimizing impact

Sampling Behavior

The percentage application is probabilistic:

• Not strictly every other message
• Distributed across traffic patterns
• Receiving server implements the sampling
• Different receivers may sample differently

Don't expect exact 50% split—it's approximately that percentage.

Strategic pct Deployment

The Gradual Enforcement Approach

Many organizations deploy DMARC in phases:

Phase 1: Monitoring (pct=100, p=none)

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

• Collect data without any policy enforcement
• See failure rates and patterns
• Duration: 2-4 weeks

Phase 2: Quarantine with Low Sampling (pct=10, p=quarantine)

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

• Apply quarantine to 10% of failing messages
• Monitor impact on mail delivery
• Identify any issues
• Duration: 1-2 weeks

Phase 3: Quarantine with Higher Sampling (pct=50, p=quarantine)

v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]

• Apply quarantine to 50% of failing messages
• Larger test of policy effect
• Identify edge cases
• Duration: 1-2 weeks

Phase 4: Full Rejection (pct=100, p=reject)

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

• Full enforcement
• All failing messages rejected
• Only after confidence is high

Typical Timeline

A safe DMARC rollout might take 4-8 weeks:

• Week 1-2: Monitoring (p=none, pct=100)
• Week 3-4: Quarantine (p=quarantine, pct=10)
• Week 5-6: Quarantine (p=quarantine, pct=50)
• Week 7-8: Reject (p=reject, pct=100)

This gradual approach prevents breaking legitimate mail delivery.

When to Use Different pct Values

pct=100 (Full Enforcement)

Use when:

• Policy is well-tested and proven safe
• Infrastructure is fully authenticated
• You're confident in mail sources
• You want maximum protection against spoofing

Example:

v=DMARC1; p=reject; pct=100

pct=50 (Half Enforcement)

Use when:

• Testing quarantine or reject policies
• Infrastructure is mostly, but not entirely, authenticated
• You want to catch major problems while keeping mail flowing
• Transitioning between policy levels

Example:

v=DMARC1; p=quarantine; pct=50

pct=10 (Conservative Testing)

Use when:

• First time applying quarantine/reject policy
• Unknown mail sources might be affected
• Need to gather data before higher enforcement
• Risk of major mail delivery disruption

Example:

v=DMARC1; p=quarantine; pct=10

pct=0 (No Enforcement)

Use when:

• Actively troubleshooting authentication failures
• Collecting data with p=none (reports only)
• Temporarily disabling enforcement for investigation

Example:

v=DMARC1; p=none; pct=0

Common pct Mistakes

Mistake 1: Jumping to pct=100 Too Quickly

Problem: Deploying p=reject; pct=100 without testing

Result:

• Legitimate mail gets blocked
• Business processes break
• Customer communications interrupted
• Emergency rollback required

Solution: Follow gradual enforcement approach

Mistake 2: Setting pct Too Low for Too Long

Problem: Keeping pct=5 indefinitely, thinking you're testing

Reality:

• With pct=5, only 5% of failures are caught by policy
• Reports still show 95% of failures as passing
• You never actually test the policy effect
• Deployment stalls

Solution: Increase pct after each phase to actually test policy

Mistake 3: Forgetting About pct When Troubleshooting

Problem: Mail is failing, but you forgot that pct=25 applies

Reality:

• 75% of failures still pass through
• Issue is harder to identify
• Troubleshooting is complicated

Solution: Increase pct=100 temporarily during troubleshooting

Mistake 4: Not Monitoring During pct Enforcement

Problem: Applying pct=50 reject policy but not monitoring delivery

Result:

• Legitimate mail gets blocked with no visibility
• No one realizes there's a problem
• Service degradation goes undetected

Solution: Monitor aggregate reports and mail logs throughout enforcement

Monitoring pct Enforcement

What to Track

When using pct values less than 100:

1. Failure rate: What percentage of messages fail DKIM/SPF?
2. Policy application: Are receiving servers actually sampling?
3. Delivery impact: Are legitimate emails being rejected?
4. Source analysis: Which senders are failing?

Reading Reports with pct

When pct=50 with p=reject:

• Aggregate reports show all mail (100%)
• Policy was applied to ~50%
• Actual rejection count ≈ (failure_count × pct/100)

Example:

100,000 total messages
20,000 fail DMARC (20% failure rate)
pct=50 means 10,000 are rejected by policy
Other 10,000 still pass through (policy not applied)

Adjusting Based on Data

High failure rate?
  → Investigate mail sources
  → Fix SPF/DKIM for legitimate sources
  → Don't increase pct until failures are resolved

Low failure rate?
  → Infrastructure is well-configured
  → Safe to increase pct

Delivery problems reported?
  → Likely pct is too high for current authentication
  → Decrease pct to reduce impact
  → Fix authentication issues
  → Then increase pct again

pct Considerations by Policy Type

With p=none (Monitoring)

v=DMARC1; p=none; pct=100

• pct doesn't matter with p=none (no policy applied anyway)
• Keep at 100 to get complete reporting data
• Use to establish baseline

With p=quarantine

v=DMARC1; p=quarantine; pct=50

• pct controls how many fail to quarantine
• Gradual enforcement approach works well
• Start low, increase as confidence grows
• Test before moving to reject

With p=reject

v=DMARC1; p=reject; pct=100

• High pct = stronger protection against spoofing
• pct=100 is end goal for security
• Only use pct<100 during testing/troubleshooting
• Be cautious—rejections are final

Advanced pct Strategies

Emergency Debugging

If deployment breaks mail:

v=DMARC1; p=reject; pct=0

• Temporarily set pct=0 while troubleshooting
• Preserves policy setting but doesn't apply it
• Allows time to investigate
• Then increase pct again

A/B Testing

Monitor effects of different pct values:

Week 1: pct=25, monitor failures
Week 2: pct=50, monitor failures
Week 3: pct=75, monitor failures
Week 4: pct=100, monitor failures

This empirical approach shows actual impacts.

pct in DMARC Records

Complete Record Example

v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; rf=afrf; adkim=s; aspf=s

• p=quarantine: Quarantine failing messages
• pct=50: Apply to 50% of messages
• rua: Aggregate reports
• ruf: Forensic reports
• fo=1: Get forensic reports for all failures
• adkim=s: Strict DKIM alignment
• aspf=s: Strict SPF alignment

pct Doesn't Replace Testing

Important: pct is not a replacement for proper testing.

Proper approach:

1. Test infrastructure in staging
2. Monitor with p=none and full DMARC validation
3. Use pct to gradually enforce
4. Continue monitoring throughout

pct is a safety mechanism, not a testing tool.

Conclusion

The DMARC pct tag is a powerful feature for safe DMARC deployment. By understanding how to use pct for gradual enforcement, you can:

• Test policies without breaking mail
• Identify infrastructure issues before full enforcement
• Monitor policy effects on delivery
• Roll out rejection policies safely

Following a phased approach with gradually increasing pct values allows organizations to reach p=reject (strongest security posture) with confidence that legitimate mail won't be disrupted.

Proper use of pct is a hallmark of mature DMARC deployment—rushing to pct=100 without testing is how organizations accidentally break email delivery and damage customer relationships.