DNS Validator

One click validates everything email needs from your DNS: domain existence, MX routing, SPF, DKIM, and DMARC. Each protocol gets an honest, evidence-backed verdict — and a deep link to the dedicated checker when you want more detail.

Validate a domain's email DNS

One check covers domain existence, MX routing, SPF, DKIM, and DMARC — each with its own evidence and a link to the dedicated checker.

We query public DNS for NS, MX, and authentication TXT records on your behalf.

DKIM check

DKIM lives at a provider-specific selector. Choose how to look for it.

We query public DNS (NS, A, MX, and TXT records) for the domain you enter. The domain and results are used only to answer your request and are not stored.

How the DNS Validator works

Domain existence and MX come first

The validator checks that the domain is delegated in DNS (NS, with an A-record fallback) and that MX records exist so mail can actually be routed to it. A missing domain or missing MX is a hard failure regardless of authentication records.

SPF, DKIM, and DMARC run through the dedicated engines

The same server-side checkers that power the SPF, DKIM, and DMARC tools analyze the records — recursive include walk, DKIM key inspection, and the RFC 9989 policy tree walk included. No parser is reimplemented and no internal HTTP calls are made.

DKIM is handled honestly

Supply a selector for a definitive answer, or scan the common provider selectors. A scan that finds nothing is reported as unknown with guidance for finding your selector — never as a failure, because the selector may simply be uncommon.

You get counts, evidence, and a critical path

Summary counts, one evidence card per protocol, and recommendations ordered by severity. Timeouts and DNS failures stay unknown instead of counting as passes, and every card links to the dedicated tool for a deeper look.

What this validation does and does not tell you

  • This is a configuration check, not a deliverability guarantee: DNS can be perfect while reputation, content, or sending practices keep mail out of the inbox.
  • SPF validation is static — without a sending IP it cannot say whether a specific message passes.
  • A DKIM scan that finds no selector is inconclusive, not proof of absence; only a user-supplied selector with no record is a definitive DKIM failure.
  • DNS timeouts and server failures are shown as unknown and are never converted into pass or fail.
  • DMARC reporting destinations may ignore reports even when the record is valid; this validator does not verify that reports actually arrive.

Related free tools

SPF Record Checker

Deep-dive into the SPF record: mechanism table, include tree, and the RFC 7208 10-lookup limit.

Open tool

DKIM Record Checker

Inspect a specific DKIM selector’s key type, size, and flags in detail.

Open tool

DMARC Record Checker

See the full DMARC tag table, report destinations, and external authorization status.

Open tool

DNS Record Checker

Browse every record type — A, AAAA, MX, TXT, NS, CNAME, CAA, SOA, and SRV — for a domain.

Open tool

Deliverability Score

A transparent weighted score across authentication, blacklist, BIMI, and MTA-STS signals.

Open tool

Domain Scanner

A comprehensive email-domain security audit with a prioritized remediation plan.

Open tool

Frequently Asked Questions

What does the DNS Validator check?

It runs five checks against public DNS: whether the domain exists and is delegated (NS), whether it can receive mail (MX), and whether SPF, DKIM, and DMARC records are published and valid. Each protocol gets its own independent verdict — pass, warning, fail, or unknown — with the DNS evidence behind it and a link to the dedicated checker for that protocol.

Why is DKIM sometimes reported as “unknown”?

DKIM keys live at provider-specific selector names like google._domainkey or selector1._domainkey. If you scan the common selectors and none answers, the result is unknown — not a failure — because your provider may use a custom selector. Find the selector in the s= tag of a DKIM-Signature header on an email you sent, then run the check with that selector for a definitive answer. Only a selector you explicitly supplied that definitively has no record counts as failed.

What does “unknown” mean for the other protocols?

A DNS timeout, SERVFAIL, or refused answer means the check could not complete — it says nothing about whether the record exists. Unknown results are never counted as passing or failing; they are shown as unknown and you can retry. This matters because treating a timeout as “clean” would hide real misconfiguration.

Does a passing validation guarantee my mail reaches the inbox?

No. This tool reads DNS configuration only. Correct MX, SPF, DKIM, and DMARC records are necessary hygiene, but inbox placement also depends on sender reputation, engagement, content, and whether your provider actually signs and sends mail with these records. Think of the result as a configuration health check, not a deliverability prediction.

How many DNS queries does one validation use?

At most 43: NS (plus one A fallback), MX, up to 20 for the recursive SPF walk, up to 3 for the DMARC policy tree walk, up to 5 for DMARC external-report authorization, and either 1 for a supplied DKIM selector or up to 12 for the common-selector scan. Each query has a 4-second timeout, the checks run concurrently, and nothing is stored after the response is sent.

Which dedicated tools does this aggregate use?

The validation reuses the same server-side engines as the SPF Record Checker, DKIM Record Checker, DMARC Record Checker, and DNS Record Checker — it calls their library functions directly rather than re-checking over HTTP, so the evidence in each card matches what the dedicated tool would show.

Increase Your Sales Right Now

Automate Sales Outreach & Get Booked!

Start Free Trial

(14 Day Free Trial, No CC Required)