How to Move from DMARC p=none to p=reject Without Breaking Your Email

What p=none Actually Means and Why It Is Not Protection

If your DMARC record reads v=DMARC1; p=none;, your domain is not protected. You are paying for monitoring and getting none of the security benefit.

p=none tells receiving mail servers to take no action on emails that fail DMARC alignment. They deliver everything, regardless of whether your domain is being spoofed right now. An attacker can send email as yourdomain.com to any recipient whose server accepts it, and your p=none policy will not stop them.

The confusion comes from the word "policy." It sounds active. But p=none is passive -- it collects reports, it does not block anything. Most operators who contact DMARCFlow for the first time are surprised to learn that their "policy" has been doing nothing except generating log files for months.

This is why security frameworks and inbox providers push for enforcement. Gmail and Yahoo's 2024 sender requirements specify that bulk senders must have at least some level of DMARC enforcement. But the real reason to move to p=reject is straightforward: it is the only DMARC policy that actually stops spoofing of your domain.

The Three DMARC Policy Levels Explained

DMARC has three policy settings:

p=none -- Monitor only. Take no action on failures. Useful for the initial monitoring period and for catching new sending sources before you enforce.

p=quarantine -- Treat failing email as suspicious. The receiving server may route it to spam or junk. This is a softer enforcement step. It reduces spoofing impact without fully blocking.

p=reject -- Reject failing email outright. The receiving server refuses to deliver it. This is full enforcement. It stops spoofing completely but only works well when your legitimate sending sources are correctly configured.

The progression most operators follow is p=none for weeks or months, then p=quarantine as a transitional step, then p=reject once reports show that all legitimate sources are passing alignment. Some operators skip quarantine and go straight to reject, which works fine if the pre-upgrade review was thorough.

How to Read Your Aggregate Reports Before Upgrading

Before changing your policy, you need to understand what your aggregate (RUA) reports are telling you. RUA reports arrive daily or weekly from receiving servers and summarize what they saw when receiving email from your domain.

The most important field is the "source IP" breakdown. Each unique IP sending on behalf of your domain appears in the report with a count of emails sent, and a pass/fail breakdown for SPF, DKIM, and DMARC alignment.

You are looking for three things:

1. All your legitimate senders appear in the report. Your primary mail server, any marketing platform, any SaaS tool that sends on your behalf -- they should all show up as sources. If a source is missing from the report entirely, it may be sending email that never reaches a DMARC-capable receiver, or it may not be using your domain in the From address at all.

2. All legitimate sources pass SPF or DKIM alignment. This is the key check. A source passes DMARC when either SPF alignment OR DKIM alignment passes. If a legitimate ESP is failing both, you need to fix its configuration before going to p=reject.

3. The volume of failures is low and explainable. Some failures are normal -- forwarded email, internal systems that relay without proper signing, test sends from developers. What you do not want is a high volume of failures from sources you cannot identify.

Manually reviewing raw DMARC aggregate XML reports is tedious and error-prone. Most operators find it faster to use a tool that presents RUA data as a categorized source list with pass/fail breakdowns. DMARCFlow, for example, parses RUA reports automatically and flags new senders, misconfigured ESPs, and spoofing attempts in separate views, which makes the pre-upgrade review faster and less likely to miss something.

The Pre-Upgrade Checklist -- Are You Ready for p=reject?

Run through this before changing your policy:

Known senders are all passing. Every ESP, mail server, and SaaS tool in your RUA report that you recognize should show pass for either SPF alignment or DKIM alignment. If any known sender fails both, fix its configuration first.

You have identified unknown sources and classified them. Unknown sources in your RUA report fall into two categories: spoofing attempts (attackers sending from external IPs using your domain) and misconfigured legitimate services (a vendor or internal tool that is using your domain incorrectly). You need to investigate high-volume unknown sources before enforcing. DMARCFlow's automated sender categorization separates known from unknown and highlights new entries, which is the fastest way to work through this list.

Forwarding is accounted for. If your users forward email to external addresses using your domain as the From address, those forwarded messages will fail DMARC after you enforce. The fix is usually DKIM signing at the original sender, or using an authenticated receiving chain (ARC) if the forwarding is institutional. Do not go to p=reject without knowing whether forwarding is a factor in your environment.

Subdomains are covered. If you send from newsletter.example.com and your DMARC record only covers the root domain (example.com), you need a separate subdomain record. Subdomain spoofing is not blocked by a root-level p=reject.

Your RUA reporting endpoint is active. You need to keep receiving aggregate reports after you enforce so you can catch new problems quickly. DMARCFlow provides ongoing RUA parsing as part of its monitoring service, including alerts when a new sending source appears after enforcement.

How to Change Your DMARC Policy Safely

Once the checklist is clean, changing the policy is mechanically simple. You edit the p= value in your DNS TXT record.

Start with p=quarantine for one to two weeks before moving to p=reject. This is a safety net. If something was missed, quarantine means failures go to spam rather than hard bouncing, which gives you time to fix it.

The full record looks like this:

v=DMARC1; p=reject; rua=mailto:reports@example.com; pct=100;

pct=100 means the policy applies to 100% of failing messages. You can start with pct=25 to ease in, but for most operators who have completed the checklist, going straight to 100% is fine.

After changing the record, monitor your RUA reports daily for the first week. New sending sources sometimes only appear under real enforcement pressure.

What to Watch For in the First 48 Hours After Going to p=reject

The first two days are when problems surface. Here is what to look for:

User reports of missing email. If someone complains that an expected email did not arrive, check your RUA report for that sender's IP and alignment status. If they were passing before and are failing now, something changed -- either a new mail relay was introduced or the sending server changed its configuration.

Unexpected new sources at high volume. A sudden new source with many failures after enforcement usually means a legitimate service was updated or a new tool was connected without your knowledge. Investigate and fix before blocking it accidentally.

Lower email volume across the board. Some legitimate sources may have been silently failing DMARC before you enforced. If overall delivered volume drops significantly, check your report for consistently failing sources.

DMARCFlow's alerting system notifies you when a new source appears or when aggregate failure rates spike, which is the fastest way to catch these issues before users start complaining.

When Legitimate Mail Still Fails After the Upgrade

This happens even after a thorough pre-upgrade review. Here is what to do:

Identify the failing source in your RUA report. Look at the source IP, the sending domain, and which alignment check is failing.

If SPF alignment fails but DKIM passes -- the sending server's SPF record is correct but the From domain does not match the envelope sender domain. This is common with marketing platforms and some SaaS tools. The fix is usually to ensure the platform signs with a DKIM key that matches your sending domain.

If DKIM alignment fails but SPF passes -- the DKIM selector being used does not include your domain in the signature. Many ESPs let you add a custom DKIM selector for your domain. Once added and verified, DKIM alignment should pass.

If both fail -- the sending service is not using your domain correctly at all. This usually requires a support ticket with the vendor to configure authenticated sending with your domain.

If forwarding is the cause -- you have limited options. The cleanest fix is for the forwarding service to ARC-sign the message before forwarding, which preserves the original authentication results. Some forwarding services offer this. Alternatively, consider whether the forwarding chain is necessary or whether the sender can use a different delivery method. If forwarding is a regular pattern for your organization, DMARCFlow's alerting system will surface it quickly after enforcement -- before it becomes a user complaint.

Why p=reject Is the Only Real Defense Against Email Spoofing

p=quarantine reduces spoofing impact but does not stop it. A recipient server that routes suspicious mail to spam still accepts the message, which means attackers can still reach inboxes. p=reject is the only policy that fully closes the door.

For domain owners, the business case is direct. Brand impersonation, invoice fraud, executive impersonation -- all of these start with spoofed From addresses. DMARC enforcement at p=reject makes those attacks technically impossible from your domain.

The transition does require setup work, but it is a one-time effort. After enforcement, your RUA reports show exactly who is sending as your domain, which means you catch both attacks and misconfigurations in one view.

Bottom line: If you are still at p=none, the risk is not hypothetical. Spoofed email from your domain is reaching recipients right now. The pre-upgrade process takes a few days. The protection it provides is immediate.