DMARC external destination verification

30 May 2026 · 13 min read

You published a DMARC record, pointed the rua and ruf tags at a reporting address, and the reports never arrived. Or worse, they arrived for the first month and then a receiver quietly stopped sending them. In a large share of these cases the cause is not a broken record at all. It is a missing piece of DNS configuration on the receiving side of the report, a small TXT record that the standard requires before a mail server is allowed to send your reports to an address outside your own domain. The standard calls this external destination verification, and almost nobody sets it up until something breaks.

This article is specifically about that mechanism: what it is, why RFC 7489 made it mandatory, exactly which DNS record to publish, where to publish it, what it must contain, and the long list of subtle ways people get it wrong. It is not a general "what is DMARC" piece. If you want the wider context, the RFC 7489 walkthrough reads the whole specification, and the DMARC glossary entry covers the basics. Here we stay on one clause and its consequences.

The problem the mechanism solves

A DMARC record lives at _dmarc.example.com and tells the world where to send reports. The two report destinations are set by the rua tag (aggregate reports) and the ruf tag (failure, sometimes called forensic, reports). A typical record looks like this:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1"

Here both report addresses are at example.com, the same domain the DMARC record is published for. That is the simple case, and it needs no extra configuration. The receiver sees that the report address belongs to the same domain that published the policy and assumes, reasonably, that the domain owner is happy to receive reports there.

Now consider the far more common real-world case. You use a monitoring service, a managed DMARC provider, or simply a separate operations domain to collect reports. Your record points somewhere else:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:reports@dmarc-vendor.net; ruf=mailto:reports@dmarc-vendor.net; fo=1"

Now the report address is at dmarc-vendor.net, a domain that has nothing obviously to do with example.com. This is an external destination: the domain in the mailto: URI differs from the Organizational Domain of the domain that published the DMARC record.

Think about what that opens up if there were no checks. Anyone could publish a DMARC record on their own domain pointing the rua at your address. Every receiver on the internet that processed mail from the attacker's domain would then dutifully email aggregate reports, potentially large XML attachments, to you. Multiply that across thousands of attacker domains and you have a reflection and amplification attack: a way to drown a victim's inbox in unsolicited report traffic, with the world's mail servers acting as the unwitting amplifiers. The volume can be substantial, because aggregate reports are generated by every receiver that handles the mail, once per reporting interval.

DMARC's authors saw this coming. Section 7.1 of RFC 7489 ("Verifying External Destinations") requires that before a Mail Receiver sends a report to an address outside the Organizational Domain of the policy record, it must confirm that the destination domain has consented to receive those reports. The consent is expressed as a DNS record that the destination domain publishes. No consent record, no reports. That is external destination verification.

What counts as "external"

The test is not "is the report address on a different hostname". It is "is the report address in a different Organizational Domain". The Organizational Domain is computed using the Public Suffix List, the same way DMARC computes alignment, not by counting dots. This distinction matters and trips people up constantly.

• rua=mailto:dmarc@example.com published in _dmarc.example.com is not external. Same domain.
• rua=mailto:dmarc@reports.example.com published in _dmarc.example.com is not external. reports.example.com reduces to the Organizational Domain example.com, which matches. Most receivers treat this as internal and skip verification.
• rua=mailto:dmarc@example.net published in _dmarc.example.com is external. Different Organizational Domain (example.net versus example.com), even though both are yours.
• rua=mailto:reports@vendor.com published in _dmarc.example.com is external. Obviously different domain.

The practical takeaway: the moment your report address lives anywhere outside the registrable domain of the policy you are publishing, including your own sibling domains, you cross into external-destination territory and the verification record becomes mandatory. This is the single most common reason reports silently fail for people who use a separate domain or a third-party service. The RFC 7208 walkthrough explains the Organizational Domain and Public Suffix List concept in the SPF context; DMARC reuses the same machinery.

The authorisation record, exactly

The destination domain authorises a reporting domain by publishing a DNS TXT record at a specific, constructed name. The format is defined in Section 7.1. The record name is:

<reporting-domain>._report._dmarc.<receiving-domain>

Read that carefully, because the order matters and it is easy to invert. Suppose example.com publishes a record that sends reports to reports@vendor.com. Then vendor.com is the receiving (external) domain, and example.com is the reporting domain whose reports it has agreed to accept. The record vendor.com must publish is:

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

Break the name into parts:

• example.com is the domain that wants to send reports out (the one with the DMARC policy).
• ._report._dmarc is the fixed, literal label sequence that signals this is an external-destination authorisation.
• vendor.com is the external domain being asked to receive the reports.

The value is the literal string v=DMARC1. That is the minimum and, in practice, the entirety of what most operators publish. It declares "yes, this is a valid DMARC reporting authorisation". The presence of a record beginning with v=DMARC1 at the constructed name is the consent signal. If the record is absent, malformed, or does not start with v=DMARC1, a conforming receiver must not send reports to the external address.

There is an important shorthand the specification grants. If a single external domain is willing to receive reports from any reporting domain, it can publish one wildcard-style authorisation instead of one record per sender. This is why managed DMARC services do not ask every customer to set up a record on the vendor's side: the vendor publishes a single permissive authorisation on its own infrastructure once. We come back to who is responsible for which record below, because that division of labour is where most confusion lives.

Worked example: your own second domain

The cleanest way to internalise this is a case where both domains are yours. Say your company operates acme-corp.com for mail, and you funnel all DMARC reports to a dedicated acme-dmarc.com mailbox so reporting traffic never touches production mail. Your policy record on the mail domain:

_dmarc.acme-corp.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:agg@acme-dmarc.com; ruf=mailto:fail@acme-dmarc.com; fo=1; ri=86400"

Because acme-dmarc.com is a different Organizational Domain from acme-corp.com, this is external. Without further action, many receivers will refuse to send reports to acme-dmarc.com. You authorise it by publishing, on the acme-dmarc.com zone:

acme-corp.com._report._dmarc.acme-dmarc.com.  IN  TXT  "v=DMARC1"

Now acme-dmarc.com has on record that it consents to receive acme-corp.com's DMARC reports, and conforming receivers will deliver them. Note that you control both zones here, so you publish both records yourself. There is no third party involved; the mechanism still applies because the test is about domains, not ownership.

If you have several mail domains all reporting into the one collection domain, you publish one authorisation record per reporting domain on the collection domain:

acme-corp.com._report._dmarc.acme-dmarc.com.   IN  TXT  "v=DMARC1"
acme-uk.com._report._dmarc.acme-dmarc.com.     IN  TXT  "v=DMARC1"
acme-shop.net._report._dmarc.acme-dmarc.com.   IN  TXT  "v=DMARC1"

Each names the reporting domain on the left and shares the same ._report._dmarc.acme-dmarc.com suffix.

Who publishes what: the division of labour

This is the part people get backwards, so let me state it as plainly as possible. There are two distinct DNS changes, and they live on two different zones, owned potentially by two different parties.

1. The DMARC policy record, at _dmarc.<your-domain>, containing the rua/ruf tags. You, the domain owner, publish this. It says where you want reports sent.
2. The external authorisation record, at <your-domain>._report._dmarc.<destination-domain>, containing v=DMARC1. The destination domain publishes this. It says it consents to receive your reports.

When the destination is a third-party service, the service operates the destination domain, so the service is responsible for the authorisation record, usually via a permissive wildcard authorisation that covers all of its customers at once. This is why, with most managed providers, you only ever touch your own _dmarc record and reports just work. The vendor already authorised the world to report to it.

When the destination is your own second domain, you own both zones, so you publish both records. Nobody else can do it for you, and nobody will warn you that the second record is missing.

When the destination is a partner organisation's domain (say a parent company that aggregates reporting for several subsidiaries), the partner must publish the authorisation record on their zone, naming your domain as the authorised reporter. You cannot publish it for them, because you do not control their DNS. This is a real coordination task and a frequent failure point in group structures.

Why your reports went missing

If reporting is partly or completely broken, external-destination verification is one of the first things to check, but the symptoms are confusing because enforcement is inconsistent across receivers. RFC 7489 makes verification mandatory, but the major mailbox providers have historically implemented it to varying degrees and at varying strictness.

• Some receivers check rigorously and drop reports the instant the authorisation record is missing.
• Some check only on the first send and cache the result, so a record removed later still works until the cache expires.
• Some, particularly smaller or older systems, have historically not checked at all and sent reports regardless.

The result is the maddening pattern people actually see: reports arrive from one provider but not another, or arrive from everyone for a while and then a major source goes quiet. That is not your rua syntax; that is one receiver enforcing external verification that another ignores. The fix is the same regardless: publish the authorisation record correctly so that every conforming receiver is satisfied. Do not rely on the lax ones.

To confirm whether your DMARC record and report addresses are even syntactically sound before chasing the authorisation record, run the domain through the DMARC checker. It parses the record, flags malformed rua/ruf URIs, and shows whether your report destinations are external to the policy domain, which is the trigger condition for needing the authorisation record in the first place. If you are still drafting the record, the DMARC generator builds a valid one with correctly formatted reporting tags.

The exact mistakes that break it

Across real deployments, the authorisation record fails for a small set of repeatable reasons. Walk this list before assuming anything more exotic.

The label order is inverted

The single commonest error. People publish the record on the wrong zone or with the parts in the wrong order. It is <reporting-domain>._report._dmarc.<receiving-domain>, published on the receiving domain's zone. If you put vendor.com._report._dmarc.example.com on your own zone, you have created a meaningless record. The reporting domain comes first; the zone it lives in is the receiver.

The _report label is wrong

It is _report._dmarc, with a single underscore on each label, in that order. Not _reports, not report, not _dmarc._report. The underscores matter. Some DNS panels strip leading underscores or refuse them; verify the published name exactly with a lookup rather than trusting the panel's display.

The value is missing or wrong

The TXT value must begin with v=DMARC1. An empty TXT record, a record with a stray prefix, or a record holding something else does not count as consent. Receivers look specifically for the v=DMARC1 token. Publishing just an empty quoted string is a no-op.

It was created as a subdomain CNAME by mistake

Several DNS providers, when you type a long name with underscores, behave unexpectedly: appending the zone twice (producing _report._dmarc.example.com._report._dmarc.example.com), or creating a CNAME instead of a TXT record. Always confirm the final fully qualified name and the record type after publishing.

The destination is internal and you published it anyway

If your report address is within the same Organizational Domain as the policy (for example dmarc@reports.example.com reporting for example.com), you do not need the authorisation record, and publishing one does no harm but solves nothing if reports are failing for a different reason. Check whether you are actually external first. Counting dots is not the test; the Public Suffix List is.

TTL and propagation

DNS is cached. After you add the authorisation record, receivers that already cached a "no record" answer will keep failing until that negative cache expires. Give it time, ideally up to the TTL you set, before concluding it has not worked. Keep the TTL modest (3600 seconds is reasonable) while you are still validating.

Multiple mail domains, one collection domain, partial coverage

If five domains report into one collection domain but you only published the authorisation record for three of them, the other two will have missing reports while the rest work perfectly. This looks like an intermittent bug and is actually three records where you needed five. Audit the full list of reporting domains against the authorisation records present.

Verifying it actually works

You cannot fully verify external-destination authorisation just by looking at your own DMARC record, because the relevant record lives on the destination zone. Verify it directly with a DNS lookup of the constructed name:

dig +short TXT example.com._report._dmarc.vendor.com

You want back a single quoted string starting v=DMARC1. If you get NXDOMAIN or an empty answer, the authorisation is not in place and external reports will be refused by conforming receivers. Substitute your reporting domain for example.com and your destination domain for vendor.com.

Beyond the DNS check, the real proof is reports arriving from a broad set of receivers, not just one. If aggregate reports show up from a single permissive provider but none from the strict ones, treat that as a sign the authorisation record is still missing or malformed, not as success. Continuous reporting health is exactly what change-alert monitoring is for: it watches whether reports keep flowing and flags the moment a major source goes quiet, which is the earliest practical signal that an authorisation record has broken or a destination has changed.

How this fits the wider DMARC rollout

External destination verification sits at the boundary between two phases of a DMARC programme: getting reports flowing, and acting on them. You cannot safely move from p=none to p=quarantine to p=reject without trustworthy reporting, because the reports are how you discover every legitimate sender before you start rejecting mail. If a swathe of receivers are silently refusing to send you reports because the authorisation record is missing, your view of who sends as your domain is incomplete, and tightening policy on an incomplete picture is how legitimate mail gets blocked.

So treat the authorisation record as a prerequisite, not a nicety. Get it right early, confirm reports arrive from Google, Microsoft, Yahoo and a spread of others, and only then start reading the data and triaging sources. When unfamiliar senders show up in those reports, reports show unknown sources walks through triaging them. The reporting requirements for the major mailbox providers, and what they expect of you before they will accept your mail at scale, are summarised on the requirements page.

If you would rather not maintain _report._dmarc authorisation records, chase missing reports across providers, and manually verify which receivers are honouring your external destinations, that coordination is part of what the done-for-you DMARC monitoring product handles. It receives reports on an already-authorised destination, so the external-verification record is never your problem, and it alerts you the moment reporting health changes rather than leaving you to notice months later that a source went dark.

The practical takeaway

Sending DMARC reports to any address outside the registrable domain of your policy is an external destination, and RFC 7489 requires the destination domain to publish a consent record before conforming receivers will deliver reports there. That record is a TXT entry named <reporting-domain>._report._dmarc.<receiving-domain> with the value v=DMARC1, published on the receiving domain's zone. Third-party services usually handle this for you with a single permissive authorisation; your own second domains and partner domains do not, and that is where reports silently vanish. Get the label order right, confirm the value, account for every reporting domain, and verify the published record with a direct DNS lookup rather than trusting your DNS panel.

Start by confirming your record is even external and well-formed with the DMARC checker; if it is, publish the authorisation record on the destination zone and verify it with dig. If you would rather the whole reporting pipeline, authorisation included, simply work, that is what hosted DMARC monitoring is built to take off your plate.