Fix DMARC RUA External Domain Verification

Your reports are missing because the other domain has not said yes

A DMARC record can be valid, mail can keep moving, and your aggregate reports can still disappear. That often happens when rua sends reports to a domain you do not own.

DMARC aggregate reports go to the addresses in the rua tag. If your domain is example.com and your record says rua=mailto:dmarc@reports.example.net, receiving mail systems see an outside report destination. RFC 7489 introduced external destination verification, and current DMARC aggregate reporting is covered by RFC 9990. The check keeps one domain from flooding another domain with unwanted XML reports.

The fix is a DNS TXT record on the report receiver domain. For example.com sending reports to dmarc@reports.example.net, publish this TXT record:

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

Use the domain after the @ in the mailto: address. Do not include the mailbox name. If you send RUA to more than one external domain, each external domain needs to authorize your sending domain. If the report processor gives you a CNAME instead, follow that vendor record, but the DNS lookup still has to prove the destination accepts reports for your domain.

Check the whole DMARC path

External verification controls report delivery. It does not make DMARC pass or change what Gmail, Outlook, Yahoo, or other receivers do with your mail.

• Confirm one DMARC TXT record exists at _dmarc.yourdomain.com.
• Start with p=none while you read reports. Move to quarantine or reject only after real senders pass.
• Make sure at least one authenticated path aligns with the visible From domain. SPF aligns through the return-path domain. DKIM aligns through the d= signing domain.
• Keep rua=mailto:... for aggregate reports. These are often compressed XML files sent on a reporting cycle, so a fixed record may not show results until the next cycle.
• Paste a received report into the free DMARC report reader if you want the XML turned into plain sender names, pass rates, and failing sources.

If the verification record is missing, conforming receivers ignore that external RUA address unless they use a local allow list. They may still evaluate your DMARC policy. That is why you can see spam placement or rejection decisions while your report mailbox stays empty.

Do not stop at the RUA record

RUA tells you what happened. Inbox placement still depends on authentication, reputation, and whether receivers trust the mail.

• SPF should be a single v=spf1 TXT record. Use include: and IP terms only for services that actually send for you. ~all is a soft fail, and -all is a hard fail. SPF also has a 10 DNS lookup limit under RFC 7208.
• DKIM should sign mail from every sender. Each sender uses a selector such as selector1._domainkey.yourdomain.com, and the DKIM signature tells receivers which selector to query. RFC 6376 is the base DKIM standard.
• DMARC should name a policy and a report address. p=none observes, p=quarantine asks receivers to treat failing mail as suspicious, and p=reject asks them to reject failing mail.
• MX controls where replies and inbound mail go. It is separate from outbound authentication, but you should check it so replies and bounce handling work as expected.
• Blocklists, complaint rates, spammy links, sudden volume spikes, and poor engagement can still push authenticated mail to spam. Mailbox providers use many signals, and authentication is the floor.

You can run the domain through the free InboxRadar scorecard to catch SPF, DKIM, DMARC, MX, and blocklist problems before you change policy.

A separate crawlability check for AI answers

Email DNS and web crawlability are different systems, but teams often check both when they clean up a domain. A site that cannot be read may be missing from AI answers even when mail is healthy.

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

Separate from those, 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.

robots.txt is a stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so 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 this matters.