DNS Record Checker - Verify SPF, DKIM, DMARC & More

Free Online DNS Lookup Tool — Check A, MX, TXT, NS, CAA and More

Enter a domain and this DNS lookup tool queries nine record types at once — A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA — and returns the values, the TTLs and a plain-English reading of what they mean. It goes further than a raw dig dump: it parses your SPF and DMARC records, identifies which DNS provider and which email provider you are actually using, and scores the domain’s DNS configuration out of 100 with a letter grade and a list of specific fixes.

It is built for the people who spend their week in DNS: sysadmins moving a domain to a new host, email admins chasing a deliverability problem, security teams checking whether a domain has CAA records before a certificate issue, and web developers who need to know whether a change has actually taken effect. Queries run over DNS-over-HTTPS against Cloudflare’s public resolver, so results reflect a real public recursive resolver rather than whatever your laptop happens to have cached.

Every Record Type, and What It Is Actually For

One record type deliberately sits outside this list: PTR. A PTR record maps an IP address back to a name, and it lives in the reverse zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) rather than in your domain’s forward zone. It is normally controlled by whoever owns the IP block — your hosting provider or ISP — not by you, which is why a forward lookup on a domain name never returns one. It matters most for outbound email: many receiving servers reject or penalise mail from an IP with no PTR, or with a PTR that does not match the sending hostname.

How to Use This DNS Lookup Tool

1. Type a domain name. Full URLs and trailing slashes are cleaned up automatically, so https://example.com/page resolves as example.com.
2. Optionally narrow the record types using the type selector if you only care about, say, MX and TXT.
3. Run the lookup. Records appear in a table grouped by type, each with its TTL and a copy button; the whole result set can be exported.
4. Read the health score. The grade is derived from concrete checks: are A records present, is there IPv6, are MX records configured with a backup, is SPF present, is DMARC present, are CAA records set, are TTLs sane, and are there at least two nameservers.
5. Work the recommendations list. Each item is a specific, actionable change rather than a generic warning.

Reading SPF, DKIM and DMARC

All three email-authentication mechanisms are published as TXT records, and the tool parses them rather than just printing them. An SPF record such as v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all is broken into its mechanisms — which senders are authorised — and its qualifier. The final term matters most:

• -all (hard fail) — anything not listed is unauthorised. The correct end state.
• ~all (soft fail) — treat unlisted senders with suspicion but still accept. A reasonable place to sit during rollout.
• ?all (neutral) or +all — effectively no policy. +all authorises the entire internet to send as you; it is always a misconfiguration.

SPF also has a hard limit of ten DNS-resolving mechanisms (include, a, mx, ptr, exists, redirect). Exceed it and the record returns permerror, which many receivers treat as no SPF at all. The ptr mechanism is deprecated and should be removed wherever you find it.

DMARC lives at _dmarc.yourdomain.com and ties SPF and DKIM results to the visible From address through alignment. Its policy tag runs p=none (monitor only) → p=quarantine → p=reject. Publishing p=none with an rua= reporting address is the correct first step; leaving it there permanently is the most common half-finished email-security project in existence. If you need to build or repair these records, the SPF record generator and DMARC record generator produce syntactically valid records for you.

TTL, Caching and What “Propagation” Really Means

DNS has no push mechanism, so nothing actually propagates. What happens is simpler and more predictable: every record carries a TTL in seconds, and any resolver that has already answered for that name will keep serving its cached copy until the TTL expires. When people say a change is “still propagating”, what they mean is that caches populated before the change have not yet aged out.

The practical consequence is that you control your own migration window in advance. Lower the TTL on the records you are about to change to 300 seconds, wait for the old TTL to fully elapse so every cache holds the short value, then make the change — and the world follows within five minutes. Do it in the other order and you wait out the old TTL regardless.

Two other caching behaviours catch people out. Negative answers (NXDOMAIN) are cached too, governed by the minimum field in the SOA record, so a name you query before creating it may appear missing for a while afterwards. And some resolvers and operating systems clamp or ignore very low TTLs, so five minutes is a floor rather than a guarantee.

Very long TTLs earn a warning in the health score for exactly this reason: a 24-hour TTL is fine on a stable NS record and a liability on an A record you may need to move in an emergency.

Authoritative Versus Cached Answers

An authoritative answer comes from a nameserver listed in the domain’s NS records — the server that holds the zone. A cached (non-authoritative) answer comes from a recursive resolver repeating something it learned earlier. This tool queries a public recursive resolver, so its answers are recursive, and the TTL shown is the remaining lifetime in that resolver’s cache rather than the full configured value. A TTL of 3600 on one lookup and 2841 thirty seconds later on the next is the cache counting down, not a configuration change.

To read the value straight from the source, query an authoritative nameserver directly: dig @ns1.example.com example.com A. The reply will lack the ra flag and carry aa (authoritative answer), and the TTL will be the full configured value every time. Comparing an authoritative answer against a recursive one is the definitive way to tell “my change is not live” from “my change is live but still cached somewhere”.

Related Tools

Pair a DNS lookup with the WHOIS lookup to see registration and registrar detail, the SSL certificate checker to confirm the certificate served at the address the A record points to, and the subnet calculator when you are working out which network an answer belongs to.

Frequently Asked Questions

Which record types does this tool query?

A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA. You can select a subset if you only want specific types.

Why does my new record not show up?

Either it has not been saved at the authoritative nameserver, or a resolver is still serving a cached answer or a cached NXDOMAIN. Query your authoritative nameserver directly to tell the two apart — if the record is there, it is a caching delay and it will clear when the TTL expires.

Can I look up a reverse DNS (PTR) record here?

No — this is a forward lookup on a domain name, and PTR records live in the reverse in-addr.arpa zone controlled by whoever owns the IP address. Ask your hosting provider or ISP to set or correct one.

What TTL should I use?

3600 seconds (one hour) is a sensible default for A, AAAA, CNAME and MX records. Use 300 seconds during a planned migration, and 86400 for records that essentially never change. Set the short TTL at least one old-TTL period before you need it.

Why do I have two SPF records?

You should not. A domain may publish only one v=spf1 TXT record; two produce a permanent error and receivers may ignore SPF entirely. Merge them into a single record by combining the include: mechanisms, keeping the total resolving lookups at ten or fewer.

Do I need CAA records?

They are not required, but they are cheap insurance. A CAA record tells every public certificate authority which of them may issue for your domain, so a mis-issuance attempt through a CA you do not use is refused at the source. One line such as 0 issue "letsencrypt.org" is enough to start.

What does the health grade actually measure?

Concrete configuration facts, not opinion: presence of A and AAAA records, MX configuration and redundancy, SPF, DKIM and DMARC presence, CAA records, TTL sanity, and whether the domain has at least two nameservers. Each contributes to a score out of 100 which maps to an A–F grade, and each deduction comes with the specific recommendation that would fix it.

Why does the tool say I am using a provider I have never heard of?

Provider detection reads the NS records for DNS and the MX records for email, then matches them against known hostname patterns. If your mail routes through a security gateway, the MX will show the gateway; the tool then checks DKIM selectors and SPF includes to infer the mailbox provider sitting behind it. A resold or white-labelled service can surface as the underlying vendor.

Is a CNAME allowed at the root of my domain?

Not in standard DNS. A CNAME must be the only record at its name, and the apex necessarily carries SOA and NS records. Providers work around this with ALIAS, ANAME or CNAME-flattening records that resolve the target server-side and answer with an A record.

Is my lookup logged?

The domain you enter is sent to a public DNS-over-HTTPS resolver to answer the query — that is unavoidable for any DNS tool. Nothing is stored on our side, and results are not associated with you.