DNS Lookup — Check A, MX, TXT, NS and CNAME Records

Instantly look up DNS records for any domain — A, AAAA, MX, TXT, NS, CNAME, SOA, and CAA. This free DNS lookup tool queries the public DNS resolver directly from your browser with no sign-up, no API key, and no rate limits.

Each Record Type Answers a Different Question

A domain does not have one DNS entry; it has a set of them, and each one exists to answer a specific question a different piece of software is asking. Knowing which question you have tells you which record to look up.

The NS row is the one to check first when something makes no sense at all. If the nameservers listed are not the provider you have been editing, every change you have made has been going to a zone nobody consults.

TTL Is Why Your Change Has Not Appeared

Every record carries a time to live: the number of seconds a resolver may keep the answer before asking again. It is the single most useful number in a DNS result and the most frequently ignored.

When you edit a record, the authoritative server updates immediately. Every resolver that already cached the old answer keeps serving it until its copy expires. A TTL of 86400 seconds means some networks may continue handing out the previous value for up to a day.

The practical consequence is a planning one. If you know a change is coming, lower the TTL well in advance — long enough before the change that the old, long TTL has expired everywhere. Dropping it to a few minutes an hour before you switch achieves nothing, because the resolvers still holding the old record are also holding the old TTL.

Nothing Actually Propagates

"DNS propagation" describes the delay accurately and the mechanism misleadingly. No update travels outward through the internet. The authoritative answer changes in one place at one moment, and everywhere else simply continues serving what it already had until that copy expires.

This explains behaviour that otherwise looks random. A colleague sees the new site while you see the old one, because your resolvers cached at different times. Your phone on mobile data is correct while your laptop on the office network is not, for the same reason. Nothing is broken and nothing is half-finished — you are looking at two caches with different expiry times.

It also explains why the usual advice works. Flushing your local cache or querying a public resolver directly bypasses whichever cache is holding the stale copy. It does not speed anything up for anyone else.

The Three Records That Decide Whether Your Mail Is Trusted

Mail authentication is published entirely as TXT records, and each of the three stops a different problem.

SPF lists which servers are permitted to send mail using your domain. A receiving server checks the sending address against that list. One domain should publish exactly one SPF record — two is a configuration error that causes checks to fail rather than to combine.

DKIM adds a cryptographic signature to outgoing mail, with the public key published in DNS. The recipient verifies that the message was genuinely sent by an authorised system and was not altered on the way.

DMARC ties the two together and states what a recipient should do when a message fails: take no action, quarantine it, or reject it outright. It also requests reports, which are how you discover who is sending mail as your domain.

A common and expensive mistake is publishing DMARC with a strict policy before confirming that all legitimate senders pass. Marketing platforms, invoicing systems and helpdesk tools all send on your behalf, and a strict policy applied too early silently rejects mail you wanted delivered. If mail is bouncing at one provider, these records are worth checking before you blame the recipient list — our email validator covers the address side of the same problem.

Reading a Lookup That Comes Back Empty

An empty result is not one condition, and the difference matters.

The second row catches people out most often. Asking for MX records on a domain that only hosts a website returns nothing, and that is the correct answer rather than a fault.

What a Lookup Cannot Tell You

DNS answers where things are, not whether they work. A perfect set of records is entirely compatible with a site that is down.

• An A record pointing at a server says nothing about whether that server is running or responding.
• MX records prove mail is configured, not that any particular mailbox exists or that the server is accepting connections.
• Records are public by design, so a lookup reveals only what the owner chose to publish. Internal names and private infrastructure do not appear.
• You see the answer your resolver holds, which may not be the current authoritative one. Two people running the same query can legitimately get different results.

To check what your own connection looks like from outside, the IP detector shows the address and network you appear to be using, and our guide to what your IP address and DNS reveal covers the privacy side.

If the domain resolves but a link to it still lands somewhere unexpected, the redirect checker follows the hops the browser takes after DNS has done its part.

A DNS record is one answer about a domain, and the obvious next questions are who else can see it and what that address gives away. The network lookup tools answer those without asking you to install anything.

DNS Questions