What to Do with DMARC Aggregate Reports at p=none

You set up DMARC, published your record, and chose p=none. That last part means nothing gets rejected or quarantined -- your emails sail through either way. But now your inbox has a daily XML report from Google, or Yahoo, or Microsoft, and you have no idea what to do with it.

That report is not noise. It is the most direct view you have into who is sending email on behalf of your domain. Here is how to make p=none useful instead of ignored -- and where DMARCFlow fits into making that practical rather than a manual review task you keep deferring.

What p=none actually means

p=none is monitoring mode. Your DMARC record tells receiving mail servers not to take action on authentication failures -- pass or fail, the email gets delivered. The trade-off is that you get visibility into your email authentication landscape in return.

That visibility comes as aggregate reports sent to the RUA email address in your DMARC record. These are XML files compressed into a zip, sent daily per provider, per domain. The format is defined in RFC 7489 section 6.3.

Most domain owners who publish p=none never look at these reports. That is the gap this post fills.

What an aggregate report actually contains

Every aggregate report covers a 24-hour window and has three main parts.

The metadata header tells you which domain it covers, the report sender is address (so you can identify which provider generated it), the date range, and the number of messages processed.

The policy_published block shows what your DMARC record says -- the domain, the alignment mode (relaxed or strict), and the p= value you published on that date.

Then comes the data. Each block represents a unique sending event with four fields that matter most:

source_ip: the IP address that sent the email
dkim_result: pass, fail, or no result
spf_result: pass, fail, or no result
alignment: whether DKIM and SPF aligned with your domain (aligned or not aligned)

If dkim_result says "pass" and alignment says "aligned", that sending source is correctly signing its email with your domain. If it says "fail" and alignment says "not aligned", that source is either misconfigured or someone is trying to send as your domain from an unauthorized server.

Reading the report: which results mean something

Here is the short version of how to evaluate each sending source.

SPF pass + DKIM pass + aligned means that IP is authorized and correctly configured. These are your known-good senders. You expect high volume here from your primary mail system.

SPF pass + aligned but DKIM fail or no result is common with some bulk senders and legacy systems that authenticate via SPF only. It is not necessarily a problem, but it is worth noting if you expected that source to sign with DKIM.

SPF fail + not aligned is the one to pay attention to. This means an email arrived from a server that is not on your approved SPF list and did not DKIM-sign as your domain. This is the pattern that spoofing produces.

One failure from an unknown IP is worth investigating. Hundreds of failures from your own known sending infrastructure means something is misconfigured -- maybe a marketing automation tool you forgot to include in SPF, or a CRM that routes through a third party.

What counts as normal traffic versus a problem

Not every failure is an attack. Some failures are expected and acceptable at p=none.

Expected failures:

Forwarded emails: when someone forwards your email to an external address, the forwarder becomes the new sender and SPF fails. This is a known limitation. ARC can help here, but it is not universally deployed.
Mailing lists: some mailing list services repurpose the From header, breaking alignment. This is a long-standing design tension in email.
Legacy internal systems: older printers, SCADA systems, and IoT devices sometimes send alerts via email without any authentication at all.

Red flags:

High failure rates from IPs in ranges you do not recognize
Failures from IPs in countries where you have no sending infrastructure
Patterns of failures that arrive in bursts, suggesting automated spoofing rather than one-off misconfiguration
DKIM signatures failing for sources that are supposed to be DKIM-authorized

The goal at p=none is not zero failures. The goal is to build a complete map of every legitimate source of email for your domain, so you can safely move to p=quarantine or p=reject when the map is done.

Red flags to look for in your reports

Three patterns that should prompt action even at p=none:

Unknown IPs sending high volumes: If you see thousands of emails per day from an IP you do not recognize, and they are all failing alignment, that is a spoofing campaign using your domain. p=none will not block it, but you will know it is happening.

Your own IPs misaligned: If your own mail servers are generating alignment failures, something is wrong with your SPF or DKIM setup. Fix it before moving to enforcement.

Consistent third-party failures: If a vendor or platform you use is regularly failing alignment, their configuration needs attention. Continuing to ignore it means moving to p=reject will break their email.

When to act: how p=none reports tell you it is time to move to quarantine

The reports themselves tell you when you are ready.

Your domain is ready for p=quarantine when:

You have identified every legitimate sending source and none are producing unexpected failures
Your own infrastructure passes alignment reliably
Third-party senders you control are correctly configured
You have reviewed the report data for at least 30 days and found no unexpected spoofing patterns

You are not ready when:

You still see failures from IPs you have not identified
Your own sending systems occasionally misalign
You have not yet reviewed the reports enough to know what normal looks like

The 30-day window is not a rule -- it is a practical minimum. Some domains need three months of data before they trust the picture. Rushing to p=reject before you understand your sending landscape is how legitimate email breaks.

Tools that make aggregate reports easier to read

Raw aggregate reports are XML. Opening them in a text editor is not the intended experience.

If you manage one domain, a DMARC report parser like dmarcian, mailhardener, or dmarc-report-viewer will turn the XML into a readable dashboard. Most offer a free tier that handles one domain.

If you manage multiple domains -- an MSP, an agency, or an organization with several brands -- manual parsing stops scaling fast. DMARCFlow was built for exactly this: it pulls aggregate reports from all your domains, normalizes the data, and surfaces anomalies across your portfolio so you can act on p=none reports without building a custom pipeline for each domain.

That is the practical difference between a tool that gives you reports and a tool that gives you signal.

Summary: p=none reports are data, not noise

Setting p=none is the right first step. But p=none without report monitoring is just a DNS record that does nothing. The reports are the point.

Read them long enough to know what your domain's normal looks like. Watch for the red flags. When the failures you see are all expected and explained, that is when you know it is time to move to the next policy level.

FAQ

How often do I receive DMARC aggregate reports?

Most major providers send one report per day, per domain. Some may send multiple reports if your volume is high. The timing varies by provider -- Google tends to send in the early afternoon UTC.

What does p=none mean in DMARC?

p=none tells receiving mail servers to take no action on authentication failures. Emails are delivered regardless of whether they pass or fail DMARC. The value is entirely in the visibility the reports provide.

When should I move from p=none to quarantine?

Move when you have reviewed at least 30 days of aggregate reports, have identified all legitimate sending sources, and your own infrastructure produces no unexpected alignment failures. Rushing this step breaks legitimate email.

How do I know if someone is spoofing my domain from DMARC reports?

Look for high-volume failures from IP addresses you do not recognize, especially if they arrive in regular patterns suggesting automated sending. Legitimate spoofing attempts often show as thousands of failures from different IPs in a short window.

Can I receive DMARC reports from all email providers?

Most major consumer mail providers send aggregate reports: Google, Microsoft, Yahoo, Apple Mail, and others. Some smaller or regional providers do not support RUA reporting. Missing reports from a major provider may indicate a configuration problem with your RUA endpoint rather than a provider limitation.