DMARC at p=none: How to Read Your Reports and Know When to Enforce

You published DMARC with a policy of p=none. You are now receiving daily XML reports full of numbers you do not understand. This post explains what those reports are telling you and how to know when you have enough signal to move to enforcement.

Why p=none Is Just the Starting Point

p=none tells receiving mail servers to take no action on messages that fail DMARC. It is a monitoring mode, nothing more. Your domain is not protected from impersonation at this stage. You are only collecting data.

The reason most administrators start here is practical: before you can enforce DMARC, you need to know who is legitimately sending email on behalf of your domain. That includes your primary mail server, any third-party mailing services, internal relay servers, and any application that sends email as your domain. If you set p=quarantine or p=reject before identifying all of those sources, you will break legitimate mail and spend the next weekend firefighting.

p=none is not a long-term security posture. It is a data collection phase.

What DMARC Aggregate Reports Actually Tell You

DMARC aggregate reports arrive at your rua email address. They are XML files, which makes them hard to read directly, but the data inside tells you exactly who is sending email as your domain and whether those messages are passing or failing authentication.

Here is what matters inside an aggregate report.

Sending source: the IP address of the server that sent the message.

SPF result: did the sending IP pass SPF for your domain. This is authentication, not alignment.

DKIM result: did the message carry a valid DKIM signature from your domain. This is also authentication, not alignment.

Alignment result: did the SPF or DKIM result come from a domain that aligns with your DMARC policy domain. A message can pass SPF but fail alignment if the RFC5321 From domain and the SPF-authorized domain are not the same.

Disposition: what the receiving server was told to do with the message. At p=none this is always none, regardless of pass or fail.

The most important signal in your aggregate report is the failure rate. If you have 1,000 messages sent in a 24-hour period and 950 pass DMARC, your failure rate is 5%. If those 50 failures come from sources you do not recognize, that is a problem. If they come from a known mailing list that forwards as your domain, that is a different problem.

The Five Patterns to Look for Before Moving to Enforcement

Before you change your DMARC policy from p=none to anything else, review your aggregate reports and look for these five patterns.

Pattern 1: Unknown sending sources

Every IP address in your report should belong to a sender you recognize. If you see an IP address sending as your domain and you do not know who operates that server, investigate before enforcing. This could be a legitimate third-party service you forgot about, or it could be someone spoofing your domain.

Pattern 2: High failure rates from known sources

If one of your known sending sources consistently shows DMARC failures, it is not ready for enforcement. A 2% consistent failure rate from a mailing platform means 2% of your transactional emails will be rejected or quarantined once you enforce. Resolve the alignment issue first.

Pattern 3: Subdomains sending without separate DMARC records

Many organizations have subdomains for marketing automation, support platforms, or internal systems that send as the parent domain. If those subdomains do not have their own aligned DKIM keys or SPF records, they will fail DMARC once you enforce. Either publish dedicated DMARC records for those subdomains or exclude them with a pct tag.

Pattern 4: Forwarding chains causing failures

Email forwarding is one of the most common causes of unexpected DMARC failures. When a forwarding service receives a message and re-sends it from its own infrastructure, the RFC5321 From header still shows your domain, but the SPF check runs against the forwarder's IP and the DKIM signature may not survive the re-send. This is a forwarding problem, not a spoofing problem. You can address it with ARC (Authenticated Received Chain) if your forwarding chain supports it, or by having the recipient whitelist your domain.

Pattern 5: Third-party mailing lists that sign as their own domain

Some third-party mailing platforms send messages where the RFC5322 From address is your subscriber's address, not yours, while the Reply-To points back to the original sender. This can cause DMARC alignment failures if the mailing platform does not sign with your domain. It is not a security problem, but it will cause failures once you enforce.

When You Are Ready to Move From p=none to p=quarantine

The threshold is not a fixed number. It depends on your volume and your sending mix.

The practical readiness criteria:

You have received at least two to four weeks of aggregate reports with no unknown sending sources appearing.
Your overall DMARC failure rate is below 1% for consecutive reporting periods.
Every known sending source that generates failures has a remediation plan in place.
You have reviewed subdomain sending practices and either published subdomain-specific DMARC records or documented why they do not matter.

If all four conditions are met, you can move to p=quarantine as a lower-risk intermediate step. p=quarantine tells receiving servers to treat failing messages as suspicious, usually by routing them to the spam folder rather than rejecting them outright.

Most guides skip this part: you need monitoring that alerts you when your failure rate changes suddenly. If a new sending source starts appearing in your reports after you move to p=quarantine, you need to know within hours, not days. Manual report review every few days is not sufficient during an enforcement transition.

When You Are Ready to Move From p=quarantine to p=reject

Move to p=reject only when:

p=quarantine has been active for at least one full reporting cycle with no escalation in legitimate mail complaints.
Your failure rate has remained below 0.5% during the quarantine period.
You have resolved every known alignment issue from your p=none data collection.
Your abuse and complaint rates are low (below 0.1% of total volume).

p=reject is permanent once mail is in flight. A receiving server that rejects a message does not send it to spam. It refuses delivery entirely. There is no retrieving a rejected message. That is why the readiness bar is higher.

This is also where DMARCFlow earns its place. The historical baseline you collected during p=none tells you what normal looks like. When that baseline shifts, you need to know immediately. DMARCFlow monitors your aggregate reports daily and alerts you when failure rates cross thresholds you define, not when you remember to check.

Step-by-Step Migration Checklist

Use this checklist before each policy change.

Before moving to p=quarantine:

Export current aggregate report as baseline
Confirm all known sending IPs are documented
Confirm failure rate below 1% for at least two weeks
Confirm subdomain sending sources have aligned records or are excluded
Set up monitoring for sudden changes in failure rate
Notify internal IT and helpdesk about the upcoming change

Before moving to p=reject:

Review quarantine period reports for any new failure sources
Confirm failure rate below 0.5% during quarantine
Confirm zero unknown sending sources in reports
Set up real-time alerting for DMARC failures
Brief your mail server administrators about the change
Have a rollback plan: if mail breaks, you need to revert p=reject within minutes, not hours

The step most likely to be skipped: the rollback plan. If your primary mail server operator deploys a configuration change while you are at p=reject and it causes alignment failures, you need to be able to revert p=reject immediately. Know where your DNS is, know who can change it, and have a tested path to revert before you push the button.

Common Mistakes That Break Legitimate Mail During Enforcement

The most common reason legitimate mail breaks after moving to DMARC enforcement: organizations did not account for all their sending sources during the p=none phase.

Mailing lists are the biggest culprit. Any platform that forwards mail on behalf of your subscribers and does not preserve DKIM signatures will cause failures. Test by sending to a Gmail address and checking the authentication results.

Third-party marketing platforms that send from infrastructure they control rather than your domain will also fail. If your ESP does not offer custom DKIM signing under your domain, you cannot send bulk mail from that platform with p=reject active.

Shared hosting environments where multiple domains send from the same IP are another trap. SPF only authorizes the sending domain, but if the shared IP is also used by other tenants who send as different domains, alignment can fail in ways that are hard to predict.

The fix is always the same: resolve the underlying sending practice before enforcing, not after.

FAQ

Does p=none protect my domain from impersonation?

No. p=none has no effect on how receiving servers treat messages. It only requests authentication reports. Your domain is not protected until you set p=quarantine or p=reject.

How long should I stay at p=none before moving to enforcement?

At minimum two to four weeks, but duration is less important than data quality. Stay at p=none until your failure rate is below 1% and you have identified every sending source in your reports.

What does a DMARC aggregate report look like?

It is an XML file delivered to the email address specified in your rua record. It lists sending sources, their IP addresses, SPF and DKIM results, alignment results, and message disposition. Most people use a tool to read these because raw XML is not human-friendly.

What is the difference between rua and ruf reports?

rua is for aggregate reports, which are summary data delivered daily. ruf is for forensic failure reports, which contain individual message-level details. ruf reports are not widely supported and can generate significant volume.

My own mail server shows failures in the reports. What does that mean?

This usually means one of two things: a subdomain is sending without proper alignment, or an internal relay is rewriting the From address. Review your mail server logs and compare the failing IPs against your known infrastructure.

What DMARCFlow Does for You During This Process

DMARCFlow parses your aggregate reports automatically and shows you which sending sources are passing and failing, updated daily. Instead of opening XML files, you get a plain-English dashboard that shows your failure rate over time, new sending sources that appear suddenly, and which specific domains are causing alignment failures.

This matters during the p=none phase because you need to spot new sources quickly. If a new sending source appears in your reports and you do not notice it for two weeks, you have two weeks of potentially unauthorized sending before you act.

During enforcement, DMARCFlow alerts you when your failure rate crosses thresholds you define. If legitimate mail starts failing because an application team deployed a new sending tool without telling you, you will know within hours instead of discovering it when internal email stops working.

For teams moving to p=reject, DMARCFlow provides the historical baseline you need to prove the transition was safe and the reporting you need to prove it stayed safe afterward.

You can try DMARCFlow for one euro per month. No sales call required.