How to Move DMARC to p=reject Safely (For Beginners)

If someone told you to "just set DMARC to reject" on your domain and you do not know what that means, this guide is for you.

p=reject is the strictest DMARC policy. When a receiving mail server sees it, it drops messages that fail DMARC checks. That sounds scary. But "p=reject" does not mean "reject all email from your domain." It means "reject only the email that fails to prove it actually came from your domain." Legitimate email that passes SPF or DKIM alignment still arrives normally.

The risk is not that p=reject blocks good email. The risk is that your domain is sending email that cannot pass DMARC checks - and you would not know it until your own mail starts bouncing.

Here is how to move to p=reject safely, even if you have never touched SPF, DKIM, or DMARC before.

The Three-Phase Path to p=reject

Most teams rush to p=reject because they have heard it is the "secure" setting. It is - but only after you have confirmed your legitimate email can actually pass the checks. The safe path has three phases.

Phase 1: p=none with Aggregate Reports

Start here. p=none means the receiving server takes no action on failing email - it just tells you what it saw. This is your learning phase.

Set your DMARC record to:


v=DMARC1; p=none; rua=mailto:your@email.com;

The rua parameter tells receiving servers to send you aggregate reports. These reports tell you which sending sources are sending email on behalf of your domain and whether those sources pass or fail DMARC checks.

This phase typically lasts 2 to 4 weeks. You are looking for one thing: a clear picture of every legitimate source sending email from your domain, and confirmation that all of them pass DMARC alignment.

Phase 2: p=quarantine

When your aggregate reports show zero unexpected failures - meaning every legitimate sending source consistently passes - move to p=quarantine.


v=DMARC1; p=quarantine; rua=mailto:your@email.com;

p=quarantine tells receiving servers to mark failing email as suspicious, not to drop it outright. This is your safety net. If something is misconfigured, you will see complaints instead of silence.

This phase also lasts 2 to 4 weeks.

Phase 3: p=reject

Only move to p=reject when your aggregate reports show consistent pass rates across all legitimate sending sources and you have zero unexpected failures over at least two reporting periods.


v=DMARC1; p=reject; rua=mailto:your@email.com;

What Aggregate Reports Tell You (And Why They Matter)

Most teams skip directly to p=reject because they do not know how to read aggregate reports. That is understandable. Raw DMARC XML reports are not human-readable by default.

This is where monitoring tools matter. DMARCFlow parses aggregate reports and turns them into plain-English findings: which sending sources are passing, which are failing, and whether each failure is expected. For a team with no prior email authentication background, this is the difference between knowing whether you are ready for p=reject and hoping you are.

Common Reasons Legitimate Email Fails DMARC Before You Move to p=reject

These are the failure patterns most commonly found in aggregate reports during Phase 1. Fix them before moving to p=quarantine or p=reject.

Subdomains Without Their Own SPF or DKIM

If your root domain has a DMARC record with p=reject, and a subdomain is sending email without its own SPF record or DKIM key, that subdomain's email will be rejected. This catches many teams off guard.

Third-Party Senders and Marketing Platforms

Any service that sends email on your behalf - your CRM, marketing platform, invoicing tool, support desk - must send with SPF and DKIM aligned to your domain. If they send from their own domain instead, that email will fail DMARC when your policy is p=reject.

Legacy Devices and Internal Relays

Old printers, scanners, and internal mail relays often relay email without proper authentication. They are a frequent cause of unexpected failures in aggregate reports.

Spoofed Email From Outside Your Domain

Aggregate reports also show attempts to send email that pretends to be from your domain but comes from outside infrastructure. These failures are expected and actually indicate that DMARC is working. Do not panic when you see them.

The Readiness Checklist

Before you move to p=reject, confirm every item on this list.

You have received at least 2 weeks of aggregate reports
Every legitimate sending source shows a consistent DMARC pass rate in those reports
All marketing, CRM, and third-party email tools send with SPF or DKIM aligned to your domain
Subdomains that send email have their own SPF records (or are covered by your existing SPF)
Legacy devices and internal relays that send email are either authenticated or isolated
You have a monitoring tool that will alert you to sudden changes in DMARC pass rates
You know how to read aggregate reports or use a tool that translates them for you

If you are working through this list and realize you do not know how to read the aggregate reports, that is the most important gap to close first. Everything else on the list depends on understanding what your reports actually say. DMARCFlow was built to close that gap - it monitors your aggregate reports continuously and alerts you to new failures before you move to the next phase.

How DMARCFlow Fits This Process

DMARCFlow is built for exactly this situation. It reads your aggregate reports and translates them into plain-English findings: which sources are passing, which are failing, and what the failures mean. For a team with no prior email authentication experience, that translation layer is the difference between an informed decision and a guess.

You do not need to learn the XML format of DMARC reports or become an SPF expert. You need to know whether your legitimate email is passing and whether anything unexpected has changed. DMARCFlow gives you that in a monitoring dashboard with alerting.

FAQ

How long does each phase take?

Most teams spend 2 to 4 weeks in each phase. Rushing through phases because p=reject "feels final" is the most common mistake. If you see new sending sources appearing in your reports, extend the current phase until the picture is clear.

What if my email breaks after moving to p=reject?

If legitimate email stops arriving, you moved too fast. Roll back to p=quarantine immediately and check your aggregate reports for new failures. The rollback is instant - just update your DNS record.

Can I move to p=reject if I use Microsoft 365 or Google Workspace?

Yes. Both platforms support DMARC. Microsoft 365 and Google Workspace send with proper SPF and DKIM alignment by default. The catch is any third-party tool integrated with your Microsoft or Google account - those need to be checked individually.

What if I have no idea what my sending sources are?

Start with p=none and wait for aggregate reports. After two weeks you will have a complete map of every IP sending email as your domain. Some will be expected, some will be surprises. The surprises are what you are looking for.

Do I need a professional consultant to do this?

Not for most teams. If your email setup is standard - Microsoft 365 or Google Workspace, a handful of known third-party tools - you can work through this checklist yourself. If you have a complex multi-vendor setup with custom mail infrastructure, a consultant who specializes in email authentication is worth the cost.

Summary

The path to p=reject is not a single DNS change. It is a process of learning what your domain is actually sending, identifying the sources that cannot prove they are legitimate, and fixing those before you tell receiving servers to start rejecting the rest.

Teams with no prior email authentication experience can follow this path safely. The aggregate reports are your safety net. Monitoring tools like DMARCFlow make those reports readable. The three-phase approach - p=none, p=quarantine, p=reject - gives you a checkpoint at each stage before you commit to the next one.

Skip the phases and you are guessing. Follow the phases and you are making a decision you can defend.