Knowing how to read DMARC aggregate reports helps a small business see who sends email for its domain. These reports can reveal legitimate services, misconfigured systems, and possible spoofing without requiring you to inspect every message.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It lets a domain owner publish instructions for handling messages that fail authentication. It also creates a reporting channel, so receiving mail systems can send summary data back to the domain owner.
The reports do not usually contain message bodies. Instead, they summarize sending activity over a period. That makes them useful for planning changes, but they still require careful interpretation.
A practical way to learn how to read DMARC aggregate reports is to connect each reported source with a known business service before changing DNS.
What a DMARC aggregate report shows
Mail providers often deliver a DMARC aggregate report as an XML file or dashboard summary created from XML files. XML is a structured format that computers use to organize data. Mail providers commonly send one report per reporting period.
Each report normally identifies the reporting organization, the date range, and the domain that published the DMARC record. It also includes records for source IP addresses that sent messages using the domain in the visible From address.
- Report metadata: This identifies the receiving organization and reporting window.
- Policy data: This shows the published DMARC policy, such as none, quarantine, or reject.
- Source IP: This is the address that connected to the receiving mail system.
- Message count: This indicates how many messages the source represented during the period.
- Disposition: This describes how the receiver handled messages under the reported policy.
- SPF result: This shows whether the sending source passed SPF evaluation.
- DKIM result: This shows whether a DKIM signature passed verification.
- Alignment result: This shows whether authentication matched the visible From domain.
Do not treat the message count as a perfect measure of your outbound mail volume. Providers may group events differently, and reporting schedules vary. Use it as evidence, then compare it with known business activity.
How to identify sending sources
The source IP is the starting point for finding a sender. An IP address alone rarely tells you which employee, application, or vendor sent the message. You need to connect it with your mail provider, transaction system, website, or service platform.
Make a simple inventory before changing DNS. List your normal mailbox provider, website forms, accounting platform, customer relationship system, marketing platform, ticketing system, scanner, printer, and line-of-business applications.
Next, compare each known service with the report. A source may belong to a third party that sends on your behalf. For example, a booking platform might send confirmations using your domain, while a marketing service might send newsletters.
Some sources will look unfamiliar because a provider uses shared infrastructure. Search the provider’s official documentation or ask its support team to confirm its sending ranges. Do not add an unknown source to SPF only because its IP appears in a report.
Separate legitimate services from suspicious activity
A source deserves investigation when it has a large volume, appears repeatedly, or does not match any business system. However, an unfamiliar source is not automatically malicious. Cloud services can use changing addresses, shared mail systems, or regional infrastructure.
Check the date range and message volume first. Then review the authentication results. A source that fails both SPF and DKIM may represent spoofing, but it might also reflect an overlooked application or a broken vendor setup.
Keep an evidence record. Note the IP, provider, volume, authentication results, business owner, and decision. This prevents repeated investigation and gives you a clear change history.
SPF, DKIM, and alignment explained
SPF, or Sender Policy Framework, publishes which systems may send mail for a domain. Receiving servers check the connecting source against the domain’s SPF record. SPF authentication usually evaluates the envelope sender, which is a technical address used during mail delivery.
DKIM, or DomainKeys Identified Mail, adds a digital signature to a message. The receiving server uses a public key in DNS to check whether the signature is valid and whether the signed content remains intact.
DMARC checks more than a simple pass. It also checks alignment. Alignment means the authenticated domain matches, or suitably relates to, the domain shown to the recipient in the From address.
For SPF alignment, the authenticated envelope domain must align with the visible From domain. For DKIM alignment, the signing domain in the DKIM header must align with that visible From domain.
A message can pass SPF but fail SPF alignment. It can also pass DKIM while failing DKIM alignment. Therefore, read the authentication result and the alignment result together.
Read authentication results together
| SPF | DKIM | Alignment | Likely interpretation |
|---|---|---|---|
| Pass | Pass | Pass | Strong evidence of authenticated, aligned sending |
| Pass | Fail | Pass through SPF | Usually acceptable, but review DKIM configuration |
| Fail | Pass | Pass through DKIM | Often acceptable, but investigate SPF coverage |
| Fail | Fail | Fail | Investigate the source before enforcement |
DMARC generally passes when either SPF or DKIM passes with alignment. That does not mean every source is approved for your business. Authentication proves control of a domain or authorized sending path; it does not prove that a vendor’s content is appropriate.
For broader background, review the DMARC.org overview of policy, alignment, and reporting. You can also compare these concepts with our guide to email delivery problems involving SPF, DKIM, DMARC, and PTR records.
How to read DMARC aggregate reports safely
Start with a reporting period that includes normal business activity. A holiday, migration, outage, or vendor change can make one report misleading.
When learning how to read DMARC aggregate reports, use a repeatable sequence rather than reacting to one failed row.
- Confirm the domain. Make sure the report covers the domain used in your visible From addresses.
- Review the policy. Record whether the published policy is none, quarantine, or reject.
- Group sources. Combine repeated records from the same provider or known system.
- Check authentication. Compare SPF, DKIM, and alignment results for each source.
- Investigate exceptions. Ask who owns unfamiliar systems and why they send mail.
- Document changes. Record approved vendors, DNS updates, and test results.
- Watch later reports. Confirm that expected traffic still passes after each change.
Use a DMARC reporting service or a trusted parser when possible. Raw XML can be difficult to review, and manual handling may expose reporting addresses or other operational data. Choose a service that explains its processing and retention practices.
Never upload reports to an untrusted website. Reports can contain domain activity details and source addresses. Treat them as business information, even when they contain no message body.
A gradual enforcement workflow
Most small businesses should avoid moving directly to a strict reject policy. First, publish a monitoring policy and collect enough reports to understand normal senders. A policy of p=none requests reporting without asking receivers to quarantine or reject failing messages.
During monitoring, fix known systems one at a time. Configure DKIM for providers that support it. Correct SPF authorization only after confirming the vendor’s instructions. Then verify that the authenticated domain aligns with the visible From domain.
After expected sources pass consistently, consider a limited quarantine policy. Quarantine asks receiving systems to treat failing messages as suspicious, often by placing them in spam. The exact result depends on the receiving provider.
Keep the change gradual. A policy can use a percentage, such as a partial rollout, where supported. Review reports after every adjustment. If legitimate mail fails, identify the source and correct it before increasing enforcement.
Finally, consider a reject policy when your inventory is reliable and legitimate traffic consistently authenticates. Rejection can reduce successful domain spoofing, but it can also block real business mail when a source remains unconfigured.
Google’s Email Sender Guidelines provide current guidance for authentication and deliverability. Requirements can change, so verify provider-specific expectations before making a policy change.
Common mistakes to avoid
One common mistake is reading every failed row as an attack. Reports describe authentication results, not intent. A forgotten website form can produce the same failure pattern as a spoofed message.
Another mistake is creating multiple SPF records. A domain should publish one SPF record, with all approved mechanisms combined within it. Ask a qualified administrator to check syntax, lookup limits, and vendor requirements before editing it.
Do not remove a source because it appears only once. It may represent a low-volume invoice, password reset, or automated alert. Instead, confirm its owner and purpose.
Also avoid treating DMARC as a complete email security program. Use strong account passwords, multifactor authentication, mailbox monitoring, and sensible access controls. DMARC protects domain use in mail, but it does not secure every account or application.
Our related guide, Email Going to Spam? Check SPF, DKIM, and DMARC, covers the connection between authentication and message placement.
When professional help makes sense
DMARC reporting becomes more manageable when someone owns the sender inventory, DNS changes, and follow-up reviews. Professional remote assistance may be appropriate when several vendors send mail, a domain migration is underway, or someone could block important messages.
Tech Rescue Ops LLC can help organize report findings, verify sending systems, and plan changes in a controlled sequence. The goal is not to make the strictest change fastest. It is to improve authentication while keeping legitimate business communication working.