DNS Record Lookup

What is a DNS lookup and what does this tool show?

A DNS lookup reads the records a domain publishes in the Domain Name System and lists them from the outside. Browsers, mail servers and Googlebot all ask the same questions before they reach a domain. Which server does this name point to, where does its e-mail go, and who runs the zone? This tool collects those answers from our server in one lookup and groups them in three blocks:

• Address records: A (IPv4), AAAA (IPv6) and, on subdomains, CNAME.
• Mail records: MX, the TXT record that holds SPF, and the DMARC record at _dmarc.
• Management records: NS, SOA and CAA, which says which certificate authorities may issue certificates.

When a client's e-mail goes missing, or traffic drops after a migration, this is the first check I run. In SEO consulting projects, DNS is also the first line of a technical audit. After all, a wrong A record or a missing SPF record creates problems no on-page work can fix. The tool only reads. It changes nothing on your domain, and it keeps neither the query nor the result.

How do A, AAAA and CNAME records find your site?

When a visitor types your address, the resolver first checks the A and AAAA records. The A record holds the IPv4 address and the AAAA record the IPv6 address. When both point to the same server, users on either network reach your site. The large green value in the tool is the first A record, and if there are more addresses you see a small +1 next to it. For more detail on the IPv6 side, use the IPv6 test; to see which country and provider an IP address belongs to, use the IP lookup.

A CNAME, on the other hand, maps one name to another; www.example.com can point to example.com, for instance. There is one rule I run into often: under RFC 1034, a name that has a CNAME cannot hold any other record. Since the root of a domain always carries SOA and NS records, you cannot put a CNAME there. That is why the tool usually shows CNAME records on subdomains such as www rather than on the root. For the root, you either enter A and AAAA records or use an ALIAS style record if your DNS provider offers one.

How do MX records and their preference numbers work?

An MX record tells other mail servers where to deliver e-mail for your domain. Every MX record carries a preference number, and the sending server tries the lowest number first. For example, with records at 10 and 20, the 20 only takes over when the 10 fails. Between records with the same number, the sender picks one at random. The tool sorts MX records in that order and shows the provider's root domain on the summary card. So you can tell at a glance whether your mail runs on Google, Microsoft or elsewhere.

Then there is the null MX. Under RFC 7505, a single record with preference 0 and a target of just a dot means the domain accepts no e-mail at all. The tool does not treat this as an error; it labels it Null MX instead. When you switch mail providers, the MX record is only one part of the job, so also remove the old records and update SPF. I walk through the full setup in my guide to business e-mail on your own domain.

How do you check SPF, DKIM and DMARC with a DNS lookup?

All three are TXT records, but they live under different names. SPF sits on the domain itself, starts with v=spf1 and lists the servers allowed to send mail for you. DMARC sits at _dmarc.example.com, starts with v=DMARC1 and tells receivers what to do when authentication fails. DKIM sits at selector._domainkey.example.com and holds the public key that verifies the signature.

• SPF: RFC 7208 says a domain must not publish more than one SPF record, so the tool shows that case in red. A trailing -all is a strict rule and ~all a soft one, while +all allows everyone.
• DMARC: p=none only monitors, p=quarantine marks failing mail as suspicious and p=reject refuses it. RFC 9989, published in May 2026, states that if several DMARC records come back for one name, they are all discarded.
• DKIM: You cannot find it without the selector. In the header of a message you received, the s= value in the DKIM-Signature line is the selector; type that name into the tool.

Google's email sender guidelines require SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day to Gmail, and the DMARC policy may be none. Smaller senders still need SPF or DKIM. So aim for all three rows to be green on your own domain.

What is TTL, and why don't DNS changes show up at once?

TTL (Time To Live) tells resolvers how many seconds they may keep a record in their cache. 3600 means one hour and 86400 one day. When you change a record, resolvers that cached the old value keep serving it until its TTL runs out. What people call DNS propagation is really this wait, and it is set by the old record's TTL rather than by a fixed number of days.

The tool shows each TTL both in seconds and as a readable duration. However, the number you see is the time left in our resolver's cache. It is equal to or lower than the authoritative value, and it can drop between two lookups. The Negative TTL on the SOA row, in turn, says how long a "this record does not exist" answer stays cached (RFC 2308). If a subdomain you just added does not appear yet, this is usually why.

My practical rule before a migration: lower the TTL to 300 seconds at least one old TTL period before the move, then raise it again afterwards. After that, confirm your redirects with the redirect checker.

What do NS, SOA and CAA records tell you?

NS records show which name servers run your domain's DNS zone. The tool writes their root domain on the summary card; if you see cloudflare.com, for instance, you edit your records in the Cloudflare dashboard. If you changed a record in your hosting panel and nothing happens, look here first. When NS points to a different provider, your change never goes live.

SOA is the zone header. It holds the primary name server, the contact address, the serial number and the refresh timers. The tool turns the first dot of the contact into an @ sign, so hostmaster.example.com appears as hostmaster@example.com. The serial rises with every change, and secondary servers use it to notice updates.

CAA is less known but valuable for security. Under RFC 8659 it limits which certificate authorities may issue SSL certificates for your domain. The issue tag covers normal certificates, issuewild covers wildcard ones, and iodef names the address for violation reports. Without a CAA record, any authority may issue. In web design projects, we list only the provider we actually buy the certificate from.

Which DNS lookup steps should you follow during a site migration?

In my experience, a large share of migration problems come from DNS rather than from code. That is why every move follows the same order.

1. Before the move: Look up all current records and save them with Copy result. Verification records on the TXT rows are the ones people forget most.
2. Lower the TTL: Set the TTL of the A, AAAA and www records to 300 seconds at least a day in advance.
3. On the day: Enter the new IP address, then run the tool again and confirm that A and AAAA point to the new server.
4. Protect e-mail: Check that the MX, SPF and DMARC rows look exactly as they did before the move.
5. Afterwards: Raise the TTL back to its old value and watch crawl errors in Search Console.

I cover what it takes to keep your search visibility in the website migration SEO checklist. In short, once DNS is right, the rest of the migration becomes much easier to manage.