DMARC Enforcement Without Preparation: Why Jumping from p=none to p=reject Fails

The scenario: two admins, one domain, no plan

An IT consultant gets a straightforward-sounding assignment: two M365 admins need to move their company domain’s DMARC policy from p=none to p=reject. Sounds like an afternoon’s work. The catch: neither admin has ever touched DMARC before, there is no documentation of authorised senders, and nobody has ever looked at the aggregate reports sitting in the RUA inbox. No sender inventory, no test phase, no rollback plan.

This is not a rare edge case. It shows up regularly in IT forums — most recently in a widely discussed thread on r/DMARC, where an experienced admin describes exactly this situation and asks how to stop his colleagues before the damage is done.

What happens when you rush p=reject

DMARC at p=reject tells receiving mail servers to outright reject messages that fail both SPF and DKIM. That sounds like exactly what you want — until you realise that many legitimate senders inside a typical organisation are not configured correctly.

Common casualties of a rushed enforcement:

• Marketing platforms like Mailchimp, HubSpot, or Brevo that send from their own IP ranges but are missing from the SPF record
• Accounting software that sends invoices directly over SMTP with no DKIM signature
• Third-party services sending on behalf of the domain — recruiting platforms, helpdesk tools, monitoring alerts
• Internal relay servers that were quietly left behind during an M365 migration

Once p=reject is live and any of these senders is misconfigured, the mail does not land in spam — it bounces hard. The sender gets a non-delivery report, the recipient sees nothing. In the worst case, the business only finds out when customers ask why they never received a quote or an invoice.

Why DMARC reports are the only reliable starting point

Before anyone even considers p=quarantine, they need to know who is sending on behalf of the domain. The only reliable source for that is DMARC aggregate reports (RUA). These XML reports are sent daily by receiving mail servers — Google, Microsoft, Yahoo, and others — to the reporting address in the DNS record.

The problem: raw XML reports are barely human-readable. A single report can contain hundreds of rows, broken down by source IP, sending domain, SPF result, and DKIM result. Without systematic analysis, you have no real picture of your sending landscape — and that was precisely the situation the two M365 admins were in.

A structured process looks like this:

1. Add an RUA address and collect reports for at least four weeks
2. Analyse the reports: which IPs are sending for the domain? Which pass SPF, which pass DKIM, which pass both?
3. Build a sender inventory: document every legitimate source, configure SPF and DKIM for all of them
4. Move to p=quarantine and monitor for another two to four weeks
5. Only then switch to p=reject — and keep monitoring afterwards

In practice, this process takes six to twelve weeks. Compressing it into two days is how you cause a mail outage.

The M365 trap: more senders than you think

Microsoft 365 is well-documented as a mail platform, but many organisations underestimate how many additional services send email from their domain. Power Automate flows, SharePoint notifications, external connectors — all of that can be legitimate mail traffic that never made it into any sender inventory.

On top of that: M365 supports DKIM signing for custom domains, but it has to be explicitly enabled. If you forget that step and flip to p=reject, you may end up blocking your own outbound traffic — SPF breaks on forwarding, and without DKIM as a fallback, messages fail authentication entirely.

What the experienced admin in the thread recommends

The author of the Reddit thread puts it plainly: you cannot send two admins off to enforce DMARC if they have never seen an aggregate report. That is not a criticism of the admins — DMARC is genuinely complex, and without tooling the learning curve is steep.

His recommendation: do not touch enforcement until the sender inventory is complete and the reports have looked clean for several weeks. Anything else is guesswork.

Tooling is what separates success from outage

The difference between a smooth DMARC rollout and a mail outage usually comes down to tooling, not admin competence. Manual report analysis misses senders. No monitoring means problems surface too late.

A solid DMARC monitoring tool should:

• Automatically ingest and parse aggregate reports
• Group senders by compliance status (SPF pass, DKIM pass, both, neither)
• Flag new or unknown sending IPs immediately
• Guide the path from p=none to p=reject with concrete, step-by-step recommendations

That is the approach DMARCPulse takes: automated report analysis, sender inventory building, and incremental enforcement guidance — so IT admins know exactly when it is safe to move to the next policy level.

Check how your domain is configured right now, for free: DMARCPulse Free Domain Check