Who can receive your DMARC reports: what six vendor zones answered on 2026-08-25 and 2026-08-27

That difference is measurable from a single dig command, it takes about ten seconds per service, and you can reproduce every line of this page yourself. This is not a claim about which service is better. It is a claim about what six DNS zones returned on two dates, 2026-08-25 and 2026-08-27, and DNS records are public facts.

Why an authorization record exists at all

When you publish rua=mailto:[email protected] in your DMARC record, you are asking every mail receiver on the internet to send report traffic to a domain you may not control. The standard anticipated the obvious abuse and required receivers to check first.

The current specification is RFC 9990, DMARC Aggregate Reporting, published May 2026. It obsoletes RFC 7489, which carried this mechanism in section 7.1 until then. Here is the rationale, quoted verbatim from RFC 9990 section 4, "Verifying External Destinations":

Without checks, this would allow a bad actor to publish a DMARC Policy Record that requests that reports be sent to a victim address and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included.

And the steps the receiver takes, again verbatim from the same section. Note the numbering: these are RFC 9990 steps, and they differ from the RFC 7489 numbering an older article may cite.

1. Extract the host portion of the authority component of the URI. Call this the "destination host", as it refers to a Report Receiver.

2. Prepend the string "_report._dmarc".

3. Prepend the domain name from which the policy was retrieved, after conversion to an A-label [RFC5890] if needed.

4. If the length of the constructed name exceed DNS limits, a positive determination of the external reporting relationship cannot be made; stop.

5. Query the DNS for a TXT record at the constructed name. If the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later.

[...]

7. If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop.

8. If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Consumer.

[...]

So if example.com publishes rua=mailto:[email protected], a conforming receiver queries:

example.com._report._dmarc.vendor.example

A TXT record starting v=DMARC1 at that name means the vendor has said yes.

The part the earlier version left out

The same section, four paragraphs after the steps above, says this. It is quoted verbatim and it is the reason this page was rewritten:

A Report Consumer that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain.

So a wildcard is not a failure to comply. It is the mechanism the specification offers to a destination that serves many domains, and it has been in the text since RFC 7489 in 2015. What follows measures which of the two models each destination uses. It does not measure whether anyone is doing something wrong.

The control: query a name that cannot be a real customer

The interesting question is not whether a vendor answers for its actual customers. It is whether the vendor answers for a domain that is not a customer, has never been a customer, and does not exist.

So the test is a random label. If a vendor answers a name nobody has ever registered, the destination is using the wildcard model, and step 8 above succeeds for every domain on the internet.

The random label used for every measurement on this page, generated once for this run:

cc1x4dd605a954d9

Two queries per service. The first uses the random label. The second uses example.com, the reserved documentation domain, which is nobody's customer either.

dig +short TXT cc1x4dd605a954d9._report._dmarc.<service>
dig +short TXT example.com._report._dmarc.<service>

First run 2026-08-25T11:38:02Z with label cc1x4dd605a954d9. Second run 2026-08-27T11:45:23Z with a fresh label cc3e6bf0f372b9, so the second run repeats nothing from the first. Both against resolver 8.8.8.8.

Results

These are two dated observations, not a standing property of any of these services. A DNS record can be added or removed at any time, and the table above says only what these zones returned at the two moments named. The command is below. If it matters to you, run it yourself rather than trusting this page. If any of it changes, this page is corrected by republication and the correction is dated. It is never edited silently.

The exact session output from the first run, unedited:

$ dig +short TXT cc1x4dd605a954d9._report._dmarc.uriports.com
(no answer)
$ dig +short TXT cc1x4dd605a954d9._report._dmarc.dmarc-reports.cloudflare.net
"v=DMARC1;"
$ dig +short TXT cc1x4dd605a954d9._report._dmarc.ar.glockapps.com
"v=DMARC1"
$ dig +short TXT cc1x4dd605a954d9._report._dmarc.fr.glockapps.com
"v=DMARC1"
$ dig +short TXT cc1x4dd605a954d9._report._dmarc.mxtoolbox.dmarc-report.com
"v=DMARC1"
$ dig +short TXT cc1x4dd605a954d9._report._dmarc.forensics.dmarc-report.com
"v=DMARC1"

Proving the one negative is real

A "no answer" result is worthless unless you can show the query mechanism was working. Two checks establish that.

The uriports.com zone resolves normally, so the empty result is a real absence and not a broken lookup:

$ dig +short NS uriports.com
intention.ns01.nl.
intention.ns02.nl.
intention.ns03.nl.
intention.ns04.org.

And the response codes differ in exactly the way they should:

$ dig +noall +comment TXT cc1x4dd605a954d9._report._dmarc.uriports.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

$ dig +noall +comment TXT cc1x4dd605a954d9._report._dmarc.ar.glockapps.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR

A positive control, to show the resolver answers TXT queries at all:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:[email protected]"

And a negative control, a name that must not resolve:

$ dig +short TXT cc1x4dd605a954d9._report._dmarc.cc1x4dd605a954d9-nonexistent.example
(no answer)

What a wildcard does and does not mean

A wildcard authorization is a deliberate operational choice, and there is a straightforward reason to make it. A report destination serving many thousands of customers would otherwise have to publish and maintain one TXT record per customer domain, and every onboarding would carry a DNS step that can silently fail. A wildcard removes that failure mode. Reports flow on day one.

The trade is real and the specification makes it deliberately. With a wildcard in place, step 8 succeeds for every domain, so the verification confirms that the destination accepts reports without confirming any relationship with the sender. The consequence sits with the destination operator, who can be named as a report target by a domain it has never heard of. That is a load question for them, not a security exposure for you.

The other model costs the destination nothing at load time and costs its customers a setup step. Neither is better in the abstract. They fail in different directions, and only one of them fails on your side.

One thing this measurement cannot tell you: whether a given vendor performs its own checks after the reports arrive. A wildcard in DNS says the authorization gate is open. It says nothing about what happens downstream of it, and this page makes no claim about that.

Running it on your own destination

Take whatever is in your own rua tag, strip it to the host part, and query a name that could not be yours:

dig +short TXT $(head -c 6 /dev/urandom | od -An -tx1 | tr -d ' \n')._report._dmarc.<your-report-host>

An answer means the destination uses the wildcard model and you have nothing to publish. No answer means it names each domain, and in that case your own domain needs its own record at <your-domain>._report._dmarc.<your-report-host> before a conforming receiver will send anything.

That second case is the one worth checking today, because a missing authorization record is silent. Your DMARC record looks correct, your policy is published, and the reports simply never arrive.

Our audit runs this control on every report it generates, at audit.humerly.com.

Frequently asked questions

Does a wildcard authorization record mean my DMARC reports are insecure?

No. A wildcard record is one of the two authorization models RFC 9990 section 4 provides, and the section names it explicitly. It means the external destination check will succeed for any domain naming that destination. Your own reports still go where your rua tag points. The consequence sits with the destination operator, who can be named as a report target by a domain they have no relationship with.

Why does the random label matter? Why not just query my own domain?

Querying your own domain cannot distinguish the two cases. If a vendor publishes a wildcard, your domain answers. If a vendor published a record specifically for you, your domain also answers. The results are identical. Only a name that could not have been provisioned separates them, which is why every measurement above was run twice, once with a random string and once with example.com.

My reports stopped arriving and my DMARC record has not changed. Is this why?

It can be. If your destination does not publish a wildcard, the authorization lives in a separate TXT record at <your-domain>._report._dmarc.<destination>, and that record can be removed, expire, or never have been created without your DMARC record changing at all. Query it directly and see. If it returns nothing, conforming receivers stop at step 7 and your reports are never generated.