DMARC external report destinations (authorize third-party RUA/RUF)

dmarctutorial

Sometimes DMARC reports need to go somewhere other than the domain in the From address. That is common when reports are collected by a shared mailbox, a central security team, or an external processor such as DMARCPal that receives and organizes reports. DMARC allows that, but only after the destination domain explicitly authorizes it. This is the step most often skipped when reports never arrive.

Why authorization is required

Without a safety check, anyone could publish rua=mailto:reports@example.org and force an unrelated domain to receive huge volumes of DMARC mail. So the standard adds a simple proof-of-control step: the destination domain publishes a DNS record that says "yes, I accept reports for that source domain."

The exact DNS record you need

Assume the DMARC record is on example.com and the reports should go to agg@example.net. That is an external destination because the mailbox domain is example.net, not example.com (this is the same pattern used when sending reports to a DMARC processor like DMARCPal).

Add this TXT record under the destination domain:

example.com._report._dmarc.example.net.  IN TXT  "v=DMARC1"

Two small details that matter:

  • The left side starts with the reporting domain (example.com), not the mailbox domain.
  • The record lives under the destination domain (example.net).

That one TXT record authorizes example.net to receive DMARC reports for example.com. If reports should also be sent for example.org, it needs its own authorization record under the same destination domain.

If ruf is involved

ruf (forensic/failure reports) follows the same external authorization rule as rua.

DMARCPal focuses on aggregate rua reporting and intentionally does not process ruf to keep setups simple and preserve privacy. ruf is rarely used in practice, so most domains never need it.

Common reasons reports never show up

  • The authorization TXT record is missing or placed under the wrong domain.
  • The reporting domain in the authorization record does not exactly match the From domain (subdomains count).
  • The rua address uses a subdomain like reports.example.net, but the authorization record is published under example.net instead of under reports.example.net.
  • Expecting instant results. Some mailbox providers send aggregate reports once per day or less.

If there is uncertainty, a quick DNS check helps. For the example above, look up the TXT record at example.com._report._dmarc.example.net and confirm it returns v=DMARC1. Most external report processors, including DMARCPal, expect this record before reports will flow.

Example DMARC record with external rua

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:agg@example.net; adkim=r; aspf=r"

Once the authorization record exists, receivers are allowed to send to that rua address.

Extra references from mailbox providers

If it helps to review what comes inside aggregate reports, the walkthrough DMARC reporting 101: how to read aggregate XML reports and take action provides a practical view.

Previous Post