How to Move from p=none to p=reject: A Step-by-Step DMARC Migration Guide

Why moving past p=none matters

A DMARC record with p=none is a monitoring tool, not a security control. It tells receiving mail servers: "Here are my reporting addresses, but don't actually do anything when something fails." Spoofers go through unhindered. p=none provides zero protection.

The whole point of DMARC is the policy: p=quarantine sends failures to the spam folder, and p=reject tells receivers to drop them at the SMTP layer so they never land in any folder. Until you reach p=reject at 100%, your brand is still exposed to spoofing.

The reason most domains stall at p=none is the (entirely justified) fear of blocking their own legitimate mail — a third-party platform you forgot about, a subdomain a different team owns, a transactional service no one documented. This guide is the de-risking plan: a phased rollout where every transition is small, reversible, and gated on what your aggregate reports actually show.

Pre-flight checks before you start

Before you even publish p=none, do the basics:

1. SPF is published and clean. Run our SPF Checker. Under the 10-DNS-lookup limit, ending with -all or ~all, no +all, no duplicate records. Read the full SPF guide if you're not sure.
2. DKIM is published for every sender. Each platform that sends as your domain needs a DKIM selector under your domain — not the vendor's. See the DKIM guide for selectors, key sizes, and multi-vendor patterns.
3. You have a reporting mailbox or service. Aggregate reports arrive as gzipped XML attachments daily from dozens of receivers. Don't pipe them to a human's inbox — use a dedicated mailbox or a DMARC analyser that ingests and parses them.
4. You can roll back the DNS record in minutes. Make sure you have access to the DNS provider and that TTL on the DMARC record is short (300–3600 seconds) during the migration window. Long TTLs hurt — you can't roll back fast.
5. Inventory of senders. Make a list: marketing platform, CRM, helpdesk, transactional provider, in-house mail, accounting tool, e-commerce notifications. You'll cross-check this against the reports.

Phase 1: p=none, monitor for 2–4 weeks

Publish:

_dmarc.example.com. IN TXT
"v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r"

Tags explained:

• p=none — No enforcement, just reporting.
• rua=mailto:... — Where aggregate reports are sent. You can list multiple addresses comma-separated. If the reporting mailbox is on a different domain than the DMARC record, that domain needs to authorise the reporting; see RFC 7489 §7.1.
• pct=100 — "Apply this policy to 100% of messages." It's a no-op at p=none but lets you copy/paste this template into the next phases.
• adkim=r, aspf=r — Relaxed alignment. We'll tighten these in Phase 5.

What to do during this phase:

1. Wait 7–10 days before reading reports. Reports trickle in — if you check on day 2 you'll see a tiny fraction of your real volume.
2. Build a sender catalogue from the reports. Every <record> element in the XML lists a source IP and authentication results. Map each IP to a real-world sender: "203.0.113.45 = our marketing platform", "198.51.100.12 = a vendor we forgot about".
3. Identify unauthenticated legitimate senders. Anything sending on your behalf with dmarc=fail needs fixing — usually by adding DKIM under your domain or extending SPF.
4. Identify spoofers. IPs you don't recognise that fail DMARC are either bad actors or shadow-IT senders. Investigate; if confirmed malicious, you're ready to enforce.

Exit criteria for Phase 1: at least 95% of your legitimate mail volume passes DMARC, every passing IP is mapped to a known sender, and you understand which failing IPs are legitimate vs malicious.

Phase 2: p=quarantine, pct=10 (1–2 weeks)

This is the first transition that actually affects delivery. By starting at pct=10, only 10% of failing messages get the quarantine treatment — the other 90% still pass through. This is a controlled bleed test.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=10; adkim=r; aspf=r

What to watch:

• Aggregate-report failure rate. Compare to the Phase 1 baseline; it should be roughly the same.
• Any spike in support tickets — "I'm not getting your password reset email." This is your early signal that a transactional sender is failing alignment.
• Postmaster Tools (Gmail / Microsoft / Yahoo) for changes in spam rate or authentication.

If the failure rate is stable and there are no incident reports for 7–10 days, move to Phase 3. If you see a real failure (legitimate mail going to spam), roll back to p=none, fix the alignment issue, and re-enter Phase 2.

Phase 3: ramp quarantine to 100%

Bump pct in stages, holding each level for a week or so:

1. p=quarantine; pct=25 — hold 7 days.
2. p=quarantine; pct=50 — hold 7 days.
3. p=quarantine; pct=100 — hold 7–14 days.

At each step the rule is the same: watch for new failures in reports, watch Postmaster Tools, watch the support queue. If something legitimate breaks, drop back one level and fix it before climbing again.

An important quirk: pct only applies to quarantine and reject. Receivers that don't honour pct (a minority but they exist) treat everything as the full policy. Treat pct as a soft guardrail, not a guarantee.

By the end of Phase 3 you've effectively eliminated spoofed mail to inboxes — it's all going to spam — but it's still being delivered. Phase 4 closes that.

Phase 4: p=reject, ramp 10 → 50 → 100

Now you're moving from "delivered to spam" to "rejected at SMTP." A bad alignment failure here means the sender bounces. The percentage ramp matters more than ever.

1. p=reject; pct=10 — hold 7 days. 10% of failing mail bounces; 90% gets the previous quarantine treatment.
2. p=reject; pct=25 — hold 7 days.
3. p=reject; pct=50 — hold 7–10 days.
4. p=reject; pct=100 — hold indefinitely. You're now fully enforced.

At p=reject; pct=100, your DMARC record becomes:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r

(You can drop the pct=100 — it's the default — but leaving it for explicitness is fine.)

One often-overlooked extra: the sp= tag for subdomain policy. If you don't send from subdomains, set sp=reject from the start to block subdomain spoofing too:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com

If subdomains do send mail, give each a dedicated policy record at _dmarc.<sub>.example.com and run its own ramp.

Phase 5: tighten alignment (adkim=s, aspf=s)

By default, DMARC uses relaxed alignment: d=mail.example.com in DKIM aligns with From: hello@example.com as long as they share the organizational domain (example.com).

Strict alignment requires an exact match. d=mail.example.com would not align with From: hello@example.com under strict mode — only d=example.com would.

Strict alignment is appropriate for high-value domains where you want to prevent spoofing of the parent by anyone using a subdomain — including your own infrastructure. It's the highest assurance level but the most fragile: any vendor that signs with a different subdomain breaks alignment.

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com

Roll this out only after several weeks of clean reports at p=reject; pct=100, and only if every vendor is signing with your exact organizational domain.

Reading DMARC aggregate reports

An aggregate report is a gzipped XML document covering one day's traffic from one receiver to your domain. The structure:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1716422400</begin>
      <end>1716508800</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <pct>25</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.45</source_ip>
      <count>1240</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result></dkim>
      <spf><domain>example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
  <!-- more records -->
</feedback>

Each <record> is one source IP's batch for that day. The fields to focus on:

• source_ip — Map this to a real-world sender.
• count — Number of messages.
• policy_evaluated/disposition — What the receiver did: none, quarantine, or reject.
• policy_evaluated/dkim and spf — The DMARC alignment result (pass/fail), not just the raw check.
• auth_results — The raw protocol-level results, including which domain signed/passed.

The key distinction: auth_results/dkim/result=pass means DKIM verified cryptographically. policy_evaluated/dkim=pass means it verified and aligned with the From header. You can have one without the other — that's the classic third-party-sender problem.

Triaging failures at each phase

When a record shows policy_evaluated/dkim=fail and policy_evaluated/spf=fail, classify the source IP into one of these buckets:

1. Known legitimate sender, misconfigured. Action: fix the alignment. Usually means asking the vendor to sign with d=example.com, or adding a custom Return-Path under your domain to bring SPF into alignment.
2. Forgotten legitimate sender. Someone in marketing signed up for a tool a year ago. Action: either retire the tool, or onboard it properly with DKIM-on-your-domain.
3. Forwarded mail. A recipient set up automatic forwarding from customer@example.com → customer@gmail.com. Your DKIM survives forwarding (good), but SPF doesn't (the forwarding server's IP isn't in your SPF). As long as DKIM aligns, DMARC still passes. If only SPF passed originally, forwarded mail fails. This is normal background noise — usually under 1% of volume.
4. Mailing list rewrites. Lists frequently rewrite From and modify the body, breaking DKIM. The fix is ARC (which lists are slowly adopting). Until then, mailing-list failures are expected; their volume is usually negligible.
5. Spoofers. Unknown IPs sending in volume with no authentication. Action: this is exactly what DMARC enforcement is for. Move forward in your migration.

When to roll back

The rule: any incident affecting real users is grounds for an immediate one-level rollback. Examples:

• Support tickets about missing password resets.
• A spike in quarantine or reject dispositions for a known internal sender.
• A drop in deliverability in Postmaster Tools.
• A new vendor onboarded mid-migration without DKIM setup — their mail is now failing.

Roll back, fix, and resume. Don't try to push through — the goal is to reach p=reject sustainably, not to hit a deadline.

What "roll back" means in practice:

1. At p=reject; pct=25 with an incident → drop to p=quarantine; pct=100.
2. At p=quarantine; pct=50 with an incident → drop to p=quarantine; pct=10.
3. Major incident at any phase → drop straight to p=none, investigate, then re-enter from Phase 2 (you don't need to redo Phase 1).

Because TTL on the DMARC record is short, the rollback propagates in minutes — not hours.

How Sendvery surfaces these signals

The whole migration depends on visibility into your aggregate reports — which IPs are passing, which are failing, what their alignment looks like, and how the trend is moving. That's exactly what Sendvery does:

• Auto-ingests aggregate reports from a dedicated reporting mailbox — no manual XML parsing.
• Maps source IPs to senders using RDAP and known-vendor heuristics, so you see "Mailchimp" instead of "23.249.218.X".
• Per-sender alignment status: a vendor with DKIM passing but not aligned shows up as a yellow row, not a green one. That's the actionable signal.
• Trend dashboards per source so you can see "this vendor's failure rate doubled last week" before users notice.
• Phase-by-phase guidance: pre-built filters for "what's currently failing DMARC?" — the list that drives your migration decisions.
• DNS monitoring for the DMARC record itself, so accidental changes (someone fat-fingered p=none back on) trigger an alert.

Ready to start? Run our DMARC Checker against your domain to confirm your current policy, then read the DMARC fundamentals if you need a refresher. For the broader picture, the SPF/DKIM/DMARC overview covers how the three protocols fit together.