Blog · Dmarc
What to do with DMARC reports when your policy is p=none
You set up DMARC. You picked p=none because you were told to start there. Now you are getting emails with XML attachments or entries in a portal, and you are not sure what any of it means.
That is the exact problem DMARCFlow was built to solve. If you are spending more time reading raw DMARC reports than acting on them, you are doing it the hard way. This guide walks through what the reports actually mean and how to work through them efficiently, with and without a dedicated tool.
Why p=none is a monitoring mode, not a policy
p=none tells receiving mail servers to take no action on messages that fail DMARC. Your domain will accept mail regardless of whether it passes or fails. The sole purpose of setting p=none is to watch what is happening before you decide what to do.
Think of it like turning on all the sensors before you start driving. You want to know what the engine sounds like, which warning lights trigger, and whether anything is leaking before you commit to a route.
The goal is to build a complete picture of what legitimate mail from your domain looks like in the wild. Once you know that, you can set a real enforcement policy with confidence instead of guessing.
The two types of DMARC reports you receive
DMARC sends two kinds of reports to the address you specified in your record.
Aggregate reports (RUA) are the main digest. They arrive on a schedule the receiver chooses and contain a summarized view of authentication results across all mail from your domain in that period. You see which source IPs are sending, what SPF and DKIM results they produced, and whether alignment passed or failed. No message content, just metadata about each sending attempt.
Forensic reports (RUF) arrive in near real-time for individual failures. Each one is a copy of a message that failed DMARC. In practice, most organizations disable forensic reports because the volume is high and the privacy implications of receiving copies of failed messages are awkward.
For most administrators running p=none, aggregate reports are the useful signal.
How to read an aggregate report without a specialized tool
Aggregate reports arrive as XML. You can open them in a browser or a text editor. Here is what you are looking at.
Each entry corresponds to one source IP that sent mail claiming to be from your domain during the reporting period. For each IP, you get:
- The result of the SPF check (pass or fail)
- The result of the DKIM check (pass or fail)
- The DMARC alignment result (pass or fail)
- A count of messages involved
A message passes DMARC when both authentication (SPF or DKIM) passes AND alignment is correct. If either check fails alignment, the overall DMARC result is fail.
The most common confusion: SPF can pass but DMARC can still fail because alignment is separate from authentication. Your SPF record authorizes a server to send on behalf of your domain, but DMARC also checks whether that server is sending from a domain that matches the one in your From address. A server can be authorized by SPF and still fail alignment if it is sending for a subdomain or a third-party domain.
Common reasons for DMARC failures that are not real problems
Before you escalate a spike in failures, check whether any of these apply.
Forwarded email. When someone forwards a message from your domain to an external address, their mail server rewrites the From header to show your domain. Their server is not authorized to send for your domain, so DMARC fails. This is one of the most common sources of DMARC failures in aggregate reports and it is not a security incident.
Internal mail relays. If your organization routes mail through an internal relay or gateway before it reaches the internet, that relay may appear as a source IP in your reports. If the relay does not apply SPF or DKIM for your domain, it will show as failures. These are expected if your relay is not set up to authenticate.
Mailing lists. Some mailing list services send from their own infrastructure but use your domain in the From address. This causes DMARC failures for every subscriber. The mailing list needs to apply its own authentication or use a sender address format that does not trigger DMARC.
Third-party SaaS providers. Any service that sends email on your behalf from your domain needs to authenticate using DKIM keys you control, or be explicitly authorized in your SPF record. If they send without authentication, they show up as failures in your aggregate reports.
None of these mean your domain is being impersonated. They mean your authentication setup has gaps. Gaps are worth closing, but they are not emergencies.
A practical triage workflow for new DMARC administrators
Work through an aggregate report like this.
Step 1: List every source IP in the report. Do not worry about message counts yet. Get the full list of unique IPs.
Step 2: Cross-reference against known senders. Check each IP against your own mail servers, your SaaS providers, your CRM, your marketing platform, your internal relay, and any other service you know sends mail from your domain. Mark each IP as known or unknown.
Step 3: Investigate unknown IPs. An unknown IP sending from your domain is worth a closer look. It could be a service someone on your team signed up for without telling you, or it could be forwarding. Some organizations are surprised by what they find at this step.
Step 4: Track the failure rate over 2 to 4 weeks. One report snapshot is not enough. You want to see whether the same failures appear consistently or are one-time events. Consistent failures from the same IP are more likely to indicate a real problem.
Step 5: Build an allowlist of known-good IPs. As you identify legitimate senders, document them in your SPF record or verify their DKIM keys. This reduces noise in future reports and makes it easier to spot IPs that should not be there.
How do you know when you are ready to move to a real policy
Most administrators rush this step. The answer is not a fixed number of days. The answer is whether you have answered three questions:
If you can answer yes to all three, you are ready to move to p=quarantine. If you also have a process for updating your authentication records when your infrastructure changes, you are ready to consider p=reject.
Rushing this step is the most common cause of self-inflicted email outages.
How DMARCFlow helps you stay on top of your reports
Reading raw DMARC XML is doable but slow. If you manage more than one domain, or if your sending volume is high, you will spend more time parsing reports than acting on them.
DMARCFlow aggregates RUA reports automatically and surfaces the data in a dashboard. You see authentication results per domain, per IP, over time. New source IPs appear in an alert queue so you catch unexpected senders immediately. Your failure rate trend is visible in a chart, not buried in a folder of gzip files.
The triage workflow described above becomes faster because the data is already organized by IP, by domain, by result. Unknown IPs are flagged rather than hidden in XML. Your historical trend is available at a glance.
If you manage multiple clients or domains, DMARCFlow gives you one view across all of them. That is the part that manually reading aggregate reports cannot give you, no matter how diligent you are at parsing XML.
FAQ
What is the difference between aggregate and forensic DMARC reports?
Aggregate reports (RUA) are periodic digests summarizing authentication results by source IP. Forensic reports (RUF) are near-real-time copies of individual failed messages. Most organizations use RUA for monitoring and disable RUF because of volume and privacy concerns.
Why do I see failures in my DMARC reports for email I did not send?
Most often this is forwarded email, a mailing list, or a third-party service sending on your behalf without proper authentication. It can also mean someone is sending email that appears to come from your domain without authorization. Check the source IP before assuming it is impersonation.
How long should I run p=none before moving to quarantine or reject?
There is no universal timeline. Run p=none long enough to identify every legitimate source IP and confirm they are all passing authentication. For some organizations this is two weeks. For others with complex email setups it is several months.
Can I use DMARC reports to find unauthorized email sources?
Yes. Aggregate reports show every IP sending mail from your domain. IPs you do not recognize are worth investigating. A sudden new IP that was not there last month is a more urgent signal than IPs that have been there consistently since you started monitoring.