DMARC rua Mailto Syntax: Valid Examples

The working rua mailto pattern

One missing mailto: can make your DMARC reports disappear. The rua tag tells receivers where to send aggregate DMARC reports, and the address has to be written as a URI.

A basic DMARC record with a valid aggregate report mailbox looks like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The key part is rua=mailto:dmarc-reports@example.com. Use mailto:, then the mailbox that should receive reports. The mailbox can be on your own domain, a subdomain, or a reporting service. A reporting address on another domain needs DNS approval from that domain.

You can list more than one destination by separating the URIs with commas:

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

Keep DMARC tags separated by semicolons. Keep the rua values separated by commas. Do not put a plain address after rua=.

Valid examples and common mistakes

The record lives at _dmarc.yourdomain.com. It is a TXT record. Start with p=none while you learn what is passing, then move toward quarantine or reject after SPF, DKIM, and DMARC alignment are clean.

• Good: v=DMARC1; p=none; rua=mailto:dmarc@example.com
• Good: v=DMARC1; p=quarantine; rua=mailto:reports@example.com
• Good: v=DMARC1; p=reject; rua=mailto:dmarc@example.com!10m if you want to request a maximum report size.
• Bad: rua=dmarc@example.com because it is missing mailto:.
• Bad: rua=mailto:dmarc@example.com mailto:ops@example.com because multiple URIs need commas.
• Bad: publishing two DMARC TXT records at the same host. DMARC expects one policy record.

The optional size limit goes after the mailbox with an exclamation mark, such as !10m. Many domains do not need it. If reports are too large for the mailbox, use a report reader instead of guessing.

If you use a third-party reporting address, the report domain has to authorize it. For example, if example.com sends reports to dmarc@vendor.net, the vendor normally publishes a TXT record at example.com._report._dmarc.vendor.net with v=DMARC1. Without that external reporting check, receivers that enforce RFC 7489 can ignore the destination.

What arrives in the rua mailbox

DMARC aggregate reports are XML files, often compressed and attached to email. They show which sources sent mail for your domain and whether SPF or DKIM aligned with the visible From domain.

They are usually batch reports, not instant alerts. They do not show message bodies. They help you answer practical questions: which sender is real, which sender is failing DKIM, which vendor is using the wrong envelope domain, and whether a stricter DMARC policy would block good mail.

SPF still matters. Your SPF record names the servers allowed to send for the envelope sender domain. SPF evaluation has a 10-DNS-lookup limit, so remove unused includes before adding more. Use ~all while testing if you are not sure every sender is listed. Use -all only when the authorized sender list is tight. DKIM matters too. Each sending service should sign with its selector, and the DKIM signing domain should match the From domain or share its organizational domain under relaxed DMARC alignment.

Inbox placement also depends on MX health, domain reputation, blocklists, complaint rate, content, links, and engagement. Gmail and Outlook do not route mail to the inbox just because DMARC exists. They look for sender behavior that appears wanted and trustworthy. You can run the free InboxRadar domain scorecard to catch obvious SPF, DKIM, DMARC, MX, and blocklist issues before you tighten policy.

AI-search visibility is separate

DMARC protects mail. It does not decide whether AI search engines can read your site. If your sender guide or help center should appear in AI answers, check crawl access too.

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 because they use the normal Search index, and Applebot for Apple Intelligence. Disallowing those in robots.txt removes you from that engine.

Training controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens, not separate crawl user agents.

A robots.txt file is a stated policy, not proof of what happened in your logs. Perplexity-User and Bytespider have been reported to ignore it, so treat log evidence and vendor docs separately. Googlebot documents JavaScript rendering. For the other AI crawlers, client-side-only content is an undocumented risk, so put important text in the first HTML response when you can. The free AI visibility checker can help spot blocked crawlers and thin HTML.

Quick setup checklist

Use this when reports are not showing up or when you are publishing DMARC for the first time.

• Create a real mailbox or reporting address that can receive compressed XML attachments.
• Publish one TXT record at _dmarc.yourdomain.com.
• Use v=DMARC1; p=none; rua=mailto:reports@yourdomain.com as the first safe policy.
• If the mailbox is on another domain, confirm the external report authorization record exists.
• Wait at least a day. Some receivers send aggregate reports daily, and some send none.
• Read the XML before moving from none to quarantine or reject. The free DMARC report reader makes that easier.

For the underlying rules, use the published specs as the source of truth: RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For mailbox-provider expectations, check the current Google and Microsoft sender guidelines before changing a high-volume domain.