When your DMARC record sends reports to an address on another organization’s domain, that domain has to say it accepts them, with a TXT record at yourdomain._report._dmarc.theirdomain. Without it, receivers that follow the standard don’t send the reports. Check every rua and ruf address of your domain below and see exactly which record is missing.
Last verified 1 October 2026.
DMARC checkers report this as “DMARC external validation”, “external destination verification failed”, “external verification failure” or “rua address not authorized”. They all mean the same thing: a reporting address in your DMARC record is on a domain outside your organization, and that domain doesn’t publish a record authorizing reports for your domain.
The check exists so nobody can aim a flood of reports at a stranger’s mailbox by writing it into their own DMARC record. Before a receiver sends a report to an address on another organization’s domain, it looks up a TXT record built from both domains:
@ in the address, for example rua.vendor.example in mailto:abc@rua.vendor.example._report._dmarc in front of it, then the domain the DMARC record was found on: example.com._report._dmarc.rua.vendor.example.v=DMARC1 authorizes the reports. If there is none, the address isn’t authorized and no reports are sent to it.RFC 9990, the DMARC aggregate reporting standard published in May 2026, makes this check a requirement: when the address’s Organizational Domain isn’t identical to yours, “the following verification steps MUST be taken” (§4). The original specification, RFC 7489 (§7.1), described the same steps as ones “to be taken”, without a MUST, and allowed receivers to use a local list of permitted destinations instead. RFC 9991 §5 applies the same check to ruf (failure report) addresses.
Your email still gets delivered. This affects only where DMARC reports go. Your p= policy is applied the same way. What you lose is the reports themselves, and with them the view of every service that sends as your domain.
Sources: RFC 9990 §4 (Verifying External Destinations); RFC 9991 §5; RFC 7489 §7.1; RFC 9989 §4.10 (Organizational Domain) (checked 1 October 2026).
Enter the domain in your From: address. The lookups run in your browser against public DNS: your DMARC record, the Organizational Domain of each reporting address, and the authorization record for each one on another organization’s domain, the same steps a receiver takes.
What this can and can’t tell you: it reads DNS right now, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails), and finds each Organizational Domain with RFC 9989’s DNS tree walk. Receivers that still follow RFC 7489 use a public suffix list for that step, which gives the same answer for almost every domain. It can’t tell you whether a particular receiver performs the check, or whether a mailbox accepts the reports once they are sent. It checks up to ten reporting hosts.
The authorization record lives on the domain that receives the reports, not on yours. Who can add it depends on whose address it is.
Reporting services publish the authorization for their customers, usually as one wildcard record that covers every domain (*._report._dmarc.their-host). If it’s missing for your domain:
For example, a group of brands that sends every brand’s reports to dmarc@parent-company.example. Add a TXT record in the receiving domain’s DNS:
| Type | TXT |
|---|---|
| Name | example.com._report._dmarc (in the zone of parent-company.example) |
| Value | v=DMARC1 |
Most DNS hosts want the name relative to the zone, so you type example.com._report._dmarc and they add .parent-company.example. Typing the full name often doubles the domain. To accept reports for every domain you own with one record, use *._report._dmarc instead; that accepts reports for any domain, which is what reporting services do, so only use it if you’re fine with that.
The domain that goes in front of _report._dmarc is the one your DMARC record is published on. For a subdomain without its own record (it uses the parent’s), that is the parent domain, and the checker above shows the exact name.
You can’t add DNS records to gmail.com or outlook.com, and their owners don’t publish authorizations for your domain. Point rua at an address on your own domain (for example dmarc@yourdomain.com, which needs no authorization) or at a reporting service. Aggregate reports are XML files, so a reporting service or a parser makes them readable.
Run the checker above once the record is published. From a terminal you can also query the name directly:
dig +short TXT example.com._report._dmarc.rua.vendor.exampleYou want a line starting "v=DMARC1. On Windows, use nslookup -type=TXT with the same name. Reports start arriving with each receiver’s next reporting period.
Only addresses on another organization’s domain are checked. An address on your own domain, or on a subdomain of it, needs nothing: rua=mailto:dmarc@example.com in the record for example.com or news.example.com is fine as it is. “Organization” here means the Organizational Domain: usually the registered domain, such as example.com or example.co.uk. Two different registered domains, even if you own both, count as two organizations.
Only mailto: addresses are checked: they are the reporting addresses receivers are required to support (RFC 9989 §4.7).
Reports only help if the rest of your DMARC setup is right. Grade the whole domain with the free DMARC, SPF and DKIM checker. If a checker also reports more than one DMARC record, fix that first: see multiple DMARC records found, since receivers ignore every record (and its rua) when there are two.
_report._dmarc record on my own domain?No. The record goes on the domain that receives the reports, the one after the @ in the rua or ruf address. If example.com sends reports to reports@vendor.example, vendor.example publishes example.com._report._dmarc.vendor.example. Adding it to your own zone does nothing.
No. External destination verification only decides whether receivers send DMARC reports to that address. Your p= policy is applied the same either way. What you lose is visibility: no aggregate reports from receivers that verify, so you can’t see who sends as your domain.
Yes. A TXT record at *._report._dmarc.vendor.example containing v=DMARC1 authorizes reports for any domain. RFC 7489 and RFC 9990 both describe this wildcard, and reporting services commonly publish it.
ruf address need the same authorization?Yes. RFC 9991 §5 requires receivers that send failure reports to run the same verification for ruf addresses on another domain.
Not reliably. The address is on another organization’s domain, so it needs an authorization record on gmail.com or outlook.com, and you can’t add records there. Use an address on your own domain or a DMARC reporting service that publishes the authorization.