When to Upgrade from DMARC p=none to quarantine or reject

What p=none actually does (and does not do)

p=none tells receiving servers to take no action on mail that fails DMARC alignment. That sounds like "do nothing," but it is not. Receiving servers still process the mail normally, and many send aggregate reports to the RUA address listed in your DMARC record. You get data about what is happening without changing what lands in inboxes.

The result is a passive monitoring phase. Nothing breaks. Nothing gets rejected. You receive reports about whether mail from your domain is passing or failing, and from which IP addresses it originates.

The critical misunderstanding is treating p=none as a final resting state rather than a data-gathering phase. Domains that set p=none and never act on the reports are paying for a subscription to their own email health data and ignoring it entirely.

Why domains stay at p=none too long

Three reasons come up repeatedly:

Aggregate reports are hard to read. A raw DMARC aggregate report is an XML file that most email admins open once, find unreadable, and stop opening. Without a tool to parse the data, p=none feels like collecting electricity bills and never reading them.

Fear of breaking forwarding. Email forwarding rewrites the From header in ways that cause DMARC failures even when SPF and DKIM are perfectly configured on the sending side. Admins worry that tightening the policy will trap legitimate forwarded mail. This concern is valid but often manageable once the actual forwarding paths are mapped.

Unknown third-party senders. A domain may use a CRM, a marketing automation platform, a ticketing system, or a legacy internal relay that sends mail "from" the company domain without proper DKIM signing. These sources appear as failures in aggregate reports but are easy to overlook when no one is reading those reports.

The three readiness checks before any upgrade

Before moving to p=quarantine, confirm these three things are true:

1. RUA reports are being received and parsed. You have an active RUA address configured in your DMARC DNS record and a tool or service collecting those reports. Raw XML reports do not help if no one reads them.

2. All legitimate sending sources are documented. You know every IP address that sends mail from your domain. This includes primary mail servers, marketing automation platforms, CRM systems, internal relays, and any SaaS tool that sends on your behalf.

3. Forwarding paths that could break are identified. You have mapped which forwarding setups rewrite the From header and assessed whether those forwarding relationships are replaceable or necessary.

If any of these three is unknown or incomplete, stay at p=none longer. The data from aggregate reports makes the unknowns visible.

What to look for in aggregate reports before upgrading

A DMARC aggregate report covers a 24-hour period and lists every source that sent mail "from" your domain. The two signals that matter most before upgrading are alignment pass rate and unknown sources.

Alignment pass rate tells you what percentage of mail from your domain arrives with valid SPF and DKIM alignment. If 95 percent or more of your legitimate traffic is passing and the failing portion has an identifiable cause, you are likely ready. If 30 percent of your legitimate traffic is failing, moving to enforcement will break legitimate mail.

Unknown sources are IP addresses in the report that you do not recognize. These could be third-party platforms you forgot about, compromised credentials being used to relay spam, or misconfigured SaaS integrations. Before upgrading, every unknown source needs to be either authorized and documented, or investigated and blocked.

How DMARCFlow makes the monitoring phase actionable

Reading aggregate reports is the prerequisite for every upgrade decision in this guide. Without parsed report data, you are guessing whether your alignment rate is 95 percent or 40 percent, and you cannot tell which new failure sources appear after you change your policy.

DMARCFlow parses RUA aggregate reports and presents three things that matter during the monitoring phase: your alignment pass rate over time, the full list of active sending sources grouped by domain, and alerts when new sources appear that were not in previous reports. These are the three inputs that drive every readiness check above.

The 1 EUR/month entry tier covers RUA report parsing. That is the minimum viable setup for the p=none monitoring phase. Without it, you have a DMARC record that generates data you are not using.

When you are ready to move to p=quarantine, the same DMARCFlow dashboard shows whether your alignment rate holds or whether enforcement introduces new failure sources that did not appear at p=none. This is the core feedback loop that makes the staged upgrade path safer than guessing.

Step-by-step upgrade path

#### Stage 1: Move to p=quarantine

Set your DMARC record to v=DMARC1; p=quarantine; rua=mailto:your-reports@example.com; pct=25;

The pct parameter limits enforcement to 25 percent of messages that fail DMARC alignment. Mail that passes alignment is unaffected. Mail that fails alignment has a 25 percent chance of being sent to the spam or junk folder; the other 75 percent continues as normal.

Stay at 25 percent for a minimum of two weeks. Longer for high-volume domains or domains with complex sending patterns. Watch your support channels for reports of missing mail, particularly from external senders such as banking notifications, government communications, or subscription confirmations.

During this stage, DMARCFlow will show you whether the messages being quarantined match the expected failure profile or whether legitimate sources are being caught unexpectedly.

#### Stage 2: Validate quarantine results

Before increasing enforcement, confirm that quarantine is not catching legitimate mail. Look for:

Users reporting missing notifications from external services
Automated system alerts that are not arriving (payment confirmations, security alerts, shipping updates)
Complaints about expected mail appearing in spam folders

If none of these are happening and your aggregate reports show the same alignment pass rate as before, increase pct to 50, then 75, then 100 over subsequent two-week intervals. Each step is a checkpoint. DMARCFlow alerts make it straightforward to spot whether a pct change introduced new failure sources before those failures become user complaints.

#### Stage 3: Move to p=reject

Once p=quarantine at 100 percent has been stable for at least two weeks with no legitimate mail issues, move to p=reject:

v=DMARC1; p=reject; rua=mailto:your-reports@example.com;

Receiving servers will now refuse mail that fails DMARC alignment outright. Any mail from an unauthorized source or through a misconfigured relay gets rejected at the receiving server level.

The first 48 hours after setting p=reject require active monitoring. Watch for spikes in rejected mail from sources you thought were legitimate. Some legitimate senders (older mailing lists, certain SaaS tools) may have been borderline all along and will fail now that the policy is strict. DMARCFlow's daily summary makes it easier to catch these spikes before they become wider email delivery problems.

Common reasons legitimate mail breaks after the upgrade

Email forwarding that rewrites the From header. This is the most common cause of DMARC failures after upgrade. When a forwarder receives a message and resends it "from" the original domain, the forwarded message arrives from the forwarder's IP with the original domain in the From header. DMARC alignment fails because the IP is not authorized. Solution: use a subdomain for forwarding-sensitive communications, or configure the forwarder to preserve the original headers.

Third-party platforms sending without DKIM. Marketing automation platforms, event management tools, and legacy CRMs often send mail "from" the company domain but sign with their own DKIM key, not the company's. Their DKIM selector will not align with your domain. Solution: either configure those platforms to use a subdomain, or migrate to platforms that support proper DKIM signing for your domain.

Internal mail relays that do not align. Some organizations run internal mail relays or SMTP gateways that rewrite addresses or relay on behalf of users without preserving the original sending infrastructure. Solution: audit internal relay configurations before upgrading, or use a dedicated sending domain for relay traffic.

How to handle third-party senders you cannot control

Some SaaS tools send from your domain without offering DKIM configuration. This is common with older platforms or tools that treat email as a commodity feature. Options:

Subdomain separation. Use a subdomain such as marketing.yourdomain.com for campaigns and announcements. The parent domain enforces strict DMARC while the subdomain can use a looser policy. This is the cleanest approach for tools that cannot be reconfigured.

Email relay with alignment correction. Route the tool's mail through a relay that signs with your DKIM key and operates within your SPF range. This adds complexity but preserves enforcement on the parent domain.

Accept a limited enforcement policy. If the volume of mail from that platform is low and the platform cannot be replaced, stay at p=quarantine for that domain. p=quarantine still provides meaningful protection against direct domain spoofing.

FAQ

How long should I stay at p=none before upgrading?
At minimum, collect 30 days of aggregate report data. If your domain has many sending sources or irregular email patterns (seasonal campaigns, third-party integrations that send infrequently), collect data for 60 to 90 days. The longer the baseline, the clearer it is whether your alignment rate is genuinely stable.

Can I skip p=quarantine and go straight to p=reject?
Technically yes. There is no technical requirement to pass through quarantine. Practically, skipping quarantine means you lose the safety net of suspicious mail still being delivered to spam while you validate. If your sending infrastructure is simple and well-documented, you may be ready to go directly to p=reject. If you have any unknown sources or third-party senders, use quarantine as your validation stage.

What happens to my mailing lists after p=reject?
Mailing lists that forward mail and rewrite the From header will break. This includes some legacy mailing list software and most auto-forwarding rules configured at the mail server level. If you have mailing lists you cannot replace, test them before upgrading or use a subdomain for list traffic that carries a looser DMARC policy.

Do I need to configure anything new before upgrading?
You need a working RUA address in your DMARC DNS record and a way to read those reports. Without report parsing, you are upgrading without visibility. Configure RUA first, verify reports are arriving, then make the policy change.

What is the biggest mistake admins make during the upgrade?
Moving to p=reject before identifying all legitimate sending sources. Any authorized sender that is not aligned will have mail rejected. The upgrade feels like a security improvement, but it also introduces reliability risk because legitimate mail from misconfigured sources gets blocked. Identifying those sources first is the work that makes the upgrade safe.