Is your DMARC actually being checked? What DNS lookups reveal

You published SPF, DKIM and DMARC, a checker website says all three look fine, and mail still lands in spam at some providers. Or the DMARC reports you expected never come. Before guessing, there is a simpler question to answer: are receivers even finding your records?

1 What a receiver looks up

When a message arrives, the receiving server asks DNS for:

Every check depends on the lookup succeeding. A typo in a name, a record in the wrong zone or a selector that only exists at your mail provider all look the same to the receiver: no record, so no check.

2 Check your records from a real message

Send a message to an outside mailbox and open the full headers. The DKIM-Signature line tells you exactly what the receiver will query:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2025; ...

dig +short TXT mail2025._domainkey.example.com     # the DKIM key for s=mail2025, d=example.com
dig +short TXT _dmarc.example.com                  # the DMARC policy
dig +short TXT example.com | grep 'v=spf1'         # the SPF record: exactly one line expected

The receiver's verdict is in the Authentication-Results header of the received message (spf=pass, dkim=pass, dmarc=pass). If DNS returns the records and the header still says none or fail, the problem is alignment or signing, not DNS.

2.1 Mistakes that silently stop a check

• A record with the zone name twice. Typing the full name into a panel that appends the zone produces _dmarc.example.com.example.com. Query the exact name with dig.
• Two SPF records. SPF allows one v=spf1 record per name; with two, receivers return an error and many treat it as no SPF.
• Too many SPF lookups. SPF evaluation stops after 10 DNS-querying mechanisms (include, a, mx, exists, redirect); nested includes from several mail services reach that quickly.
• The DKIM selector exists only at the provider. Some services ask you to publish a CNAME from your selector to theirs; if that step was skipped, the signature cannot be verified.
• DMARC on the wrong domain. DMARC is looked up for the From domain. If you send as news.example.com, the receiver looks for _dmarc.news.example.com first, then _dmarc.example.com.

3 What DNS queries reveal

Your authoritative DNS sees every lookup that reaches it. That gives you a view no mail tool has: not what the receiver decided, but whether it asked.

• MX, SPF and DMARC lookups move together. Mail you send causes receivers to look up SPF and DMARC; mail sent to you causes lookups of your MX. In one zone in our data, DMARC lookups were about 5% of MX lookups and SPF about 26%; in another, SPF lookups matched MX but DMARC lookups were zero, which pointed straight at a missing DMARC record.
• A selector that receivers ask for and does not exist means mail is signed with a key nobody can find.
• The networks asking show who receives your mail. In example data for a newsletter sent from our own domain, DKIM and DMARC lookups came from Microsoft (about 14%), Cloudflare (13%), Google (10%), Amazon (10%), Ringier Axel Springer / Onet (10%), Hetzner (10%), home.pl, Yahoo, Interia and WP. Polish mail providers run their own recognisable resolvers; about 37% of lookups came through networks (public resolvers, cloud hosts) that do not identify the receiver.

3.1 Most failed DKIM lookups are scanners

In the same example data, more than half of all DKIM lookups ended in NXDOMAIN. Almost all of them were sweeps: one source asking for protonmail, protonmail2, fm1, fm2, zendesk1 and dozens of other common selector names in a row, often through public resolvers, to discover which services a domain uses. They say nothing about your mail. The signal worth acting on is narrower: a selector that appears in your own DKIM-Signature headers and comes back NXDOMAIN, asked for by mail providers' resolvers, repeatedly.

4 How PrimeDNS handles this

• Email DNS health in PrimeDNS Observability shows MX, SPF, DMARC and DKIM lookups per zone side by side, with their ratio to MX and the trend, so a DMARC record that nobody can find shows up as a gap in the chart, not as a guess.
• Top NXDOMAIN names reveal selectors and policy names that receivers ask for and that do not exist.
• The networks that query you show which mail providers are actually checking your records.
• SPF, DKIM and DMARC wizards above the record table build each record with the right name and syntax, which removes the most common typos.
• The Audit Log shows when a mail record was changed and by whom, which is often the answer to "it worked last week".

Setup steps are in the SPF, DKIM and DMARC guide; the charts are explained in the Observability guide.

Data: example data from the PrimeDNS nameservers for our own domains, aggregated per network. No customer domains or resolver addresses are published. Network names are those registered for the autonomous systems and belong to their owners.