DMARC Rollout: Going From p=none to p=reject Safely

Moving a DMARC policy from p=none to reject is the right goal — a domain sitting at p=reject cannot be spoofed at scale — but doing it in a single step is how people block their own invoices, newsletters, and helpdesk mail. This guide is about how to move DMARC from p=none to reject safely: you monitor at none, fix every legitimate sending source the reports reveal, tighten to quarantine, and only then reject, working through low-volume subdomains before you ever touch the parent domain.

One freshness note first. DMARC is now defined by RFC 9989, published in 2026, which obsoletes the original RFC 7489 (2015) and RFC 9091. The staged rollout below is unchanged by that update, but one common tactic — the pct tag that let you apply a policy to a percentage of mail — was removed in RFC 9989, so this guide does not build the plan around it. Where that matters, it is flagged.

Before you start: authentication first, then a way to read reports#

DMARC does nothing on its own. It sits on top of SPF and DKIM and simply tells a receiving server what to do when a message fails both checks. So before you publish any policy, every legitimate source that sends as your domain — your mail platform, your marketing tool, your CRM, your invoicing system, your support desk — needs SPF or DKIM set up and aligned with the From address. A message passes DMARC when SPF or DKIM passes and the authenticated domain lines up with the domain your recipients actually see.

The second prerequisite is somewhere to receive reports. A DMARC record with an rua address tells receivers to send you daily aggregate reports — an XML summary of who is sending as your domain and whether each source passed. Those reports are the entire feedback loop for this project. You cannot safely tighten a policy you are not measuring, which is why this is a monitoring exercise before it is a security one.

• Inventory every sending source. List every system that sends email as your domain before you publish anything — the surprise senders are exactly the ones a reject policy blocks.
• Set up SPF and DKIM for each source, then check alignment. DMARC cares about alignment, not just a raw pass; a sibling guide on relaxed versus strict alignment covers where they differ.
• Publish an rua address you will actually read. A dedicated mailbox or a reporting dashboard beats trying to parse raw aggregate XML by eye.
• Start on the domain with the least to lose. Pick a low-volume subdomain with few senders as your first candidate, not the main domain your business runs on.

The staged rollout, one policy at a time#

The rollout is three policy stages, and the discipline is in the exit criteria: you do not advance until the reports say the current stage is clean. Run the whole sequence on one domain, confirm it, then repeat it on the next — saving the parent domain for last.

1. 1

   Publish p=none and read the reports

   Start with v=DMARC1; p=none; rua=mailto:you@yourdomain. Nothing changes for your mail — none is monitor-only — but receivers begin sending aggregate reports. Read them until you can see every legitimate source, and fix SPF or DKIM alignment for any that fail. Exit criterion: your known senders authenticate and align, and you can account for everything left in the report.

2. 2

   Move to p=quarantine and watch

   Change the policy to p=quarantine. Now mail that fails DMARC is treated as suspicious — typically routed to the spam or Junk folder rather than refused outright. Keep reading the reports. Exit criterion: a sustained clean stretch with no legitimate mail being quarantined, held long enough to catch low-frequency senders like monthly invoices or a quarterly statement.

3. 3

   Set p=reject

   Change the policy to p=reject. Failing mail is now refused at the SMTP layer — Microsoft 365 rejects with 550 5.7.1, and other providers return a similar 5.7.x error. Because you reach this stage only after quarantine ran clean, the mail being rejected is the spoofed and unauthenticated mail you wanted gone in the first place.

4. 4

   Repeat up the volume ladder, parent domain last

   Run the same three stages on your next domain, moving from low-volume, low-complexity subdomains toward higher-volume ones and finishing with the parent domain. A parent DMARC record automatically covers subdomains that lack their own; the sp tag sets a separate subdomain policy when you need one.

How long should you stay at each stage?#

There is no fixed number of days, because the right duration depends on your sending patterns, not the calendar. The honest rule is to stay at each stage until the aggregate reports read clean for that stage, and long enough to have seen your infrequent senders at least once. Many teams spend a few weeks at none and a few weeks at quarantine per domain, but treat that as a floor, not a target — a full billing cycle is a better yardstick than a week.

The three stages at a glance#

How each major provider treats your policy#

Receivers, not you, decide what happens to mail that fails your DMARC, and the big providers behave slightly differently. They also increasingly require you to publish DMARC at all for higher-volume sending. The table below is accurate as of 2026 — verify the current rules on each provider's own postmaster page, because these requirements have moved repeatedly and will move again.

What to do when legitimate mail starts failing#

If the reports show a legitimate source failing — or worse, if real mail lands in quarantine — do not push forward. The whole point of staging is that none and quarantine are recoverable and reject is not, so a failing source caught at quarantine is a problem surfaced, not a disaster.

The two most common causes are a sender you forgot and forwarding. A forgotten sender — a new marketing tool, a billing platform, a form plugin — just needs SPF or DKIM set up and aligned for the domain it sends from. Forwarding and mailing lists are trickier: plain forwarding breaks SPF, and a list that modifies the message breaks DKIM, so mail that was fine at the source fails at the final destination. The fix is ARC (Authenticated Received Chain) at the forwarding service, or accepting that a slice of forwarded mail will fail.

If you need to move back, you can. Dropping from reject to quarantine, or quarantine to none, takes effect as fast as the DNS record propagates. Roll back, fix the source, confirm it in the reports, and re-advance — that reversibility is exactly why the staging exists.

A faster way to handle what reaches your inbox#

Two parts of this are genuinely tedious. Reading raw aggregate XML by eye is the first, and the honest faster way for that is a dedicated DMARC reporting service that turns the reports into a source-by-source dashboard — Microsoft even publishes a catalog of them. That is a monitoring tool, and it is not us: AI Emaily does not publish, monitor, or roll out DMARC records, and a page that implied otherwise would be worth nothing.

The second part is the mail a reject policy never touches. DMARC at reject stops other people from receiving spoofs of your domain; it does nothing about the phishing and impersonation that still land in your own inbox. Triaging that inbound mail is the job we do — AI Emaily flags spoofed and suspicious messages with its spam protection and keeps them out of your way, on the Gmail, Outlook, or IMAP account you already use.

We build AI Emaily, so we will say so plainly: it complements DMARC on the receiving side and does not replace the DNS work above.

You can try it on a free trial to see how it triages the impersonation attempts your outbound DMARC policy was never designed to catch.