DNS Lookup Tool

Open a DNS lookup tool, enter the domain or hostname, pick the record type you want (A, MX, TXT, etc.), and run the query. The tool queries authoritative or recursive resolvers and shows you the values along with their TTLs. For a full picture, check A, AAAA, CNAME, MX, NS, TXT, and CAA — that covers most production setups. I always tell juniors to screenshot the results during audits because DNS can change between when you check and when you write the report.

Run through a checklist: A and AAAA for the website's IP, CNAME for any aliases (www, cdn, etc.), MX with priority values for email, NS for delegation, TXT for SPF and verification entries, DKIM selectors, DMARC, and CAA for certificate authority restrictions. Note current TTLs before the cutover and lower them 24–48 hours in advance for faster switchover. Missing any one of these is how you break email after a migration — and email breakage is what clients shout about loudest.

Use a DNS lookup tool, enter the domain, select "A " as the record type, and submit. The result shows one or more IPv4 addresses where the site is hosted — for example 142.250.190.78. If the site uses a CDN, you'll often see a Cloudflare or AWS IP instead of the origin server. For IPv6, run a separate AAAA query because A and AAAA are different record types. If nothing returns, check whether the domain uses an ALIAS or ANAME record at the apex.

Query MX records and you'll get a list with priority numbers and mail server hostnames — lower priority means higher preference. So priority 10 mail.google.com is tried before priority 20 backup-mx.example.com. Verify the hostnames match what your email provider documented (Google Workspace, Microsoft 365, Zoho, etc.). Then run separate TXT lookups for SPF, DKIM selectors, and DMARC. If any one of these is wrong, mail either bounces or lands in spam — and clients won't always tell you until invoices stop reaching customers.

TTL (Time To Live) is how many seconds a resolver is allowed to cache a DNS answer before asking again. So a TTL of 3600 means the cached value stays valid for one hour. Lower TTL = faster updates worldwide but more queries hitting your nameservers. Higher TTL = better performance but slower changes during migrations. Standard practice: keep TTL at 3600 normally, but drop it to 300 a day before any planned DNS change. That way propagation feels almost instant when you flip the switch.

Different resolvers cache for different durations, sit in different geographic locations, and may use split-horizon DNS where internal and external answers differ. Google's 8.8.8.8 might return the new value while a local ISP resolver still serves the cached old one. EDNS Client Subnet and DNSSEC behavior also vary between providers. During DNS changes this is normal — until every resolver's cached entry expires by TTL, you'll see inconsistent answers. Tools that query 20+ resolvers globally make this obvious instead of confusing.

Query the domain's TXT records — SPF appears as a single string starting with "v=spf1 ". For DKIM, you have to query the specific selector subdomain like "selector1._domainkey.yourdomain.com " because each email provider uses its own selector name. Google uses "google ", Microsoft uses "selector1 " and "selector2 ", Mailchimp has its own pattern. DMARC sits at "_dmarc.yourdomain.com " as another TXT record. Always validate SPF doesn't exceed 10 DNS lookups — that's a common reason for delivery issues nobody catches early.

Quick rundown. A maps a hostname to an IPv4 address — direct. CNAME points one hostname to another (alias) — useful for CDN and subdomains. MX tells the world where to deliver email, with priority numbers. NS delegates which nameservers are authoritative for the zone. TXT stores arbitrary text — used for SPF, DKIM, DMARC, domain verification, and similar metadata. Each plays a different role and you can't substitute one for another. Knowing which to check for which problem is half the troubleshooting battle.

Start basic: spell-check the domain, confirm the right record type, and verify the nameservers actually exist. Then test from multiple resolvers — if Google's 8.8.8.8 works but your local ISP doesn't, it's a propagation or caching issue. Check that parent-zone delegation matches what the registrar shows. For SERVFAIL, suspect DNSSEC misconfiguration. NXDOMAIN means the record genuinely doesn't exist. Also confirm you're hitting the authoritative server with `dig +trace` if you want the unfiltered truth — that bypasses every recursive cache in the chain.

Yes, and you should query subdomains separately rather than assuming they inherit from the apex. Subdomains can have their own A records, CNAMEs, or even be delegated to different nameservers. So `mail.example.com` might point somewhere completely different from `example.com`. Just enter the full subdomain in the DNS tool and pick the record type. If you get nothing back, check whether the subdomain is covered by a wildcard record (*.example.com) or simply doesn't exist as a separate entry.