No reports yet? What to check

Updated 2026-08-03 · Troubleshooting

You added your domain, published the TXT record, and the dashboard is… empty. This is the most common question we get, and in the large majority of cases nothing is wrong — the reporting cycle simply hasn't turned over yet. But not always. This article walks the causes in order of probability, with a concrete check for each.

The 60-second version:

What the dashboard shows while you wait

First, what "waiting" honestly looks like, so you can recognise it. A domain with no reports shows a Pending badge on its overview card, a compliance ring showing —, and charts that read "Awaiting report data…". Its detail page says "awaiting first report" in the status line above the title, and the Sending sources table shows "No sending sources in this period."

None of that indicates a fault. It is the normal state of every domain between publishing the record and the first report arriving — and the badge flips to Verified automatically the moment that first report is stored. Nothing to click.

Most likely: nobody has sent a report yet

Mailbox providers send aggregate reports on a daily batch cycle — most operators generate one report per day, covering the previous 24 hours, typically dispatched around midnight UTC. So even a flawless setup involves waiting: the first reports usually arrive 24–48 hours after two things are both true — the record is live in public DNS, and real mail from your domain is reaching that provider's users.

Note where the clock starts: when the record became visible, not when you added the domain to DMARCmetric. If you published the record this morning, an empty dashboard tonight means nothing at all. Check back tomorrow before troubleshooting anything.

Next: is the record really published?

If 48 hours have passed, verify the record from the outside. Any machine with dig or nslookup can do it:

dig +short TXT _dmarc.yourdomain.com

You want exactly one line beginning v=DMARC1. If you don't see it — or see something mangled — the usual suspects, in order:

• Wrong host name. The record must live at _dmarc.yourdomain.com. A common slip is pasting the full name into a DNS panel that auto-appends your domain, producing _dmarc.yourdomain.com.yourdomain.com.
• Smart quotes or typos. Values copied through word processors or chat apps can pick up curly quotes; DNS values need plain characters. A missing ; between tags breaks parsing too.
• Published at the wrong DNS provider. The record must be added wherever your domain's nameservers actually point. If the domain runs on Cloudflare but you edited the registrar's DNS panel, the record exists — invisibly. Check with dig +short NS yourdomain.com and make sure you edited that provider.
• Two DMARC records. Two TXT lines starting v=DMARC1 is treated by receivers as no record at all. Merge them into one.

Two results here are easier to misread than they look. A lookup that keeps returning a record you have already replaced is usually a cached answer rather than a missing one. And a record flagged as a policy that is not enabled needs splitting in two: p=none changes what receivers do with failing mail, not whether reports reach you, while a p= tag that is missing or holding an invalid value is a real defect — with no usable rua beside it, receivers disregard the record altogether, reporting included; with a valid rua they fall back to monitoring and the reports keep flowing.

Prefer a browser? The free DMARC checker fetches the live record and explains its policy and reporting tags, and the Verify DNS button on your domain's settings page runs the same live lookup from inside the product.

Check the rua address character by character

Reports reach your workspace through the unique address in your record's rua= tag — it must contain rua+<your-token>@reports.dmarcmetric.com exactly as shown on your domain's settings page. The token is what routes reports to your account, so a single mistyped character sends them nowhere.

Two failure shapes to look for in your dig output:

• The rua= points somewhere else entirely — an old monitoring tool, or a personal mailbox from a previous experiment. The reports are flowing; they're just not coming here. Replace the address (or add ours alongside, comma-separated).
• The token is present but altered — truncated in a copy-paste, or wrapped in quotes that became part of the value. Re-copy it from the settings page; the Verify DNS button will tell you explicitly when a record exists but its rua doesn't match your token.

Does the domain actually send mail?

Reporters only generate a report when they observe mail claiming to be your domain. A parked domain, a brand-protection registration, or a domain that sends a handful of messages a week can have a perfect record and still see nothing for days — and some operators skip reporting on very small volumes altogether.

If that's your situation, prime the pump: send a few ordinary emails from the domain to a Gmail or Outlook.com mailbox you control. That guarantees at least one major reporter has traffic to report on the next cycle.

When the first report lands

The domain flips to Verified — that badge literally means "first aggregate report received and stored", as explained in Verify your domain — and the charts start filling in. Don't judge the numbers on day one: each reporter describes only its own slice of your traffic, so give it a week or so for enough operators to report in and the full shape to emerge. That's when the real work starts: reading what the reports say about who is sending as your domain.