DMARC Report Addresses Leak Your Security Vendor: The rua= Market

DMARC's reporting loop is the part of the protocol that actually makes deployment manageable: receivers send daily aggregate reports about your domain's authentication results to whatever address you put in the rua= tag. Almost nobody reads those XML files by hand, so an entire industry exists to receive and analyse them — and because the receiving address sits in a public DNS TXT record, the industry's customer lists are effectively published. As of the 2026-07-05 snapshot, our daily email infrastructure report parses 459,124 DMARC records in the Tranco top-1M, and the rua= destinations in them classify cleanly into named vendors.

How a TXT record names your vendor

Managed DMARC services work by ingestion: you point your reports at an address on the vendor's infrastructure, typically with a customer-specific local part or subdomain, and their platform does the parsing, source identification, and alignment forensics. The result is that the vendor's domain appears verbatim in your record:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine;
    rua=mailto:example-com@ag.dmarcian.com"

Our classifier matches these destination patterns for the recognisable names in the space — Valimail, dmarcian, EasyDMARC, Red Sift, Proofpoint Email Fraud Defense, Agari, URIports, Postmark's DMARC digests, and others. We deliberately do not publish per-vendor market shares as headline numbers — classification coverage varies across the long tail of destinations, and a single domain can list several rua= addresses at once — but the vendor breakdown is visible in the DMARC section of the live report, recomputed nightly.

What the rua= line tells an outside observer

For a security or IT administrator, the interesting question is what this public field discloses — about your own organisation, and about any domain you care to look up:

Which vendor you pay. A recognisable monitoring domain in rua= identifies your DMARC tooling as reliably as an MX record identifies your gateway. Competitors, salespeople, and researchers all read it.
Whether a programme is active at all. A DMARC record with no rua= tag requests no reports: nobody is watching. Combined with p=none, that is a record published for compliance and then abandoned — the pattern behind the p=none illusion. A managed-vendor address, by contrast, implies an ongoing subscription and usually an owner.
Programme maturity, roughly. Self-hosted mailbox destinations (dmarc@example.com) suggest an in-house process of unknowable health; a specialist platform suggests the organisation intends to reach enforcement. Neither is proof, but as a prior it is better than nothing — the same logic as reading training platforms out of SPF.

Is the leak dangerous?

Mostly no. Knowing your DMARC vendor gives an attacker little direct capability — the reports flow from receivers to the vendor, not through any channel the attacker can join. The main costs are commercial (your stack is visible to competitors and sellers) and reputational (an empty or dangling rua= advertises neglect). Treat it like an MX record: public by design, so make sure what it says is what you would say out loud.

The detail worth auditing: external destination authorisation

One mechanism in the reporting loop deserves a place on your audit checklist. When rua= points at a domain other than the one publishing the record — which is exactly what every managed vendor requires — receivers verify that the destination consents to receive reports for your domain. The vendor publishes an authorisation record of the form yourdomain.com._report._dmarc.vendor.com, and reports flow only while it resolves. Practical consequences:

Churned subscriptions fail silently. If you leave a vendor but forget the rua= tag, the authorisation record disappears and reporting simply stops — no error reaches you. Your record now names a vendor you no longer pay, and nobody is reading anything.
Anyone can check the relationship. The authorisation lookup is public too, so an observer can distinguish a live vendor engagement from a stale tag — useful in due diligence, and equally available to attackers profiling how attentively a domain's email security is run.
Multiple destinations are legal and common. Records may list several mailto: URIs — a vendor plus an internal archive is a sensible belt-and-braces pattern, at the price of one more thing to keep current.

The reporting loop, in other words, has its own hygiene: a rua= that points somewhere real, an authorisation that still resolves, and someone who acts on what arrives. Those three checks take minutes and are, in our experience of reading nearly half a million of these records nightly, failed surprisingly often. The full DMARC dataset — policies, reporting destinations, vendor classification — is available in machine-readable form at api/latest.json.

FAQ

Can anyone really see which DMARC vendor a company uses?

Yes, whenever the company uses a managed service in the standard way. The rua= tag in the public DMARC TXT record names the report destination, and managed vendors receive reports on their own domains — dmarcian, Valimail, EasyDMARC, Red Sift, Proofpoint EFD, Agari, URIports and others are all recognisable from the address pattern.

Is publishing a vendor rua= address a security risk?

Not materially. Aggregate reports flow from mail receivers to the report address; an outside attacker cannot intercept or join that flow by knowing the address. The disclosure is comparable to your MX record revealing your mail provider — commercial intelligence, not an exploitable weakness.

What does it mean if a DMARC record has no rua= tag?

No aggregate reports are being requested, so no one is monitoring authentication results for the domain. Combined with p=none, it usually indicates a record published to satisfy a checklist and never operationalised. Adding a rua= destination is the first step of any real DMARC programme.

Why do reports to my vendor require a special DNS record on their side?

When the report destination is on a different domain than the one publishing the DMARC record, receivers check an external destination verification record on the destination domain to confirm it consents to receive your reports. Vendors publish it automatically for active customers — which is why reporting silently stops if the subscription lapses but your rua= tag remains.