A Third of European Companies Turned DMARC On and Get No Reports Back

A DMARC record does two jobs. It publishes the domain owner's requested handling policy for mail that fails authentication (p=none, quarantine, or reject), which receiving systems can honour or override with their own decisions, and it names an address that should receive aggregate reports: a periodic XML feed summarising which source IPs sent mail claiming to be the domain and how that mail fared against SPF, DKIM and alignment. That report address is the rua= tag.

The reports are what make a DMARC deployment observable rather than blind. Each aggregate report is a periodic summary from a receiving mail provider: the source IPs that sent mail claiming to be your domain, how many messages each sent, and whether they passed SPF, DKIM and alignment. In practice that is how you find the marketing platform, invoicing tool or regional office quietly sending as your domain but failing authentication, how you catch a spoofing run against your brand, and how you gain the confidence to move a policy from p=none to reject without silently dropping legitimate mail. Without an rua= address none of that arrives: you publish a policy and see nothing behind it. The reports give visibility into the sources observed sending as a domain and which of them fail authentication. An authentication failure is not automatically an impersonation attempt: it is frequently a legitimate sender that has not been aligned yet, such as a newly added marketing tool. The value of the feedback is that it lets the domain owner tell those cases apart, which is exactly what a domain with no rua= tag cannot do.

So we looked at the rua= tag on every European company domain in the CipherCue directory that publishes a DMARC record: 69,887 of them. A large share publish DMARC and then collect nothing at all. Among those that do report, the single biggest destination is European, not American, which cuts against the usual assumption that Europe's email layer is a US monoculture.

A third of policies are running blind

Of the 69,887 domains with a DMARC record, 23,406 have no rua= tag: 33.5%. The policy is published and receiving systems can act on it, but the owner receives no DMARC aggregate feedback through rua. No aggregate view of which sources are sending as the domain, and no way to tell from DMARC whether a legitimate sender is failing alignment. (An organisation may still have other visibility, from its mail provider or SIEM; it just is not getting it through DMARC.) It is the single most common rua gap we found, and far more common than a malformed address (more on those below).

We are not the first to notice that DMARC reporting is widely half-configured. A peer-reviewed measurement study presented at USENIX Security 2023, tracking reporting across .com, .net, .org and .se over 13 months, found "pervasive mismanagement and missing security considerations in DMARC reporting". That work looked at whole TLDs from the report-consumer's side; ours looks at a European company cohort from the DNS record's side, so the numbers are not directly comparable. They point the same way: publishing a policy is common, wiring up the feedback loop behind it is not.

Of the rest, most point at an external domain

Among the 46,481 domains that have an rua= tag, 29,401 list at least one address on a registrable domain different from their own: 63.3% of the domains with reporting, or 42.1% of the full 69,887-domain cohort. A same-domain destination is the minority. One thing to keep in mind for the rest of this piece: an rua= value records where a domain owner has asked reports to be sent, not proof that they are delivered there. An external consumer normally has to opt in with a matching _report._dmarc record, which we did not verify at scale, so read these as configured destinations. (There is a dig check for it at the end.)

These external destinations are spread across 3,864 distinct registrable domains, so this is not a market with one or two obvious owners. But the head of the distribution is concentrated. Ranking every external destination by how many European domains point at it (counting each company domain once, and merging obvious aliases such as Brevo's mailinblue.com) gives a top ten that is a mix of email service providers, dedicated DMARC-monitoring tools, and one CDN:

The single most common external destination is European: Brevo, a French email service provider, at 3,600 domains. That is the surprise. The European Commission's own standards monitoring and the broader digital-sovereignty debate both start from the premise that Europe's email layer is a US monoculture, and for mailbox hosting that premise largely holds. For DMARC reporting it does not: the busiest single destination is French, not American.

The top two destinations are both dedicated reporting mechanisms, not accidental catch-alls. Cloudflare (second, at 2,792) runs a DMARC Management product that adds a Cloudflare rua destination and processes the aggregate reports. Brevo instructs its customers to add rua=mailto:rua@dmarc.brevo.com as part of authenticating a sending domain. What the DNS record cannot tell us is intent: whether an organisation deliberately shopped for a DMARC reporting product, or simply followed the setup steps of a sending platform or DNS provider it had already adopted for other reasons. A Brevo rua tag looks identical either way. So the ranking measures which products end up receiving reports, not how deliberately each was chosen.

Narrow the field to the products whose actual job is DMARC monitoring, and classify each strictly by founding country, and the result is almost a dead heat. The US-founded tools in the top ten, Valimail and dmarcian, account for 2,979 European domains. The EU/UK-founded ones, DMARC Analyzer, DMARC Advisor and OnDMARC, account for 2,982. A gap of three domains. EasyDMARC (486), founded in Armenia and US-incorporated, belongs to neither group and is kept out of that comparison rather than folded into one side. In this cohort, European specialist monitoring products are used at essentially the same rate as American ones.

Per country

Grouping eight countries together as "Europe" hides real differences, so here are the raw counts for the eight with enough domains to report on. The share pointing at an external domain runs from 35.1% in Poland to 56.8% in Ireland. Germany, Poland and Italy lean more towards same-domain destinations than the others.

Malformed addresses: 0.46%

We also checked for rua addresses that were simply broken: typos that quietly send reports nowhere. Across the 45,854 domains with a rua tag in the eight countries above, 213 have an address that will not parse. That is 0.46%. The mistakes are the human ones you would guess: mailto:dmarc.heritage.org with no @ at all, an address missing the mailto: scheme, an empty rua=mailto:, and one record with a stray closing quotation mark left in from a copy-paste. At that rate, broken syntax barely moves the totals. The reporting gap is the third of domains that set no rua at all, plus the open question of where the valid addresses actually point.

Two limits on reading this

Two limits are worth stating plainly, because they bound what any of this can claim. First, an aggregate report carries no message bodies, so none of this is about reading anyone's email; it is source IPs, counts and authentication results, which is enough to infer which services send for a domain but not always to name the product. Second, the report data covers only traffic the reporting receiver happened to see, so a quiet sending source that never reached a reporting provider will not appear.

A third limit is data residency. The rua= tag names a vendor, not a location: a vendor headquartered outside the EU may still run EU-resident infrastructure and hold the data under an EU entity, and several of these advertise exactly that. So the destination in DNS is where a sovereignty review starts, not where it ends. It establishes which supplier relationship is configured, which is usually the first thing to pin down and the thing most often missed.

A domain pointing reports at dmarcian is not less secure than one pointing at Brevo; both are ahead of the third that publish a policy and set no rua. The configured destination just tells you which supplier an organisation reached for, and for most that was whoever already sent their mail or served their DNS, not a deliberate choice of DMARC tooling. Checking which supplier your own domain named takes a single DNS lookup.

Check your own domain

The basic observation in this piece takes one command. Query the _dmarc record for a domain:

dig +short TXT _dmarc.example.com

Read the rua= tag in the answer. If there is no rua=, the domain gets no aggregate feedback through DMARC. If there is one, compare the registrable domain in the mailto: address with the domain you looked up: an address at example.com is a same-domain destination, while an address at, say, ag.dmarcian.com is an external one.

For an external destination, you can also check whether the receiving domain has authorised it, which is what actually permits delivery. If example.com asks reports to be sent to rua=mailto:x@thirdparty.net, the authorisation record lives on the receiver:

dig +short TXT example.com._report._dmarc.thirdparty.net

A valid v=DMARC1 response there means the third party has opted in to receive reports for that domain. No response means the configured destination may not actually receive them. This piece measures the rua= tag in DNS; it does not verify that last step at scale.

SenderLedger reads your domain's public DNS in seconds, no account needed. Start free for one domain to see every service sending as you and work towards p=reject without blocking your own mail.