MSPs
How to Move from DMARC p=none to p=reject Without Losing Mail
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Move in stages: monitor at p=none for at least two weeks, read aggregate reports to identify every legitimate sender, fix authentication for those sources, advance to p=quarantine at a low percentage, watch again, step up to p=quarantine at 100%, then repeat with p=reject at increasing percentages.
What does p=none actually tell you?
A DMARC record at p=none collects aggregate reports showing every IP address sending email from your domain, message volume, and whether SPF, DKIM, and DMARC passed or failed for each source (dmarcreport.com). The policy itself takes no enforcement action. While attackers can still use your domain freely at p=none, the value is in the data (valimail.com).
These XML reports arrive daily from Google, Microsoft, Yahoo, and thousands of other receivers. They surface the legitimate sources you knew about (Microsoft 365, your marketing platform) and the ones you did not (the finance team's billing tool, the help desk software configured three years ago, the HR system sending automated offer letters).
Collect at least one to two weeks of reports before acting on them (dev.to). For organizations with monthly or quarterly sending patterns, the free AI-visibility check (/check) can flag domain health issues immediately, but DMARC aggregate data needs a full sending cycle to be complete.
Why does moving straight to reject break legitimate mail?
If SPF and DKIM are not properly configured, a p=reject policy will block your own legitimate emails, which can severely disrupt business communications (powerdmarc.com). The technical reason is straightforward: DMARC requires aligned authentication, meaning either SPF or DKIM must pass with domain alignment, and if both aligned checks fail, DMARC fails (suped.com).
Many organizations send email through marketing, support, CRM, billing, analytics, and notification platforms, and if those vendors are not configured for SPF and DKIM alignment, legitimate messages may be rejected per DMARC policy (dmarcreport.com). This is not theoretical. Even legitimate messages might get blocked or land in spam, and your team could be missing leads or invoices and not know it.
The staged rollout exists to surface these problems while recovery is still possible. Quarantine puts failing mail in spam, so a legitimate sender you missed is recoverable, while reject discards the message outright.
The practical rollout sequence
Safe DMARC migration is staged: publish p=none, monitor 30 to 60 days using a DMARC reporting platform, identify and authenticate every legitimate sender, then advance to p=quarantine pct=25 for 14 days, pct=100 for 14 to 30 days, p=reject pct=10 for 14 days, pct=100 for ongoing enforcement. Total timeline is 90 to 180 days, because skipping staging causes legitimate mail to be quarantined or rejected.
The MDaemon Technologies blog lays out a conservative cadence: Confirm p=none is producing clean reports for at least two weeks, move to p=quarantine pct=10 for one week, step through pct=25 and pct=50 at one week each, watch pct=100 for two weeks before moving to reject, then apply p=reject pct=10 for one week and step up from there, for a total of roughly two months.
For MSPs managing multiple client domains, the operational reality is that moving from p=none to p=reject typically takes 9 to 18 months when done correctly, with each phase requiring a minimum of 90 days of monitoring and analysis, because rushing through phases risks blocking legitimate email and disrupting business operations.
How to read the reports without drowning in XML
RUA, or DMARC aggregate report, is an XML file sent daily to the address specified in a DMARC record's rua tag, summarizing which emails passed or failed SPF and DKIM authentication, including sending IP addresses, domains, message counts, and authentication results. Reading raw XML by hand does not scale.
Use a DMARC reporting platform or point the rua tag at a parser. RUA reports give you comprehensive visibility into your domain's email activity, with any email server that has received emails from your domain during the reporting period sending a report, which helps identify authentication gaps, sending patterns, and security threats. The specific data points that matter are the source IP, volume, SPF result, DKIM result, and DMARC alignment outcome. Group failures by source IP and investigate every unrecognized sender before you tighten policy.
ActiScore's DNS and TLS checks include SPF, DMARC, and DKIM validation alongside the rest of the guide (/guide). For MSPs running technical audits across a client portfolio, ActiScore's pricing (/pricing) starts at $79 per month for 250 scans and white-labels from the first paid plan.
What happens at p=quarantine, and why it is not optional
p=quarantine is used to review suspicious emails while at DMARC enforcement without the risk of permanently losing legitimate emails, and quarantined emails typically end up in the recipient's spam or junk folder. Quarantine is not a harmless preview, because it asks receivers to take action on messages that fail DMARC, usually spam-folder placement, filtering, or another local action.
A legitimate message can still be delayed, hidden, or handled in a way the sender cannot reverse, so use aggregate reports and representative message tests to find legitimate failures before requesting quarantine. The operational value is that a message landing in spam is recoverable. A message rejected at SMTP is gone.
Move to quarantine first and stay there long enough to see a full sending cycle in your reports, with a fortnight as the usual minimum, because this is the window where a sender nobody remembered shows up as recoverable junk rather than as a bounce.
When you are ready for p=reject
Move to reject when you have been at p=quarantine pct=100 for at least 90 days, zero legitimate mail has been quarantined during that period, all authorized senders consistently pass DMARC, you have a process for authenticating new senders before they go live, and your organization accepts the risk that undiscovered legitimate senders will be blocked.
When you tighten policy and a single user reports a missing message, the temptation is to roll the whole policy back, but the right response is to find the specific sender that broke, fix that sender, and continue. Keep aggregate reporting running after you reach p=reject. New vendors and configuration changes can introduce legitimate failures under either policy.
The staged rollout takes months, not days, because the cost of a missed sender at p=reject is immediate and visible. Business continuity depends on the boring work of reading reports and fixing alignment before you request enforcement.
Common questions
What does DMARC p=none actually do?
A DMARC record at p=none collects aggregate reports showing every IP address sending email from your domain, message volume, and whether SPF, DKIM, and DMARC passed or failed for each source. The policy itself takes no enforcement action, so attackers can still use your domain freely. The value is in the data: these XML reports arrive daily from receivers and surface legitimate sources you knew about plus ones you did not, like forgotten help desk software or HR systems.
Why can't I just go straight to p=reject?
If SPF and DKIM are not properly configured, a p=reject policy will block your own legitimate emails and severely disrupt business communications. Many organizations send through marketing, support, CRM, billing, and notification platforms, and if those vendors are not configured for SPF and DKIM alignment, legitimate messages will be rejected per DMARC policy. The staged rollout exists to surface these problems while recovery is still possible, because quarantine puts failing mail in spam where it is recoverable, while reject discards the message outright.
How long does it take to move from p=none to p=reject?
Safe DMARC migration typically takes 90 to 180 days for a single domain, and for MSPs managing multiple client domains the timeline is often 9 to 18 months when done correctly. The sequence is: publish p=none and monitor 30 to 60 days, identify and authenticate every legitimate sender, advance to p=quarantine pct=25 for 14 days, pct=100 for 14 to 30 days, then p=reject pct=10 for 14 days and step up to pct=100. Skipping staging causes legitimate mail to be quarantined or rejected.
What is p=quarantine and why do I need it?
p=quarantine asks email receivers to take action on messages that fail DMARC, usually spam-folder placement, and quarantined emails typically end up in the recipient's junk folder rather than being permanently rejected. Quarantine is not optional because a legitimate message landing in spam is recoverable, but a message rejected at SMTP is gone. Move to quarantine first and stay there long enough to see a full sending cycle in your reports, with a fortnight as the usual minimum, so forgotten senders show up as recoverable junk rather than bounces.
When am I ready to move to p=reject?
Move to reject when you have been at p=quarantine pct=100 for at least 90 days, zero legitimate mail has been quarantined during that period, all authorized senders consistently pass DMARC, and you have a process for authenticating new senders before they go live. When you tighten policy and a user reports a missing message, the right response is to find the specific sender that broke, fix that sender, and continue rather than rolling the whole policy back. Keep aggregate reporting running after you reach p=reject because new vendors and configuration changes can introduce legitimate failures.