How to Read a DMARC Aggregate XML Report by Hand in 2026

Why reading DMARC aggregate reports by hand matters

You receive a DMARC aggregate report, open it, and see a wall of XML. It looks like noise. But beneath the tags and attributes is a clear record of how your domain is being used—across every email provider, every sender, every attempt to spoof or deliver.

Most teams rely on dashboards. But a dashboard only shows you what it’s programmed to highlight. When deliverability drops or spam complaints spike, you need to read the raw report. Only then do you see the real picture—like detecting an obscure third-party sender that’s been hijacking your brand, or catching misconfigurations that no automated tool flags.

Learning how to read a DMARC aggregate XML report by hand isn’t about obsession with detail. It’s about speed, precision, and control. You’re not waiting for a tool to alert you—you’re spotting the signal in the noise.

Key takeaways

• Raw DMARC aggregate reports reveal actual sender behavior across domains, not just aggregated summaries.
• Manual inspection uncovers subtle misconfigurations or spoofing attempts that automated tools may miss.
• Understanding XML structure enables faster root-cause analysis during inbox placement issues or complaint spikes.

What is a DMARC aggregate XML report? A clear breakdown

DMARC aggregate reports are weekly or daily XML files sent to a specified email address when inbound emails fail or pass SPF or DKIM checks. They contain machine-readable data on email volume, authentication results (pass, fail, or none), source IP addresses, and the sending domain—all standardized under RFC 7483. You can read them by hand to spot abuse patterns, verify DMARC policy effectiveness, or troubleshoot delivery issues.

The structure behind the data

Each report is structured consistently across domains, making it possible to parse and analyze even without special tools. The root element is <feedback>, followed by <report_metadata> with details like the reporting domain, report ID, and production date. From there, the report lists all messages processed, grouping them by IP address, authentication results, and source domain.

Inside <record> elements, you’ll find key signals: an auth_result field showing whether SPF and DKIM passed, failed, or were not tested. Each record also includes the first 20 characters of the sending IP address, the observed domain (where the email claimed to come from), and a count of messages. These are essential for spotting spoofing attempts or misconfigured senders.

Why you should read these reports manually

Let’s be honest—most teams don’t. They rely on dashboards. But reading a DMARC report by hand gives you control. You’ll spot patterns others miss: a single IP sending 90% of failed DKIM attempts, or domains sending from unusual locations. You can cross-reference the IP with blacklists like Spamhaus or use tools like MxToolbox to confirm reputation.

While automated tools help, understanding the XML format lets you respond quickly when threats emerge. For example, a sudden spike in “no authentication” events might mean a new unverified sender is abusing your domain. This is where DMARC reports shine—not just as logs, but as real-time threat intelligence. The format, defined in RFC 7483, ensures consistency across all domains, so you’re not learning a new structure every time.

If you're verifying sender authenticity or testing email deliverability, tools like MailTester can help you pre-validate your list. Inbox placement testing shows real inboxes—no proxies. Or use the bulk verification to clean lists before sending, reducing spoofing risks. Our API gives you real-time checks at scale, which pairs well with monitoring your DMARC reports for anomalies.

How to read a DMARC aggregate XML report by hand: a step-by-step process

You can read a DMARC aggregate XML report by hand by downloading it from the email address specified in your DMARC policy’s rua tag, opening it in a text editor or XML viewer, then walking through theroot element to check domain identity, source IPs, authentication results, and message disposition. Eachrepresents a reported sender, and reviewing fields like,, andhelps diagnose spoofing attempts or misconfigured senders. Useto spot unusual volumes.

Step-by-step: parsing a DMARC report

1. Download the report from the email inbox listed in your DMARC policy’s rua tag. These are typically sent weekly and contain aggregated data on messages sent using your domain.
2. Open in a text editor like VS Code, Notepad++, or any XML-aware tool. Avoid browsers that render XML as a full page—look for raw structure.
3. Locate the <report> element, the root of the document. This contains metadata like date_range, policy_published, and report_id. Confirm the org_name and domain match your organization.
4. Check <identities> to verify the reporting domain is your own. If it shows a different domain, you may be receiving reports from a third-party monitoring service or have a misconfigured policy.
5. Read each <record> block. Each represents one observed email sent using your domain’s name. These are grouped by sender IP and authentication outcome.
6. Review <sourceIps> for IPs that appear unexpectedly. High volumes from unknown IPs may indicate spoofing or compromised accounts. Compare with your approved senders list.
7. Inspect <auth_results>. Look for spf and dkim outcomes. "fail" or "none" means the email failed SPF or DKIM checks. If both fail, the message is likely unauthorized.
8. Check <disposition>. If it's "quarantine" or "reject", the email was actioned per your DMARC policy. If it’s "none", the sender was not blocked, even if authentication failed.
9. Use <count> to assess frequency. A sudden spike in counts from a single IP or from IPs not in your sender list suggests abuse or misconfiguration.
10. Export to spreadsheet. Copy the key fields—IP, count, disposition, auth_results—into CSV or Excel for trend tracking. You can correlate spikes with phishing incidents or new campaigns.

Why this process matters

Daily monitoring of DMARC reports helps you detect unauthorized use of your domain before attackers exploit it. The IETF’s DMARC specification outlines how these reports are structured and used. If you use multiple mailers or third-party tools, regular review ensures only trusted sources send on your behalf.

For teams managing sender reputation, automated tools like the MailTester bulk verification or inbox placement tester can help validate your domains and test email delivery—complementing DMARC data with real-world placement insights.

Key fields in a DMARC aggregate XML report: what they mean

You can read a DMARC aggregate XML report by hand by focusing on six core fields:,,,,,,, and. Each reveals a piece of the authentication puzzle.shows the time window of the report,is a unique tracker,reflects your domain’s DMARC policy (none, quarantine, or reject),reveals which domains were tested,shows sending IPs,details SPF and DKIM pass/fail outcomes,tracks how the receiver acted, andgives you the volume of messages from each IP/domain combination. These fields together confirm whether your emails are being authenticated as intended.

Understanding the structure: what each field reveals

Let’s go through the most meaningful fields in a DMARC aggregate report, not just their names, but what they tell you about your email security and deliverability.

RFC 7483 defines the DMARC specification, including the structure of these reports. While the data is raw, understanding each field helps you detect spoofing, verify policy enforcement, and improve sender reputation.

Use this insight to refine your email setup. If you’re validating your mailing list before sending, tools like MailTester’s bulk verification help detect invalid or risky addresses before they cause issues in your DMARC reports.

How to spot a spoofing attempt in a DMARC report

You can detect a spoofing attempt in a DMARC aggregate report by looking for a high volume of messages marked with SPF=FAIL and DKIM=FAIL from unfamiliar or unexpected IP addresses. If those IPs belong to public cloud providers or are not part of your email infrastructure, and if the volume spikes suddenly—especially over hours—this is a strong signal of abuse. Cross-reference these records across time to spot anomalies that don’t align with your legitimate sending patterns.

Look for IPs outside your infrastructure

Check the sourceIP values in the report. If you see IPs from known public cloud providers—like AWS, Google Cloud, or Microsoft Azure—spiking in failed mail, it’s unlikely these are your own servers. These IPs are often used by attackers to send forged emails because they’re easy to access and blend in with real traffic. You can verify known IP ranges through public databases such as ipdeny.com or RIPE Atlas.

Watch for sudden volume spikes

A single IP sending hundreds or thousands of messages in a few hours without a corresponding sender reputation boost is a red flag. Legitimate sending systems typically have steady volumes or predictable patterns. Sudden spikes in failed records—especially from the same IP—suggest automated abuse, like credential stuffing or phishing campaigns. Use time-based breakdowns in your DMARC report to identify such bursts. If your domain has no authorized senders using those IPs, treat the traffic as likely malicious.

Let’s say you see 1,200 SPF=FAIL and DKIM=FAIL records in a single 24-hour period from an IP in a Google Cloud range that wasn’t in your sending list. That’s not normal. It’s likely a spoofing attempt. You can use your existing email-verification tools to test whether the sending domain is valid and traceable. For large-scale analysis, tools like MailTester’s bulk verification can help validate sending domains and catch risky patterns early in your campaign pipeline.

The key is to treat DMARC reports not as background noise, but as active monitoring tools. Each row entry gives you a signal about the health of your domain’s email ecosystem. When patterns deviate—especially when combined with technical failures and unexpected IPs—you’re seeing a real-world indicator of abuse. This is why continuous monitoring and timely action matter.

What to do when you find failed authentication in your DMARC report

If your DMARC aggregate XML report shows failed authentication, start by checking whether all legitimate sending sources—marketing, support, transactional—are properly authenticated via SPF or DKIM. Then, verify third-party tools aren’t sending as your domain without proper setup. Look for misconfigured platforms or leaked credentials. If legitimate sends are failing, adjust your DMARC policy (p=quarantine or p=reject) only after confirming the failures aren’t from valid traffic. Use tools like inbox placement testing to validate real-world results before tightening policy.

Check authorized sending sources

• Review your SPF record and confirm every domain or IP that sends emails on your behalf is listed.
• Ensure every sending platform (like Mailchimp, SendGrid, or HubSpot) uses a valid DKIM signature, not just SPF.
• If a tool sends from your domain but isn’t in SPF or lacks DKIM, it will fail DMARC—even if it’s a legitimate sender.
• Use RFC 7073’s guidelines on DMARC reporting to understand what counts as a "pass" or "fail" by standard.

Investigate unexpected senders

• Identify any tools or platforms (e.g., CRMs, helpdesk systems) that might be sending emails as your domain without explicit setup.
• Check for misconfigured applications that use your domain’s email addresses in From fields but don’t authenticate.
• Verify if a user or team member has forwarded mail or set up a forwarding rule that bypasses authentication.
• Look for domains or IPs associated with automated scripts, bots, or compromised accounts—these often send without authentication.

DMARC fails don’t always mean attack—or even misconfiguration. Sometimes they’re signals that you’ve expanded your sending ecosystem without updating your policies.

Once you’ve mapped legitimate senders, use bulk list verification to test your sending list for valid identities and catch-all addresses early. You can also run real-time verification via the verification API to validate new contacts before sending.

If you see consistent failures from a single platform, it’s likely misconfigured. Fix it. If the failure source is outside your control (e.g., a third-party vendor not using your domain correctly), consider whether you should allow it at all or if it should be rebranded with a different domain.

Finally, reassess your DMARC policy. A strict p=reject only makes sense once you're confident the vast majority of outbound mail passes authentication. Until then, start with p=quarantine, monitor the report, and adjust only after validating each failure is not a false positive from real traffic.

Common pitfalls when reading DMARC reports manually

You might think every failed SPF or DKIM check in a DMARC aggregate report means an attack is underway—but that’s a common mistake. Many reports show failures due to outdated tools, misconfigured legacy systems, or even legitimate third-party senders using non-compliant configurations. Assuming all failures are malicious leads to wasted time and missed real threats. Let’s walk through the real traps.

Not all failures are malicious

SPF and DKIM failures often appear in reports not because of attackers, but because of tools or systems that don’t follow modern standards. For example, older email marketing platforms or legacy CRM integrations may use sending domains that don’t align with your SPF record. These fail the DMARC check, but they’re not malicious. You'll see this in <reason> fields with temperror or policy, not spf or dkim misalignment. Check the <sourceDomain> and <identities> fields to verify if the sending domain is even within your control.

Also, don’t ignore reports where <disposition> is set to none. These still contribute to your failure rate and may indicate policy misalignment. Even if the recipient doesn’t reject the message, a high number of none dispositions across domains shows you’re leaking senders or misconfigurations in your ecosystem—especially if you manage multiple brands or subsidiaries.

Mixing up identities and source domains

The <identities> field shows the domain used in the email’s header (like From:), while <sourceDomain> shows the domain actually sending the message (like the MAIL FROM domain). These don’t always match—especially with third-party services. For instance, an email sent via SendGrid might pass SPF for [email protected] but fail DKIM because SendGrid uses a different domain to authenticate. This mismatch is normal and doesn’t mean your domain is compromised. It's why you need both fields for context.

Skipping reports across multiple periods is another trap. A single report shows only a 7-day window. Overlook the pattern across weeks or months, and you might miss slow-evolving issues like gradual exposure from a new sender, or seasonal spikes from marketing campaigns. Aggregated data over time can reveal trends that isolated reports won’t—but it requires consistent monitoring.

For teams that want to simplify this, tools like MailTester’s inbox placement tester help validate email delivery in real inboxes, while their verification API can help assess domain health ahead of sending. Still, manual analysis remains essential for deep security reviews. Use the pricing page to see how even small teams can afford reliable verification at scale.

For reference, the DMARC specification (RFC 7483) details report structure and semantics. Always check the source domain against your internal email flows—don’t assume a failure equals a breach.

How MailTester helps you act on DMARC data in real time

You don’t need to read DMARC aggregate XML reports by hand to act on them. MailTester converts that raw data into real-time signals: it checks whether your senders are blocked due to DMARC failures, identifies invalid or role-based addresses that could be exploited in spoofing attacks, and uses AI to flag anomalies you might overlook—all while integrating with your existing workflow via API or bulk verification.

From diagnosis to defense: turning reports into action

Reading DMARC XML by hand is possible, but slow and error-prone. By the time you parse a report, attackers may already have used compromised accounts or spoofed domains. MailTester automates this process. It ingests your DMARC data and translates it into specific, actionable insights—like which domains are failing alignment, which IPs are sending mail without proper authentication, or which addresses are being used in fraudulent campaigns.

Let’s say your report shows a sudden spike in failures from a subdomain you don’t manage. MailTester doesn’t just surface it—it cross-references it with known bad actors and checks whether those addresses are valid or role-based (like admin@ or support@). If they’re role-based or invalid, they’re high-risk for spoofing, and MailTester flags them immediately. This helps you close gaps before attackers exploit them.

Real-time verification, intelligent alerts

Use MailTester’s inbox-placement tester to test whether emails from your domains are being filtered or blocked—especially in cases where DMARC policies are enforced. If a sender fails DMARC but still reaches inboxes, that’s a red flag: it could mean relaxed enforcement or misconfigured policy. MailTester pinpoints whether low inbox placement correlates with failed DMARC results, giving you a direct link between policy and deliverability.

Our API and bulk verification tools detect invalid or role-based sender addresses before they get used in spoofing attempts. This proactive step complements DMARC by reducing the attack surface of your domain. You can even integrate MailTester with platforms like HubSpot, Klaviyo, or SendGrid to verify recipient lists in real time—no more sending to addresses that could harm your sender reputation.

And when raw data doesn’t tell the whole story, our in-app AI assistant steps in. It doesn’t just list anomalies—it interprets them. For example, a sudden spike in failures from a single IP might be a misconfigured system. Or it might be the start of a phishing campaign. The AI flags patterns that humans miss, often before they escalate.

For details on how to test your domain’s deliverability or clean your email lists, see our inbox placement tool or bulk verification. Every credit you buy never expires, so you can keep testing as your attack surface evolves.

Integrating DMARC insights into your list hygiene and deliverability workflow

You can turn raw DMARC aggregate XML reports into actionable list hygiene steps by identifying unauthorized senders, validating their legitimacy with your trusted tools, and proactively removing risky IPs or domains. Let’s go through how to move from report data to real-world cleanup.

Mapping Failed DMARC Reports to Your Sender Ecosystem

• Scan DMARC reports monthly for senders with consistent failure rates—especially those showing fail or none alignment in SPF or DKIM.
• Match reported sender IPs or domains against your internal list of approved email vendors. If an IP appears in reports but isn’t on your approved list, it’s likely unauthorized.
• Use MailTester’s bulk verification to cross-check those IPs and domains: if they return as “invalid” or “risky,” prioritize removing them from your list.
• Block domains flagged in reports as unauthorized senders—especially if they’re used for transactional or marketing messages not originated by your team.

Tracking Repeat Abusers and Strengthening Your Sender Reputation

• Monitor repeat offenders over consecutive monthly reports. Persistent failures often signal misconfigured systems or compromised accounts.
• Use your email-verification API to validate the authenticity of senders before enabling them—don’t assume legitimacy just because they’re active.
• Update your email sending workflow to prevent future inclusion of known bad actors. Even one compromised vendor can damage your sender reputation.
• Leverage inbox placement testing to gauge the real-world impact of removing problematic senders—this gives you feedback on deliverability improvements.

DMARC reports are only useful when you act on them. Real-time validation and consistent monitoring turn forensic data into operational defense. A 2021 ICANN study found that 68% of phishing attempts in reported domains originated from unauthenticated sources—highlighting the need to treat DMARC failures as system breaches.

Let’s treat each DMARC failure as a flag, not noise. Your sender list should be a living document, updated with every report. The goal isn’t perfection—it’s sustainability. By cross-checking against trusted tools like MailTester, you reduce exposure without sacrificing outreach.

The limits of DMARC: what it can't tell you

DMARC tells you whether an email passed authentication, not whether it was read, opened, or clicked. It doesn't detect malicious content, nor does it fix poor sender reputation. It reflects aggregate delivery patterns across domains, not individual user results. You need complementary tools to assess inbox placement, content safety, or engagement.

DMARC doesn’t confirm message engagement

You can't know if someone opened your email just because DMARC passed. That data — opens, clicks, time spent — comes from email tracking pixels, not authentication reports. A message may pass DMARC and still go straight to trash, never seen. The RFC 7483 standard explicitly limits DMARC’s scope to authentication, not user behavior.

Authentication failures aren't the same as malicious content

DMARC only verifies if the sender’s domain aligns with SPF and DKIM. It won’t catch a phishing link in the body, a malicious attachment, or a deceptive subject line. If an email passes DMARC but delivers malware, the report says nothing about content. You need scanning tools like those from Spamhaus or Mimecast to uncover such risks. DMARC isn’t a security substitute — it’s a sender verification layer.

Also, DMARC doesn’t diagnose sender reputation. A sender can pass DMARC and still be marked as spam due to high bounce rates, low engagement, or blacklisting. Reputation is built through consistent sending behavior, list hygiene, and feedback loops — not authentication alone.

Finally, DMARC aggregate reports are statistical, not individual. You’ll see totals like “100,000 messages sent, 99,865 passed” across your domain, but no details on who received what, or why one user missed it. That’s the point: they’re designed for domain-level visibility, not user-level diagnostics. If you need to test actual inbox placement or verify deliverability per recipient, you need a live inbox test.

For that, tools like MailTester’s inbox placement tester simulate real delivery across major providers. It shows whether your message lands in primary inbox, spam, or gets blocked — giving you insight DMARC alone can’t offer. Use it alongside DMARC to close the gap between authentication and real-world deliverability.

Final takeaway: mastering DMARC reports improves sender reputation

Reading DMARC aggregate XML reports by hand gives you a detailed, unfiltered view of your domain’s email traffic. You see exactly which IPs are sending, how often messages are failing alignment, and whether unauthorized sources are impersonating your domain.

This level of understanding allows you to make informed decisions about authentication policies, detect abuse patterns faster, and improve inbox placement by eliminating weak links in your sending chain.

While tools can automate parsing, knowing how to interpret the raw XML ensures you’re not dependent on black-box systems. You’ll catch anomalies early, validate third-party reports, and maintain control over your sender reputation.

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• How to Configure SPF DKIM DMARC for Outlook.com Deliverability
• How TLS Encryption Affects Email Verification and Sender Reputation
• DMARC Reporting Analyzer with Inbox Placement Test
• SMTP Verification and DMARC Alignment for Email Deliverability 2026

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does a DMARC aggregate report tell me?

It shows how many messages were sent from your domain, whether they passed SPF or DKIM checks, and which IPs attempted to send them.

Can I read DMARC reports without third-party tools?

Yes—DMARC reports are plaintext XML. You can open them in any text editor or XML viewer to inspect the data manually.

Why are some DMARC reports marked as failed when I didn’t send those emails?

They are likely spoofing attempts. Failed authentication from unknown IPs indicates unauthorized use of your domain.

How often do DMARC reports arrive?

Typically once a week, though some senders deliver daily reports. The frequency depends on the reporting destination and policy.

Can DMARC reports identify spam traps?

No—DMARC reports only show authentication outcomes. They don't identify if an email address is a spam trap.

Do I need to read every DMARC report by hand?

Not usually. Use manual reading to investigate anomalies or train your team. Most organizations use automation for daily analysis.

How does MailTester help with DMARC data?

MailTester validates sender IPs, checks email lists for risk, and integrates with tools like SendGrid and HubSpot to improve deliverability and detect abuse.

What’s the difference between DMARC aggregate and forensic reports?

Aggregate reports summarize email volume and authentication status. Forensic reports show individual message details, useful for incident response.

Is DMARC effective against phishing?

It reduces the chance of successful phishing using your domain, but does not block all phishing attempts—especially those not using your domain.

How long should I keep DMARC reports?

Store reports for at least 30 days to track trends; retain for six months if investigating a breach or campaign.

Can a DMARC record hurt deliverability?

Only if misconfigured. A p=reject policy applied too early can block legitimate mail if your infrastructure isn’t ready.

Do all email providers send DMARC reports?

Most major providers do, but some do not. You may not receive reports from smaller or less-compliant services.