DMARC Rollout Plan: From p=none to p=reject Without Losing Mail

What a DMARC rollout is really doing

DMARC lets a domain owner tell receiving mail systems what to do with messages that claim to be from the domain but fail authentication. The DMARC policy has three levels: p=none asks for no action, p=quarantine asks the receiver to treat failing mail with suspicion, and p=reject asks it to refuse the mail. The risk in moving from the first to the last is simple: if a legitimate sender is not authenticating correctly, it will start losing mail when you tighten the policy. A good DMARC rollout plan is mostly about finding every legitimate sender before that happens.

This plan assumes SPF and DKIM already exist for your main mail system. If you are unsure, begin with the email health check to see which records are published, and read how to check email domain records for what each one does.

How DMARC decides pass or fail

A message passes DMARC if SPF or DKIM passes and, crucially, the domain it authenticated is aligned with the domain in the visible From address. It fails only if both fail. Alignment is where most rollouts hit trouble. A marketing platform may pass SPF for its own bounce domain and sign DKIM with its own domain, so both authentication checks pass but neither aligns with your From domain, and DMARC fails. By default alignment is relaxed, meaning a subdomain of the same organizational domain aligns; strict mode requires an exact match.

Stage 0: take stock

Before publishing anything, list who sends mail as your domain. Typical senders are your main mailbox service, a marketing platform, a ticketing or support system, an invoicing or billing system, a website contact form, monitoring and printers or scanners, and a few forgotten servers. Ask each department, and also check the DNS: your SPF record often names the services someone once approved. Remove nothing yet; collect.

Stage 1: publish p=none with reporting

Publish a DMARC record at _dmarc.yourdomain with p=none and an rua=mailto: address for aggregate reports. A minimal example is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use a dedicated shared mailbox or group for reports, not a person's inbox, and expect the volume to grow. If the report address is in a different domain from the one being protected, the receiving domain has to publish a small TXT record to authorise report delivery, or receivers may not send reports. Many teams use a DMARC reporting service to turn the XML into something readable; if you do, check what the service stores and who can see it.

Stay at p=none long enough to see a full business cycle. That should include month-end invoicing, any quarterly mailings and seasonal campaigns, since infrequent senders are the ones you miss. Microsoft's guidance is to monitor for enough time before moving up, without giving a fixed number; the right length depends on how many senders you have and how regular they are.

How to read aggregate reports

Receivers usually send aggregate reports as a daily XML attachment, often compressed. Reading raw XML is tedious, so use a viewer or a script, but understand the fields:

• source_ip: the server that sent the mail, and count, how many messages.
• policy_evaluated: whether SPF and DKIM were aligned, and what disposition the receiver applied.
• auth_results: the raw SPF and DKIM results and the domains they used.
• header_from and the envelope sender, so you see which domain was used.

The pattern to look for is a known, legitimate source where the authentication result is pass but the aligned result is fail. That is a sender who needs fixing, either by signing DKIM with your domain or by using a bounce address in your domain. A high-volume unknown source that fails everything is probably spoofing, and DMARC will protect recipients once you enforce. Forwarded mail and mailing lists often fail and are normal background noise; do not chase every line.

Not every receiver sends reports, so the data is a sample of your mail rather than all of it. Also note that Microsoft 365 does not send the per-message forensic reports, so do not rely on ruf; start with rua only.

Stage 2: find and fix the senders

Work through the senders from the aggregate reports, one at a time. For each, decide whether it should send as your domain. If yes, make it align. The two usual fixes are to configure DKIM signing in the service using your domain, which tends to be the more robust route since it also survives most forwarding, and to configure a custom return-path domain so SPF aligns. If a service cannot do either, send its mail from a subdomain and give that subdomain its own record. If a sender should not exist, remove it from SPF and ask why it was sending.

Use a subdomain for third-party bulk senders so that their reputation does not reflect on your main domain. For domains that never send mail, you can publish a restrictive record straight away, as parked domains should not be sending at all.

Check progress by re-reading the reports: the legitimate sources should move from failing to aligned passes. Use the DMARC record inspector to check your record's syntax and tags before you publish a change; it explains a pasted record and does not look it up in DNS.

Stage 3: move to p=quarantine

When the reports show your legitimate senders aligned, change to p=quarantine. The pct tag in the record lets you apply the policy to a share of failing messages first, and Microsoft's own example steps through increments such as 10, 25, 50, 75 and 100. Be aware that pct comes from the original specification, RFC 7489. A newer revision of the standard is reported to retire it in favour of a simple test-mode tag, so check the current specification and how your receivers treat partial enforcement before relying on it. Whichever way you stage it, keep watching reports and the help desk for complaints about missing mail.

Wait for a full cycle again before the last step. Tell the business a change is coming and who to contact.

Stage 4: move to p=reject

When quarantine has been quiet, change to p=reject. Rejected mail is bounced or discarded by the receiver, so there is no junk folder to rescue it from. That is why the previous stages exist. Keep reading reports, because new senders appear when a team signs up for a new service without asking you.

If you have subdomains, decide whether they inherit the parent policy, as they do when no record exists for them, or need their own. The sp tag sets a policy for subdomains in the parent's record. Roll out low-volume, low-complexity domains first and leave the main domain until last, which is Microsoft's suggested order.

After the rollout

DMARC is not a one-time project. Add "does this send mail as our domain?" to the checklist for any new application, review aggregate reports monthly, and keep an eye on the SPF lookup limit as senders are added. A policy of p=reject does not stop all phishing. It makes direct spoofing of your exact domain much harder; look-alike domains remain.

Keep a record of each change and the date, so that if mail disappears you can see what changed. Verify your own record syntax, alignment settings and report addresses against Microsoft Learn and the DMARC specification before you publish.