DMARC reports: understand your domain’s email traffic

DMARC aggregate reports summarize authentication observations made by receiving systems. This guide uses sending stream for a distinct source or workflow, such as a CRM, receipts or a campaign tool. Use the reports to identify traffic that needs investigation and assess the evidence for a policy decision. Inbox placement, recipient permission and campaign performance need separate evidence.

A useful review ends with a short list of decisions: leave a confirmed healthy stream alone, repair a known sending path, investigate an unfamiliar source, or postpone a policy change while a material question remains open. A large dashboard percentage is an opening question, not the finished review.

Choose one visible From domain and a defined period before opening the data. Gather the sending inventory, named business owners, expected activity, and access to relevant sending logs. If a stream is described only as “the sales tool,” find the person who can identify its configured sending domain and produce a recent message sample.

This guide assumes authentication is already configured and focuses on interpreting the resulting evidence. Use the authentication guide for DNS records and message-header checks; use Google Postmaster Tools for its separate provider-level signals. Keep the review narrow enough that every unresolved row can receive an owner.

Build a small intake register before combining files. Record the reporting organization, report identifier, covered domain, interval, received time, and file location. Treat repeated downloads or forwarded copies as candidates for deduplication. Keep the original evidence so an analyst can revisit a disputed row without relying on a screenshot.

Choose a consistent time zone for the review and show it in the title. A file received on Friday may describe Thursday’s traffic. Compare matching intervals; distinguish an absent report from a report containing no relevant observations. If an interval crosses a configuration change, attach the change time to the review instead of treating all traffic as one unchanged setup.

Use the messages in the selected reports as the denominator for a reported pass rate. Your sending platform’s attempted volume belongs in a separate reconciliation. Document the reporting organizations and intervals represented so a colleague can see the boundaries of the claim. An incomplete collection can still reveal a repair, but it cannot justify a statement about every message you sent.

Google recommends regular monitoring of the daily DMARC reports. Set a cadence your team can sustain, with a named reviewer and backup. During a known configuration change, schedule an additional review when relevant evidence arrives rather than assuming that an empty inbox means the change worked.

Read the report in layers. The evaluated DKIM and SPF results include alignment; the raw authentication results describe the underlying checks. A raw pass does not by itself establish a DMARC pass. At least one qualifying aligned authentication path must pass.

The table below is a reading map, not a replacement XML schema. Keep the complete record available while making an analyst’s extract, especially when a message has several signatures or a receiver supplies additional context. Use a message sample and sending configuration to explain a result before proposing a fix.

The following fictional review covers example.com at one reporting receiver for 5 November 2026, from 00:00 to 24:00 UTC. These five analyst groups contain all 12,000 messages in the selected evidence. The domain policy is p=none and every group has an observed disposition of none. The addresses are documentation examples.

The team has confirmed the first four streams through its inventory and sending records. The forwarding route is known from that evidence; its label was not inferred from an unfamiliar IP. The final source remains unassigned. Several report rows could contribute to a group in a real review, so retain a link from each group to its underlying records.

• Total observations: 7,500 + 3,000 + 900 + 400 + 200 = 12,000.
• Passing aligned authentication: 7,500 + 3,000 + 400 = 10,900, or 90.83% of the reported total.
• No passing aligned path: 900 + 200 = 1,100, or 9.17% of the reported total.
• Confirmed owned traffic: 11,800 messages, including 900 that need a repair. Separately, 200 reported messages remain unassigned and need an ownership investigation.

Build the ownership decision from several pieces of evidence. An IP address can narrow the search, but a recognizable network name is insufficient to establish who authorized the messages. Ask the business owner to match the report period and source to a sending account, expected campaign or transaction, and message sample.

For the campaign stream, the raw SPF pass is useful diagnostic evidence. The owner still needs to explain the mismatch and the missing aligned DKIM pass. Create a ticket for that exact sending path. Record the proposed configuration change, who controls it, and how a new message sample and a later report will demonstrate the outcome.

For the unassigned source, search the inventory for forgotten pilots, recently migrated services, and teams outside the main marketing operation. Keep “unassigned” as a temporary classification until there is enough evidence to call it an authorized stream or suspected impersonation. A request to authorize an unfamiliar source requires its own ownership decision; a failing row is not a reason to add it to an SPF record.

Attach a due date and escalation owner to material unanswered questions. If the owner cannot retrieve a message sample, write that limitation down. The next reviewer should know whether the investigation is waiting for access, technical evidence, or a business decision.

DMARC passes when an eligible aligned SPF or DKIM path passes. Receiver handling also reflects local decisions, so the reported disposition is not an inbox-placement result. Read the requested policy, observed disposition, and any supplied explanation together.

In the fictional review, the known campaign defect affects 900 authorized messages. Repair that path before using these observations to justify stronger enforcement. The unknown 200 messages need investigation, but they should not obscure the clearly owned defect. Keep both issues visible with different owners and closure evidence.

After the repair, choose a later period that actually contains the corrected stream. Confirm that the affected campaign sent, that the receiver reported the relevant period, and that the expected aligned path appears. A quiet day without campaign activity is an inconclusive retest. If the source or identity changed during the repair, document that change so the comparison does not accidentally omit the stream.

The domain owner should review remaining exceptions alongside the importance of each stream. A small failing receipt stream may deserve attention ahead of a larger experimental campaign. Record the business exposure and rollback owner before changing policy. Define the checks that would trigger a rollback or another investigation; avoid treating an arbitrary overall pass percentage as a universal release threshold.

RFC 9989 and RFC 9990, published in May 2026, replace RFC 7489 for DMARC and aggregate reporting respectively. Current aggregate reporting has no pct element and can include discovery_method and testing. The optional version element still uses 1.0, so that number alone cannot identify a current-format report.

Treat compatibility as an intake question. Retain the received file and record which documented format your parser or reviewer used. Ask how unfamiliar fields and older examples are handled. A successful import is only useful if the output preserves the evidence needed for your review; check a small sample against the original file before trusting a new mapping.

Standards publication does not establish that every reporting receiver or analysis product has changed its implementation. Keep observed provider behavior separate from current specification requirements. If an older example contains pct, label its context rather than presenting it as the current schema. This guide uses an original analyst extract to teach interpretation without implying that a shortened example is a valid report.

Recheck the format guidance when a parser changes, a receiver begins sending a different structure, or an unexpected field affects the result. Assign that review to the person who owns report intake.

Keep the handoff compact enough for the domain owner to act on it. Link the underlying files and tickets rather than pasting an entire report into a chat thread. Separate observed facts from the explanation you are still testing, and put an owner beside every proposed action.

Use the template below for the fictional case or replace each value with your own evidence. If a field is unknown, say what is missing and who will retrieve it. Close the review only when the next decision and its evidence requirement are explicit; a completed spreadsheet alone does not resolve an authentication defect.