DMARC External Reporting: How to Audit Your rua= Destinations

Imagine you publish `v=DMARC1; p=reject; rua=mailto:dmarc-reports@my-vendor.com`. That tells every mailbox provider on the planet: please send your daily DMARC reports for my domain to that mailbox. Without any other check, this would be a phenomenal denial-of-service vector — an attacker could publish a DMARC record pointing rua= at a victim's mailbox and trigger a daily flood of XML reports from Gmail, Microsoft, and Yahoo.

That is exactly the attack RFC 7489 §7.1 was written to prevent. The rule: whenever your DMARC `rua=` or `ruf=` destination is on a different organisational domain than the DMARC record itself, the receiver MUST verify that the destination domain has explicitly authorised your domain to send it reports. The authorisation lives in DNS, at a specific TXT record on the receiver's side. No authorisation, no reports.

The practical consequence is that if you use a third-party DMARC analytics vendor — Postmark DMARC, dmarcian, RedSift, Valimail, Cisco — and they have not published an authorisation record for your domain on their side, your DMARC reports never arrive. You configured rua=, you see no reports, you assume the configuration is correct, and the silence kills you.

Here is the rule, in everyday English. Suppose your DMARC record on `acme.com` has `rua=mailto:dmarc@reports.vendor.com`. The receiver — Gmail, say — does this check before sending any reports:

1. Extract the destination domain from the URI: `reports.vendor.com`. 2. Construct the verification query name: `acme.com._report._dmarc.reports.vendor.com`. 3. Query DNS for a TXT record at that name. 4. If the response contains a `v=DMARC1` record, the destination is authorised. Send reports. 5. If no such record exists, the destination is NOT authorised. Discard the report silently.

The receiver does not bounce, log, or warn you when authorisation is missing. The reports just never arrive. If your team has never set up the authorisation record on the vendor side, you have a DMARC record that looks correct in every other respect but generates zero report traffic.

The rule applies separately to every destination URI you list. If you have `rua=mailto:reports@vendor-a.com,mailto:reports@vendor-b.com`, each vendor has to publish its own authorisation record.

EdgeDNS's DMARC endpoint runs the §7.1 check automatically for every cross-domain `rua=` and `ruf=` destination it finds. The response includes a structured `external_authorization` array — one entry per destination — with the verification record name, the result, and any DNS error from the lookup.

When the check returns `authorized: false`, the fix is on the vendor's side, not yours. You need to ask the vendor (or your own DNS team, if the destination domain is yours) to publish a TXT record at the specific name in the `checked_record` field. The content can be as simple as `v=DMARC1`.

Most reputable DMARC analytics vendors do this automatically when you onboard — you provide them with the list of monitored domains and they pre-publish the authorisation records. The ones that catch people out are:

• Vendors that require you to fill in a form before they publish — easy to forget to complete.

• Vendors that publish authorisation per-tenant rather than once globally — every new customer needs an explicit add.

• Internal DMARC processors hosted in a sibling business unit — you are technically a 'third-party domain' to their reporting mailbox.

If the vendor will not or cannot publish the record, your options are: (a) move the reports back to a same-domain destination, (b) switch vendors, or (c) accept that you are not receiving DMARC reports.

The vendor onboarding miss. Most painful version: a security team subscribes to a DMARC analytics vendor, adds the vendor's mailbox to `rua=`, waits two weeks, and reports start trickling in. Six months later, the team adds a new domain to the same vendor account — but forgets to ask the vendor to publish the authorisation record for the new domain. Reports for the original domain keep arriving (so the team thinks everything is fine); reports for the new domain silently disappear. The diagnosis is impossible without auditing each destination.

The internal-shared-services pattern. A holding company has `holding.com` and a security-tools subsidiary at `secops.holding.io`. Reports for every brand the holding company owns are routed to a central mailbox at the subsidiary. Because `secops.holding.io` is technically a different organisational domain from `brand-a.com` / `brand-b.com` / `brand-c.com`, each of those brands needs an authorisation record at `secops.holding.io`. Nobody knew, nobody published. Two years of reports lost.

The vendor name change. A DMARC vendor rebrands and rolls its email-receiving infrastructure to a new domain. Existing customers' rua= URIs keep pointing at the old name; the old name still accepts mail but the new authorisation records are only published at the new name. Reports stop arriving without any DNS or DMARC change on the customer's side.

The common thread is that DMARC authorisation, once it breaks, breaks silently. A weekly audit (one API call) is the only way to catch any of these in time.

Because authorisation breaks silently, the only effective control is automated monitoring. The minimum viable check is to run the DMARC endpoint against every monitored domain once a week, looking for any `external_authorization` entry where `authorized == false`. Anything that turns up gets a ticket on the security team's backlog.

The slightly fancier version is to combine the check with a 'are reports arriving?' signal — most DMARC vendors expose an inbox count per domain. The combination of `authorized: false` plus `report_count_last_7d: 0` is unambiguous: reports are missing AND we know why.

A cron-based one-liner using EdgeDNS:

DMARC — Domain-based Message Authentication, Reporting & Conformance. The policy layer for SPF and DKIM.

rua= — DMARC tag specifying where aggregate (daily summary) reports should be sent.

ruf= — DMARC tag for forensic (per-message failure) reports. The same §7.1 authorisation rule applies.

Aggregate report — daily XML file from each mailbox provider summarising authentication results for your domain. The thing the rua= destination receives.

Organisational domain — the shortest registrable parent of a domain. `mail.acme.com` and `web.acme.com` share the org domain `acme.com`; `acme.com` and `vendor.com` do not.

RFC 7489 §7.1 — the specific section of the DMARC RFC that defines the cross-domain authorisation check.