DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

DMARC Monitoring: What to Actually Do With Your Reports

By DMARCGuardian Editorial Team ·

The Problem With DMARC Reports

You enabled DMARC. You are getting reports. They arrive as XML attachments with names like dmarc_20240901000000.xml, and when you open them, you see rows of cryptic failure data. So you close the file and move on.

This is the most common pattern with DMARC monitoring. Organizations set it up, get reports, and then do nothing with them. The data sits there, unused.

The problem is not that DMARC reports are useless. The problem is that most admins do not know how to read them or what to do with the results.

This guide fixes that. By the end, you will know what your DMARC reports actually say, which failures matter, and how to act on the data.

Why DMARC Reports Exist

DMARC exists to solve an email problem: anyone can send mail pretending to be your domain. SPF and DKIM help, but they do not tell you what is happening. DMARC reports close that gap.

When you publish a DMARC record with a reporting address, receiving servers send you reports. These reports tell you:

  • Which servers are sending mail on your behalf
  • Which messages passed or failed authentication
  • Whether your policy is being enforced

Without these reports, you are flying blind. You do not know if your email is being spoofed. You do not know if your SPF or DKIM setup is working correctly. You do not know if legitimate mail is being blocked.

Understanding Your DMARC Report

DMARC reports come in two types, and knowing the difference matters.

RUA (Aggregate Reports)

RUA reports are the main reports you receive. They are sent daily and give you a summary of all mail flowing through servers that receive mail from your domain.

An RUA report contains:
  • The sending server IP
  • The count of messages
  • The SPF result (pass or fail)
  • The DKIM result (pass or fail)
  • The DMARC result (pass or fail)
  • The reason for any failure if available

Think of RUA as your daily overview. It tells you the volume and the aggregate result, not the details of each message.

RUF (Failure Reports)

RUF reports are real-time forensic reports. They are sent for individual messages that failed DMARC. They contain much more detail, including headers from specific messages.

RUF reports are useful for investigating specific problems, but they generate a lot of data. Most organizations start with RUA only and add RUF later if needed.

Reading the Report: What Normal Looks Like

Here is a practical framework for reading DMARC reports.

First, look at your volume baseline. How many messages are your receiving servers seeing per day? If you send 1000 emails a day and your reports show 1000 messages, that is normal. If your reports show 10,000 messages when you only send 1000, that is worth investigating.

Second, look at the SPF and DKIM pass rates. A healthy domain typically has SPF passing for 80-95% of messages and DKIM passing for 90-99% of messages. These ranges vary based on your email setup.

Third, look at DMARC alignment. This is where SPF or DKIM pass but DMARC still fails. This happens when the organizational domain in the From header does not match the domain in the SPF or DKIM signature. A small percentage of alignment failures is normal due to forwarding. Large percentages indicate configuration problems.

When Failures Are Real Problems

Not every DMARC failure means something is wrong. Here is how to separate real problems from noise.

SPF Alignment Failures

SPF checks which server is allowed to send mail for your domain. A DKIM alignment failure means the DKIM signature domain does not match the From header domain. Both are common with forwarded mail. When a message is forwarded, the intermediate server sends it onward, and the SPF or DKIM check fails because the server is not authorized.

Forwarding-related failures typically show up as small percentages. If you see 100% DKIM failures, something is broken.

DKIM Alignment Failures

DKIM attaches a cryptographic signature to your messages. A DKIM alignment failure means the signature domain does not match the From header domain. This often happens when using third-party email services that sign on your behalf but use their own domain in the signature.

If you use a marketing automation platform, a support ticketing system, or any service that sends email on your behalf, you may see DKIM alignment failures. The fix is usually to configure that service to use your domain in the DKIM signature.

Policy Violations

A policy violation is when a message fails DMARC because it is not authorized. This is the case DMARC is designed to catch. If you see a high volume of policy violations and the sending IPs are not yours, someone is spoofing your domain.

Policy violations from unknown IPs are the cases that matter most. These represent attempted or successful spoofing of your domain.

A Simple Decision Framework

When you get a DMARC report, work through these questions in order:

1. Is the sending IP mine?
- Yes: Continue to step 2
- No: Continue to step 3

2. Is the failure rate normal for my setup?
- Yes: No action needed
- No: Investigate configuration changes, new services, or forwarding rules

3. Is this a known sender (legitimate service using my domain)?
- Yes: Update your authentication to include them
- No: Investigate potential spoofing

This framework catches 90% of what you will see in DMARC reports. The most common outcome is "yes" to "is the sending IP mine" and "yes" to "is the failure rate normal." Those are the reports you file away and check periodically.

What to Do When You Find Problems

If your investigation reveals a problem, here is what to do.

For SPF issues, check your SPF record. Make sure all authorized sending servers are included. Common culprits are:
  • Marketing automation platforms
  • Support ticketing systems
  • Legacy internal mail servers
  • Cloud services you added without updating SPF

For DKIM issues, check which service is sending the failing mail. If it is a service you control, ensure DKIM is configured with your domain. If it is a third party, either configure them to send with your domain or add their IPs to your SPF record.

For spoofing, if you see unknown IPs sending mail that looks like it is from your domain, that is spoofing. The volume tells you the scale. A few messages is noise. Thousands of messages is a problem. Report spoofing to the abusedepartments of the sending domains where possible.

Automating DMARC Monitoring

The framework above works, but doing it manually is tedious. DMARC reports arrive daily, and reading them manually does not scale.

This is where dedicated tools help. DMARCFlow aggregates your DMARC reports into a dashboard that shows you trends over time, highlights anomalies, and alerts you when something needs attention. The alternative is spending hours manually parsing XML files that most email tools export in different formats.

The key metric to automate is your pass rate trend. If your SPF pass rate drops from 90% to 70% over a week, that is worth investigating. If it stays at 70% consistently, that may be your new baseline.

Automation does not replace understanding. You still need to know what the numbers mean. But once you understand the framework, automation lets you monitor at scale without drowning in data.

FAQ

How often should I check DMARC reports?
Weekly at minimum during initial setup. Monthly is enough once you have a stable baseline. If you are making changes to your email infrastructure, check daily during the transition period.

What is a normal DMARC failure rate?
It depends on your email mix. For a typical company using only internal mail servers, SPF should pass 95%+ and DKIM should pass 98%+. If you use many third-party services, your failure rates may be higher. Track your baseline and watch for sudden changes rather than aiming for a specific number.

Should I panic when I see DMARC failures?
No. Some failures are normal, especially with forwarding and third-party services. Use the decision framework above. Failures from your own IPs that are consistent over time are usually fine. Sudden changes or failures from unknown IPs are worth investigating.

Can I automate DMARC monitoring?
Yes. Use a DMARC reporting tool that aggregates reports and sends alerts for anomalies. Manual monitoring works for initial setup but becomes impractical at scale.

The Bottom Line

DMARC reports tell you what is happening with email sent using your domain. Most admins ignore them because they do not know how to read them. That is a mistake.

The good news is the reading is not hard. Check your volume baseline, watch your pass rates, and investigate sudden changes. The decision framework above handles the vast majority of what you will see.

If you want help with the automation side, DMARCFlow monitors your DMARC reports continuously and alerts you when something needs attention. It turns the daily XML dump into actionable summaries.

Start reading your reports. Even 10 minutes a week is better than nothing. The threats you catch early are the ones you can actually fix.