Does the external verification record change my DMARC policy?

No. The report.dmarc record only authorizes report delivery for the named domain. It has no p= tag, changes nothing about how receivers treat your mail, and does not affect SPF, DKIM, or alignment. Publishing it cannot make your enforcement stricter or looser — it only unblocks the reporting channel, so the worst case of getting it wrong is that reports keep failing to arrive, not that legitimate mail gets blocked.

Is the verification record a security risk since it's public?

No. Every DNS record is public, and this one contains only v=DMARC1;. It reveals that a reporting relationship exists between two domains but exposes no mailbox contents, no policy secrets, and nothing an attacker can weaponize. The record's entire purpose is anti-abuse, so publishing it improves your posture rather than weakening it.

What if the external domain never publishes the record?

Receivers that enforce the check will drop reports destined for that address, and you lose the aggregate data that tells you which senders are failing authentication — the visibility that makes a safe move to p=quarantine or p=reject possible. If a third party controls the zone and will not add the record, switch your rua to a domain you can edit, or a subdomain of your own domain, and republish.

Can I automate publishing these records?

Yes. Most DNS providers expose an API, so the verification TXT record can be scripted into a DMARC deployment pipeline the same way you would automate the policy record itself. This is common in MSP workflows where the same reporting domain is authorized across many client zones — the host label changes per client, but the value stays v=DMARC1;.

How is this different from an ordinary DMARC failure in my reports?

Very different. A DMARC failure in a report means a specific message did not pass SPF or DKIM alignment — a sender problem you diagnose by reading the reports. An external verification failure means the reports themselves cannot be delivered because the reporting relationship was never authorized. One is about your mail; the other is about your ability to see data about your mail.

Why am I seeing 'External Verification Failure' in DMARC?

Why am I seeing an ‘External Verification Failure’ in my DMARC reports?

You see an "External verification failure" when the mailbox in your DMARC rua or ruf tag sits on a different organizational domain than the one being reported on, and that external domain has not published the authorization record that lets it receive your reports. The fix is one TXT record in the external domain's DNS: yourdomain.com._report._dmarc.external-domain.com with the value v=DMARC1;. Until that record exists, compliant receivers refuse to send reports to the address, and you lose visibility into how your mail is authenticating.

Four steps to fix a DMARC external verification failure, from finding the external domain to confirming with a checker.

The warning clears once the external report domain publishes its verification TXT record.

What "External verification failure" means

A DMARC record names two reporting addresses. The rua tag collects aggregate reports — daily XML summaries of every source sending as your domain — and the ruf tag collects failure (forensic) samples of individual messages that failed. Both are written as mailto: URIs, for example rua=mailto:reports@reports.example.net.

The trouble starts when the domain after the @ differs from the domain that published the DMARC record. If example.com publishes a policy but points rua at reports@reports.example.net, then reports.example.net is an external destination: it belongs to a different organizational domain and is being asked to receive mail on behalf of example.com. Before a receiver will honor that request, it performs an external destination verification check, defined in RFC 7489 section 7.1 (and carried forward, clarified, into the DMARCbis aggregate-reporting spec RFC 9990). If the check fails, the receiver logs an "external verification failure" and does not deliver the report.

This is why the warning appears even when the rest of your DMARC record is flawless. The policy syntax can be correct, SPF and DKIM can be aligned, and reports still will not arrive — because the authorization step for the reporting path was never completed on the far end.

Why receivers require this check

The check exists to stop a specific abuse. Without it, an attacker could publish a DMARC record on a domain they control and set rua or ruf to point at a victim's mailbox. They would then blast large volumes of mail that fails authentication across many receivers. Each receiver, obediently generating reports, would flood the victim with unsolicited XML — a reflection-style denial-of-service that turns the reporting system itself into the weapon.

External destination verification closes that door. By requiring the receiving domain to explicitly publish a record saying "yes, I agree to accept reports for example.com," DMARC ensures a domain can only be signed up to receive reports by someone who controls its DNS. You cannot volunteer a stranger's inbox to be buried in reports, because you cannot publish DNS records under their domain. The check is a consent handshake between two zones, and the "failure" you see is simply that handshake not yet being completed.

This design has a practical consequence worth internalizing: you can only use report addresses on domains you control. Free-mail services such as Gmail, Outlook.com, or Yahoo cannot be used for rua or ruf, because you cannot add a _report._dmarc record under gmail.com. If you want reports mailed to a person, forward them internally from a mailbox on a domain you own — do not name a free-mail address directly in the record.

How to fix it

Fixing the failure is a matter of publishing one record in the right zone. The confusing part is which zone and which order the labels go in, so get this exactly right.

1. Identify the external domain. Look at your DMARC record and read the domain after the @ in each mailto:. That is the external/receiving domain — the one whose DNS you need to edit. You can inspect your live record with the DMARC checker or a raw DNS lookup.

2. Build the record host. The host name follows a strict pattern: the reported domain first, then the fixed label ._report._dmarc., then the external domain last. To let reports.example.net receive reports about example.com, the host is example.com._report._dmarc.reports.example.net. The reported domain leads; the receiving domain trails. Reversing these two is the single most common mistake and produces a record that does nothing.

3. Set the value. The record is a TXT record with the value v=DMARC1;. Per RFC 9990, the v=DMARC1 tag is mandatory and must appear first; the trailing semicolon is conventional and widely expected, so include it.

Example DNS TXT record that verifies an external domain so it can receive DMARC reports.

Add this record in the external domain's DNS — the domain after the @ in your report address.

4. Publish it in the external domain's zone. This record goes in the DNS of the receiving domain, not the domain being reported on. If a third party — a monitoring provider, an MSP, or a separate reporting subdomain — holds that zone, they publish it; you supply them the exact host and value.

5. Confirm. DNS propagation runs from a few minutes to 48 hours depending on your TTL. Once it resolves, re-run a checker to confirm the record is visible and reports will flow. The Email Security Score surfaces DMARC alongside SPF, DKIM, and BIMI so you can confirm the whole authentication picture in one pass.

Common variations

Subdomains. If you report on a subdomain — say mail.example.com — the verification host uses that full subdomain as the leading label: mail.example.com._report._dmarc.reports.example.net. The reported name is whatever domain published the DMARC record, exactly as written.

Multiple report addresses on the same domain. You do not need a separate verification record per mailbox. A single example.com._report._dmarc.reports.example.net TXT record authorizes any rua or ruf address at reports.example.net to receive reports for example.com. The record authorizes the domain-to-domain relationship, not the individual inbox.

Multiple external domains. If your rua list names two different receiving domains, each needs its own verification record in its own zone. One record per external domain, per reported domain.

Wildcard authorization. RFC 7489 lets the receiving domain publish a wildcard host, ._report._dmarc.reports.example.net with value v=DMARC1;, to authorize reports for every* domain that points at it — useful for a provider or MSP collecting reports across many client domains without maintaining a record per client. Receiver support for the wildcard form is not universal, so per-domain records remain the safest default when a specific client's reports must not be missed.