Your DMARC record has sat at p=none for months, and every aggregate report says your SPF and DKIM authentication passes cleanly. Now you want to move DMARC to quarantine so spoofed mail actually gets treated as suspicious instead of just logged. The risk: flip the policy too fast and your own newsletter tool, a forwarded ticket from a partner, or a mailing list you forgot about starts landing in spam right alongside the attackers you meant to block.
DMARC is the DNS record that tells a receiving mail server what to do when a message fails SPF or DKIM alignment — none, quarantine, or reject. EmailControl watches that policy, and the authentication checks behind it, so a bad move to quarantine turns up as an alert instead of a support ticket from a customer who never got your invoice.
What Does p=quarantine Actually Do to Your Mail?
p=quarantine tells a receiving server to treat a message that fails SPF or DKIM alignment as suspicious, usually routing it to the recipient's spam folder, instead of delivering it to the inbox or refusing it outright at the SMTP level. It is the middle setting between p=none, which only logs failures, and p=reject, which bounces the message before it is accepted.
The DMARC specification defines a pct= tag that applies the policy to only a share of mail, as set out in RFC 7489, section 6.3. A record of p=quarantine; pct=10 quarantines roughly one message in ten that fails alignment, while the rest still pass through under the old none behavior — so you watch the effect on a slice of traffic before it applies to everything. Every mailbox provider that publishes DMARC support, including the large webmail and enterprise platforms, honors pct= the same way, so the staging behavior is consistent no matter where your recipients read mail.
How Long Should You Stay at p=none Before Moving to Quarantine?
Stay at p=none until you have at least two to three weeks of aggregate (rua) reports showing every legitimate sending source — your mail server, marketing platform, helpdesk, and any forwarders — passes SPF or DKIM alignment consistently, not just most days. A source that fails intermittently at p=none will fail the same way at p=quarantine, except now the mail actually disappears into spam.
| Policy | What happens to failing mail | When to use it |
|---|---|---|
| p=none | Delivered normally; failure only recorded in reports | First 2-4 weeks, to inventory every sending source |
| p=quarantine | Routed to spam folder, not the inbox | Once reports show your own sources pass consistently |
| p=reject | Refused at the SMTP level before delivery | After quarantine runs clean for several weeks at pct=100 |
The gap between p=none and p=quarantine is also where sender reputation starts to matter beyond DMARC itself. A source that lands in spam under quarantine tends to keep landing in spam even after you fix the underlying SPF or DKIM problem, because the mailbox provider's own filtering has already learned to distrust it — one more reason to fix alignment before you enforce, not after.
What Fields Does a DMARC Aggregate Report Actually Contain?
A rua report is an XML file, not a dashboard, and that is why most migrations stall at the reading stage rather than the DNS stage. Each record inside it lists a source_ip that sent mail claiming your domain, a count of how many messages came from it in that window, a disposition showing what your current policy did with them, and separate pass or fail results for SPF and DKIM alignment.
A source with a high count and a fail disposition is either a sending tool you have not authorized in SPF yet or a spoofing attempt — the two look identical in the report until you check whether you recognize the source_ip. Confirming that list, one source at a time, before you touch the policy is the actual work of the migration; the DNS record change itself is one line.
The Migration Sequence From None to Reject
The order matters more than the speed. Skipping a step is what causes a customer's mail to vanish without a bounce message anyone notices.
- Publish p=none with a rua= address and collect reports for at least two weeks.
- List every sending source the reports surface — mail server, CRM, helpdesk, marketing tool, any forwarding rule.
- Fix SPF or DKIM alignment for each source that fails, one at a time, and confirm the fix in the next report.
- Switch to p=quarantine; pct=10 and watch for a week.
- Raise pct= in steps of 25 to 50 only after each step shows zero unexpected quarantines.
- Hold at p=quarantine; pct=100 for two to three weeks before considering p=reject.
Once quarantine is stable, the same staged pct= approach applies to reject — the DNS record changes, the discipline of watching reports before raising the percentage does not. A domain that jumps from p=none straight to p=reject skips the one stage where a mistake is merely embarrassing instead of a lost invoice or a missed contract.
Reading the aggregate reports by hand at each step is where most migrations stall out, because the XML files are not built for a person to skim, and a domain sending from three or four sources can easily produce reports from a dozen different source_ip values once every mail relay and forwarder is counted. EmailControl parses DMARC results alongside your SPF and DKIM records on every scheduled check and flags a source the moment it starts failing at your current pct= level, before it becomes a pattern you find weeks later. The record syntax, selector list, and common failure causes are covered on the FAQ page.
What Breaks When You Move to Quarantine Too Early?
The honest objection to any of this is effort: staging a policy over five or six steps feels slower than just setting p=reject and being done with it. The cost of skipping the stages is real, though — a vendor tool your finance team depends on, or a mailing list a former employee set up years ago, can fail alignment silently at p=none and then start losing mail the moment you tighten the policy, with no error message pointing back at DMARC as the cause.
Monitoring does not require rewriting how your organization sends mail. EmailControl checks the policy on every scan — weekly on the free plan, daily on Pro, hourly on Agency, detailed on the pricing page — and an alert reaches you within 15 minutes of a check that finds a new failure, so the staged rollout stays a DNS change you control instead of a mystery your customers report first. The same check also folds DMARC status into your overall score, weighted alongside blacklist cleanliness and SPF or DKIM validity, so a quarantine migration that goes wrong shows up as a score drop, not just a buried report you forgot to open.
None of this requires handing over registrar access. EmailControl reads public DNS and the reports your own record already asks for — it never sends mail through your domain and never touches your mail server credentials, so adding it to the migration does not add a new system that can break your mail flow.
Start Monitoring Before You Flip the Policy
Add your domain and run a free check before you touch the DMARC record at all — it takes about a minute and shows every current sending source and whether it passes SPF and DKIM today, which is the exact list you need before you write p=quarantine into DNS. Start free monitoring and you will see the same report EmailControl checks on every scheduled scan afterward.