KoltrixSending DMARC reports to another domain: the auth record
If your rua address lives on a different domain, receivers check an authorization record first. How the _report._dmarc record works and how to test it.
On this page(11 sections)
You set rua=mailto:[email protected] in your DMARC record, waited a week, and no reports arrived. Your record is valid.
The vendor's domain just never agreed to receive your reports, and receivers checked.
Why receivers ask permission
A DMARC record lets a domain owner tell every receiver on the internet to email a report to an address of their choosing, every day. Without a safeguard, anyone could publish a DMARC record that points at a victim's mailbox and turn large receivers into a reporting flood aimed at someone else.
So the DMARC specifications include an authorization step. When the report destination is in a different domain from the one the policy is for, the receiver first checks whether the destination domain has agreed to accept reports about the policy domain. This is defined in RFC 7489 and carried forward in the updated reporting specification, RFC 9990.
When the check applies
The check happens only when the report address's domain differs from the domain that published the policy, in the sense of organizational domains.
| Policy domain | rua address |
Check needed? |
|---|---|---|
| example.com | [email protected] | No |
| example.com | [email protected] | No (same organizational domain) |
| example.com | [email protected] | Yes |
| shop.example.com | [email protected] | No |
| example.net | [email protected] | Yes |
The last row catches many people out: a company with several domains wants all reports in one mailbox at its main domain. Each additional domain needs authorization from the main one.
The authorization record
The receiver looks for a TXT record at a specially constructed name in the destination domain:
<policy-domain>._report._dmarc.<destination-domain>For a policy at example.com sending reports to [email protected], the receiver queries:
example.com._report._dmarc.dmarc-vendor.exampleIf a TXT record beginning with v=DMARC1 exists there, the destination has agreed. If not, a receiver following the specification drops that destination and sends nothing to it.
The record itself is minimal:
example.com._report._dmarc.dmarc-vendor.example. TXT "v=DMARC1"Who publishes it
The authorization record lives in the destination's DNS, not yours. That has practical consequences:
- If you use a reporting vendor, the vendor publishes the record for your domain. Reputable vendors either publish a wildcard covering all customers or add your domain when you sign up. If reports are not arriving, ask whether they have authorized your specific domain.
- If you consolidate reports for several domains you own, you publish the records yourself in the zone of the receiving domain.
Wildcards
A destination willing to accept reports for any domain can publish a wildcard:
*._report._dmarc.dmarc-vendor.example. TXT "v=DMARC1"DNS wildcards match one or more labels, so this covers single-label and multi-label policy domains alike. Report vendors commonly use this pattern. If you consolidate reports for your own domains, explicit records per domain are tidier and do not invite strangers to send you reports.
Consolidating reports for many domains
Suppose you own example.com, example.net and example-shop.com, and want every report at [email protected].
Each policy points to the shared address:
_dmarc.example.net. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.example-shop.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"And example.com authorizes each one:
example.net._report._dmarc.example.com. TXT "v=DMARC1"
example-shop.com._report._dmarc.example.com. TXT "v=DMARC1"example.com's own policy needs no authorization, since its reports go to its own domain.
Testing the setup
Query the name a receiver would construct:
dig +short TXT example.net._report._dmarc.example.com
# "v=DMARC1"An empty answer means receivers that follow the specification will not send reports to that destination.
Then confirm your policy record parses correctly and the rua address is spelled with the mailto: prefix:
dig +short TXT _dmarc.example.netReports start arriving within a day or two once both sides are correct, though each receiver sends on its own schedule.
Other reasons reports do not arrive
If authorization is in place and reports still do not show up, check:
- Missing
mailto:.[email protected]without the scheme is invalid. - Multiple addresses formatted wrongly. Separate them with commas:
rua=mailto:[email protected],mailto:[email protected]. - Mailbox size limits or filters. Report attachments are compressed, but busy domains generate many of them. Some mail filters quarantine zip attachments by default.
- Low volume. A domain that sends very little mail generates few or no reports.
- Not all receivers report. Plenty of receivers evaluate DMARC without sending aggregate reports.
Failure reports follow the same rule
The ruf tag for failure reports uses the same external authorization mechanism. Given how few receivers send failure reports, and the privacy concerns around them, many organizations do not set ruf at all.
A note on privacy and volume
Pointing reports at a third party means sharing data about your mail flows: the IP addresses that send as your domain, message counts per day, and authentication results. Aggregate reports contain no message content or recipient addresses, but they do reveal which vendors you use and how much mail you send. Before authorizing an outside service, check its data handling terms the same way you would for any processor of operational data.
Volume is the other consideration. A domain sending a modest amount of mail might receive a few dozen reports a day, one per participating receiver. A large sender can receive hundreds. If you send reports to a shared mailbox that people also read, they will quickly bury everything else. A dedicated address, or a mailbox that feeds directly into a parser, keeps reports from becoming noise. Whichever route you choose, make sure someone actually looks at the summarized results on a regular schedule; an authorization record that works perfectly is pointless if the reports it unlocks are never read.
Checklist
- Determine whether each
ruadestination is in a different organizational domain from the policy. - For each external destination, confirm a
v=DMARC1record exists at<policy-domain>._report._dmarc.<destination-domain>. - Ask reporting vendors to authorize your domains if they have not.
- Use explicit per-domain records when consolidating your own domains.
- Include the
mailto:prefix and separate multiple addresses with commas. - Allow compressed attachments through to the report mailbox.
Key takeaways
- Receivers only send reports to an address in another domain if that domain publishes an authorization record.
- The record lives at
<policy-domain>._report._dmarc.<destination-domain>and containsv=DMARC1. - Vendors usually publish it for you; for your own domains, you publish it in the receiving domain's zone.
- Test with
digbefore waiting days for reports that will never come.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
