22 June 2026 · 5 min read
If your DMARC record sends reports to an address on a different domain, that domain has to publish a TXT record agreeing to receive them, or receivers will not send the reports. For rua=mailto:reports@vendor.example in the record for example.com, the receiving domain publishes:
example.com._report._dmarc.vendor.example. TXT "v=DMARC1;"This is external destination verification. It is now defined in section 4 of RFC 9990, the DMARC aggregate reporting standard published in May 2026, which replaced the equivalent section of RFC 7489. When reports never arrive at a third-party or second-domain address, a missing or misnamed authorisation record is one of the first things to check.
Why it exists
Without a check, anyone could publish a DMARC record on their own domains pointing rua= at your mailbox, and receivers worldwide would send you their reports. The authorisation record stops that: a destination only receives reports for domains it has agreed to accept.
When a destination counts as external
RFC 9990 treats a report address as external when the organisational domain of the domain that published the DMARC record differs from the organisational domain of the host in the rua address.
| DMARC record for | Report address | External? |
|---|---|---|
example.com | dmarc@example.com | No |
example.com | dmarc@reports.example.com | No: same organisational domain |
example.com | dmarc@example.net | Yes, even though you own both |
example.com | reports@vendor.example | Yes |
Under RFC 9989, receivers find the organisational domain with a DNS tree walk over DMARC records rather than the Public Suffix List; for ordinary domains, the answer is the registered domain, as in the table.
The authorisation record
- Name:
<policy domain>._report._dmarc.<destination host>. The policy domain, the one publishing the DMARC record, comes first. The destination host, taken from theruaaddress, comes last. - Where: in the destination's DNS zone, not yours.
- Value: a TXT record starting
v=DMARC1. The trailing semicolon is optional.
Microsoft's DMARC documentation shows the same pattern: for contoso.com sending reports to fabrikam.com, the record is contoso.com._report._dmarc.fabrikam.com with v=DMARC1;.
Wildcard. A destination that accepts reports for any domain can publish one record instead of one per customer:
*._report._dmarc.vendor.example. TXT "v=DMARC1;"This is why most reporting services work without you doing anything on their side.
Redirecting. The authorisation record may contain its own rua tag to replace the original address, but only with an address on the same destination host. If it points elsewhere, receivers must not send to either address.
Who publishes what
| Record | Where | Who publishes it |
|---|---|---|
Your DMARC policy with rua= | _dmarc.example.com | You |
| The authorisation | example.com._report._dmarc.<destination> | Whoever runs the destination domain |
- A reporting service: the service publishes the authorisation, usually as a wildcard. You only edit your own DMARC record.
- Your own second domain: you run both zones, so you publish both records. Nobody else will notice the second one is missing.
- A parent company or partner: they must publish the authorisation in their zone, naming your domain. You cannot do it for them.
Example: several domains reporting to one collection domain
_dmarc.acme.example. TXT "v=DMARC1; p=quarantine; rua=mailto:agg@acme-reports.example"
acme.example._report._dmarc.acme-reports.example. TXT "v=DMARC1;"
acme-uk.example._report._dmarc.acme-reports.example. TXT "v=DMARC1;"
acme-shop.example._report._dmarc.acme-reports.example. TXT "v=DMARC1;"One authorisation per reporting domain, or a single wildcard if the collection domain should accept reports from any domain. If only some of your domains are authorised, only those domains' reports arrive.
Mistakes that stop reports arriving
- The name the wrong way round. It is
<your domain>._report._dmarc.<destination>, published on the destination's zone.vendor.example._report._dmarc.example.comin your own zone does nothing. - Wrong labels. It is
_report._dmarc: not_reports, not_dmarc._report. Some DNS panels handle leading underscores badly, so check the published name with a lookup. - A missing or wrong value. The TXT value must start with
v=DMARC1. An empty record does not count. - A doubled zone name. Panels that append the zone can produce
example.com._report._dmarc.vendor.example.vendor.example. Enter only the part before the zone if your panel appends it. - Partial coverage. Five domains reporting to one destination need five records, or a wildcard.
- Negative caching. Resolvers that already cached "no such record" keep that answer until it expires, so give a new record time.
Checking it
Query the constructed name directly:
dig +short TXT example.com._report._dmarc.vendor.exampleYou want a single string starting v=DMARC1. No answer means receivers following RFC 9990 will ignore that report address. If the destination uses a wildcard, querying your exact name still returns it.
Then check that aggregate reports arrive from several large receivers, not just one. The DMARC checker shows your published record and its report addresses, and the DMARC generator builds a correctly formatted rua tag.
Why it matters for enforcement
Moving from p=none to p=quarantine and p=reject depends on seeing every legitimate sender in your reports. If some receivers are not sending reports because the authorisation is missing, you are tightening policy with part of the picture missing. Fix reporting first. Fixing multiple DMARC records covers a related cause of reports drying up, and DMARC analytics receives reports at an address that is already authorised, so this record is never your problem.