How to move from p=none to p=reject safely

How to move from p=none to p=reject without breaking your email

Setting your DMARC policy to p=none tells receiving mail servers to collect reports about what is sending mail from your domain but to take no action on failures. It is a useful starting point. It is not a destination.

The goal of p=none is to give you enough data to understand your email sending landscape before you turn on enforcement. Once you have that picture, p=quarantine and then p=reject are the actual goals. Staying at p=none indefinitely is like keeping your front door unlocked while you study the blueprints of your building.

This guide walks through the exact sequence: audit first, read reports, build your inventory, transition through p=quarantine, then enforce at p=reject. It includes a rollback plan because things do go wrong and you need to be able to undo them quickly.

Why p=none is a starting point, not a destination

p=none serves one purpose: observation without consequence. While it is active, receiving servers accept everything that arrives regardless of whether it passes SPF, DKIM, or DMARC alignment. You get reports. Nothing breaks.

The problem is that p=none does not protect anything. If someone spoofs your domain, those messages still land in inboxes. You get a report that says the message failed, but the recipient still received it.

p=quarantine tells receiving servers to move suspicious mail to the spam folder instead of the inbox. p=reject tells them to refuse delivery entirely. Both require that your legitimate sending infrastructure is properly authenticated first.

The transition from p=none to p=reject is not a single switch flip. It is a sequence of steps that lets you correct problems before they cause outages.

Pre-flight audit: what to know before you change anything

Before you touch your DMARC policy record, you need to answer one question: what actually sends mail from my domain?

This includes:

- Your primary mail system (Microsoft 365, Google Workspace, your own MTA)

- Any marketing automation platforms that send on your behalf

- Transactional email services (billing systems, password reset flows, notifications)

- CRM platforms that send from your domain

- Any legacy or niche systems that were set up years ago and may have been forgotten

If you do not have this inventory, you risk flipping p=reject and discovering that a critical service has been sending unauthenticated mail the whole time. The result is exactly the kind of outage you were trying to avoid.

Use a tool like DMARCFlow to parse your XML aggregate reports automatically and build this inventory before making any policy changes. Manually reading XML report files is slow and error-prone. A tool that extracts the sending domains, failure rates, and DKIM/SPF alignment data in one view saves hours and surfaces problems you would otherwise miss.

Reading your DMARC aggregate reports for the first time

Your DMARC policy record specifies where reports go via the rua tag. If you set rua=mailto:dmarc-reports@yourdomain.com, you receive daily XML aggregate reports from every participating receiver.

A DMARC aggregate report covers a 24-hour period and contains one block per sending source observed. Each record includes:

- The sending domain and IP

- The SPF result (pass or fail)

- The DKIM result (pass or fail)

- The DMARC alignment result (aligned or not)

- A count of messages

Your goal in this phase is not to read every record. Your goal is to answer: do all of my legitimate senders show SPF and DKIM passing with aligned domains?

If a sending source shows repeated failures, that source needs to be investigated before you move to p=quarantine. Common causes:

- The sending server IP is not in your SPF record

- The sending domain uses a subdomain that is not covered by your SPF record (missing include: directive)

- The DKIM selector is missing or has expired

- The sending system uses a From address that does not match the organizational domain

RFC 9989 updated the DMARC aggregate report format to include additional metadata fields. If your reporting receiver supports the updated format, you will also see information about forwarding chains and envelope-sender behavior that was not visible in earlier report versions.

Building your sending domain inventory

Start with your DNS: list every domain and subdomain you have ever used for sending email. Then cross-reference that list against the domains appearing in your aggregate reports.

Mark each one as:

- Known and intended: a service you control and want to keep sending

- Known but unintended: a service that should not be sending from this domain, needs to be shut down or reconfigured

- Unknown: a domain in your reports that you did not know was sending mail, needs immediate investigation

Unknown domains are the highest risk before you move to p=reject. They are often:

- Internal systems with hardcoded sender addresses

- Old marketing platforms that were decommissioned but not removed from DNS

- Partner or vendor integrations that are using your domain without your knowledge

DMARCFlow builds this inventory automatically by extracting unique sending domains from your aggregate reports and flagging any that are not in your approved sender list. You can review the full list in one view and make corrections before they become outages. After you move to p=reject, you return to the same report view to confirm that your failure rate stays low and that no new unknown domains have appeared.

The transition sequence: p=quarantine first, then p=reject

Do not go straight from p=none to p=reject. The intermediate step is p=quarantine.

Your DMARC record controls the policy. The standard tags are:

- p=none — monitor only, no action

- p=quarantine — suspicious mail goes to spam

- p=reject — refuse delivery of failing mail

The sp= tag applies the policy to subdomains. If you want the same policy for subdomains as your root domain, add sp=reject to your record.

The pct= tag controls the percentage of failing messages that are affected. Setting pct=0 is a useful testing mechanism before full enforcement. It means 0% of failing messages are affected, so nothing changes while you monitor. Raise pct gradually: 10, 25, 50, 75, 100 as you gain confidence.

A typical transition record at each stage:

p=none (current):

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=0

p=quarantine (transition):

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; sp=reject; pct=10

p=reject (target):

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; sp=reject; pct=100

Stay at p=quarantine for at least two weeks before moving to p=reject. This gives you enough aggregate report data to see whether any legitimate senders are being quarantined. If you see quarantined messages from a sender that should be passing, fix that sender before proceeding.

What to watch for in the first 30 days after p=reject

Once you set p=reject, any message from your domain that fails SPF, DKIM, or alignment is refused at the receiving server. This is the goal. It also means you need to monitor actively.

Watch for:

- Increases in your DMARC failure counts from senders that were previously unknown

- Bounce messages in your postmaster mailbox from receiving servers refusing delivery

- Complaints from internal users that their emails are not reaching specific recipients

The most common cause of post-reject issues is a sending system that was silently failing before and is now loudly refused. A vendor's CRM that has been sending through a third-party relay without proper authentication is the kind of thing that only surfaces after you enforce.

DMARCFlow tracks your aggregate report data over time and flags sudden changes in failure rates, which is the fastest way to catch a new problem before it becomes a support ticket.

How to roll back quickly if something breaks

If something breaks after you move to p=reject, the fastest fix is to lower the policy back to p=none and raise pct to 0:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=0

This stops enforcement immediately and lets mail flow while you investigate. Make this change from wherever you manage your DNS records. DNS propagation is fast for TXT records, typically under five minutes.

Do not wait to see if it resolves itself. If a critical system like your billing platform or a patient portal is down, every minute of delay is a missed notification. Roll back first, investigate second.

Common failure points and how to avoid them

Forgotten sending systems: A system that was set up five years ago and sends three emails a month. Nobody remembers it exists. It is not in your SPF record. It is not DKIM-signed. It fails DMARC alignment silently at p=none and loudly at p=reject. Fix: check your aggregate reports for any sending domain you do not recognize.

Marketing platform misconfiguration: Your email marketing platform sends from a subdomain like emails.example.com but your DMARC record only covers example.com. The platform may handle DKIM signing correctly for its own subdomain but fail alignment with your organizational domain. Fix: either add the marketing platform's sending subdomain to your SPF record or update your DMARC record to sp=quarantine so subdomains have their own policy.

Forwarding chains: If a recipient's server forwards your message to another address, the forwarded copy may fail DMARC because the forwarding server's IP is not in your SPF record and the From address may not align. This is a known DMARC limitation with forwarding. Fix: most modern forwarding services use the Envelope-From (RFC 5321 MailFrom) rather than the From address (RFC 5322 From) for SPF checks, which reduces this problem. However, if you are seeing failures from known forwarding chains, check whether your receiving partners are using SRS (Sender Rewriting Scheme).

Shared infrastructure: If your domain is hosted on a shared platform (a legacy ISP, a co-location provider, a SaaS that sends from your domain on your behalf) and that platform sends mail from multiple customers using the same IP ranges, your SPF record may be too broad and include IPs that are not exclusively yours. Fix: move to DKIM-based authentication where possible, which is tied to the signing domain rather than the sending IP.

Start here

If you are at p=none today, your immediate next step is: read your last 30 days of aggregate reports and build a list of every sending domain in them. Cross-reference that list against your known senders. Anything unknown, investigate.

When your inventory is complete and all known legitimate senders are passing alignment, move to p=quarantine at pct=10. Monitor for two weeks. Raise pct gradually. When you reach pct=100 at p=quarantine and no legitimate mail is being quarantined, move to p=reject.

DMARCFlow automates the report parsing and inventory step. It is the tool that makes this sequence practical instead of a weekend project spent reading XML files.