Blog · Dmarc
How to Actually Use Your DMARC Aggregate and Failure Reports: A Practical Checklist
You set up DMARC monitoring. You published your RUA and RUF endpoints. And then your first report arrives and you see hundreds of failures and you have no idea where to start.
This is the most common situation for admins after their first DMARC setup. The reports are technically correct. The problem is that the reports do not tell you what to do next.
Here is a practical checklist for actually using your DMARC aggregate and failure reports.
What RUA and RUF Reports Are For
RUA (Reporting URI Aggregate) is a daily XML digest from receiving mail servers that processed mail from your domain. Think of it as a summary of everything that tried to send as your domain over the past 24 hours.
RUF (Reporting URI Failure) is forensic data on individual messages that failed DMARC authentication. You get fewer of these because receiving servers are not obligated to send failure reports and most opt not to.
The practical difference: RUA tells you the picture. RUF tells you the details.
Start with RUA for everything routine. Use RUF only when something specific needs investigating.
Check Your Sending Sources First
Open your aggregate report and look at the sending sources listed. These are the IP addresses that sent mail claiming to be from your domain. In aggregate report XML, look for the
Every source should be recognizable or authorized. If you see an IP address you do not know, that is the first thing to investigate.
For each sending source, ask:
- Is this our own mail server?
- Is this a third-party service we actively use (CRM, marketing platform, support tool)?
- Is this something we forgot we were using?
- Is this completely unknown?
Unknown sources are not automatically a problem. A marketing platform you signed up for three years ago and forgot about will show up as an unknown source until you authorize it in your SPF record or set up DKIM for it. But you need to know it is there before you can decide whether it belongs.
Identify the Failure Type Before You Panic
DMARC reports categorize failures. The three most common results you will see are:
None (pass) -- The message passed DMARC. Your domain aligned and authentication passed. This is what you want.
Fail -- The message failed DMARC. The receiving server saw a problem with SPF, DKIM, or the alignment between them and your From domain. At p=none, nothing happens to these messages except that they get logged. At p=quarantine, they may be marked suspicious. At p=reject, they are refused.
PermError / TempError -- A permanent or temporary error in the DMARC record itself. A PermError most commonly happens when you have two DMARC records published at the same time - for example, one at _dmarc.example.com and a conflicting one at example.com. A TempError is usually a DNS lookup failure at the receiving server side and resolves on its own.
When you see a high failure count, start by checking what policy level your record is set to. p=none means you are in monitoring mode. The failures you see are not blocking anything yet. They are data.
Look at the "Why" Before You Try to Fix Anything
In aggregate reports, each failure row includes a breakdown. Look for the specific reason before jumping to solutions.
SPF failures usually mean one of two things: either the sending server is not in your SPF record, or the sending server is in your record but the envelope-from domain does not match your From domain.
DKIM failures usually mean the signing domain in the DKIM signature does not match the domain in your From header. This happens often with third-party senders who sign with their own domain instead of yours.
Both failing at the same time usually points to email forwarding. When a message is forwarded, the forwarding server becomes the new sender. It is not authorized for your domain, so both SPF and DKIM fail. This is normal and expected. It is one of the known limitations of DMARC.
"Local policy" results are not your problem to fix. These indicate the receiving server applied a local policy override, which is outside your control.
What to Act On Immediately
A few specific signals deserve fast action:
Unknown sending sources with high volume. If a large volume of mail is coming from an IP you do not recognize, investigate before it becomes a problem. It might be a forgotten marketing tool. It might be something misconfigured. Either way, you want to know.
A sudden spike in failures from a known legitimate source. If a vendor you trust suddenly starts failing DMARC, something changed on their end. They may have changed their sending infrastructure, let a DKIM key expire, or moved to a new IP range. Reach out to them.
DKIM failures on mail you send yourself. If your own sending systems are showing DKIM failures, your DKIM selector has likely expired or your DKIM DNS record was overwritten. Look for your own sending IP in the
Your own domain appearing as an unauthorized source. This usually means a forwarding chain is active. You may see your own domain listed as a source sending mail that fails DMARC. This typically happens when a recipient's mail system forwards your message to another address and that second hop fails authentication.
What to Track Over Time
Some things do not need immediate action but need to be on your radar:
Your baseline failure rate. When you first start monitoring, establish what "normal" looks like for your domain. Number of messages sent per day, approximate failure percentage, common failure reasons. A spike from your baseline is more useful signal than the absolute failure count.
Third-party senders you have not yet authorized. Your aggregate report will show every service sending on your behalf. Track the ones that are failing so you can bring them into compliance before you move to enforcement. Moving from p=none to p=quarantine while a major sending source is still failing is a good way to break your own email delivery.
Forwarding chains affecting your domain. If forwarding is causing failures, track whether it is happening at volume. Some forwarding is acceptable. Large-scale forwarding from auto-archive rules or mailing list services can generate enough failures to be worth solving.
When to Use RUF (Failure) Reports
Aggregate reports give you counts and sources. Failure reports give you the individual message details.
Use failure reports when:
- A specific user reported not receiving expected mail and you want to check if it failed DMARC
- You want to see the exact DKIM signature and header that failed, including the selector domain
- You are investigating a specific incident rather than doing routine monitoring
- You need to show someone exactly what a failed message looked like
Failure reports are verbose and require parsing. For routine monitoring, aggregate reports are usually enough. Failure reports are for when you need granular detail.
How Automation Changes This Workflow
Manual review of DMARC reports works fine when you have one domain, three sending sources, and low volume. It stops working when you have multiple domains, ten or twenty sending sources (each with their own DKIM keys and SPF configurations), and daily volume that generates hundreds of report rows.
At that scale, parsing aggregate reports manually becomes a full-time task. The XML format is not designed for human reading. Most of what you are looking for in a manual review is pattern recognition: this source is new, this DKIM selector has started failing, this failure rate has tripled since yesterday.
DMARCFlow automates the parsing, grouping, and alerting on report data. It normalizes the data so you see sending sources and failure trends instead of raw XML. You still need to make the decisions, but you stop spending time translating the reports into something readable.
If you are getting DMARC reports for more than a few domains or more than a handful of sending sources, automated monitoring is worth considering. The manual workflow described above is correct. It is just not scalable.
FAQ
How often do I receive DMARC aggregate reports?
Most receiving servers send aggregate reports daily, but there is no standard schedule enforced. Some servers send daily, some weekly, some only when a threshold is reached. If you have p=none set up correctly and have an RUA endpoint published, reports will arrive whenever the receiving server chooses to send them.
What is the difference between RUA and RUF?
RUA is aggregate data: a summary of message counts, sources, and results over a time period. RUF is forensic data: details about individual messages that failed. Most admins use RUA for routine monitoring and only look at RUF when investigating specific incidents.
My DMARC report shows failures but mail is going through. Why?
At p=none, failures are logged but nothing is rejected or quarantined. At p=quarantine, failures may be marked suspicious but still delivered. At p=reject, mail is refused. If you are at p=none or p=quarantine and mail is going through, that is expected behavior.
How do I know if a failure is real or just onboarding noise?
Onboarding noise typically looks like known third-party senders failing DKIM, low-volume failures from legacy internal systems, and forwarding-related failures from message chains. Real misconfigurations look like your own mail server failing DKIM, sudden spikes in failure volume from a known source, or unknown high-volume sources you cannot identify.
What is the fastest way to reduce DMARC failures?
Authorize your third-party senders. Either add their IPs to your SPF record or set up DKIM for them using your domain. Until a sender is authorized, their mail will fail DMARC when sent from your domain.