DMARC RUA Multiple Email Addresses: Correct Syntax

Use one rua tag, with a comma list

One extra semicolon can turn two DMARC inboxes into one silent failure. If you want aggregate reports sent to more than one place, put every destination in the same rua tag.

The correct pattern is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:reports@vendor.example

Each destination is a URI. For email delivery, that means each address starts with mailto:. Separate the URIs with commas. Do not publish a second rua= tag for the second address. DMARC records are tag-value records, and duplicate tags can make the record fail validation or produce inconsistent parsing.

Publish this as a single TXT record at _dmarc.example.com. Keep one DMARC record for the name. Multiple TXT records at the same DMARC name can make policy discovery fail.

Check external report destinations

A report address under your own domain is simple. A report address under another domain needs permission from that domain.

If your domain is example.com and your rua address is mailto:agg@reports.example.net, receivers may look for a confirming TXT record under the report receiver domain. The usual name is example.com._report._dmarc.reports.example.net, with a value like v=DMARC1. Without that check, many receivers will skip the external destination to prevent report abuse.

This matters when you send reports to a DMARC vendor, a security mailbox on a different company domain, or a shared service address. Ask that provider for the exact verification record before you change DNS.

• Use one rua= tag.
• Put every address in that tag, separated by commas.
• Start each address with mailto:.
• Confirm external destination DNS before relying on it.
• Send reports to a mailbox or parser that can handle daily XML files, often compressed.

Make the reports worth reading

RUA reports do not fix delivery by themselves. They tell you which sources are sending as your domain, and whether SPF or DKIM aligned with the visible From domain.

Start with p=none while you map real traffic. Move to p=quarantine or p=reject after the reports show your legitimate mail passing. If you jump to enforcement before the reports are clean, you can block your own mail.

Publish one SPF TXT record at each hostname that sends mail, avoid +all, and usually end with ~all while you monitor or -all when you know every sender. SPF evaluation has a 10 DNS lookup limit under RFC 7208, so long include chains can turn into a permanent error. DKIM needs your provider to sign mail and publish a selector record such as selector._domainkey.example.com. DMARC passes when either SPF or DKIM passes and aligns with the From domain.

Gmail, Outlook, and other mailbox providers also look at reputation, complaint rates, blocklists, message quality, and whether your MX and DNS are sane. Still, broken SPF, missing DKIM, or no DMARC policy is one of the fastest ways to look suspicious. You can check the live records with the free domain scorecard, and you can open raw aggregate files with the DMARC report reader.

If you publish setup docs, keep them crawlable

Teams often publish DMARC setup pages for customers and support staff. If that page should show up in AI answers, treat crawl access as part of the launch check.

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.

robots.txt is a stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so use logs when you need evidence. Only Googlebot documents JavaScript rendering. Client-side-only content may be invisible to other AI crawlers, but that is an undocumented risk, not a proven rule for each bot. If this matters for your help center, test it with the AI visibility checker.

Source checks that keep you out of trouble

When a DNS answer sounds clever, check it against the standards or the mailbox provider rules before you ship it.

Use RFC 7489 for DMARC record syntax and aggregate reporting, RFC 7208 for SPF records and lookup limits, and RFC 6376 for DKIM signatures and selector DNS. For inbox placement rules, read the current Google and Microsoft sender guidelines. For AI crawler controls, use the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl. Related email setup guides live at InboxRadar guides.