What to Do with DMARC Monitoring Reports: A Practical Guide for Admins Who Are Stuck at p=none

You set up DMARC monitoring and switched your policy to p=none. Now you are looking at a ZIP file containing something called a DMARC aggregate report and you have no idea what to do with it.

You are not alone. This is the most common situation after initial DMARC deployment, and the reports are genuinely confusing the first time you see one.

This guide walks you through what a DMARC report actually tells you, what to look for first, and how to use the data to make a plan before you touch your policy.

What Is a DMARC Aggregate Report, Anyway?

When a major receiver like Google, Microsoft, or Yahoo receives a message from your domain, they check the DMARC record and send a daily or weekly report back to the address listed in your DMARC rua tag. The format is XML inside a ZIP file. Most tools unzip and parse it for you, but the raw structure is the same everywhere because it is defined in RFC 7489.

Each report covers a specific time window and contains one or more records. Each record describes one sending source and what the receiver observed for that source's messages.

Here are the fields that actually matter in a DMARC record:

disposition (dispo): What the receiver did with the message. Three possible values: : none — the receiver took no special action : quarantine — the receiver marked the message as suspicious : reject — the receiver refused the message

This is the most important field in your report. If you see reject dispositions on messages you believe should have been accepted, something in your authentication is misconfigured.

SPF domain and result
The domain used in the RFC5321.MailFrom (envelope sender) and whether it passed or failed SPF at that domain.

DKIM domain and result
The domain that signed the message with DKIM and whether the signature validated.

DKIM and SPF alignment (a)
Whether the signing or SPF domain aligned with the RFC5322.From header domain. This is separate from whether SPF or DKIM passed on its own. A message can have SPF pass and still fail DMARC because the RFC5321.MailFrom domain does not align with the RFC5322.From domain.

Reading Your First DMARC Report: The Fields That Matter

When you open a DMARC aggregate report, whether through a tool or a parsed view, focus on these in this order:

1. Disposition summary
Start here. What percentage of messages had disposition none, quarantine, or reject? At p=none, you will see almost everything as none. If you see quarantine or reject results, your policy is already active on some receivers.

2. SPF and DKIM pass rates across all sources
High pass rates (above 90%) across your own infrastructure usually mean your authentication is working correctly. Persistent failures on messages you expect to succeed point to configuration problems.

3. New sources
This is the most important thing to watch for over time. A new sending source you do not recognize could mean a third-party service started sending on your behalf, or it could mean someone is spoofing your domain.

How to Identify Your Legitimate Email Sources

Most organizations send from a small, known set of infrastructure. Your legitimate sources usually fall into a predictable list:

• Your primary mail server (Exchange, Postfix, M365, Google Workspace)
• A marketing email platform (Mailchimp, HubSpot, SendGrid)
• A service desk or CRM that sends on your behalf
• Transactional email (billing, receipts, password resets)

Cross-reference the sending IP addresses in your DMARC report against your known infrastructure. Any sending IP not in your SPF record that is sending legitimate mail is a gap you need to close before you can safely move to p=quarantine or p=reject.

One common scenario: a marketing platform or SaaS tool sends renewal notifications or invoices from your domain. If the platform is not authorized in your SPF record and does not DKIM-sign with your domain, those messages will fail DMARC. You would see this as a consistent failure pattern from one source, and the fix is to either configure the platform correctly or exclude that domain from your DMARC policy.

Common DMARC Report Patterns and What They Mean

Mostly pass, a few failures from forwarding
Forwarded mail often fails DMARC. The forwarding service does not DKIM-sign with the original domain and the RFC5321.MailFrom domain changes. This is expected behavior. If you need forwarded mail to pass DMARC, your correspondents need to use SRS (Sender Rewriting Scheme).

Failures from third-party services you recognize
The service either does not DKIM-sign with your domain or is not in your SPF record. Fix the service configuration before moving to enforcement. Do not move to p=reject while legitimate mail is failing.

Failures from services you do not recognize at all
Investigate immediately. Unknown sources that pass DMARC are the most serious concern because they indicate either a service you forgot about, a legitimate forwarding setup you were not told about, or spoofing.

Sudden appearance of new sources without corresponding changes on your end
This can indicate spoofing. If you see new sending infrastructure appear in your reports without an associated change in your own email stack, treat it as a security signal until proven otherwise.

Building Your p=none Source Inventory

The practical first step after receiving your first few DMARC reports is to build a source inventory. List every sending IP you see, who it belongs to, whether it is expected, and whether it passes DMARC.

A simple spreadsheet works. Three columns:
1. Sending IP or range
2. Associated service or infrastructure
3. DMARC result (pass/fail) and alignment status

• Trusted: your own infrastructure, consistently passing
• Needs fixing: authorized senders with consistent failures (usually missing SPF or DKIM)
• Unknown: needs investigation before you can classify it

Your goal at p=none is to reduce the unknown category over time and fix the needs fixing category. You cannot safely move to enforcement while unknown sources are still appearing in your reports.

When to Move from p=none to p=quarantine

The standard readiness checklist before moving to p=quarantine:

• You have 30 to 60 days of DMARC report data showing mostly trusted sources
• All legitimate sources in your inventory are passing DMARC consistently
• You have investigated and resolved all unknown sources
• You have a process for reviewing DMARC reports regularly

Move gradually. Start with a small percentage using the pct tag, though be aware that major receivers like Google and Microsoft largely ignore pct and apply the policy to all or nothing. Most deployment guides recommend moving to quarantine first, staying there for a monitoring period, then moving to reject.

A real example: one organization had been running p=none for six months and believed their configuration was stable. Their DMARC reports showed a consistent failure pattern from a transactional email service they had onboarded three months prior. Because they were reviewing reports, they caught it before moving to enforcement and fixed the DKIM configuration first. If they had moved to p=reject without reviewing reports, legitimate billing emails would have been blocked for three weeks before anyone noticed.

How DMARCFlow Makes DMARC Reporting Easier

DMARCFlow handles the report collection and parsing automatically. You connect your domain, point the DMARC rua destination to DMARCFlow, and the platform unpacks and normalizes the daily reports into a dashboard instead of requiring you to unzip XML files manually every morning.

The source inventory builds itself as reports come in. DMARCFlow flags new sending sources automatically so you do not have to remember to compare yesterday's report with today's. For each source, you see the DKIM and SPF pass rates over time, the alignment history, and whether the source is still active.

When you are ready to move from p=none to quarantine, DMARCFlow shows your current disposition breakdown, flags any sources that are still failing, and tracks your progress after the policy change so you can spot regressions quickly.

For MSPs managing multiple domains, DMARCFlow aggregates DMARC data across all client domains in one view. Each domain has its own policy settings and report stream. You can triage new sources across your entire client base in minutes instead of opening ZIP files for each domain separately.

FAQ

What does p=none mean in a DMARC report?
p=none tells receiving mail servers to take no action on messages that fail DMARC. It is monitoring mode. You see all the data but nothing is blocked or flagged. This is the right starting point before enforcement.

How often should I check my DMARC reports?
At p=none, monthly is sufficient if nothing unusual is happening. At p=quarantine or p=reject, weekly or real-time is better. Review reports whenever you add a new sending service or change your mail infrastructure.

Why do forwarded messages fail DMARC?
Forwarding breaks DKIM because the forwarding server modifies the message headers or body, invalidating the signature. The RFC5321.MailFrom also changes to the forwarder's domain, which fails SPF alignment. This is expected and documented behavior. SRS (Sender Rewriting Scheme) is the standard workaround.

What is the difference between SPF pass and DMARC pass?
SPF pass means the RFC5321.MailFrom domain authorized the sending server via DNS. DMARC pass requires at least one of SPF or DKIM to pass AND the relevant domain to align with the RFC5322.From header. SPF can pass but DMARC still fail because of alignment. They are separate checks.

What should I do before moving from p=none to p=reject?
Fix all consistent failures from legitimate sources first. Ensure your source inventory shows only trusted sources. Have a process for reviewing reports after the change. Consider running at p=quarantine first to catch any surprises before full enforcement.