A report starts with an observation
An email with a subject such as “Report domain” is not automatically a service alert. A receiving mail provider is summarising messages it observed using your sender domain during a stated period. Everything in that summary may be working normally. It is neither confirmation of an account compromise nor a delivery failure notice for a particular email.
Aggregate reports are requested through the rua destination in the domain’s DMARC record. Their data sits in an XML attachment, often compressed. An empty email body does not make the report useless. Equally, a familiar display name does not authenticate the report: process these files through a controlled reporting workflow. [1] [3]
Establish the period before counting
Start with report_metadata: who produced the report, what is its report ID and which UTC period does date_range cover? Then check the domain in policy_published. The date the email arrived is not the reporting period. A count represents messages grouped by the relevant combination of results. It is not a count of customers, people or security incidents.
When collecting files, define a repeatable counting rule. Compare the reporter, domain, report ID, period and contents. Identical retransmissions must not inflate the total. Partially overlapping reports may not contain enough detail to subtract the overlap accurately. Keep that limitation visible instead of presenting a total that appears more precise than the evidence. [1]
An SPF pass is not necessarily a DMARC pass
auth_results contains the individual SPF and DKIM authentication results. policy_evaluated records their DMARC assessment, including domain alignment. Compare these with header_from, the domain in the visible sender field. A technical pass for a sending provider’s domain is insufficient when the required relationship with your visible sender domain is missing.
DMARC passes when at least one of SPF or DKIM succeeds and aligns with the visible From domain. SPF can therefore fail while DMARC passes through a valid, aligned DKIM signature. A message can carry several DKIM signatures with different results. Look for the successful aligned identifier, rather than selecting one isolated fail as the overall verdict. [1] [2]
Define the report
Identify the reporter, domain, period and report ID; remove duplicate copies.
Identify the sending route
Compare the source, SPF/DKIM results and alignment with the authorised sending inventory.
Resolve the difference
Correct a legitimate failure, investigate an unfamiliar source or record the observation.
A decision supported by evidence
Record the owner, sending route checked and next review date. Verify delivery separately.
An explanatory review path with no real message or customer data. A DMARC result and proof of delivery provide different types of evidence.
Read the common result combinations
This table concerns SPF and DKIM inside policy_evaluated, not the raw values in auth_results. It supports interpretation. It does not establish that a particular service is authorised or that message content is trustworthy. [1] [2]
Swipe or scroll sideways to read the table.
| Reported result | Meaning | Next step |
|---|---|---|
| SPF pass, DKIM pass | Both routes pass the DMARC assessment. | Match the source to an authorised sending service. |
| SPF fail, DKIM pass | DMARC passes through DKIM. | Investigate the SPF difference and possible forwarding separately. |
| SPF pass, DKIM fail | DMARC passes through SPF. | Investigate DKIM for this route; SPF alone is less resilient to forwarding. |
| SPF fail, DKIM fail | No successful aligned authentication route. | Distinguish legitimate misconfiguration, forwarding and unauthorised use. |
| Missing or unreadable result | This record does not support a reliable assessment. | Check the format and processing; do not count it as zero failures. |
An unfamiliar IP needs attribution
A provider name or data-centre location does not establish who initiated a particular message. Shared sending infrastructure may carry mail for many customers. Compare the source with your actual authorised services: ordinary mailboxes, website forms, billing platforms, support systems and newsletters each need their own inventory entry.
Domains, DKIM selectors, sending logs and a controlled received message can help establish the route. Do not add an unfamiliar IP to SPF simply to make a warning disappear. Establish authorisation first. Where an approved service is affected, assign the correction to an owner and specify evidence for the retest. A successful webmail test does not validate the website’s sending configuration. [2] [4]
“none” does not mean “in the inbox”
disposition describes the reported treatment within DMARC evaluation. A value of none does not prove delivery; quarantine does not reliably identify the eventual folder for an individual message. Receivers can apply other rules. Even a DMARC pass guarantees neither inbox placement nor trustworthy content. Investigate a specific missing email using sending logs, bounce messages and, where available, the received original.
Reports also cover only the perspective of the reporting receivers during the stated interval. Missing reports and gaps are not evidence of zero sending or zero abuse. Record the gap. Compare trends across equal periods with the same reporters, and check whether coverage changed before interpreting a rise or fall. [1] [4]
Turn the finding into an assigned action
Take action when an authorised, commercially important sending route fails DMARC or its results change unexpectedly. Repeated unfamiliar sources need attribution. The appropriate action follows from the evidence; it is not automatically a stronger or weaker DNS policy. Before changing policy, identify and validate legitimate sending routes and correct known authentication failures. [2]
- Check the reporter, domain, UTC interval and duplicate reports.
- Separate raw SPF/DKIM results from DMARC alignment.
- Assign an unexpected source to a service and responsible owner.
- Inspect an authorised test message, relevant headers and sending logs.
- Define the correction, change window and rollback procedure.
- After the change, verify authentication and actual delivery separately.