Publishing p=reject on day one is a way to discover which internal systems send as your domain, by breaking them. The staged version takes longer and breaks nothing.

Stage 0: publish p=none with reporting

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain

This enforces nothing. Its entire purpose is to turn on aggregate reports, which arrive daily from every major provider and tell you who is sending as your domain.

Point rua at something that parses XML. The reports are gzipped, machine-shaped, and arrive from dozens of sources; a human mailbox is not a useful destination.

Stage 1: read the reports for a fortnight

You are looking for sources you did not expect. Almost every organisation finds at least one — an invoicing system, a CRM, a monitoring tool, a help desk, a marketing platform somebody signed up for in 2019.

For each source, decide: is this legitimate mail that should be authenticated, or is it something that should stop? Then either align it or turn it off. Do not move the policy while any legitimate source is still failing.

Two weeks is the minimum because monthly processes exist. Invoicing that runs on the first of the month will not appear in a report generated on the tenth.

Stage 2: set the subdomain policy first

v=DMARC1; p=none; sp=reject; rua=mailto:dmarc@yourdomain

The sp tag sets policy for subdomains independently of the parent. If you do not send from subdomains, nothing legitimate breaks — and you have immediately closed the most common spoofing vector, because an attacker who cannot use your domain will try mail.yourdomain or secure-yourdomain.

This is the highest-value, lowest-risk step in the whole process and it is routinely skipped.

Stage 3: quarantine, with a percentage

v=DMARC1; p=quarantine; pct=10; sp=reject; rua=mailto:dmarc@yourdomain

The pct tag applies the policy to a sample. At 10, one in ten failing messages is quarantined and the rest are treated as none. If something was missed in stage 1, it degrades for a tenth of recipients rather than all of them.

Raise it in steps — 10, 25, 50, 100 — watching reports between each. A week at each level is reasonable. Note that pct is ignored entirely when the policy is none, so it does nothing until this stage.

Stage 4: reject

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain

Move here once p=quarantine; pct=100 has run for a couple of weeks with no legitimate source failing. At that point reject changes very little — mail that was being quarantined is now refused — but it is the only policy that actually stops spoofing rather than foldering it.

What breaks at reject, and what to do

Forwarding. A forwarded message fails SPF, because it arrives from the forwarder. If DKIM is intact it still aligns and DMARC passes, which is the main argument for making sure DKIM is correct before you enforce.

Mailing lists. Lists that rewrite the subject or append a footer break the DKIM body hash. Well-run lists rewrite the From header to their own domain to avoid this; badly run ones do not. ARC exists to address it and adoption is partial.

Third-party senders you forgot. Which is what stages 1 to 3 were for.

Keep reading the reports

Enforcement is not the end. New systems get added, providers change infrastructure, and a source that aligned last quarter can stop. The reports are the only thing that tells you, and they only arrive if rua is still pointing somewhere that works.

Check your current record with the DMARC checker, or build one with the generator.

Getting from p=none to p=reject without losing mail