The required record is a DNS TXT authorization record on the domain that will receive the DMARC reports. If example.com publishes a DMARC record that sends aggregate reports to reports@abc.com, then abc.com needs to publish a TXT record at example.com._report._dmarc.abc.com with the value v=DMARC1;.
This record is needed only when the DMARC report destination is outside the organizational domain of the domain that published the DMARC policy. If your DMARC record for example.com sends reports to dmarc@example.com or a mailbox under the same organizational domain, you do not need this extra authorization record.
- Record name: use the reporting domain, then ._report._dmarc., then the destination domain.
- Record type: publish it as a TXT record in the DNS zone that receives reports.
- Record value: use v=DMARC1; unless your report processor gives you a more specific value.
- Reason: the receiving domain is declaring that it agrees to accept DMARC report traffic for the other domain.
External DMARC report authorization recordtext
Name: example.com._report._dmarc.abc.com. Type: TXT Value: "v=DMARC1;"
The required DNS record
The naming pattern is the part that trips people up. The TXT record does not live under the sending domain. It lives under the report destination domain. The left side of the record names the domain requesting reports, and the right side is the domain that will receive them.
For a sending domain of example.com and a report address at reports@abc.com, the authorization lookup is under abc.com. That means the DNS administrator for abc.com, not the administrator for example.com, must publish the authorization TXT record.
Flowchart showing DMARC policy, external RUA, DNS authorization, and report delivery.
DMARC record requesting external aggregate reportstext
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@abc.com"
Matching authorization record on the destination domaintext
example.com._report._dmarc.abc.com. TXT "v=DMARC1;"
I treat the trailing dot as a display detail. Many DNS control panels ask for only the host part, such as example.com._report._dmarc, because the zone name abc.com is appended automatically. Other DNS providers ask for the full name. The final DNS result must resolve as the full name above.
When this record is needed
The extra TXT record is an external destination verification record. It exists because DMARC reports can be large and numerous. Without a consent check, any domain owner could point its rua address at an unrelated mailbox and cause receivers to send report files there. The authorization record prevents unwilling domains from receiving that traffic.
The same practical rule applies to aggregate report addresses in rua and failure report addresses in ruf. In normal operations, the rua address matters most because aggregate reports are the primary feed for DMARC monitoring.
Same organizational domain
No external authorization record is needed when the report destination is under the same organizational domain as the DMARC policy domain.
- Example: reports for example.com go to dmarc@example.com.
- Subdomain: reports for mail.example.com go to an address under example.com.
External destination domain
An authorization TXT record is needed when the report mailbox is outside the organizational domain that published the DMARC policy.
- Example: reports for example.com go to reports@abc.com.
- Fix: publish the TXT record under abc.com so report senders see consent.
|
|
|
|
|---|---|---|---|
example.com | example.com | No | None |
example.com | abc.com | Yes | abc.com |
shop.example.com | example.com | No | None |
example.com | reports.abc.com | Yes | reports.abc.com |
Quick examples for common RUA destinations.
For a deeper explanation of the external reporting rule, the DMARC.org explainer is a useful reference. I also keep a separate note on whether external RUA reports can be sent to a different domain.
How to create the authorization record
Start with the DMARC domain, then the mailbox domain in the report URI. Do not use the whole email address in the authorization record name. Use only the host part after the @ sign.
If the DMARC record says rua=mailto:reports@abc.com, the destination host is abc.com. If it says rua=mailto:dmarc@reports.abc.com, the destination host is reports.abc.com. This small distinction explains many failed setups.
Do not publish this under the sending domain
The external authorization record belongs in the DNS for the report destination. If example.com sends reports to abc.com, publishing the authorization TXT record only in example.com will not satisfy the external destination check.
- Find domain: identify the domain that published the DMARC record, such as example.com.
- Find host: extract the host from the rua email address, such as abc.com.
- Build name: combine them as example.com._report._dmarc.abc.com.
- Set value: publish a TXT value of v=DMARC1;.
If you are writing the DMARC policy from scratch, use a record generator to avoid syntax mistakes in the base DMARC record before you troubleshoot external reporting.
How to validate and monitor it
Validation has two layers. First, verify that the DMARC record itself is syntactically valid. Second, verify that the external destination record exists at the exact name that receivers will query. A valid DMARC record can still lose reporting data if the external authorization record is missing.
I check the published DMARC record first, because a typo in rua changes the authorization record name. After that, I query the external authorization TXT record directly. A DMARC checker is useful because it catches the record syntax and the reporting destination at the same time.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
When a checker reports that the destination domain is not authorized, do not assume the DMARC record itself is broken. The fix is usually on the destination side. That matters when the destination belongs to a vendor, a parent company, an agency, or a shared reporting domain controlled by another DNS team.
Manual DNS checkbash
dig TXT example.com._report._dmarc.abc.com +short # Expected output: "v=DMARC1;"
DNS propagation also matters. A newly published TXT record can appear from one resolver before another. If a report sender checked while the record was absent, wait for the TTL to expire and check again. I also avoid using long TTLs during setup because mistakes are easier to fix when the cache window is short.
Why some reports still arrive without it
A missing external authorization record does not cause SPF, DKIM, or DMARC authentication to fail. It affects report delivery. Receivers are expected to check the external destination before sending reports, but real-world behavior is not perfectly uniform. That is why you can see a warning and still receive a few reports.
Do not use those few reports as proof that the setup is correct. The missing record means compliant receivers can suppress reporting, so the data set becomes incomplete. That creates a practical problem: you might think a sender has no authentication failures simply because the mailbox providers that saw the failures did not send reports.
Treat the warning as data loss
The warning does not mean your email is rejected. It means your reporting feed is not dependable. Fix the authorization record before using DMARC report volume to make policy decisions.
- Authentication: SPF, DKIM, and DMARC results are evaluated separately from report destination consent.
- Reporting: aggregate reports can be withheld when the destination domain has not authorized receipt.
- Decision: do not move to a stricter policy until the report feed is complete enough to trust.
The clearest operational test is simple: publish the authorization record, confirm it resolves, then watch report volume and source coverage over the next few reporting cycles. If new mailbox providers start appearing in the data, the previous setup was hiding part of your traffic.
Where Suped fits
For most teams, Suped is the best overall DMARC platform for this workflow because this problem is not only a DNS syntax issue. It is a monitoring issue. You need to know whether reports arrive, whether sources are authenticated, and whether DNS changes actually fixed the gap.
Suped's product gives you DMARC report processing, automated issue detection, real-time alerts, Hosted DMARC, Hosted SPF, SPF flattening, Hosted MTA-STS, blocklist monitoring, MSP-friendly multi-tenancy, and a feature-rich free plan in one platform. That makes the external reporting record part of a visible workflow instead of a one-off DNS edit that nobody checks again.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The most useful workflow is to create or review the DMARC record, verify report delivery, and then stage policy changes only after the source data is clean. With Hosted DMARC, Suped's product also reduces the number of DNS edits needed when you need to adjust reporting addresses or policy.
Manual DNS workflow
- Setup: you create the DMARC record and the external authorization record by hand.
- Checks: you manually query DNS and compare report volume after each change.
- Risk: silent report loss can persist if nobody owns the follow-up.
Suped workflow
- Setup: Suped's product guides the DMARC record and report destination setup.
- Checks: issue detection and alerts show when reporting or authentication needs attention.
- Scale: multi-domain and MSP views help teams manage this across many clients.
Views from the trenches
Best practices
Create the external TXT record before relying on aggregate report coverage for policy moves.
Check the exact host in the RUA address before building the authorization DNS name.
Treat report destination warnings as reporting gaps, not authentication failures.
Common pitfalls
Publishing the authorization record under the sending domain instead of the recipient.
Assuming a few incoming reports means every mailbox provider accepts the full setup.
Using a placeholder report address and then making policy decisions from partial data.
Expert tips
Keep the setup TTL short until the TXT record is verified through public DNS checks.
Ask the reporting platform for its exact external authorization TXT record value.
Monitor source coverage after the fix to confirm that missing reports have returned.
Expert from Email Geeks says the recipient domain needs to publish consent before it receives DMARC aggregate reports for another domain.
2023-12-21 - Email Geeks
Marketer from Email Geeks says the simple pattern is a TXT record at the sending domain, then _report._dmarc, then the report destination domain.
2023-12-21 - Email Geeks
The practical answer
The DNS record required for DMARC reports to an external domain is a TXT record at <dmarc-domain>._report._dmarc.<destination-domain> with a value of v=DMARC1;. For example.com sending reports to abc.com, that is example.com._report._dmarc.abc.com.
If the report address is on the same organizational domain, you usually do not need the extra record. If it is on a third-party or otherwise external domain, publish the authorization record before you trust the report feed. The clean setup is: valid DMARC TXT record, correct mailto: RUA address, matching external destination TXT record, then monitored report delivery.
