Why Your DMARC Reports Stop Arriving

You set up a DMARC record. You added the RUA reporting address. You waited. Nothing arrived.

This is one of the most common DMARC complaints, and it has a predictable set of causes. The good news: every one of them is fixable once you know where to look.

The core issue is that DMARC aggregate reports are sent as email messages with XML attachments. They travel from the receiving mail server (Google, Microsoft, FastMail, whoever processed your mail) back to whatever address you specified in your rua= tag. If that address is hard to reach, incorrectly formatted, or gets filtered, the reports disappear silently.

Here is the full breakdown.

The Most Common Causes of Missing DMARC Reports

Your RUA endpoint is not reachable from the public internet

The single most common reason reports never arrive: your RUA endpoint is not accepting connections from external mail servers.

This happens most often with organizations that set up a dedicated DMARC reporting address like dmarc-reports@yourdomain.com on Microsoft 365 or Google Workspace. Those platforms accept messages from authenticated internal users, but many third-party DMARC aggregators send reports from mail servers that do not authenticate to your tenant. The message arrives and gets rejected or silently dropped.

To test this: send a plain text email with a small XML attachment from a personal Gmail or ProtonMail account to your RUA address. If it does not arrive, your aggregator's reports will not arrive either.

Your DMARC record has a syntax error or wrong domain in the rua tag

The DMARC record at _dmarc.yourdomain.com must follow a precise format. The most common mistakes:

Typo in the tag name: ru i= instead of rua=
Missing underscore: dmarc.yourdomain.com instead of _dmarc.yourdomain.com
Pointing the RUA address to a domain that is not the same as the sending domain or a subdomain of it

A correct record looks like this:


v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

The rua= tag tells receivers where to send aggregate reports. If the target address is not reachable or incorrectly formatted, reports are lost.

Use a DMARC lookup tool to verify your record is published and correctly formatted before assuming the problem is elsewhere.

Your SMTP server is blocking or filtering incoming report delivery

DMARC aggregate reports are delivered as email messages with XML file attachments. If your incoming mail server has strict spam filtering, attachment blocking, or XML file restrictions, those messages may be intercepted before they reach your inbox.

Common causes:

Your spam filter flags XML attachments as potentially malicious

Your email security stack (Microsoft 365 ATP, Google Workspace, third-party SEG) marks the message as suspicious and quarantines it silently

Size limits on your receiving server reject reports from high-volume senders

Check your spam folder and quarantine logs first. If you find XML messages from Google, Microsoft, or FastMail marked as spam, adjust your filter rules to allow them.

Your reporting service endpoint has TLS or authentication issues

If you are using a third-party DMARC reporting service that provides a custom endpoint URL rather than a direct email address, the problem may be on their side:

The service does not support TLS on their report submission endpoint
Their sending infrastructure fails DMARC checks, meaning they cannot deliver reports about your domain because their own mail is not authenticated properly

This second case is more common than expected. Some aggregators send reports from addresses that fail DKIM or SPF checks for the domain they are reporting on. When that happens, the receiving mail server may treat their report delivery as a spoofing attempt.

Reports are still within the normal delivery window

DMARC reports are not real-time. The specification requires receivers to send aggregate reports at least once per day, but many large receivers (Google, Yahoo, Microsoft) batch their reports and send them on a schedule that can stretch to 24-48 hours after legitimate email volume passes through their systems.

If you have not yet sent enough real email volume through your domain, receivers may not generate reports for you yet. New domains or low-volume senders can wait a week or more before receiving their first aggregate report.

Expected windows:

Small volume senders: 24-72 hours after first significant email volume

High-volume senders: reports typically start arriving within 24 hours

Some aggregators batch weekly in addition to daily

This is the most benign cause and the one most often overlooked by frustrated admins.

How to Check If Your RUA Endpoint Is Reachable

Before troubleshooting your DMARC record, verify that your RUA endpoint can actually receive email from the outside world:

1. Send a test email from a personal Gmail or ProtonMail account to your RUA address with any text in the body
2. If it does not arrive within a few minutes, check your spam folder and quarantine
3. If it still does not arrive, the endpoint is not reachable from external senders and your DMARC reports will not arrive either

The fix depends on your setup. For Microsoft 365, you may need to allow anonymous relay or create a dedicated mailbox that accepts external mail. For Google Workspace, check that the receiving address does not require sender authentication. For third-party aggregators, verify their sending infrastructure passes basic email authentication checks.

What a Correct DMARC RUA Record Looks Like

A working DMARC record with RUA reporting has at minimum:


v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

If you are using a reporting service:


v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com,https://dmarcflow.example.com/reports/yourdomain

The rua= tag accepts multiple addresses separated by commas. Each one must be reachable.

Common mistakes to avoid:

Using ruf= instead of rua= if you only want aggregate reports (ruf is for forensic reports)

Pointing rua= to an address at a different domain that does not have its own DMARC record

Forgetting the mailto: prefix on email-based RUA addresses

How DMARC Report Timing Works

Aggregate reports are not sent immediately after an email is processed. They are compiled and batched by the receiver, then delivered to your RUA address on a schedule determined by the receiver's own infrastructure.

Key facts about report timing:

Most receivers send aggregate reports once per day at minimum

Google and Microsoft batch reports and may delay delivery beyond 24 hours for lower-volume senders

High-volume senders (thousands of messages per day) typically receive reports faster

Some receivers send reports only when they have something worth reporting, so silent days are normal

If you recently published your DMARC record, give it 48-72 hours before concluding something is broken. If reports arrive and then stop, check your mail server logs and DNS records first.

Using a DMARC Monitoring Tool to Bypass SMTP Delivery Problems Entirely

If you have spent more than 15 minutes troubleshooting RUA delivery, consider using a purpose-built DMARC monitoring service that receives and parses your reports automatically.

The core problem with SMTP-based RUA delivery is that it depends on your receiving mail server working correctly. DMARC monitoring services like DMARCFlow provide a stable aggregation endpoint that is designed specifically to receive reports and present them in a structured dashboard. The reports still come via email, but the endpoint is maintained by a service that understands DMARC format and can parse the XML reliably.

When DMARCFlow is worth considering:

You have tried the troubleshooting steps above and reports still are not arriving

You want someone else to handle the parsing and make the data actionable

Your internal team does not have time to manually review raw XML aggregate reports

You need forensic reports (failure samples) in addition to aggregate data, which requires a dedicated endpoint

DMARCFlow receives your reports via its aggregation endpoint and presents the data in a dashboard that shows authentication trends, failure rates, and domain usage over time. This is more reliable than checking a shared mailbox manually, and it removes the dependency on your internal mail server accepting XML attachments.

If you want to verify your DMARC setup is working correctly right now, DMARCFlow offers a free DMARC lookup tool that checks your record syntax and reports what receivers see.

FAQ

How often should I receive DMARC aggregate reports?
Most DMARC aggregators send reports daily, but the actual frequency depends on your email volume and the receiver's own batching schedule. Some large receivers send reports every few days rather than daily. If you send low volumes, you may receive reports less frequently.

Can I use a free email provider address for RUA reports?
Yes, in principle. The mailto: syntax works with any valid email address. In practice, free email providers often have strict attachment policies that may interfere with XML delivery. Using a dedicated address at your own domain gives you more control over filtering and access.

My hosting provider blocks port 25. Does that affect RUA delivery?
Port 25 is used for server-to-server SMTP delivery, which is how receivers send reports to your RUA address. If your host blocks incoming port 25, you cannot receive direct SMTP deliveries. Most DMARC monitoring services work around this by providing a reporting address that accepts submissions on standard authenticated SMTP ports (587 or 465) rather than relying on unauthenticated port 25 delivery.

Reports arrive sometimes but not every day. Is that normal?
Yes, occasional gaps in the 24-48 hour range are normal, especially with large receivers like Google and Microsoft that batch reports. If gaps extend beyond a week or reports stop arriving entirely after previously working, check your mail server logs, update your spam filter rules, and verify your DMARC record has not changed.