Verify your domain
After you add a domain, it shows a Pending badge — on its overview card, in the domain selector and on its settings page. This article explains exactly what flips a domain to Verified, why it sometimes takes longer than expected, and how to check things yourself while you wait.
What "pending" and "verified" mean
DMARCmetric verifies domains by receiving your first aggregate report. There is no verification code to paste and no separate ownership record: a valid DMARC report arriving at your unique rua+<token>@reports.dmarcmetric.com address proves the record is published on your domain, so the badge flips to verified automatically — no action needed. The domain's settings page then shows the date the first report was seen.
Until then the status is pending, which simply means: no DMARC report received yet. As the settings page puts it, reports begin within roughly 24–48 hours once the record is published and the domain actually sends mail — mailbox providers such as Google and Microsoft send aggregate reports on a daily cycle, so even a perfect setup involves some waiting.
"Verify DNS" is a different check
Both the setup wizard and the domain settings page have a Verify DNS button. This does not flip the badge — it runs a live DNS lookup of _dmarc. on your domain right now and tells you one of three things:
- Found it — your DMARC record is published correctly, and reports will start arriving within a day. Now it's just the reporting cycle.
- A DMARC record exists but its rua does not point to this domain's token — a record is live, but its
rua=doesn't include your unique reporting address. Set the value shown on the page exactly. - No DMARC record found yet — the record isn't visible in public DNS. Usually propagation; sometimes the record was saved at the wrong name.
Use Verify DNS to confirm your side of the work is done. The verified badge follows on its own when the first report lands.
Why verification can lag
If the badge is still pending after a day or two, it's almost always one of these:
- Record at the wrong host. The record must live at
_dmarc.yourdomain.com— not at the bare domain, not at_dmarc.www.yourdomain.com. A common slip: pasting the full name into a DNS panel that automatically appends your domain, producing_dmarc.example.com.example.com. - Value typos. The token must be copied exactly. Watch for "smart quotes" added by word processors or chat apps — DNS values must use plain characters — and for missing
;separators or an alteredmailto:. - DNS propagation. Changes usually show within minutes but can take hours depending on TTLs. Re-check with the Verify DNS button. If a changed record still comes back with its old value, that is a cached answer rather than a slow one — see Still seeing the old record? Clear your DNS cache.
- No real mail volume yet. Reporters only send a report when they actually see mail from your domain. A parked domain, or one that sends a handful of messages a week, generates few reports — the record can be perfect and the badge still pending simply because nothing has been observed yet. Sending a few normal emails to a Gmail mailbox is a legitimate way to prime the pump. For a full checklist of what to examine, see No reports yet.
Still seeing the old record? Clear your DNS cache
You corrected the record, but dig keeps returning the old value — or keeps returning nothing at all. That is almost always a cache answering, not a record that failed to save.
Every resolver between you and your DNS host keeps a copy of the previous answer until its TTL runs out: your operating system, your browser, your router, your ISP's resolver, and any public resolver you happen to query. The TTL that governs the wait is the one attached to the old answer, because that is the copy sitting in the cache — shortening the TTL today helps the next change, not this one. Absence is cached too: if nothing was published at _dmarc. when the first lookup ran, resolvers remember that "no record" answer for anywhere from a few minutes to an hour, which is why a freshly published record can still look missing.
Flushing the caches you control removes the local layers:
| Where | What to run | Notes |
|---|---|---|
| Windows | ipconfig /flushdns | Use an elevated Command Prompt or PowerShell. |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder | Run both halves — the second restarts the resolver that answers most lookups. |
| Linux with systemd-resolved | sudo resolvectl flush-caches | On older releases the command is sudo systemd-resolve --flush-caches. |
| Linux or a router running dnsmasq | sudo systemctl restart dnsmasq | Also the fix when a home router keeps serving the old answer; power-cycling it does the same job. |
| Chrome | chrome://net-internals/#dns | Chrome keeps its own host cache. Open that page and use "Clear host cache" — browsers cache independently of the operating system. |
Those commands stop at your own machine and your own network. Beyond them, dig @8.8.8.8 _dmarc.example.com TXT asks Google Public DNS directly and skips everything local — useful, but do not read it as the truth. Google Public DNS is a cache as well, and it caches failures: if it looked your name up before you published, it can go on answering "no record" until that negative entry expires.
For an answer that owes nothing to any cache, walk the delegation down from the root servers:
dig +trace _dmarc.example.com TXTOr ask the nameservers that actually host your zone:
dig +short NS example.com
dig @ns1.yourprovider.com _dmarc.example.com TXTIf the authoritative nameserver returns the record and the public resolvers do not, nothing is wrong — you are waiting out the previous TTL. Google Public DNS and Cloudflare each publish a cache-flush form that drops a single name from their own cache, which is worth knowing because our own checks read those two resolvers. Every other resolver in the chain expires the entry on its own schedule, and there is nothing you can do to hurry it. If the authoritative nameserver does not return it either, the record is not live where you think it is: check the host name and the DNS provider again, as covered in No reports yet.
The same caching applies to us. The Verify DNS button and our free DMARC record lookup both resolve over DNS-over-HTTPS, with Google as the primary resolver and Cloudflare as the fallback, so they report what those two resolvers currently hold — not what your nameserver started serving a minute ago. If a lookup disagrees with dig +trace, wait a few minutes and run it again before changing anything.
Check the record yourself
You don't have to wait for the button — any machine with dig or nslookup can query your record directly:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comYou should see one line beginning v=DMARC1 whose rua= contains your rua+<token>@reports.dmarcmetric.com address. Two records starting v=DMARC1 is a misconfiguration — receivers treat that as no record at all, so merge them into one.
Prefer a browser? Run your domain through our free DMARC checker — it fetches the live record and explains its policy, reporting and alignment tags, no sign-in needed.
After verification
The moment the first report is stored, the domain flips to verified and its dashboard starts filling in: message volume, sending sources, pass rates and threats. Early numbers are naturally sparse — one report from one provider covers only the mail that provider saw — and the picture rounds out over the first week as more operators report in.
While the data accumulates, it's a good time to learn what you're looking at: How to read a DMARC report walks through what these reports contain and how to tell a misconfigured sender from a spoofing attempt.