Free tool · no signup
Free DNS record checker
Look up every DNS record on a domain and find the faults that a list of records cannot show you. Mail records are read from six independent resolvers at once, so you can also see which of them have not caught up with your last change.
Ungated · no email required · unlimited checks
In short
- This is a free, ungated DNS record checker from SmartReach.io. It reads the A, AAAA, MX, TXT, NS, SOA, CNAME and CAA records published for a domain and reports what each one contains, along with the TTL that governs how long a stale copy of it can survive.
- MX, TXT and NS records are queried against six independent public resolvers in parallel (Google, Cloudflare, OpenDNS, AdGuard, Control D and DNS.SB) rather than one, and the check reports how many of them returned a different answer and which. Those three types get the full panel because nobody geo-routes them, so a disagreement is unambiguous; address records are read from two, because they legitimately differ per resolver behind any CDN. Agreement is evidence from caches and is not proof of global propagation.
- For each mail host it also reports the network that owns the address behind it, as an AS number and operator name, and whether that address has a reverse DNS record.
- It reads the three transport policies that live in DNS beside SPF and DMARC: MTA-STS, TLS-RPT and BIMI. A domain publishing an MTA-STS record whose policy host does not exist is reported as a fault, because senders honouring MTA-STS then cache nothing and fall back to opportunistic TLS while the protection reads as switched on.
- It resolves over DNS-over-HTTPS, which provides no way to query a domain's own nameservers, so no answer here is authoritative. It reports what public resolvers currently hold, which is what receivers and browsers actually see.
- Beyond listing records, it checks them against each other and reports the faults that only exist in combination: a CNAME at the domain apex voiding the MX and TXT records beside it (RFC 1034), an MX record pointing at an alias (RFC 2181), an MX naming a host with no address record, two SPF records cancelling out to no SPF policy (RFC 7208), and a domain with no MX record where mail silently falls back to the web server (RFC 5321).
- A null MX record (0 followed by a single dot) is reported as a deliberate declaration that a domain accepts no mail, per RFC 7505, rather than as a fault.
- DNS cannot enumerate the names within a zone, so no checker can list every record a domain publishes. DKIM keys live at selectors that cannot be discovered and are checked by a separate tool.
Paste a domain, a URL or an email address. Mail records are read from six independent resolvers, so the check can show which of them still disagree.
What this DNS record checker does
A DNS record checker reads every record published for a domain and tells you what is actually live. This one reads A, AAAA, MX, TXT, NS, SOA, CNAME and CAA, queries the mail records against six independent resolvers so it can show which have not caught up with your last change, and reports the faults that only exist between records rather than in any one of them. It is built by SmartReach.io, a cold email software that runs email, LinkedIn, calls and WhatsApp from one sequence, because the records on this page are the ones that decide whether cold email is delivered at all. The tool is free and ungated, with no signup and no limit on the number of domains you check.
Method
How to check the DNS records on a domain
Checking DNS records takes five steps, and the order matters more than the tool. Read the findings before the record list, because a domain whose records are each correct can still fail to receive mail.
- 1
Enter the domain, not the hostname you send from
Type the registrable domain, such as example.com rather than mail.example.com. MX, SPF and DMARC are published at the domain apex, so checking a subdomain reports records that were never meant to be there. Pasting a URL or an email address works, because the checker takes the domain out of either.
- 2
Read the findings before the records
The record list tells you what is published. The findings tell you what is wrong with the combination, which is where the faults that break email actually live. Errors are ordered first, then warnings, then notes that are true but not urgent.
- 3
Check where the mail goes, and who owns it
Every MX host is resolved and reported with the network that owns the address behind it, as an AS number and operator name. An MX pointing at a provider you no longer pay for is a common and completely silent fault, and the operator name is what makes it obvious.
- 4
If a record looks wrong, open the resolver breakdown
Each record shows what every individual resolver returned. If they disagree, the change is still propagating and the TTL tells you how much longer. If they agree and the value is still wrong, the change never reached your nameservers and the problem is in your DNS panel.
- 5
Fix the record, then re-check after the TTL
A correction is not live for anyone who already looked until their cached copy expires. Read the TTL on the record you changed, wait that long, then run the check again and confirm every resolver agrees on the new value.
Why a list of records is not a check
Why do my DNS records look right but email still fails?
Because every record on a domain can be individually correct while the combination is broken. These are the faults a per-type table cannot show you, since none of them is visible in any single record. The free DNS record checker from SmartReach.io reports each one by name, with the RFC it breaks and the fix.
RFC 1034
A CNAME at the domain apex
A CNAME must be the only record at its name. Published at the apex, it voids the MX and TXT records sitting beside it: your DNS panel shows them, and receivers are entitled to ignore them. SPF and DMARC records published there are not seen.
RFC 2181
An MX pointing at an alias
An MX record must name a host with an address record, not a CNAME. It resolves today because most receivers follow the chain anyway. The ones that do not defer or reject your mail, and nothing in your logs says why.
RFC 5321
An MX naming a host with no address
The MX record is present and looks correct, and the name it points at has no A or AAAA record behind it. There is nothing to connect to. Usually a typo, or a mail host decommissioned without the MX being updated.
RFC 7208
Two SPF records
A domain may publish one. Two is a permerror, and the required result is that receivers treat the domain as having no SPF policy at all. They do not add up, they cancel out, which is why adding a second vendor’s record can make deliverability worse overnight.
RFC 5321
No MX record at all
Mail does not bounce. Senders are required to fall back to the A record, so your mail is delivered to your web server. If the domain should not receive mail, a null MX record says so explicitly and stops the retries.
RFC 1035
Records the resolvers disagree about
Some resolvers hold the new value and others still hold the old one. For MX, TXT and NS that means a change part-way through propagating, and the TTL tells you how much longer it has to run. The check names which resolvers dissented rather than only that some did.
RFC 1035
An MX pointing at an IP address
An MX record must name a host, not an address literal. Receivers are not required to accept one, and many treat the domain as having no valid MX at all. The record looks populated in your DNS panel and routes nothing. Publish an A record for a hostname and point the MX at the name.
RFC 7208
No SPF record at all
Nothing says which servers may send as your domain, so receivers have one less reason to trust the mail and DMARC has nothing to align a pass against. It is not a fault in any single record, it is an absence, which is exactly what a list of what you do publish will never draw your attention to.
RFC 8461
An MTA-STS record with no policy behind it
The TXT record at _mta-sts tells senders a TLS policy exists; the policy itself is served over HTTPS at a well-known path. Publish the record without the host and senders that honour MTA-STS cache nothing and fall back to opportunistic TLS. The protection reads as switched on and is doing nothing, and checking either half alone cannot see it.
Propagation
How long does a DNS change take to propagate?
As long as the TTL on the record you changed, and no longer. The TTL is a number of seconds attached to every record telling resolvers how long they may keep it cached, so a record with a TTL of 3600 can take an hour to reach someone who looked recently, and one with 86400 can take a day. Anyone who has never asked before sees your new value immediately. There is no separate global propagation process waiting to finish, which is why the honest way to check is to ask several independent resolvers and see which ones still hold the old answer.
What six resolvers can and cannot prove
This checker reads MX, TXT and NS from Google, Cloudflare, OpenDNS, AdGuard, Control D and DNS.SB at the same time, and names the ones that returned something different. A record all six agree on has almost certainly settled. A record they split on definitely has not. Neither statement covers every resolver on the internet, and a tool checking twenty-five locations cannot claim that either. Address records are read from two resolvers on purpose, because a site behind a CDN is meant to return different addresses in different places, so a disagreement there is usually the CDN working rather than a change in flight.
The practical move is to lower the TTL to 300 seconds a day before a planned change, make the change, confirm every resolver agrees, then raise the TTL again. For sending domains this matters more than it looks, because a stale MX or SPF record is not a delay, it is mail going to the wrong place or failing authentication while it does.
Reference
What are the DNS record types, and what does each one do?
Eight record types cover almost everything a domain publishes. Four of them decide whether mail is delivered at all, and those are the ones this checker reads from six resolvers rather than two.
| Type | Name | What it does |
|---|---|---|
A | Address | The IPv4 address a name points to. This is what a browser follows to load your site. |
AAAA | IPv6 address | The same thing for IPv6. A domain can have both, and most large sites do. |
MX | Mail exchangeemail | The servers that accept mail for the domain, each with a preference number. The lowest number is tried first. |
TXT | Textemail | Free-form text. Your SPF record lives here, as do the verification strings services ask you to publish. |
NS | Nameserver | The nameservers responsible for answering questions about this domain. Set at your registrar. |
SOA | Start of authority | One record per zone, carrying the primary nameserver, the admin contact and the zone’s timers. |
CNAME | Canonical name | An alias pointing one name at another. It must be the only record at its name, which is why one at the apex breaks mail. |
CAA | Certificate authority authorization | Which certificate authorities are allowed to issue certificates for the domain. Optional, and cheap protection. |
What this check cannot tell you
Can a DNS checker see my authoritative nameservers?
No, and no tool resolving over DNS-over-HTTPS can. What follows is what this check cannot see, stated plainly, because a checker that hides its limits is the one that gives you a clean result on a broken domain.
These are cached answers, not authoritative ones
The check resolves over DNS-over-HTTPS through Google, Cloudflare, OpenDNS, AdGuard, Control D and DNS.SB, which returns what those resolvers currently hold. DNS-over-HTTPS gives no way to query your own nameservers directly, so nothing here is an authoritative answer. It is what the internet currently believes, which is the more useful of the two for most questions and is not the same thing. If you need the authoritative answer the instant you publish, before any cache expires, use dig with your nameserver named directly.
Six resolvers agreeing is not proof of global propagation
It is evidence from six independent caches, and that is all we claim. A record all six agree on has almost certainly settled; a record they split on has definitely not. Neither statement covers every resolver on the internet, and the tools that check twenty-five locations cannot honestly claim it either. The count of resolvers that actually answered is shown beside every record, so the strength of the evidence is never implied.
Only the mail records get the full panel
MX, TXT and NS are read from all six resolvers, because nobody geo-routes those and a disagreement means a change is still in flight. Address records are read from two, deliberately: a site behind any CDN is meant to return different addresses to resolvers in different places, so six opinions on an A record produce noise rather than signal. Each record says how many resolvers stand behind it.
DNS cannot list every record on a domain
There is no query that enumerates names within a zone. A checker can only ask about names it already knows, which is why DKIM keys, published at selectors that cannot be discovered, are not part of this check. The DKIM checker probes a list of known selectors instead, and reports what it found at the names it tried rather than claiming a domain has no DKIM.
This page reports that SPF and DMARC exist, and stops there
Counting SPF records is a property of the TXT set already on screen, so a duplicate is reported here. Evaluating one is a different job: resolving the include tree, counting it against the ten-lookup limit, reading a DMARC policy and its alignment. Those are separate tools, linked below, and doing the work in two places would eventually mean two tools that disagree.
Once you know which record is wrong
Which tool should I use to check SPF, DKIM and DMARC?
A DNS check tells you that a record is published and structurally sound. It does not resolve an SPF include tree against the ten-lookup limit, validate a DKIM key, or read what a DMARC policy actually does to failing mail. Each of those is its own tool, so the answers cannot drift apart. If you do not yet know which of the three is at fault, the combined checker reads all of them on one domain in a single pass.
Which servers may send as you
SPF Checker
SPF lists the servers allowed to send mail for your domain. Check that yours is published, resolves, and stays under the ten-lookup limit that silently breaks it.
What it looks like
v=spf1 include:_spf.google.com ~all
Proof the message is really yours
DKIM Checker
DKIM signs every message with a key only you hold. Check that the public key is published, parses, is not revoked, and is long enough to be trusted.
What it looks like
v=DKIM1; k=rsa; p=MIIBIjANBgkq…
What happens when a check fails
DMARC Checker
DMARC tells receivers whether to quarantine or reject mail that fails SPF and DKIM, and where to send the reports. Check your policy, alignment and reporting address.
What it looks like
v=DMARC1; p=reject; pct=100
All three records, one pass
Email Authentication Checker
Check SPF, DKIM and DMARC on any domain at once. See which of the three are missing, which are broken, and which are published but not actually enforcing anything.
What it looks like
SPF pass · DKIM pass · DMARC p=reject
The behaviour described on this page is defined by the standards, not by us. A CNAME being the only permissible record at a name is RFC 1034. An MX naming a host rather than an alias is RFC 2181. The fallback from a missing MX to the address record is RFC 5321. Two SPF records being a permerror is RFC 7208. The null MX record is RFC 7505, and MTA-STS is RFC 8461. Lookups run over DNS-over-HTTPS, RFC 8484. Last reviewed . The check is free and ungated, and the domain you enter is not stored or logged.
FREQUENTLY ASKED QUESTIONS
DNS questions, answered
Stop fixing deliverability one DNS record at a time.
Every record on this page is one you have to publish by hand, and one you can get wrong silently. SmartReach.io is a cold email software that runs email, LinkedIn, calls and WhatsApp from one sequence, and its Sales Engagement plans add the calling and LinkedIn steps with no per-seat pricing. It buys and authenticates your sending domains and mailboxes with SPF, DKIM and DMARC already in place, then warms them, rotates the sends across them, and verifies every address before a campaign goes out.