Read DMARC reports as an inventory of senders and decisions. Treat each report as a way to answer who is sending mail for the domain, which authentication checks pass, and what the receiving server does with failures. The useful unit is a sending source, because a strong overall result can hide one sender that is misconfigured or unknown. Start with the source, then read coverage, authentication result, failure reason, and receiver action. Finish by deciding whether the stream needs investigation or policy review.
Set up the feed
Start by making the report stream reliable before you interpret any row. A report you never receive cannot tell you which sender needs attention.
DMARC can be set up to receive regular reports from email servers that receive mail from your domain.1 The rua tag specifies where aggregate daily summary reports should be sent.2 Once the record is in place, participating mailbox providers send daily aggregate reports to the destination in that tag.3
A reporting service can condense the incoming information into a form that is easier to review.4 Before reading rows, confirm that the destination is monitored and that reports are reaching it.
Know which report you are holding
Separate the routine source inventory from the message-level investigation. This keeps an unavailable forensic feed from blocking the review of ordinary authentication patterns.
There are two types of DMARC reports: aggregate reports and forensic reports.5 Aggregate reports show which emails authenticate against SPF, DKIM, and DMARC and which fail those checks.6 They offer limited message-level detail, so use them to understand source patterns, authentication coverage, and failures across the mail stream.7
Forensic reports consist of redacted copies of individual emails that failed SPF, DKIM, or both.8 Keep them as a separate investigation stream. Aggregate reports remain the working view for understanding who sends mail and how receiving systems handle it.
Read each aggregate report in work order
Work through each source in a fixed order. Record the result as you go, and move on only when the current question has an answer.
Find the sending source
Ask who sent this traffic. DMARC reports identify the servers or third-party senders sending mail for your domain.9 They also identify which servers or services are sending messages that fail DMARC.10
Compare unfamiliar sources with the senders you expect to use. Flag anything you cannot account for, and move on when every source has either an explanation or an investigation path.
Check coverage
Ask how much legitimate traffic is covered by DMARC. Record the percentage of messages from the domain that pass DMARC.11 Reports can also show how much legitimate mail traffic is covered and help troubleshoot problems.12
Use the percentage to decide where to spend attention. A source with a small share of traffic can still deserve review when its authentication result or origin is unclear.
Check the authentication result
Ask which authentication path passed for each source. The report shows whether the servers or services pass or fail DMARC authentication.13 Record which messages authenticate through SPF, DKIM, and DMARC, and which fail those checks.6
Keep the source and the authentication result together. A failure without its sender is difficult to investigate, while a sender without its authentication result does not tell you what needs correction.
Read the failure reason and alignment
Ask why the message failed and whether alignment is involved. Each daily aggregate report summarizes messages claiming to come from a domain during a 24-hour window, including pass counts, failure counts, and failure reasons.14
Use the failure reason to separate a source that needs authentication work from traffic that needs investigation. A configured DMARC reporting tool raises alignment issues.15 A DMARC reporting service can help identify email sources and SPF failures for the domain.16
Check the receiver action
Ask what happened to the unauthenticated message. Reports show whether the receiving server takes no action, quarantines the message, or rejects it.17 The DMARC policy determines the actions taken on mail that fails authentication.18
Compare the reported action with the policy you expect. This tells you whether the receiving system is observing the intended handling of failed mail.
Investigate possible abuse
Ask whether the source belongs to a legitimate sender. DMARC reports can show the number and sources of fraudulent messages.19 They can also help identify possible authentication issues and malicious activity involving messages sent from the domain.20
Use the source, authentication result, failure reason, and receiver action together before escalating a stream. Move on when each unexplained source has a clear investigation path.
Decide when to move on
Finish the review by checking whether the report pattern matches the outcome you expect. This is the point where report reading becomes a decision about the domain's next configuration step.
Review DMARC reports to check that messages are being authenticated effectively and delivered as expected.21 Reports give administrators information for adjusting DMARC policy when legitimate messages fail authentication or illegitimate messages appear.22
What not to do
Keep the review tied to the sending sources and the results recorded for each one. These mistakes make the report stream less useful:
- Turning on DMARC without reports configured skips the reporting practice recommended when a domain is enabled.23
- Letting daily reports pile up unread defeats regular monitoring.24
- Treating every failed message as abuse skips the unintentional DMARC failures that regular review is meant to catch.25
- Assuming forensic reports will always be available ignores privacy and volume limits that can prevent them from arriving.26
On the next review, capture the source, coverage, authentication result, failure reason, receiver action, and follow-up in the same working note. Route unexplained streams to investigation and use the result to decide whether a policy adjustment is warranted.