DMARC External Report Destinations and the DNS Authorisation Record

DMARC reports are enormously useful, but raw XML aggregate reports arriving in a shared inbox are nearly impossible to read. Most organisations send reports to a dedicated DMARC analytics service or monitoring platform. That usually means the rua address in your DMARC record points at a domain you don't own — and DMARC has a specific rule to prevent abuse of that pattern.

This guide walks through how external report destinations work, the DNS TXT authorisation record you need to add, and the mistakes that stop reports ever reaching your analytics tool.

Why external destinations need authorisation

When a receiving mail server (Google, Microsoft, Yahoo) generates a DMARC aggregate report for yourdomain.com, it looks at the rua= tag in your DMARC record to decide where to send it. If the destination is an address at the same domain — rua=mailto:[email protected] — no extra setup is needed.

But if the destination is a different domain — rua=mailto:[email protected] — the receiver has to check that dmarc-analytics.net has agreed to accept reports about yourdomain.com. Without that check, a bad actor could flood any mailbox on the internet with report traffic by listing it in a DMARC record.

The check is a DNS TXT record published on the destination domain.

The authorisation record format

Suppose your domain is yourdomain.com and you want to send reports to [email protected]. On the dmarc-analytics.net side, a TXT record must exist at:

yourdomain.com._report._dmarc.dmarc-analytics.net

With the value:

v=DMARC1

This tells receivers that dmarc-analytics.net has authorised yourdomain.com to send DMARC reports to its mailboxes.

Most reputable DMARC analytics vendors publish a wildcard authorisation record so you don't have to ask them to add one per customer. The wildcard looks like:

*._report._dmarc.dmarc-analytics.net   TXT   "v=DMARC1"

If your vendor uses a wildcard, you don't need to do anything on their side — just list their address in your rua and ruf tags.

Example DMARC record with an external destination

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

You can verify your published DMARC record with the free DMARC record checker — it will parse the tags and flag common syntax mistakes.

Common setup mistakes

Mixing internal and external destinations

You can send reports to several addresses by separating them with commas:

rua=mailto:[email protected],mailto:[email protected]

This is useful if you want a backup copy in your own mailbox while a vendor parses the XML. Note that every external destination needs its own authorisation record.

Why reports sometimes stop arriving

Even with everything configured correctly, reports can dry up. The usual causes are:

• You changed DNS provider and the DMARC record wasn't migrated
• The destination vendor changed domains or retired an address
• Your domain volume is very low — some receivers only send reports when they see enough traffic
• Your record has a syntax error introduced by a later edit

Run the DMARC record checker monthly to catch drift. For continuous monitoring of authentication and reporting health, deliverabilitychecker.com watches for record changes and report flow.

The ruf forensic tag

The ruf tag is for forensic (failure) reports — sample messages that failed DMARC. Very few receivers send these today for privacy reasons, but the same authorisation rules apply. If you use a ruf destination on an external domain, it needs the same _report._dmarc TXT record.

Building a new DMARC record

If you're starting from scratch or need to change your reporting destinations, dmarccreator.com will walk you through building a valid record with the right tags.