DMARC gives you three enforcement policies: none, quarantine, and reject. The mistake most people make is treating them as a dial to turn to maximum as fast as possible. The right approach is a deliberate ramp, where you start in monitoring mode, read the reports until you understand every source sending as your domain, and then tighten in stages, often rolling out each step to a fraction of your mail with the pct tag. Done this way, you reach full rejection of spoofed mail without ever bouncing a legitimate message. Here is the ramp, step by step.
What the policy actually controls
The policy in a DMARC record, set by the p tag, tells receivers what to do with mail that fails DMARC, meaning it did not produce an SPF or DKIM pass that is aligned with the visible From domain. It does not affect mail that passes. The three values form a clear escalation.
| Policy | What receivers do with failing mail | Protection |
|---|---|---|
| p=none | Deliver normally, just report it | None, monitoring only |
| p=quarantine | Deliver to spam/junk or hold | Partial |
| p=reject | Refuse the message at SMTP time | Full |
Step 1: Start at p=none with reporting on
Begin with a monitoring-only record. It changes nothing about delivery but asks receivers to send you aggregate reports, which is the entire point of this stage. The rua tag is the address those daily XML reports go to.
$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"Leave this in place for at least a couple of weeks, longer for a large or complex sending footprint. Your goal is to build a complete inventory of every service that sends mail as your domain: your mailbox provider, marketing platforms, help desk, billing system, CI pipelines, and anything else. The reports show you each source and whether it passed SPF and DKIM with alignment.
Step 2: Fix alignment before you enforce
Do not advance until the reports show your legitimate sources authenticating correctly. For each source, make sure it is either covered by your SPF record with an aligned domain, or signing with DKIM using a key under your domain, or both. A source that only passes SPF under the sending platform's own domain is not aligned and will fail DMARC the moment you enforce. This fixing stage is where the real work happens; the policy changes afterward are almost anticlimactic.
Step 3: Move to quarantine, gradually with pct
Once reports are clean, step up to quarantine. Rather than applying it to all mail at once, use the pct tag to apply the policy to a percentage of failing messages, leaving the rest at the next-lower policy. This limits the blast radius if you missed a source.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comHere, 25 percent of failing mail is quarantined and the other 75 percent is treated as none. Watch the reports, and if nothing legitimate is getting caught, raise the percentage over successive days.
| Day | Record | Effect on failing mail |
|---|---|---|
| 1 | p=quarantine; pct=25 | 25% quarantined |
| 4 | p=quarantine; pct=50 | 50% quarantined |
| 8 | p=quarantine; pct=100 | All failing mail quarantined |
How pct actually behaves
One subtlety trips people up. The pct tag does not mean "enforce on this percentage." It means "apply the stated policy to this percentage, and apply the next-weaker policy to the remainder." So p=reject; pct=10 rejects 10 percent of failing mail and quarantines the other 90 percent. It is a true gradual rollout, not a sampling of whether to act at all. Once you reach pct=100 at a given policy, the tag has done its job and you can drop it.
Step 4: Move to reject
After quarantine has run at 100 percent for a week or two with no collateral damage, advance to reject, again ramping with pct if you want extra caution. At reject, receivers refuse spoofed mail outright at the SMTP conversation, which is the strongest possible stance.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=sThis is the destination. Spoofed mail using your exact domain is now rejected by every receiver that honors DMARC, which is the overwhelming majority of inbox providers.
Monitoring milestones before each step
- Before leaving none: every legitimate source appears in reports and authenticates with alignment.
- Before raising quarantine pct: no legitimate mail is landing in the quarantined bucket.
- Before moving to reject: quarantine has held at 100 percent with clean reports for a full reporting cycle.
- After reject: keep reading reports; new sources appear over time as teams adopt new tools.
A note on subdomains
The sp tag sets a separate policy for subdomains. If you enforce p=reject on the organizational domain but have subdomains that send mail you have not yet audited, you can hold them back with sp=none until they are ready, then remove it. Without an sp tag, subdomains inherit the main policy.
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.comThe reporting tags that drive the ramp
The whole ramp depends on reports, so it helps to know the tags that control them. The rua tag sets the address for aggregate reports, the daily XML summaries that list every source and its authentication results; this is the one you rely on at every stage. The optional ruf tag requests forensic, per-message failure reports, which are far less widely sent and can carry sensitive content, so many operators leave it off. The ri tag sets the aggregate reporting interval in seconds, defaulting to 86400, which is one report per day. For almost every rollout, a single rua address is all you need.
Do not rush, and do not stall
Two failure modes bracket this process. Rushing to reject before fixing alignment bounces real mail and erodes trust in the whole project. Stalling at p=none forever, which is extremely common, gives you reports but zero protection, because none is purely observational. The ramp exists precisely to move you from one to the other safely.
Verify each policy change across resolvers
A DMARC policy only takes effect once the updated TXT record is live everywhere, and a local lookup shows just one resolver's cached copy. After each step of the ramp, run your domain through the Valla DNS propagation checker to confirm the new p and pct values have propagated before you rely on them. To keep the underlying authentication solid as you tighten, pair this with our guides on SPF qualifiers and on DMARC alignment, the two things that decide whether your legitimate mail survives the move to reject.