Check DMARC report authorization
How it works
Read the policy
The _dmarc record for each domain is fetched and parsed. If the exact name has no record, the organisational domain is checked and the row is marked as inherited.
Split the destinations
Every rua and ruf URI is separated, size limits stripped, and compared against the organisational domain of the reporting domain.
Verify each external one
For destinations outside your own organisation, the tool looks up {domain}._report._dmarc.{destination} and checks it returns a DMARC1 record. Wildcards are picked up automatically by the resolver.
Get the missing records
Anything unauthorized comes back with the exact TXT record to publish, plus a CSV of the whole set for a bulk DNS import.
The rule nobody reads
Section 7.1 of RFC 7489 covers what happens when a DMARC record asks for reports to be sent somewhere outside the domain being reported on. Left alone, that would be an open reflector: anyone could publish rua=mailto:victim@example.org and point the aggregate traffic of a large domain at a stranger. So receivers are required to ask permission first. Before sending a report to dmarc@reports.io about acme.com, the receiver looks up acme.com._report._dmarc.reports.io and expects a TXT record starting v=DMARC1. No record, no report.
The check only applies when the two organisational domains differ. Reporting to an address on your own domain, or on a subdomain of it, needs nothing extra — which is why the rule stays invisible until the day you switch to a reporting platform, or a client's domain starts reporting into your own dashboard.
Why you never notice
There is no failure signal. The receiver does the lookup, finds nothing, and moves on. Nothing bounces, nothing is logged anywhere you can see. What you observe is a DMARC dashboard with far less traffic than the domain actually sends, or a handful of domains in a portfolio that never appear while the rest do. The instinct is to blame the parser or assume the domains are quiet. Nine times out of ten it is a missing _report._dmarc record on the destination side, and it has been missing since the day the record was written.
The wildcard, and when to use it
If you control the domain that receives the reports, one record settles it permanently: *._report._dmarc.yourdomain.com with the value v=DMARC1; authorizes every domain in the world to send reports to any address on it. That is exactly what the large reporting vendors publish, and it is why pointing rua at a vendor usually works with no extra step. The trade-off is that it is open: anyone can direct DMARC traffic at your mailbox. For a dedicated reporting address behind a parser that is fine. For a shared mailbox, publish the per-domain records instead — the tool exports them as a CSV you can import in one go.
What to do with each result
Authorized — nothing to do. Same org — nothing to do; the rule does not apply. Not authorized — if the destination is yours, publish the record shown; if it belongs to a vendor, the domain almost certainly has to be added inside their dashboard before their wildcard covers it, or their plan limits how many domains they accept. No rua at all — the more common problem, and the bigger one: a policy with no reporting address means you are enforcing something you cannot see. The DMARC generator writes a correct record, the DMARC checker validates the syntax, and the report parser reads the XML once it starts flowing.
Frequently asked questions
Does this apply to ruf as well as rua?
Yes, and the record is the same one. Forensic reports are rarer because most receivers do not send them at all, but the authorization requirement is identical.
My reports arrive from Google but not Microsoft. Is that this?
Probably not. Receivers differ in how strictly they apply the check and in whether they send aggregate reports at all. A missing authorization record usually kills everything from every receiver, not a subset.
What exactly goes in the TXT record?
Just v=DMARC1; at the host {your-domain}._report._dmarc.{destination-domain}. No policy tag, no rua. It is a permission marker, not a policy.
Do subdomains need their own authorization record?
Yes. The name checked is the exact domain that published the DMARC record. If send.example.com has its own _dmarc record with an external rua, it needs its own send.example.com._report._dmarc.destination entry unless a wildcard covers it.
Is a wildcard authorization record a security risk?
It lets anyone point DMARC aggregate reports at that domain. On a mailbox that feeds a parser, that is noise at worst. On a human mailbox it is worth avoiding.
Why does the tool say a policy is inherited?
Because the exact domain has no _dmarc record and the organisational domain's policy applies instead. In that case the authorization record is keyed to the organisational domain, not the subdomain.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.