How to check DNS records

Why this matters

DNS is easy to overlook because it usually works quietly in the background. When it breaks, the symptoms can look like hosting failure, email failure, certificate validation failure, or a CDN issue. Checking DNS records helps you separate routing problems from application problems.

DNS also affects migrations. Moving a site, changing email providers, adding a CDN, or verifying a third-party service often requires record edits. If the record is wrong, users may reach the wrong destination or the service may never verify ownership.

Step-by-step instructions

Start with the exact hostname. If you are troubleshooting app.example.com, do not only check example.com. DNS answers can be different at every level of the domain.

Next, choose the record type. For website traffic, check A, AAAA, and CNAME. For email, check MX and TXT. For delegation, check NS. Then compare the result with the expected value from your hosting provider, mail provider, DNS provider, or infrastructure configuration.

• Check A records for IPv4 addresses.
• Check AAAA records for IPv6 addresses.
• Check CNAME records for aliases to hosted services or CDNs.
• Check MX records for mail routing and priority.
• Check NS records for authoritative nameservers.
• Check TXT records for SPF, DKIM, DMARC, and service verification.

Common problems

A frequent problem is checking the wrong level of the domain. Another is expecting a DNS change to appear everywhere instantly. Recursive resolvers can cache old answers until the TTL expires, so different users may see different behavior during a transition.

CNAME records can also cause confusion. A hostname with a CNAME generally should not have other record types at the same name. Email issues often come from MX records pointing to the old provider or TXT records that were overwritten instead of merged.

How to read the result

Read DNS results in the context of the job the domain needs to do. If a website is not loading, start with A, AAAA, and CNAME records and compare them with the expected hosting or CDN target. If email is failing, start with MX records and then review TXT records for SPF, DKIM, and DMARC. If the whole domain seems disconnected from its DNS provider, review NS records.

Do not treat every empty record group as a failure. Many domains do not publish IPv6 AAAA records, and a domain can receive no email if it intentionally has no MX records. The useful question is whether the record that should exist for your setup is present, accurate, and visible from public DNS.

Practical DNS checklist

A DNS check is most useful when you know the expected answer before you start. Keep provider instructions, current records, and planned changes together so a lookup can confirm a fact instead of starting a guessing game.

• Use the exact hostname, not only the root domain.
• Compare results with the provider's expected values.
• Check website, email, and nameserver records separately.
• Save current records before planned changes.
• Recheck after TTL windows pass.

How to prevent DNS mistakes

Before changing DNS, write down the current records and the expected final records. Lower TTLs before planned migrations when possible, then raise them again after the change is stable. Keep ownership clear so multiple teams do not edit the same record without coordination.

For important domains, store DNS snapshots and compare them over time. That gives you a quick answer when someone asks what changed and when it changed.

How Website Certs can help

Website Certs provides a free DNS checker for A, AAAA, CNAME, MX, NS, and TXT records. It groups records by type, shows lookup results clearly, and links DNS checks to related SSL and HTTPS checks.

For monitored domains, Website Certs can store DNS snapshots and alert on important changes. That helps catch accidental edits, provider changes, and routing problems before they become long incidents.