DNS Lookup

What it does

The DNS Lookup tool fetches every common DNS record type for a domain: A (IPv4), AAAA (IPv6), MX (mail servers), NS (name servers), TXT (text records, used for SPF/DKIM/verification), CNAME (canonical name aliases), and SOA (start of authority). The output is grouped by record type with each entry’s value and TTL.

Common situations

You are setting up a new domain or troubleshooting a DNS-related issue and need to see every record at once. The lookup gives you the full DNS picture without bouncing between command-line tools.

A site is suddenly returning a different IP than expected. Check the A record; if it’s not what you set, DNS hasn’t propagated yet, or someone has changed it. The TTL value tells you how long the change takes to propagate everywhere.

Email from your domain is being marked as spam by recipients. Check the TXT records for SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Missing or misconfigured TXT records are the most common cause of email deliverability issues.

You are verifying domain ownership for Google Search Console, Microsoft 365, or another service that requires a DNS-based proof. The TXT records show the verification tokens you’ve added.

You are auditing where a domain’s email and web are hosted (different name servers might mean different providers). MX records show the mail provider; A and CNAME records reveal the web hosting; NS records show the registrar’s authoritative DNS.

What you need to know

DNS (Domain Name System) is the protocol that maps human-readable domain names to IP addresses and other metadata. Every domain has a set of records of various types, each serving a specific purpose:

A record: maps a hostname to an IPv4 address (e.g. example.com → 192.0.2.1). The fundamental record type. Most domains have multiple A records for redundancy or load balancing.

AAAA record: maps a hostname to an IPv6 address. Optional but increasingly important: many networks now prefer IPv6.

MX record: declares the mail servers responsible for accepting email for the domain. Format: priority + hostname (e.g. 10 mail.example.com). Multiple MX records with different priorities provide failover.

NS record: declares the authoritative name servers for the domain. Set at the registrar level. Most domains have 2-4 NS records pointing at the DNS provider’s servers.

TXT record: arbitrary text data. Used for SPF (sender policy), DKIM (mail signing), DMARC (policy), domain verification (Google, Microsoft, Slack, etc.), and various other text-based metadata. Often the most-populated record type on busy domains.

CNAME record: maps one hostname to another. Used to alias subdomains to canonical hostnames (e.g. www.example.com → example.com). Cannot coexist with other records on the same hostname.

SOA record: Start of Authority. Metadata about the DNS zone (primary name server, admin contact, serial number, refresh intervals). Mostly informational; rarely manipulated directly.

The TTL (Time To Live) on each record is in seconds, telling DNS resolvers how long to cache the value before re-querying. Long TTLs (3600+ seconds = 1 hour) are good for stable records; short TTLs (60-300 seconds) are useful before changes (so propagation is fast) but increase DNS query load.

The lookup runs against public DNS infrastructure (typically Google’s 8.8.8.8 or similar). Results may differ slightly from what your local resolver sees if it has cached older values. For the canonical answer, query the authoritative name servers directly; most hosting providers expose this via their control panel.

Frequently asked questions

Why are there multiple A records for a domain?

Redundancy and load balancing. Multiple A records means the resolver picks one (typically round-robin); if one IP is down, the next request gets a different one. Large sites often have many A records pointing at multiple data centres.

What’s the difference between A and AAAA?

A records map to IPv4 (32-bit) addresses; AAAA records map to IPv6 (128-bit) addresses. Modern setups should have both. IPv6 adoption is growing and some networks prefer it; domains with only A records lose IPv6 traffic to fallback IPv4.

Why doesn’t my domain have MX records?

MX records are only needed if the domain receives email. If you don’t accept email at the domain, no MX records is correct. Without MX records, the domain looks like an “A record only” entity to mail servers: they’ll either reject inbound mail or fall back to A records (deprecated behaviour).

What’s an SPF record?

A TXT record declaring which mail servers are authorised to send email for the domain. Format: v=spf1 include:_spf.google.com ~all (Google Workspace example). Without an SPF record, your mail is more likely to be marked as spam by recipients.

What’s a DKIM record?

A TXT record containing a public key used to verify mail signatures. Mail servers check incoming mail’s DKIM signature against the public key in the DNS record; if it matches, the mail is verified as not tampered. Critical for deliverability.

What’s a DMARC record?

A TXT record at _dmarc.yourdomain.com declaring what to do with mail that fails SPF or DKIM checks (allow, quarantine, reject). Sets the mail security policy. Recommended for any domain that sends email.

What’s a TTL?

Time To Live. A number (in seconds) telling DNS resolvers how long to cache the record before refreshing. Long TTLs reduce DNS queries; short TTLs allow faster propagation of changes. Default is usually 3600 (1 hour).

What’s a CNAME flattening / ALIAS record?

A CNAME at the apex (root) of a domain isn’t allowed by the DNS spec: apex records must be A or NS. Some DNS providers (Cloudflare, AWS Route 53) offer “ALIAS” or “CNAME flattening” which lets you point the apex at a hostname and resolve it to the underlying A records on the fly. Looks like a CNAME at the apex but works around the spec restriction.

Common problems

Problem: Email is going to spam despite SPF being set.

Check that SPF, DKIM, and DMARC are all configured. SPF alone isn’t enough. Modern recipients (Gmail especially) look at all three; DKIM is usually the missing piece. Use Google’s MX Toolbox or similar for a deeper deliverability audit.

Problem: Domain change isn’t propagating.

DNS propagation depends on the TTL of the record being changed. If TTL is 3600 (1 hour), propagation can take up to 1 hour. Reduce TTL before making the change (e.g. to 60 seconds) and the change propagates faster. Some intermediate resolvers cache more aggressively than the TTL suggests.

Problem: Different DNS providers show different records.

DNS propagation isn’t instantaneous. After a record change, different resolvers update at different times based on their cache state. The lookup queries one resolver; cross-check with DNS Checker or similar to see propagation status across multiple geographies.

Problem: No CNAME record but the domain still resolves to another hostname.

The redirect is at the application or web server level, not the DNS level. CNAME is a DNS-level alias; HTTP redirects (301/302) are application-level. The DNS lookup shows what DNS knows; the actual redirect path is shown in the Redirect Chain Tracer.

Problem: Multiple SPF records cause mail to fail.

You can only have one SPF record per domain. Multiple TXT records starting with v=spf1 is an error; most mail servers will reject all of them or pick one inconsistently. Combine all sender authorisations into one SPF record using include: directives.

Tips

• For email-sending domains, SPF + DKIM + DMARC is the modern baseline. Without all three, deliverability is worse. The Knowledge Center has more background on email authentication.
• Lower TTLs to 300 (5 minutes) before planned DNS changes, so propagation is fast. Restore to longer TTL afterwards.
• Multiple NS records provide DNS-level redundancy. If one name server is unreachable, others answer; most providers handle this automatically.
• IPv6 (AAAA) is increasingly important. Many networks prefer IPv6; sites without AAAA records lose those users to slower IPv4 fallback.
• DNS records should be version-controlled where possible. Many DNS providers expose APIs; track changes the same way you track code changes.

Related tools in this suite

The SSL Certificate Checker is the companion for HTTPS posture (DNS for the routing, SSL for the encryption). The Redirect Chain Tracer is useful when you suspect redirects are happening at HTTP level rather than DNS. Both are part of the SEO Suite.

What this looks like at scale

For a single domain, manual DNS lookup is fine. For organisations with many domains and subdomains, DNS should be managed as code (Terraform, Pulumi, or DNS provider APIs) with version-controlled records. Manual changes to many domains are error-prone; managed DNS is the working pattern at scale.

Take it further

If a domain has chronic DNS-related issues (deliverability, propagation, inconsistent resolution), the underlying problem is often that DNS management is spread across too many people or platforms. Talk through the setup and we can scope a consolidation.