DMARC pct Tag Explained: Roll Out Reject Safely

The pct tag is a throttle

The risky moment in DMARC is when you move from watching mail to telling receivers to quarantine or reject it. One forgotten sender can turn invoices, password resets, or sales replies into failed mail. The pct tag lets you apply that stricter policy to only part of the mail that fails DMARC while you check the reports.

In a DMARC record, pct is the requested percentage of messages that should receive the domain owner's DMARC policy. It is a whole number from 0 to 100. If you leave it out, receivers treat it as 100.

Example: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com. This asks receivers to quarantine about 25 percent of mail that fails DMARC. For the rest, the requested DMARC policy is downgraded. Local spam and abuse filters can still block or junk the message for other reasons.

pct only helps when you are using p=quarantine or p=reject. With p=none, there is no DMARC enforcement to sample. Use p=none while you find senders, then use pct when you start tightening the policy.

How pct behaves with quarantine and reject

The tag is easy to misread because it sounds like it applies to all mail. It applies to mail that fails DMARC and would otherwise receive your requested policy.

v=DMARC1; p=none; pct=10; rua=mailto:dmarc@example.com collects reports. The pct value has no real enforcement effect because the policy is none.

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com asks receivers to quarantine about half of DMARC-failing mail. Mail outside the sample is handled as though the DMARC policy were none, subject to the receiver's own filtering.

v=DMARC1; p=reject; pct=10; rua=mailto:dmarc@example.com asks receivers to reject about 10 percent of DMARC-failing mail. Under the DMARC RFC's rollout model, mail outside that sample is treated with a lower DMARC policy, usually quarantine, while the receiver can still apply its own rules.

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com asks receivers to reject all mail that fails DMARC. This is the end state for many domains, but only after reports show that wanted mail is passing.

Roll it out without blocking real mail

Start small enough that a mistake hurts less, but large enough that your reports show useful patterns.

• Publish DMARC at p=none first with a rua address so you can see who sends as your domain.
• Fix known senders until normal business mail passes DMARC through aligned SPF or aligned DKIM.
• Move to p=quarantine; pct=10 and watch reports for a few normal sending cycles.
• If the remaining failures are spoofing, stale tools, or mail you no longer need, raise pct to 25, then 50, then 100.
• After quarantine is clean at 100, move to p=reject; pct=10 and repeat the same climb.

Do not raise pct on a quiet Friday and call it done. Pick days that include your real email patterns: payroll, billing, newsletters, support tools, CRMs, and any app that sends from your domain.

What to check before enforcement

pct slows a rollout. It does not repair bad authentication. Check the basics before each increase.

• SPF: publish one SPF TXT record for the domain. Include real senders, stay within the 10 DNS lookup limit from RFC 7208, and use ~all while testing. Move toward -all only when the sender list is complete.
• DKIM: turn signing on for each sender that supports it. Use the selector the provider gives you, publish the public key in DNS, and confirm real mail has a valid DKIM signature.
• DMARC alignment: DMARC passes when SPF passes and aligns with the visible From domain, or DKIM passes and aligns with the visible From domain. A message can pass SPF and still fail DMARC if the domains do not align.
• RUA reports: read aggregate reports before each pct increase. They show source IPs, counts, policy results, and SPF/DKIM authentication results. A free DMARC report reader can turn the XML into something you can scan.
• MX and DNS: make sure MX records point to the right mail host, DNS changes have had time to propagate, and old vendors are removed from SPF and DKIM.
• Blocklists and reputation: if your domain or sending IP has a poor reputation, authentication still matters, but mailbox providers may keep routing mail to spam until reputation improves.

Gmail and Outlook look at authentication, reputation, complaint rates, content, link safety, and recipient behavior. DMARC proves that the domain in the From line is under control. It does not make poor sending practices look good.

Do not mix inbox checks with AI visibility

Email deliverability and AI search visibility are separate jobs. Both depend on letting the right systems verify or read what you publish.

For email, use a free domain scorecard to check SPF, DKIM, DMARC, MX, and drift before you increase pct. For AI search visibility, use a free AI visibility checker and review robots.txt.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. robots.txt is a stated site policy, not proof of crawler behavior. Perplexity-User and Bytespider have been reported to ignore it, so use server logs as evidence and robots.txt as policy.

Only Googlebot documents JavaScript rendering. If key content exists only after client-side JavaScript runs, other AI search crawlers may miss it. Treat that as an undocumented risk and keep important text in crawlable HTML.