Reading DMARC reports: Common mistakes to avoid at all costs

Your email authentication setup is only as strong as your understanding of what’s happening behind the scenes. Once you have implemented the authentication protocols, including SPF, DKIM, and DMARC, your work does not stop there. In fact, that’s just the start.

In the same vein, when you implement DMARC, it’s not a ‘set it and forget it’ kind of thing. Apart from enforcing a policy that will define what happens to the emails that fail authentication, DMARC also sends regular reports that tell you about what’s going on with your domain, what emails are being sent on your behalf, and whether they’re passing or failing the checks you’ve set up. 

Clearly, DMARC reports are an essential aspect of your email security setup, so you must know how to analyze them properly. After all, these reports are of no good unless you know how to read them, understand what they’re telling you, and take action based on those insights. Without that, you’re basically collecting data that sits unused while threats continue to fly under the radar.

Let’s discuss some of the common mistakes that you should avoid while evaluating DMARC reports.

What are DMARC reports?

DMARC reports are diagnostic reports that you get from mail servers about emails sent using your domain. When you set up DMARC, any server that receives your domain’s emails checks if the message passed SPF and DKIM, and then sends you a report with the results. 

These reports tell you who is sending emails using your domain; whether it’s one of your own services, a third-party tool, or someone trying to fake your domain. If you don’t check these reports, you won’t really know if your email setup is working properly or if someone is misusing your domain without your knowledge.

There are two kinds of DMARC reports:

Aggregate reports (“rua”)

These reports give you a broad overview of your domain’s activity. They tell you how many emails passed or failed DMARC, where those emails came from, and whether they aligned with your SPF and DKIM settings. Aggregate reports don’t delve into individual emails but give you a summary of overall email activity so that you can identify any unusual patterns of misuse, unexpected senders, or authentication failures.

Forensic reports (“ruf”)

You also get forensic or failure reports as part of DMARC reporting. Although they aren’t as common as “rua” reports, they provide more detailed information when an individual email fails DMARC checks. They are far more detailed than their aggregate counterparts and focus on specific failure events rather than overall trends. Forensic reports typically include the email headers, the results of SPF and DKIM checks, and sometimes a portion of the email content itself. 

You need this kind of in-depth report when you want to investigate specific incidents, like when you suspect someone is trying to spoof your domain or when a legitimate service is repeatedly failing authentication.

What are the common mistakes to avoid while evaluating DMARC reports?

If you don’t know how to analyze and leverage your DMARC reports properly, you won’t be able to fine-tune your authentication setup, thereby leaving your email ecosystem at risk.

So, here’s what not to do when reading your DMARC reports:

Not reading the reports when the DMARC policy is at p=none

This is one of the most common mistakes that many organizations make is that they think DMARC reports aren’t necessary when you’re operating under a p=none policy. But that’s exactly when the reports are most valuable.

Since at p=none, you are not actively blocking or rejecting unauthenticated emails, your only defense strategy is to keep track of who is sending emails on your behalf and whether they are passing the necessary authentication checks. This helps you spot any unauthorized senders or misconfigured systems before you tighten your DMARC policy to “quarantine” or “reject”.

Focusing only on pass/fail outcomes

While it’s easy to think that your emails will either pass or fail authentication, that approach misses important context. You also need to look at the alignment of SPF and DKIM, the sending sources, and whether these align with your authorized infrastructure. Just because an email passed DMARC doesn’t mean both SPF and DKIM passed. Remember, you only need one of them to align for DMARC to pass.

Not paying attention to unrecognized sources

If you come across an address or IP that you don’t recognize, don’t just let it slide. This could be an early sign of domain abuse or misconfiguration. Sometimes, it might just be a legitimate service you forgot to authorize, but other times, it could be a spoofing attempt or even shadow IT. 

So, it’s best that you thoroughly go through all your sending sources in your DMARC reports and update your SPF and DKIM records to include any legitimate services that are missing.

Relying only on raw XML reports

Unfortunately, DMARC reports don’t come as comprehensive Excel sheets or graphs. They come in XML format, which is hard to read directly. So, if you go on to decode these raw files, you might miss out on important insights. It is recommended that you use a DMARC analysis tool to translate reports into readable, actionable dashboards.

Ignoring subdomains

If you send emails from your subdomain as well, they are just as important as your primary domain when it comes to DMARC monitoring. If you don’t keep an eye on your subdomains in the DMARC reports, you might miss signs of someone trying to send fake emails using them. It’s important to either apply DMARC to your subdomains or at least monitor them separately, so nothing slips through unnoticed.

The whole point of these reports is that you act on the insights that they provide. Simply reviewing them won’t help unless you take action by fixing misconfigurations, authorizing legitimate services, or blocking suspicious sources.

If you don’t know where to start or how to interpret your DMARC, we’re here to help! Contact us today to get started.