A DMARC aggregate report can look like a wall of XML code, source IP addresses, and unfamiliar pass or fail results. The straight answer: it shows who is sending mail that claims to be from your domain, whether that mail passes authentication, and what receiving mail systems did with it. This DMARC aggregate report interpretation guide turns those records into practical decisions.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It works alongside SPF, or Sender Policy Framework, and DKIM, or DomainKeys Identified Mail. Together, these records help receiving systems verify that a message using your domain is authorized and has not been altered in transit.
Aggregate reports do not tell you whether every message reached an inbox. They tell you whether the messages were authenticated and aligned with your published DMARC policy. That distinction matters. Authentication problems can contribute to delivery trouble, but DMARC data is primarily a domain-control and security record.
What a DMARC aggregate report is actually telling you
A DMARC aggregate report is usually sent daily by mailbox providers and other receiving systems. It summarizes messages they saw using your domain in the visible From address. Instead of listing individual messages or recipients, it groups mail into records based on sending source, authentication results, and policy handling.
The report usually arrives as a compressed XML file. XML is a structured data format designed for software, not easy reading. A DMARC reporting service can translate it into charts, but you can still understand the underlying questions without becoming an XML expert:
- Which servers sent mail using my domain?
- How much mail came from each source?
- Did SPF and DKIM pass?
- Did the passing result align with the domain people saw in the From address?
- Did the receiver apply my DMARC policy?
Start with the source, volume, and alignment result. Those three details identify most real issues quickly.
Read the report in the right order
Do not begin by searching for the word “fail.” Begin by identifying the sending source. A failed record from a known marketing platform may need a configuration change. A failed record from an unknown overseas server may indicate spoofing, a compromised account, or an unauthorized vendor.
1. Confirm the reporting organization and date range
Near the top of the report, you will find the reporting organization, report ID, and begin and end timestamps. The reporting organization is the receiving system that generated the data. The date range is often a 24-hour period, though it can vary.
This section gives context, not a verdict. One provider’s report represents only the mail that provider saw. Review several days and multiple reporters before deciding that a source has stopped sending or that an issue is isolated.
2. Find the source IP address and message count
Each record includes a `source_ip` and a `count`. The source IP address identifies the server that transmitted the message. The count shows how many messages from that source matched the same set of results.
A source that sent one message deserves investigation, but a source that sent 5,000 messages deserves priority. Volume helps you separate a one-off event from a business process that may be misconfigured.
Match each IP address to a known sender. Common legitimate sources include your primary email provider, a customer relationship platform, an appointment system, an invoicing tool, a website form, or a managed mail server. Keep a simple inventory of every system allowed to send as your domain. It makes aggregate reports far easier to review.
If you cannot identify an IP address, do not add it to SPF just to make the failure disappear. First determine who controls it and whether it should be allowed to send. Adding an unknown source can authorize abuse rather than solve a delivery problem.
3. Check the policy evaluated result
Look for `policy_evaluated`. This section typically shows a DMARC `disposition` of `none`, `quarantine`, or `reject`.
`None` means the receiver was asked to monitor and report, without a requested enforcement action. `Quarantine` asks the receiver to treat failing mail cautiously, which may include placing it in spam. `Reject` asks the receiver not to accept mail that fails DMARC.
The disposition is your requested policy, not a guarantee of exactly what every receiving system did. Mailbox providers can apply local filtering decisions. Still, this field confirms how your DMARC record was evaluated for that group of messages.
You may also see `dkim` and `spf` values inside this section. A value of `pass` means the result passed DMARC alignment. A value of `fail` means it did not meet DMARC requirements, even if a basic SPF or DKIM check succeeded elsewhere in the record.
4. Separate authentication from alignment
This is the part that causes the most confusion. SPF can pass, DKIM can pass, and DMARC can still fail.
DMARC requires alignment. For SPF, the domain used for the technical return path must align with the domain in the visible From address. For DKIM, the domain in the DKIM signature must align with that visible From domain. Exact alignment is called strict alignment. A related subdomain can qualify under relaxed alignment, depending on your DMARC record.
For example, your visible From address might be `billing@yourcompany.com`. A billing platform may pass SPF using its own return-path domain, such as `mailer.vendor-example.com`. SPF passed, but it is not aligned with `yourcompany.com`. If the platform also signs the message with an aligned DKIM signature for your domain, DMARC can pass. If it does not, DMARC fails.
That is why DKIM is often the cleaner solution for third-party services. It allows a vendor to send on your behalf while signing with a domain that aligns with your visible From address. The exact fix depends on what the provider supports and how your domain is configured.
How to interpret common report patterns
A large, known source with SPF and DKIM both passing is usually what you want to see. Confirm that the volume roughly matches your expected email activity, then continue monitoring it.
A known source with SPF passing but DKIM failing may point to a missing, outdated, or incorrect DKIM record. It can also mean the service is signing with the wrong domain. Check the service’s sending-domain setup and compare its required DNS records with what is currently published.
A known source with DKIM passing but SPF failing may be acceptable for DMARC if DKIM is aligned. Still, investigate the SPF failure if that source should be covered by your SPF record. SPF has a limit of 10 DNS lookups, and overly complex records can produce failures that are easy to miss.
An unknown source that fails both SPF and DKIM is often attempted spoofing. If your policy is `p=none`, receiving systems are only being asked to monitor it. Before moving to `p=quarantine` or `p=reject`, make sure all legitimate senders are identified and aligned. Enforcement protects your domain, but moving too soon can affect a legitimate tool that was never added to your sending inventory.
A small number of failures from known personal or forwarded mail can be more nuanced. Forwarding can break SPF because the forwarding server is not authorized in your SPF record. DKIM may survive forwarding and preserve DMARC passing status if the message remains unchanged. Look at recurring patterns before changing DNS for isolated events.
Use the policy fields without creating a new problem
Your DMARC record may include `p`, `pct`, `adkim`, and `aspf`. The `p` tag sets the policy. The `pct` tag sets the percentage of failing mail to which the policy should apply. `adkim` and `aspf` control strict or relaxed alignment for DKIM and SPF.
A gradual enforcement approach can be sensible when your organization uses several outside senders. For example, you may begin with monitoring, correct the sources that fail, then apply quarantine to a limited percentage before increasing enforcement. The trade-off is simple: slower enforcement gives you more time to find overlooked systems, while faster enforcement reduces the window in which spoofed mail can use your domain.
Do not treat a higher DMARC policy as a finish line. New vendors, website changes, and department-level tools can introduce new mail streams later. Review reports after major changes, especially when a platform begins sending invoices, forms, alerts, or marketing messages from your domain.
A practical review routine
Review aggregate reports weekly during setup or after a major email change. Once your sending environment is stable, monthly review may be enough for many small and midsize businesses. Increase the frequency if your business handles high volumes of customer notices, payment communications, or time-sensitive appointment messages.
For each new source, document the system owner, purpose, expected volume, SPF status, DKIM status, and alignment result. Then take one of three actions: verify it as legitimate, correct its authentication, or investigate it as unauthorized. This creates an operational record your office manager, marketing team, and IT support can use without guessing.
The next step is to run MailArrive’s free email health check and review the Report Card. It can show whether your published SPF, DKIM, and DMARC records support the results you are seeing in your aggregate reports.