Your DMARC reports go to a vendor. Did the vendor agree to receive them?

You set up DMARC. You added a rua= tag so the aggregate reports go somewhere you'll actually read them, which for most people means a third-party service, mailto:[email protected] or a Valimail or Postmark address. Reports started arriving, you saw the dashboard fill in, and you moved on. Reasonable.

Here's the part that's easy to miss. When your DMARC record points reports at a domain that isn't yours, the receiving mail servers of the world don't just take your word for it. There's a rule in the DMARC spec, RFC 7489 section 7.1, that says: before any receiver sends a report to an address on a different domain than the one being reported on, it must check that the other domain has agreed to receive them. If that agreement isn't published in DNS, the receiver is required to ignore the destination and send nothing.

So you can have a perfectly valid rua=, a working vendor, a dashboard you check, and still be getting a fraction of the reports you should, or none, because the authorization record was never added. The reports you don't get are invisible by definition. Nothing errors. The dashboard just looks quieter than reality.

The record that has to exist on the other end

The authorization works by reversal. Your domain says "send my reports to the vendor." The vendor's domain has to say back "yes, I'll accept reports about that domain." That second half is a TXT record the vendor publishes, named with your policy domain in front of theirs.

If your DMARC at yourdomain.com sends reports to [email protected], then reports.vendor.com must publish a TXT record at yourdomain.com._report._dmarc.reports.vendor.com with the value v=DMARC1. A receiver about to send your report looks that record up first. Present, it sends. Absent, it drops the destination on the floor, exactly as the spec tells it to.

Vendors can publish a wildcard, *._report._dmarc.reports.vendor.com, to authorize every customer at once, and many do. So the check looks for both: the exact per-domain record and the wildcard. Only when neither exists does it flag the destination, because either one satisfies the spec.

Why this is a real gap, not pedantry

The instinct is to file this under "tidy your DNS," but the consequence is sharper than that. DMARC reports are the entire feedback loop. They're how you see which servers are sending mail as your domain, what's passing SPF and DKIM, and what's failing. They're the data you use to safely move from p=none to enforcement without blackholing your own legitimate mail.

Lose the reports and you lose the only instrument you had. You're flying on p=none with no way to ever tighten it, because you can't see what would break if you did. Or worse, you think you have visibility, the dashboard is right there, but it's built on a partial feed and you don't know what's missing from it. The gap doesn't spoof your mail or break delivery. It blinds the one mechanism that was supposed to let you fix the rest, and it does it without a single error message.

This is a separate problem from the two DMARC gaps that get more attention. It isn't p=none watching spoofed mail go by, and it isn't sp=none reopening the door on subdomains. Your policy can be p=reject; sp=reject and perfect, and this still silently switches off your reporting. It's a different tag failing in a different way.

The fix is one record, on the right domain

Two clean options. Publish the authorization record the spec wants, or point your reports at your own domain so no authorization is needed in the first place.

# your DMARC, reports to a vendor domain
_dmarc.yourdomain.com  TXT
"v=DMARC1; p=reject; rua=mailto:[email protected]"

# nothing published on the vendor side

If you use a DMARC vendor, they document the exact _report._dmarc record to add and which side adds it; the fix is usually copying one TXT entry into your DNS or theirs. If you'd rather not depend on it, send rua= to a mailbox on your own domain, where the same-domain case skips the authorization requirement entirely, and forward from there if you want the vendor's parsing.

The check is careful about when it fires, because a transient DNS hiccup shouldn't look like a missing record. It only flags a destination when both the exact and wildcard authorization lookups come back as a clean, authoritative "not found" from a working resolver, never on a timeout or a SERVFAIL. And it only looks at destinations on a different registrable domain than your policy, because a report address on your own domain needs no authorization.

SurfaceCheckr reads your _dmarc TXT record from public DNS, the same plain lookup you'd run by hand, then does the follow-up the spec calls for: for every external report destination, it checks whether that domain published the record that makes the reporting legal. No mail is sent and nothing is crafted. It's the one extra DNS query that tells you whether the reports you think you're collecting are actually allowed to reach you, which is a thing worth knowing before you trust the dashboard built on them.