Not Receiving DMARC Aggregate Reports? Fix RUA

Start with the quiet failure

A DMARC record can look right in DNS and still bring in no reports. The usual cause is small: one wrong mailto:, a mailbox that rejects XML attachments, or a report address on another domain that has not approved your domain.

The rua= tag tells receivers where to send DMARC aggregate reports if they choose to report. These reports are usually compressed XML files, often sent after a receiver's reporting window closes. They are useful because they show which IPs sent mail using your domain, whether SPF and DKIM passed, whether either result aligned with the visible From domain, and what policy the receiver applied.

If you published rua= and your inbox is empty, do not move straight to p=reject. First prove that reports can be sent, accepted, and parsed. Then use the data to fix real senders before you tighten policy.

Check the RUA tag first

Most missing-report cases start with record syntax. DMARC is strict enough that one bad tag can make the record fail discovery.

• Publish one DMARC TXT record at _dmarc.yourdomain.com. Multiple DMARC records at the same name can break discovery.
• Use one rua= tag. If you need more than one address, put them in the same tag and separate the URIs with commas.
• Start every email destination with mailto:, as in rua=mailto:dmarc@example.com.
• Do not put spaces inside the comma list. Use rua=mailto:a@example.com,mailto:b@example.com.
• Keep the record under normal DNS TXT limits by avoiding long, unused tags. Split TXT strings only if your DNS host requires it, and make sure they join into one DMARC record.

A safe monitoring record looks like this: v=DMARC1; p=none; rua=mailto:dmarc@example.com. p=none asks receivers to evaluate DMARC and send reports, but it does not ask them to quarantine or reject failing mail. Use p=quarantine or p=reject after reports show that normal mail passes aligned SPF or aligned DKIM.

If you want a quick check of SPF, DKIM, DMARC, MX, and common DNS mistakes, run the domain through the free InboxRadar scorecard. It is fastest when you need to know whether the live record is the one you meant to publish.

Make sure the mailbox can receive reports

RUA reports are machine files. A personal inbox, help desk, or security gateway can drop them before you ever see them.

• Use a real mailbox, group, or parser address that accepts mail from outside senders.
• Allow compressed attachments such as ZIP or GZIP when your mail security policy permits it.
• Check spam, quarantine, transport rules, and attachment filters for messages from large receivers.
• Make sure the mailbox has enough storage. Aggregate reports can become noisy on a busy domain.
• Look for reports after the next receiver reporting cycle. Many reports are daily, but exact timing depends on the receiver.

Not every receiver sends aggregate reports, and receivers can use local rules for volume, privacy, rate limits, and abuse protection. Gmail, Microsoft, Yahoo, and other large providers may send reports when they see mail for your domain, but you should not expect every mailbox provider to report every day. No traffic to a reporting provider means no report from that provider.

When a report arrives, open it with a parser instead of reading raw XML by hand. The free DMARC report reader turns the file into sender names, IPs, message counts, SPF results, DKIM selectors, alignment, and policy results.

Authorize external report destinations

If your rua address is on a different domain, the destination domain has to say yes in DNS. Without that approval, conforming receivers can skip that destination to prevent report spam.

Example: your sending domain is example.com, but your DMARC record says rua=mailto:dmarc@reports.example.net. The report destination domain is reports.example.net. That domain needs a TXT record like this:

example.com._report._dmarc.reports.example.net TXT v=DMARC1;

The mailbox name does not appear in that DNS name. Use the domain after the @. If you send reports to two outside domains, each outside domain needs its own authorization. If a vendor gives you a CNAME or a custom host name, follow the vendor's current setup guide, but the purpose is the same: the destination domain must prove it accepts reports for your domain.

The original DMARC rules are in RFC 7489. Use the RFC when a blog post and a vendor dashboard disagree.

Confirm you have mail worth reporting

A working rua tag does not create data by itself. Reports appear when participating receivers see mail that claims to be from your domain.

• Send test mail from each real system: Google Workspace, Microsoft 365, your app server, CRM, help desk, billing tool, and marketing platform.
• Send to mailboxes at providers that commonly send aggregate reports. One test to your own company mailbox may not prove anything.
• Check that SPF authorizes the real sender and stays under the 10 DNS lookup limit from RFC 7208. Long include chains can cause a permanent error.
• Use ~all while you are still auditing senders. Move toward -all only when every real sender is known and included.
• Make sure DKIM signing is turned on for every service. DKIM uses selectors, such as selector1._domainkey.example.com, and the signing domain must align for DMARC to pass through DKIM. The base DKIM standard is RFC 6376.

DMARC passes when SPF passes and aligns with the visible From domain, or DKIM passes and aligns with it. Raw SPF pass alone can still fail DMARC if the envelope sender domain belongs to the vendor and does not align with your From domain. Raw DKIM pass can still fail DMARC if the d= signing domain is the vendor's domain instead of yours.

Do not confuse reports with inbox placement

DMARC reports explain authentication. They do not prove that a message reached the inbox.

Mailbox providers like Gmail and Outlook route mail using many signals: SPF, DKIM, DMARC, domain and IP reputation, complaint rate, bounce rate, message content, user engagement, sending volume changes, blocklists, and their own local policy. MX records are separate. They tell other servers where inbound mail for your domain goes, so bad MX can break replies and bounces, but MX does not make outbound mail pass DMARC.

If your reports start arriving and authentication looks clean, but users still find mail in spam, read the current Google sender guidelines and Microsoft email authentication guidance. For more InboxRadar setup help, see the related guides at InboxRadar guides.

Check AI crawlability separately

Email authentication and website crawlability are different checks, but both can affect whether people find and trust a domain.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews ride the normal Search index, and there is no separate opt-out crawler. Disallowing these in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Check the current crawler docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl before changing production rules.

robots.txt is a stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so server logs prove requests, not intent. Only Googlebot documents JavaScript rendering. If key content exists only after client-side rendering, treat that as an undocumented risk for other AI crawlers. Use the free AI visibility checker when AI answer visibility matters.