How to Read DMARC Aggregate Reports (RUA) in 2026
Learn exactly how to read DMARC aggregate reports (RUA) — decode XML structure, identify threats, and improve deliverability. No jargon, just clarity.
Why Are DMARC Aggregate Reports (RUA) Essential for Email Deliverability?
You’re sending emails. Your domain is protected. So why are some messages still landing in spam, or worse—why are impostors using your name to send phishing emails?
DMARC aggregate reports (RUA) are the only way to see the full picture of how your domain is being used across the global email ecosystem. They don’t just confirm if your emails are authenticated—they reveal what’s happening outside your control.
Without digging into these reports, you’re flying blind. Unauthorized senders, misconfigured systems, and fraud attempts go undetected, eroding sender reputation over time. RUA reports provide monthly summaries of email traffic: which IPs sent mail, whether SPF or DKIM passed, and where problems occur—critical for diagnosing why your messages don’t reach inboxes.
Key takeaways
- DMARC aggregate reports (RUA) reveal unauthorized use of your domain before it damages sender reputation.
- These reports show source IPs, authentication results (SPF/DKIM), and failure patterns—essential for fixing inbox placement issues.
- Failing to analyze RUA reports means missing early warnings of phishing, spoofing, or technical misconfigurations.
What Is a DMARC Aggregate Report (RUA) and What Does It Contain?
DMARC aggregate reports (RUA) are monthly XML files sent by receiving mail servers to your designated email address, detailing authenticated and unauthenticated email activity targeting your domain. They include data on source IPs, authentication status (SPF/DKIM pass/fail), message volume, and policy violations—helping you spot spoofing attempts and improve email deliverability. You can find the full specification in RFC 7483, the official standard for DMARC reporting.
What's Inside a Typical RUA Report
Each report starts with metadata like(your domain),(the reporting period), and(policy settings). This gives you a snapshot of your domain's email traffic across all mail providers that support DMARC.
The core of the report is thesection, which aggregates data per source IP address. For each IP, you'll see how many messages were sent, whether SPF and DKIM passed or failed, and whether the sending server aligned with your domain’s policy (none, quarantine, or reject).
These reports include all messages—legitimate, forged, or misrouted—so you can identify unauthorized senders. For example, if a message claims to come from your domain but fails SPF and DKIM, it's likely spoofed. Theelement will show this clearly, with counts per authentication result.
DMARC doesn't report individual messages. It summarizes activity in large blocks, which is why you see volume totals rather than a full message log. This keeps the reports compact and manageable, especially for large senders.
Understanding this data helps you audit your email ecosystem. If you see consistent DKIM failures from a new sender, it may mean they’re misconfigured. High SPF failures from an unexpected IP could signal phishing or compromised accounts.
Let’s say you notice a spike in unauthorized emails from a known IP that doesn’t belong to your tech stack. That’s a red flag. Use that insight to tighten policies or block the source—especially if you’re running strict DMARC policies. Thesection’sfield is your primary tool for attribution.
You can also spot legitimate senders misconfiguring their setup. For example, if your marketing platform sends from a third-party server without proper alignment, you’ll see SPF pass but DKIM fail. That signals a need to either fix alignment or update your published policy.
Aggregated reports don’t tell you what specific messages failed, just how many did. To get that granularity, you’d need a DMARC forensic report (RUF), which we won’t cover here. But even without it, aggregate data gives you strong visibility into your domain’s email posture.
The structure is standardized—defined in RFC 7483—and accepted across major email providers. You can parse these reports programmatically or use third-party tools for visualization. If you’re verifying sender reputations or cleaning invalid emails, you may find tools like the bulk email list cleaning feature helpful to reduce the attack surface of your domain’s sending infrastructure.
How to Read the XML Structure of a DMARC RUA Report?
DMARC RUA reports are XML files sent by receiving mail servers to let you know which emails passed or failed authentication. You start by parsing theroot, then inspectfor timing,for your domain’s policy (none, quarantine, reject), and eachfor individual source IPs, counts, andfrom SPF and DKIM. Look atandto pinpoint why a message failed—SPF alignment, DKIM signature, or domain mismatch. Use a plain-text XML viewer to avoid parsing errors.
Step-by-step: Reading the XML Layers
- Locate theroot. This is the top-level container for all data. Every RUA report begins here. It wraps metadata, policies, and individual findings.
- Checkfor timing. It includes,, and. Theandtimestamps show the reporting window—use this to align with your sending volume and detect spikes.
- Examineto see your public DMARC policy. It tells you if your domain usesand(alignment mode), and what enforcement is set: none, quarantine, or reject. This is the rule your domain claims to enforce.
- Iterate through eachentry. Each represents one source IP address from a sender. It contains,(how many messages were sent), andshowing SPF and DKIM outcomes.
- Inspectfor SPF and DKIM. Values likeandwill show pass/fail. Adoesn’t mean the mail went to inbox—only that the technical check passed.
- Look atandto diagnose. Ifsays “spf_fail” or “dkim_fail,” you know the block. Ifis “none,” emails aren’t blocked—use that to verify if your policy is actually enforced.
- Use a plain-text XML viewer or parser. Never edit raw XML by hand. Malformed structures cause parsing errors. Tools like RFC 7483 define the format—stick to standards-compliant parsers.
Why This Matters for Deliverability
Seeingasbutassuggests your SPF record is misconfigured or your sending IP isn’t listed. Misaligned domains (e.g., sending from mail.example.com but SPF validating against example.com) trigger alignment failures. Even if the sending IP is correct, poor email branding or spoofing attempts can show up in RUA data.
You can’t fix what you can’t see. RUA reports give you visibility into unauthorized senders and technical flaws. They’re not real-time, but they offer a retrospective view of authentication performance. Combine them with inbox placement testing tools to get the full picture.
For teams managing large lists, automated parsing via API is essential. Email List Validation’s real-time verification API and bulk verification can proactively remove invalid addresses before they trigger false alarms in DMARC reports. This reduces false failures and improves sender reputation.
What Do SPF, DKIM, and Alignment Results Mean in a DMARC RUA Report?
SPF, DKIM, and alignment results in a DMARC RUA report tell you whether incoming emails claiming to come from your domain are genuinely authorized. SPF checks if the sending IP is in your SPF record. DKIM verifies the email’s cryptographic signature. Alignment confirms the From domain matches the one used in SPF or DKIM. A single 'fail' doesn’t always mean trouble—it’s when multiple sources fail that you should investigate further.
SPF: Is the Sending IP Authorized?
SPF results show whether the sender’s IP address is listed in your domain’s SPF record. A 'pass' means the IP is authorized. A 'fail' means it’s not listed—or you’ve misconfigured the record. This doesn’t mean the email is spam, but it does flag non-compliance. If you see consistent SPF fails from a known sender (like your ESP), recheck your SPF record for outdated or missing entries. SPF is part of a larger defense, not a standalone gatekeeper.
DKIM and Alignment: Trusting the Signature and the Sender’s Identity
DKIM results indicate whether the email’s cryptographic signature is valid. 'Pass' means the signature checks out with your public key. 'Fail' means either the key doesn’t match, the signature was tampered with, or there was a technical error. DKIM doesn’t validate the sender's identity—it just proves authenticity. That’s where alignment comes in.
Alignment checks if the domain in the From header matches the domain used in either SPF or DKIM. If both SPF and DKIM pass but the alignment fails, the DMARC policy will reject the message—even if it's technically valid. This is a common issue when sending from a subdomain (e.g., [email protected]) with a DKIM key tied to the root domain (yourcompany.com).
When you see multiple failures across SPF, DKIM, or alignment, especially from different sources, you’re likely dealing with compromised or misconfigured senders. Use inbox placement tests to see how your emails perform in real inboxes. You can also clean your list with bulk verification to ensure sender reputation isn’t harmed by invalid or spoofed domains.
For deeper insight, refer to the DMARC specification at RFC 7483, which defines the format and meaning of RUA reports. It’s the foundation for how these metrics are interpreted across the industry.
How to Identify Unauthorized Senders and Potential Spoofing in RUA Reports?
You can spot unauthorized senders and potential spoofing in DMARC aggregate reports (RUA) by scanning for high-volume sources with SPF and DKIM failures. Focus on IPs or domains not part of your approved email infrastructure. Reports from major providers like Gmail or Outlook showing high failure rates are red flags. Correlate these findings with sender reputation data to confirm malicious intent. Tools like bulk email list validation can help clean sender data to reduce spoofing exposure.
Key Signals to Monitor in RUA Reports
- Look for sources with a highvalue butset to "fail" andset to "fail". These are strong indicators that an email claiming to be from your domain is not authorized.
- Check theorfields. Any IP or domain not in your official email infrastructure—such as known marketing tools, internal servers, or partner systems—should raise suspicion.
- Pay special attention to reports from large email providers like Gmail, Outlook, or Yahoo. High failure rates from these sources suggest a possible spoofing campaign impersonating your domain at scale.
- Correlate RUA findings with email delivery logs and sender reputation tools. A consistent pattern of failed authentication from unknown sources, combined with poor deliverability or blocklistings, confirms malicious activity.
How to Act on These Findings
- Use the real-time email verification API to test if addresses from suspicious sources are valid and active.
- Check if the reported domains or IPs are associated with known phishing, spam, or malicious infrastructure using public threat intelligence sources such as Spamhaus or MXToolbox.
- If you identify a consistent source, update your DMARC policy (e.g., set p=quarantine or p=reject) to block unauthorized senders, but only after confirming patterns and reducing false positives.
- For ongoing monitoring, automate RUA report parsing to detect anomalies early. Some tools integrate with DMARC feed processors, but manual review remains essential for accuracy.
The most effective DMARC enforcement starts with understanding the traffic your domain receives—both legitimate and malicious.
Why Correlation Matters
Seeing a failed SPF/DKIM match in a RUA report isn't enough on its own. You need context: Is this from a known partner? A misconfigured old system? Or a new phishing attempt? Cross-reference with your own email logs, domain registration records, and third-party reputation databases. The goal isn't just to detect failure—it’s to understand intent.
Regular RUA review—especially when combined with inbox placement testing—helps you stay ahead of spoofing attempts before they damage your deliverability or brand. It’s a proactive step in email security, not just compliance.
How to Filter and Prioritize RUA Reports — What to Focus On?
Focus first on reports from Google and Microsoft — their volumes dominate, and their inbox placement decisions affect the vast majority of your recipients. Look forentries where both SPF and DKIM fail; this is a clear signal of spoofing attempts or misconfiguration. Track repeated source IPs with consistent failures — these are often compromised systems or bots. Ignore reports with 'none' in policy enforcement; they come from senders not actively protecting their domains. This filtering keeps your effort focused on real risks.
What to Prioritize in RUA Reports
- Filter for reports from Google and Microsoft — they process the largest mail volumes, so failures here reflect real-world delivery issues.
- Focus onentries where both SPF and DKIM show 'fail' — this combination strongly indicates unauthorized sending attempts or domain misconfiguration.
- Track source IPs with consistent failure patterns across multiple reports — these are likely compromised systems, bots, or scanning tools, not legitimate senders.
- Exclude reports where the policy is 'none' — these come from domains not enforcing DMARC and don’t indicate a breach or vulnerability.
- Use timestamps to identify new or recurring issues — a sudden spike in failures from a known IP should be investigated immediately.
- Check the DMARC specification (RFC 7483) to confirm how policy actions like 'quarantine' or 'reject' are defined and applied.
What to Ignore (and Why)
- Reports with 'none' in policy — they don’t enforce DMARC, so their results don’t reflect actual enforcement or security posture.
- Single, isolated failures from low-volume senders — unless they originate from a known compromised IP, they’re unlikely to impact your domain’s reputation.
- Reports with no valid source IP or malformed headers — these often reflect spam scanning tools or poorly configured mailers with no real sender identity.
- Failures with mixed outcomes (SPF pass, DKIM fail) — these may be due to poor implementation, not spoofing, and require separate analysis.
Let’s be clear: not all RUA data is equal. You're not looking for noise — you're looking for signals that could harm your domain reputation or lead to inbox filtration. The goal isn’t to catch every failed email, but to catch the ones that matter: high-volume, high-impact failures that point to real threats or configuration leaks. Tools like bulk email list cleaning help you manage sender-side hygiene, especially if you’re sending to lists that may include outdated or spoofed addresses.
Common Pitfalls When Reading DMARC Aggregate Reports (and How to Avoid Them)
DMARC aggregate reports aren’t just about counting failures — they’re about understanding patterns. You’ll waste time chasing false alarms if you assume every failure is malicious. Forwarding services, shared IPs, and misaligned DKIM selectors can all trigger legitimate failures. Focus on sustained trends, not isolated incidents, and check alignment even when SPF or DKIM pass. A single failure rarely signals a breach — high-volume or repeated issues are the real red flags.
Don’t Assume All Failures Are Malicious
Not every DMARC failure means someone’s impersonating you. Services like Gmail, Yahoo, and Outlook forward emails through their own systems, which can break SPF or DKIM alignment. Misconfigured DKIM selectors — often due to outdated keys or incorrect domain setup — can also cause pass-through failures. These are common, not malicious. Check if the source is a known forwarder or a legitimate email service provider before acting. You’d be surprised how often a “fail” is just a technical quirk, not a threat.
Treat All Reports with Equal Attention — Even Low-Volume Ones
Ignoring reports from low-volume senders can leave you blind to early signs of impersonation. Fraudsters often start small — one or two messages from a spoofed domain — and scale up only after testing success. These early warnings appear in aggregate reports even if they’re rare. A single source sending a few hundred messages a day with alignment failures might be a precursor to a larger attack. Monitor all reports, not just the big ones.
Alignment failures are easy to miss — they happen even when SPF or DKIM pass. For example, a legitimate email passing SPF but with a DKIM signature from a different domain will still fail DMARC. This is why the DMARC specification requires both SPF and DKIM to be aligned with the domain in the From header. Ignoring alignment turns your DMARC policy into a weak deterrent. Use the bulk email list cleaning tool to audit your senders and ensure all domains in your email ecosystem are properly aligned.
Finally, don’t panic over a single failure. DMARC is about volume and consistency. A few isolated failures across thousands of messages won’t disrupt your deliverability. But if the same domain or IP shows repeated failures over days, that’s a warning sign. Use the inbox placement test to validate your email’s position in real mailboxes and verify that your DMARC enforcement is working as intended without blocking real senders.
How Does Email List Validation Help Improve DMARC Reporting Accuracy?
DMARC aggregate reports rely on accurate data about incoming mail to detect spoofing and track sender compliance. When your email list includes invalid, disposable, or role addresses, those bounces and deliveries mislead the reports, inflating false positives. Email List Validation removes these unreliable addresses before sending, ensuring only deliverable, legitimate emails are used — which leads to cleaner, more trustworthy DMARC reports. This directly improves your domain’s reputation and the validity of the data your DMARC policy sees.
Reducing Noise in DMARC Reports
Role accounts (like admin@, sales@), disposable domains, and catch-all addresses often don’t respond to mail or are prone to failure. When you send to them, your messages generate bounces or soft failures, which show up in DMARC aggregate reports as potential alignment issues — even though they’re not real delivery problems. Let’s be clear: these aren’t spoofing attempts. They’re noise. Email List Validation filters them out before you send, so your DMARC reports reflect real, on-target delivery patterns rather than artifacts of a dirty list. The result? More accurate insights into actual spoofing attempts and genuine alignment issues.
Strengthening Sender Reputation Through List Quality
DMARC is not just about policy enforcement — it’s about trust. Receiving servers evaluate your domain’s reputation based on sending behavior over time. If your messages consistently go to invalid addresses or are rejected due to poor list hygiene, the servers infer you’re not a reliable sender. Email List Validation’s 98.9% accuracy ensures you’re only sending to real, active addresses. This leads to better engagement, fewer bounces, and fewer spam complaints — all factors that boost sender reputation. And as your reputation improves, receiving servers treat your messages with greater trust, which improves your DMARC results over time.
For example, RFC 7483 — which defines DMARC — notes that accurate reporting depends on valid, consistent sending patterns. If your sending list is cluttered with disposable or role addresses, that pattern becomes inconsistent. Tools like Email List Validation help you align with industry standards by maintaining clean, deliverable lists. This isn’t just operational hygiene — it’s structural support for strong DMARC enforcement.
Check your list before you send. You’ll get tighter DMARC reports, fewer false alarms, and stronger domain trust. You can start with 100 free verifications at Email List Validation’s bulk verification tool.
Why Integrate DMARC Monitoring with Email List Validation?
You can use DMARC aggregate reports (RUA) not just to detect spoofing, but to uncover poor list hygiene. When those reports show a spike in alignment failures or rejected messages, correlating them with email list validation reveals whether invalid or outdated addresses are causing deliverability issues. Linking RUA data to real-time verification tools turns passive signals into actionable fixes.
Spotting Invalid Addresses at Scale
DMARC aggregate reports show how many messages fail alignment, but not why. If your RUA logs show consistent failures from known domains, run those addresses through email list validation to see how many are outright invalid or dormant. You’re not seeing just "bounces"—you’re seeing evidence that old or poorly maintained lists are undermining your sender reputation.
Let’s say your RUA shows 300 daily failures on a list you send to via a third-party service. Feed that list into the bulk verification tool. If 25% are marked as "invalid" or "catch-all," you’ve found the root: your source list is stale. Cleaning it up reduces alignment failures and supports your DMARC policy enforcement.
Creating a Feedback Loop for Better Deliverability
When you integrate RUA reports with deliverability testing, you can isolate whether failures stem from content, volume, or address quality. For example, a spike in alignment failures during a high-volume campaign might look like a content or sending volume issue—but cross-referencing with the real-time verification API can confirm if the sender IP is being blocked due to a high ratio of invalid addresses.
This creates a closed loop: better list hygiene → fewer reject messages → fewer false positives in DMARC reports → more accurate alignment data. Over time, this improves your domain’s reputation with receiving providers. According to the DMARC.org guidance, consistent alignment and reduced delivery errors are key to building trust with major email providers.
Use your inbox placement reports to test how cleaned lists perform. If your deliverability rate improves after validation, you’ve proven that the integration works—not just in theory, but in actual inbox placement. The same logic applies to role accounts and disposable domains, which DMARC doesn’t flag but validation tools do. Catching those early prevents them from skewing your RUA data.
A Step-by-Step Guide to Analyzing Your First DMARC Aggregate Report
You’ll receive your first DMARC aggregate report (RUA) at the email address you specified in your DMARC record—typically [email protected]. The report is an XML file sent daily or weekly, depending on your policy. Open it, examine theandsections to confirm your policy settings and date range. Then scan theentries with 'fail' and highto find sources of failed authentication, especially from unfamiliar IPs. Over time, track repeated failures to spot long-term issues. If you’re seeing consistent SPF or DKIM failures, update your SPF record or audit third-party services to prevent ongoing deliverability risks.
- Check your inbox for the first RUA report sent to your designated address, like [email protected] reports arrive automatically once your policy is published. The frequency depends on yourpolicy: daily or weekly.
- Download the XML file and use a free tool like XML Validator to parse it, or use Python’s built-in XML parser for deeper inspection.Most tools can read XML without formatting issues, but ensure your parser handles nested elements likeandcorrectly.
- Examine thesection to confirm the date range and identifying details like the reporting domain and IP address of the sender.This ensures you’re reviewing the correct report for your domain and timeframe.
- Inspect theblock to verify your current DMARC policy (p=none, p=quarantine, p=reject) and alignment mode (adkim, aspf).If you’ve changed your policy, check if the report reflects the new setting—this confirms your DNS configuration is active.
- Scan theentries with highvalues and 'fail' in either SPF or DKIM.High counts with failures indicate repeated issues with authentication from specific sources. Focus on unfamiliar or unknown IPs.
- Look for consistent failures across multiple reports to identify long-term or recurring issues.Recurring failures from the same source suggest a misconfigured sender, an impersonation attempt, or an outdated third-party integration.
- If you find unauthorized senders or consistent SPF/DKIM failures, investigate the source—update your SPF record or review third-party email providers.For example, if your marketing platform sends from an IP not listed in SPF, add it to prevent future failures. This improves mailbox provider trust.
Identify the Source of Failures
When you see a high count with 'fail' from a certain IP, check if it belongs to a service you use—like a newsletter provider, CRM, or helpdesk tool. If not, it may be spoofing. Refer to RFC 7483 for technical details on DMARC reporting formats and structure.
Take Action to Improve Delivery
DMARC is only effective when you act on findings. A misconfigured sender can hurt your sender reputation. Use bulk email list validation to ensure your outbound sends are clean and compliant. For ongoing delivery health, test inbox placement with inbox placement testing.
Conclusion: Turn DMARC Aggregate Reports Into Actionable Deliverability Insights
DMARC aggregate reports (RUA) are not mere logs — they reveal patterns in authentication failures, identify unauthorized senders, and expose issues that erode sender reputation. Without context, failure counts can mislead. True insight comes from tracking trends, understanding message volume shifts, and correlating data across domains and sending sources.
What to Look For in RUA Reports
- Consistent SPF or DKIM failures point to misconfigured senders or compromised systems.
- Sudden spikes in unauthenticated reports may signal phishing attempts or credential theft.
- High volumes from unknown IPs or unexpected geographies often indicate abuse or spoofing.
When paired with proactive list hygiene — such as validating email addresses before sending — RUA data becomes part of a closed-loop system. You detect threats, fix misconfigurations, and reduce the risk of being flagged as spam. Over time, this improves inbox placement and strengthens domain trust.
Keep reading
- Email authentication and encryption: SPF, DKIM, DMARC, TLS (complete guide)
- TLS-RPT Reports: How to Read Them in 2026
- MTA-STS Policy Modes Testing vs Enforce: What You Need to Know
- DMARC p=none to quarantine to reject rollout plan 2026
- Email Authentication Settings for Better Apple Mail Inbox Placement
Ready to put this into practice? Email List Validation verifies emails with 98.9% accuracy — start with 100 free verifications.
Frequently asked questions
What does a DMARC aggregate report (RUA) tell me about my email traffic?
It shows how many emails were sent from your domain, from which IPs, and whether they passed SPF, DKIM, or alignment checks. It highlights unauthorized senders and authentication issues.
How often do DMARC aggregate reports (RUA) come in?
They are sent monthly by receiving mail servers, typically within the first few days of each new calendar month.
Can I read DMARC aggregate reports without coding skills?
Yes — use free online XML viewers or tools like https://www.xmlvalidator.org. You don’t need to write code, just understand the key fields.
What does a 'fail' in both SPF and DKIM mean in a DMARC report?
It means the email was neither authenticated via SPF nor through DKIM, indicating a potential spoofing attempt or misconfigured sending system.
Do DMARC aggregate reports reveal the contents of emails?
No — they only report metadata like source IPs, authentication results, and counts. Message content, subject lines, or recipients are never shared.
How can I automate reading DMARC reports?
Use a parsing script or integrate with a reporting tool that extracts and analyzes fields like source IP, count, and auth results automatically.
Why do some DMARC reports show 'none' for policy?
It means the sender’s domain doesn’t enforce DMARC, so their reports don’t include policy evaluation. These are often from low-volume or unsecured senders.
Is Email List Validation required to improve DMARC performance?
No — but it helps. Validating your lists reduces the number of invalid or risky addresses, which improves sender reputation and reduces the chance of DMARC failures.
What should I do if my RUA reports show many failures from a known service?
Verify the service is authorized. If not, disable it. If it is, ensure its IPs are in your SPF record and its DKIM signing is properly configured.
Can DMARC reports help prevent email spoofing?
Yes — by showing unauthorized sending sources, they enable detection of impersonation attempts and help enforce DMARC policies.
How long should I keep DMARC aggregate reports?
Store them for at least 12 months. They provide historical context for identifying trends, detecting breaches, and auditing compliance.
Are there tools that parse DMARC RUA reports automatically?
Yes — tools like MxToolbox, DMARC Analyzer, and Email List Validation can parse, visualize, and alert on RUA data to simplify analysis.