Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports have everything you need to know about who’s sending email as your domain and whether they’re passing authentication.
The only problem is that they arrive as raw XML files that no human wants to read.
This DMARC analyzer parses your DMARC XML reports into a clear, readable format so you can see which senders are passing, which are failing, and where to focus your attention. Paste or upload your report below.
What is a DMARC analyzer?
A DMARC analyzer parses the raw XML aggregate reports that receiving mail servers send to the address specified in your DMARC record’s rua= tag. Every time someone sends an email using your domain, the receiving server evaluates it against your Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records, checks alignment, and logs the result.
Those results get bundled into XML reports and sent back to you, sometimes dozens or hundreds per day, depending on your email volume. The data is all there:
- Which IPs were sent as your domain
- IPs that passed or failed
- What policy was applied
However, it’s buried inside nested XML that isn’t designed for human eyes. A DMARC analyzer translates that data into something you can work with.
How to read DMARC reports
DMARC aggregate reports follow a standard XML schema, but you don’t need to memorize it. Here’s what matters when you’re reviewing your results:
- Source IP / sending service: The IP address (or service name, if your analyzer maps it) that sent email using your domain. This tells you who is sending as you.
- SPF result and alignment: Whether the sending server’s IP was authorized in your SPF record, and whether the SPF-authenticated domain matches your “From” address. A pass with alignment means the sender is properly configured. A pass without alignment means SPF technically passed, but DMARC will still count it as a failure.
- DKIM result and alignment: Whether the email carried a valid DKIM signature, and whether the signing domain matches your “From” address. Same logic as SPF: passing DKIM without alignment doesn’t satisfy DMARC.
- Policy applied: What the receiving server did with the message based on your DMARC policy (none, quarantine, or reject).
- Message count: How many messages matched this specific combination of source, SPF result, and DKIM result during the reporting period.
It’s also worth knowing the difference between the two types of DMARC reports:
- Aggregate reports (sent to your rua= address) summarize authentication results across all messages over a reporting period, usually 24 hours.
- Forensic reports (sent to your ruf= address) provide details on individual messages that failed DMARC.
Most organizations rely primarily on aggregate reports since not all mailbox providers send forensic data.
What to look for in your DMARC report results
Raw data is only useful if you know what it’s telling you. Here are the scenarios you’ll tend to see in your reports and what each one means:
- Recognized senders passing SPF and DKIM with alignment. This is the ideal result. Your legitimate sending services are properly configured, and their email is authenticating correctly. No action needed.
- Recognized senders failing alignment. You know the service, but SPF or DKIM isn’t aligning with your “From” domain. This is a configuration issue (not an attack). It usually means the service needs its SPF include updated or its DKIM signing domain adjusted. Fix the configuration, and the failures go away. Done.
- Unknown IPs sending as your domain. If you don’t recognize the source and it’s failing authentication, this could be an unauthorized sender or someone attempting to spoof your domain. At p=none, these messages are still being delivered. At p=reject, they’re blocked.
- High volumes of unauthorized email. A spike in unrecognized, failing senders suggests your domain is being actively targeted for spoofing. This is exactly why DMARC enforcement matters. Without a quarantine or reject policy, those messages reach your recipients unchallenged.
- Services you forgot about. DMARC reports have a way of surfacing sending services that nobody on your team remembers setting up. Old marketing platforms, legacy ticketing systems, and test environments. These are shadow IT in action, and they need to be either authorized or shut down.
Why raw XML reports aren’t good enough
For a single domain sending a few hundred messages a day, manually reviewing XML might be manageable (if tedious). But most organizations outgrow that fast.
- Volume: Large organizations receive hundreds of aggregate reports per day across multiple domains. Manually parsing each one isn’t realistic.
- Format: DMARC XML is structured for machines. Nested tags, IP addresses without context, and no visual hierarchy make it difficult to scan for the information that matters.
- Context: An IP address alone doesn’t tell you which sending service it belongs to. Without a reference database mapping IPs to services, you’re stuck running manual lookups for every source in every report. Woof.
This is where ongoing monitoring matters. Sure, a one-time report check is useful for a snapshot, but email authentication isn’t static. New senders get added, configurations change, and threats emerge continuously.
Go from analysis to enforcement
Analyzing a DMARC report tells you what’s happening right now. Still, it’s just a report. Now, you need the action — that’s what actually protects your domain.
Valimail Monitor gives you continuous, real-time visibility into all the sending activity across your domains, for free. Instead of manually uploading and parsing XML files, Monitor automatically processes your DMARC reports, identifies sending services by name (not just IP address), and shows you exactly where you’re passing and failing authentication.
When you’re ready to move beyond visibility, Valimail Enforce automates the path to DMARC enforcement. It handles sender authorization, SPF and DKIM configuration, and policy management so you can reach p=reject faster and with fewer resources than doing it manually.
The analyzer on this page gives you a starting point. Monitor and Enforce give you the full picture.
Frequently asked questions
What is a DMARC analyzer?
A DMARC analyzer is a solution that parses raw DMARC XML reports into a readable format. It shows you which senders are passing or failing email authentication on your domain so you can identify misconfigurations, unauthorized senders, and spoofing attempts.
How do I read DMARC reports?
DMARC reports arrive as XML files from receiving mail servers. An analyzer converts them into structured data showing each sending source, its SPF and DKIM results, alignment status, and the policy applied. Focus on senders that are failing alignment or that you don’t recognize.
Are free DMARC analyzers enough?
For one-time checks or occasional spot reviews, a free analyzer works fine. For ongoing monitoring across multiple domains (especially if you’re working toward DMARC enforcement), you’ll want a solution that processes reports continuously and identifies senders by name. Valimail Monitor does this for free.
What’s the difference between aggregate and forensic DMARC reports?
Aggregate reports (rua) summarize authentication results for all messages sent using your domain over a reporting period, typically 24 hours. Most organizations rely on aggregate reports since forensic report support varies by mailbox provider.
