# How to Read DMARC Reports: Master Deliverability in 2026 Published: June 27, 2026 Learn how to read DMARC reports and diagnose email delivery issues. Our 2026 guide covers XML parsing, SPF/DKIM results, and analysis automation. You publish a DMARC record, point `rua` at a mailbox, and then the first report lands as a gzipped XML attachment that looks like a crash dump from someone else's infrastructure. That's a normal reaction. Most developers don't struggle with DMARC because the concepts are impossible. They struggle because the feedback loop arrives in a format built for machines first and humans second. If you're building autonomous systems, this matters more than it does in a traditional IT setup. Your agent might send onboarding emails, support replies, status notifications, handoff messages, or cross-system alerts without a human watching every send. When those messages fail authentication or get treated as suspicious, your workflow doesn't just lose deliverability. It loses trust, state continuity, and reliability. Knowing how to read DMARC reports gives you the operational view you need. You can see who is sending on behalf of your domain, whether those messages align correctly, and which senders need to be fixed, authorized, or blocked. ## Why DMARC Reports Matter for Autonomous Agents At 2:13 a.m., your incident bot sends a customer-facing alert from `status@yourdomain.com`. The message leaves your workflow, but one receiver sees it as aligned mail from an approved platform and another sees it as a spoofing attempt. If you only look at application logs, both sends appear successful. DMARC reports show what receivers observed. For autonomous systems, that gap matters. Agents send retries, escalations, summaries, billing notices, and handoff messages across multiple providers and runtimes. A single misconfigured sender can break more than inbox placement. It can interrupt stateful workflows, hide failures from users, and make agent-to-agent communication look untrustworthy to the systems on the other end. A DMARC aggregate report is the daily record of that behavior. It summarizes which sources sent mail using your domain and whether those messages passed SPF and DKIM in a way that aligned with your DMARC policy. The reports go to the address in your `rua` tag after you publish a DMARC record. That makes DMARC reports an operational input, not paperwork. If you build programmatic email flows, you need a way to verify that every sender your agents use is both authorized and configured correctly. ### Aggregate reports and forensic reports You will run into two DMARC report types: - **Aggregate reports, or RUA reports**, summarize traffic by source, authentication result, and policy outcome across a reporting window. - **Forensic reports, or RUF reports**, describe individual failures when a receiver chooses to send them. In practice, RUA is the dataset you can count on. RUF can help during a narrow investigation, but support is inconsistent and many receivers do not send those reports at all. Build your process around aggregate reporting first. > **Practical rule:** Start with RUA, treat RUF as optional, and never block your analysis pipeline waiting for failure samples. ### Why this matters in agent-driven environments Autonomous workflows tend to accumulate send paths faster than teams document them. One agent uses your transactional provider. Another sends through a support platform. A third triggers notices from a low-code automation tool. Six months later, nobody is sure which systems are still active or whether all of them sign mail correctly. DMARC reports answer the questions that matter during rollout and incident response: - **Which services are sending as your domain** - **Which senders are valid but misaligned** - **Which sources were never approved** - **Which failures point to spoofing rather than configuration drift** That last distinction matters. A broken DKIM selector on an approved sender needs a fix. Traffic from an unknown IP block claiming your domain needs containment and a stricter policy. For developers building autonomous systems, this is part of reliability engineering. We already monitor queues, retries, webhooks, and API error rates. DMARC belongs in the same category. If your agents depend on email to move work between users, vendors, and other systems, domain authentication needs the same level of visibility as any other production dependency. A safe rollout usually starts with `p=none` so you can observe real traffic before enforcement. That gives you time to inventory senders, fix alignment problems, and separate legitimate automation from abuse before you move to quarantine or reject. ## Decoding Your First Aggregate RUA Report Your agent shipped a batch of status emails overnight. The workflow completed, the API calls succeeded, and users still say messages never arrived. You open the DMARC mailbox and find an XML attachment full of tags, IPs, and pass or fail fields. That file is the fastest way to confirm whether your autonomous system is sending authenticated mail or just assuming it is. An aggregate RUA report is a summary of how receivers saw mail that claimed to come from your domain during a given time window. It does not show a full copy of each message. It shows patterns by source, which is what you need when several apps, agents, and vendors can all send on your behalf. Start at the top of the XML. Do not read it linearly and hope the structure becomes obvious. Read it in layers so you can answer one operational question at a time. ### Start with the report envelope The envelope tells you who generated the report, what dates it covers, and which DMARC policy was published for your domain during that period. That context matters because a failure under `p=none` means something different from a failure under `p=reject`. Read these fields first: - **Reporting organization**. The receiver that observed traffic using your domain. - **Date range**. The exact reporting window. - **Published policy**. The DMARC policy and alignment settings active in DNS at that time. Teams skip this step and misread stale data all the time. If the report covers yesterday but your DNS changed this morning, do not treat the file as a view of current state. ### The `` block is the part that drives action Each `` groups messages from one observed source, allowing you to determine whether a sender is healthy, broken, or unknown. Focus on these fields: 1. **`source_ip`** The sending IP the receiver saw. Map it to a provider, internal relay, cloud function, or something you do not recognize. 2. **`policy_evaluated`** The DMARC result for that source. Check disposition, SPF result, and DKIM result. 3. **Alignment fields** DMARC is not just SPF pass or DKIM pass. The authenticated domain also has to align with the visible From domain according to your policy. If you skip alignment, you will misclassify a lot of mail. A sender can pass SPF for its own bounce domain and still fail DMARC for your domain. That shows up often in programmatic email systems where developers configured delivery but not identity. ### Read it like an engineer debugging a dependency For each sender, answer the same small set of questions: - Did this source send mail using our From domain? - Did SPF align? - Did DKIM align? - What disposition did the receiver apply? - Do we expect this source to exist? That is enough for a first pass. You do not need to become an XML expert to triage a report. Here is the compact field map that matters during review: | XML Tag Path | What It Means | What to Check | |---|---|---| | `report_metadata/org_name` | The receiver that generated the report | Which provider observed the traffic | | `report_metadata/date_range` | The time window covered by the file | Whether the data is current | | `policy_published/p` | Your DMARC policy at the time | Monitor, quarantine, or reject | | `record/row/source_ip` | The sending source observed | Known sender, internal service, or unknown source | | `record/row/policy_evaluated` | DMARC evaluation result | Pass, fail, and disposition | | `record/auth_results` | SPF and DKIM auth details | Which method passed and for which domain | | `record/identifiers/header_from` | The visible From domain | Whether it matches the identity you intended | ### A short example of how to interpret one record Suppose a report shows `source_ip=198.51.100.24`, `header_from=alerts.example.com`, SPF passes for `mailer.vendor.com`, DKIM fails, and DMARC fails. That usually points to a legitimate platform sending for you without aligned authentication. The mail may be coming from a real vendor you approved, but the visible From domain and the authenticated domain do not line up closely enough for DMARC. For autonomous systems, this distinction matters. If one agent triggers mail through a third-party provider and another uses a different provider with proper DKIM alignment, one workflow will look healthy and the other will look suspicious to receivers even though both are functionally "sending email." DMARC reports expose that difference fast. ### Raw XML works for learning. It does not scale well Manual review is useful early on. Open a few files, trace one sender from `source_ip` to authentication results, and confirm that your mental model matches what receivers saw. After that, the problem shifts from parsing to repetition. Once you have multiple applications, support tools, cron jobs, and agent workflows sending mail, you need normalized views, sender classification, and trend history. Raw XML still contains the truth, but it is a poor interface for daily operations. ### A practical review order Use the same sequence every time: - **Check the date range** so you know whether the report reflects the incident window you care about. - **Identify the reporting organization** because each receiver sees only part of your total traffic. - **Read the published policy** so you interpret failures in the right enforcement context. - **Review each record** and tag it as expected, misconfigured, or unknown. - **Prioritize expected senders with failures** because those usually need configuration fixes. - **Escalate unknown failing sources** because they often indicate spoofing attempts or an undocumented service. Once you adopt that workflow, the XML stops looking like a compliance artifact. It becomes an operational log for your domain identity, which is exactly how developers should treat it when email is part of an autonomous system. ## Common Scenarios and What They Mean The useful part of DMARC analysis isn't parsing. It's classification. You need a fast way to look at a sender and decide whether it's healthy, forgotten, broken, or hostile. [EasyDMARC's overview of DMARC reports](https://easydmarc.com/blog/understanding-dmarc-reports/) frames this well. Sort sending sources into **known senders**, **unknown passing sources**, and **unknown failing sources**. That's the model that holds up in real environments. ![A diagram illustrating five different scenarios for analyzing DMARC email authentication reports from pass to failure.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/dba63d1e-6628-4dd9-a4d0-55ab21b25753/how-to-read-dmarc-reports-dmarc-analysis.jpg) ### Known sender and full pass This is the clean case. Your app, support system, or mail platform sends on behalf of your domain. SPF and DKIM align, and DMARC passes. That sender goes in the **known sender** bucket. You document it and keep watching for drift. What this means operationally: - The sender is configured correctly. - The visible From domain matches your intended identity. - Enforcement will be low risk for this source. This is what you want your agent mail paths to look like. Predictable. Verifiable. Boring. ### Known sender but one control fails A common report pattern is a legitimate source where one authentication method passes and the other fails. That doesn't always mean mail is malicious. It often means the sender is partially configured. Examples you'll run into: - SPF fails but DKIM passes - SPF passes but DKIM fails - DMARC still passes because one aligned method succeeded These are warning states, not victory states. A sender that only barely passes today can become a delivery problem after a vendor change, forwarding behavior, or DNS mistake. > Healthy DMARC posture isn't “it technically passed.” It's “we know why it passed, and the configuration is intentional.” ### Unknown source that passes This scenario surprises teams the first time they see it. The report shows a sender you didn't know about, but it passes authentication. That usually means a legitimate tool was added outside the core platform team. Marketing set up a nurture system. Support enabled a new helpdesk. A developer wired a workflow tool to send status emails. Nobody told the people managing the domain. This goes in the **unknown passing** bucket. Treat it as a documentation and governance problem. The sender might be valid, but you still need to confirm ownership, use case, and configuration. ### Unknown source that fails This is the one you should investigate quickly. The report shows mail using your domain in the header, but authentication doesn't line up and the source isn't recognized. That goes in the **unknown failing** bucket. In practice, this often means one of two things: - A legitimate sender is misconfigured - Someone is spoofing your domain The distinction comes from context. If the source maps to a platform someone on your team recently added, fix the configuration. If nobody owns it, treat it as unauthorized. ### Real-world diagnosis patterns Use this compact interpretation guide when reviewing records: - **A source you know, failing repeatedly** means your DNS or signing setup likely needs correction. - **A source you don't know, passing cleanly** means some team probably added a real mail path without central review. - **A source you don't know, failing both paths** is the strongest signal that someone is trying to impersonate your domain. - **A source that changes behavior over time** often points to vendor reconfiguration, broken DKIM signing, or an infrastructure migration that wasn't reflected in SPF or domain alignment. ### Don't overreact to every fail Not every failing record means disaster. DMARC reports capture attempted use of your domain identity, and large systems are messy. Some failures are harmless tests, forwarders, or half-finished integrations. Your job is to separate noise from patterns. A practical workflow looks like this: 1. Confirm whether the source is known. 2. Check whether at least one authentication path aligns. 3. Decide whether the sender should exist. 4. Fix, authorize, or block based on that answer. That's the muscle behind learning how to read DMARC reports. You're not just decoding XML. You're building a decision system around domain trust. ## Taking Action and Enforcing Your Policy A DMARC report review is only useful if it changes behavior in DNS and in your mail systems. Once you know which senders are legitimate, the job shifts from diagnosis to policy control. ![A six-step infographic detailing the DMARC policy enforcement process for improving email security and deliverability.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/b0669aec-deee-444a-a655-3a3de4c7176f/how-to-read-dmarc-reports-dmarc-playbook.jpg) For autonomous systems, that control matters more than it does in a purely human email setup. If an agent sends passwordless login links, billing notices, approval requests, or machine-generated incident updates, DMARC policy decides whether those messages are trusted, quarantined, or dropped. A bad rollout can break real workflows. A weak rollout leaves your domain open to impersonation. Start with `p=none`. Keep it there while you inventory every service that sends as your domain and fix the ones that should pass but do not. That gives you room to correct alignment without disrupting traffic. [Litmus explains the operational rule clearly](https://www.litmus.com/blog/reading-first-dmarc-reports). If legitimate mail fails, correct SPF or DKIM. If unknown sources keep failing, tighten policy so receivers can quarantine or reject them. ### A rollout sequence that holds up in production Use a staged approach: 1. **Publish `p=none` and collect reports** Monitor first. You need a clean map of actual senders before asking receivers to enforce anything. 2. **Repair authentication for approved systems** Fix alignment for platforms that should send mail for your product, support queue, CI system, or agents. If you need a quick refresher, this [technical overview of DKIM and SPF](https://robotomail.com/blog/what-is-dkim-and-spf) covers the mechanics behind both controls. 3. **Verify steady-state behavior** Look for consistency across several reporting cycles. A sender that passes one day and fails the next is not ready for stricter policy. 4. **Move to `p=quarantine`** Use quarantine when you are confident legitimate traffic is authenticating correctly and you want suspicious mail treated as risky instead of accepted normally. 5. **Move to `p=reject`** Use reject when you are ready for receivers to block mail that claims your domain but does not meet DMARC requirements. The trade-off is simple. Early enforcement reduces spoofing faster, but it also increases the chance of breaking a sender your team forgot to document. Slower enforcement lowers rollout risk, but it gives unauthorized traffic more time to keep using your domain identity. Pick the pace that matches how well you control your outbound mail surface. ### How to make gradual enforcement safer The `pct` tag lets you apply quarantine or reject to only part of affected mail. That is useful when you want production feedback without exposing all mail streams to the same policy change at once. It is especially helpful for domains used by multiple systems owned by different teams, where one unknown sender can still appear after you thought cleanup was done. A practical pattern looks like this: - start with `p=none` - fix known failures until reports stabilize - switch to `p=quarantine; pct=25` - increase coverage as reports stay clean - finish at full quarantine or reject That approach keeps the blast radius small. If a workflow breaks, you can identify which sender failed before the issue hits every automated message path. ### Failure patterns that block enforcement Some mistakes show up repeatedly: - **Staying on `p=none` indefinitely** because no one owns the cleanup work - **Promoting to quarantine after a quick spot check** instead of waiting for repeated clean reports - **Ignoring DKIM or SPF drift** because DMARC still passes through the other aligned path - **Treating machine-generated mail as lower risk** even when those messages trigger payments, account actions, or system state changes That last one matters. In agent-to-agent workflows, email is often part of the control plane. A quarantined approval request can stall an automated process. A spoofed system notice can trigger the wrong action if another agent trusts the sender identity. Enforcing DMARC is not just about brand protection. It is about making sure only approved systems can act under your domain name. ## Automating DMARC Analysis for Agent Workflows Your billing agent starts sending receipts from `billing.example.com`. The app works, the queue is healthy, and customers are getting mail. Three days later, aggregate reports show a new source failing alignment because a vendor relay was added outside your normal mail path. If no one is parsing those reports in time, your autonomous workflow is already running with an identity problem. ![A man transitioning from manually processing piles of DMARC XML reports to using an automated software dashboard.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/d03a5a93-b6ec-43b9-83ab-c2c36d8658ee/how-to-read-dmarc-reports-automated-dmarc.jpg) That is why manual XML review does not hold up once software starts sending on your behalf at any real scale. Reports arrive continuously from different receivers, in different files, with overlapping time windows. For agent-driven systems, DMARC analysis needs to behave like log ingestion or metrics collection. Parse it, classify it, store it, and alert on change. ### Build a parser or buy the plumbing There are two practical paths. Build your own pipeline if you need strict control over data retention, enrichment, and alert routing. That usually means ingesting gzipped XML from a mailbox or endpoint, parsing records into structured objects, normalizing sender identities, and classifying each source into buckets your team can act on. The XML parsing is manageable. The operational work is in handling malformed attachments, duplicate reports, provider-specific quirks, and the mapping between an IP in a report and the service that sent the mail. Buy the plumbing if DMARC visibility matters, but it is not where you want to spend engineering time. For many teams shipping autonomous messaging features, that is the better trade-off. You want clean report data and change detection, not another ingestion system to maintain. A practical option is a [DMARC report analyzer for programmatic email workflows](https://robotomail.com/blog/dmarc-report-analyzer) if you want parsed data instead of raw attachments. ### Treat DMARC as an event stream The useful shift happens after parsing. Do not keep DMARC in a separate admin corner of the stack. Feed parsed results into the same systems you already trust for operational signals. A good implementation sends report findings into queues, webhooks, ticketing rules, or anomaly detection jobs. If a new sender appears and fails alignment, your system should open an issue, tag the owning integration, and attach the evidence needed to fix it. If a known sender starts failing after a config change, trigger the same incident path you would use for a webhook failure or rising retry count. This matters more for autonomous systems than for human-only mail operations. In agent-to-agent workflows, email often carries approvals, status changes, receipts, reset links, or machine-readable notifications. DMARC analysis is part of message trust, and message trust is part of system correctness. Here's a good explainer if you want a visual walkthrough before implementing your own automation: ### What automation should produce Good DMARC automation should answer operational questions without anyone opening XML by hand: - **What changed** since the last reporting window - **Which sender is new** - **Whether the new sender passed or failed** - **Whether the source maps to a known service or team** - **What action should happen next** That output gives developers something they can use. Parsed DMARC data should support decisions, ownership, and remediation. If your agents can send mail automatically, your platform should also detect when a sender appears outside policy, when alignment drifts, and when trust in that mail path needs to be reviewed. ## Frequently Asked Questions About DMARC Reports ### Why am I receiving aggregate reports but not forensic reports That is normal. Aggregate reports sent to the `rua` address are the format you should expect to rely on. Forensic reports sent to the `ruf` address can include message-level failure details, but many large receivers do not send them, or send them only in limited cases because of privacy, abuse-handling, or operational policy. If you are building agent-driven mail workflows, design around aggregate visibility first. Treat forensic reports as optional extra data, not a dependency. ### Why do forwarded emails sometimes fail DMARC Forwarding often breaks SPF because the forwarder becomes the new sending system. The original IP no longer matches the path the receiver sees. DKIM can still pass if the forwarder leaves the signed headers and body intact. That is why a forwarded message may show SPF failing while DKIM passes and DMARC still succeeds. For developers, the practical point is simple. A forwarding-related failure does not always mean spoofing or a broken sender. It may be a mail path issue. ### Why do I get many small reports instead of one master report Because each receiving system reports what it observed from its own environment. DMARC reporting is decentralized by design. Gmail, Microsoft, Yahoo, and smaller receivers each generate their own view of your traffic, on their own schedule, with their own XML output. You are not waiting for a single canonical report from your domain. You are collecting many observations and merging them into one operational picture. That matters for autonomous systems because different providers may see different agents, routes, and failure modes. ### Should I read raw XML by hand Read raw XML when you are learning the format, verifying a parser, or checking an edge case. Do not make manual XML review your steady-state process. It does not scale, and it slows down incident response once multiple services, environments, or autonomous agents are sending mail under the same domain. Parsed output should tell you who sent the mail, whether alignment passed, whether the sender was expected, and who owns the fix. > The point of a DMARC report is to confirm that your domain identity is controlled and behaving as expected. ### What's the fastest way to act on a strange record Triage it with three questions. Is the sender known? Did either SPF or DKIM align for DMARC? Should that sender be using this domain at all? Those answers usually separate routine configuration work from an actual trust problem. If the source belongs to a known service, fix alignment. If it belongs to an internal team, route it to the owner. If nobody recognizes it, treat it like any other unauthorized system touching production identity. --- If your agents send email as part of core product behavior, treat DMARC visibility like any other production signal. [Robotomail](https://robotomail.com) is an email infrastructure platform built for AI agents, with programmatic mailboxes, webhook-based inbound handling, and support for custom domains with auto-configured DKIM, SPF, and DMARC. That makes it a practical fit when you want autonomous systems to send and receive mail without bolting human-centric inbox tooling onto your stack.