Moving from p=none to p=reject without breaking mail

DMARC's enforcement policy has three levels: p=none (monitor only, take no action), p=quarantine (send failing mail to spam), and p=reject (block it outright). Jumping straight to p=reject before you're confident every legitimate sender for your domain passes authentication is the single most common way DMARC rollouts break real mail.

Start with p=none and actually read the reports

p=none does nothing to delivery, it just tells receiving mail servers to send you aggregate reports on who's sending mail claiming to be from your domain, and whether it passes SPF and DKIM. This is the step people skip or ignore, but it's the only way to find every legitimate sender before you start blocking anything: your transactional email provider, marketing platform, any internal tool that sends notification emails, sometimes a forgotten one from years ago that still sends the occasional message.

Reading an actual aggregate report

DMARC aggregate reports arrive as XML, one per receiving mail server per reporting period, listing the sending IP, the volume sent, and whether SPF and DKIM passed and were aligned. Raw XML isn't pleasant to read by hand; a report analyzer (like the free tool on this site) turns it into a readable table of source IPs and pass/fail status, which is the practical way to actually review these reports rather than letting them pile up unread in an inbox, which defeats the entire purpose of the p=none monitoring stage.

Move to p=quarantine once the reports are clean

Once aggregate reports show every legitimate sender consistently passing SPF or DKIM alignment, and no unexplained failures, move to p=quarantine. This routes failing mail to spam rather than blocking it outright, a real but recoverable consequence if you missed a legitimate sender, versus reject's outright bounce.

Consider a percentage rollout within quarantine and reject

DMARC supports a pct tag that applies the policy to only a percentage of failing mail, letting you move to p=quarantine; pct=25 rather than full enforcement immediately, then increase the percentage over subsequent weeks. This gives an extra layer of staged rollout within each policy level itself, useful if you want more granular control than the three discrete policy levels alone provide.

Only then, p=reject

After quarantine has run clean for a meaningful stretch (weeks, not days), with no legitimate mail getting caught, moving to p=reject is safe. At this point you've already validated the full list of senders through two less-destructive stages, reject just closes the loop on anything not on that list, which by now is exactly what you want blocked: spoofed mail, not your own.

The realistic timeline

This isn't a rollout you complete in an afternoon. Give each stage enough time to catch infrequent senders, a monthly internal report tool, an annual renewal notice, anything that doesn't send often enough to show up in a week of aggregate reports but would still break if you moved too fast. A few weeks at each stage is a reasonable floor, not a worst case.