DNS checker: look up records and propagation

How to check DNS records

Type the domain you want to look up, such as example.com or www.example.com, choose a record type and press Check DNS. Our server sends the same question to six public resolvers at once (Cloudflare, Google Public DNS, Cisco OpenDNS, AdGuard DNS, Control D and NextDNS) and shows each answer side by side. Choose All records to see the eight common record types at once, asked of three of those resolvers.

The first table is the answer most resolvers gave. The second shows every resolver separately: its status, the records it returned, the TTL it has left on its cached copy and how long it took to answer. A resolver that disagrees with the majority is marked in gold, so you can see at a glance whether a change has reached everyone.

What each DNS record type does

DKIM keys live under their own name, in the form selector._domainkey.example.com, and DMARC under _dmarc.example.com: enter that full name and choose TXT. A CNAME cannot sit on the bare domain next to other records, which is why many DNS providers offer a flattened alias or ALIAS record for the apex instead.

DNS propagation: what is really happening

"Propagation" is a slightly misleading word. When you change a record, your DNS provider's nameservers serve the new value straight away; nothing is pushed out to the rest of the internet. What takes time is caching. Every resolver that looked up your domain recently keeps its copy until the record's TTL (time to live) runs out, and only then asks again. Until that happens, its users still get the old answer.

That is why the TTL column matters. A resolver showing an old IP with a TTL of 1,800 seconds will switch within half an hour. If you plan a move, lower the TTL to 300 seconds a day or two before, make the change, check it here, and raise the TTL again once every resolver agrees. Nameserver changes are slower, because the registry for .com, .co.uk and other endings caches your NS records too, commonly for up to two days.

Why resolvers can disagree and still be right

Different answers are not always a problem. Sites behind a content delivery network or a load balancer hand out different IP addresses by location or in rotation, so two resolvers can return different A records and both be correct. Large sites also use short TTLs, so the cached times in the table jump around.

Some resolvers also filter. AdGuard and Control D are queried here on their unfiltered addresses, but a family or security filter on your own network can still block a domain and return no answer or a block page address. When only your own device sees something different, the cause is usually your router, your internet provider or a VPN, not your DNS records.

Disagreement does matter when some resolvers still show your old host's address hours after a move, when NS records differ (the registrar and the DNS provider do not match), or when one resolver returns SERVFAIL, which often points to a broken DNSSEC setup.

Checking email records: MX, SPF and DMARC

Most email problems after a migration are DNS problems. Check three things. The MX records should list only your current provider's servers. The domain's TXT records should include exactly one SPF record, starting v=spf1, that names every service sending mail for you. And _dmarc. plus your domain should have a TXT record starting v=DMARC1 that tells receivers what to do with mail that fails those checks.

Two SPF records on the same domain make SPF fail for every message, and it is one of the most common mistakes after adding a newsletter or CRM tool. If you see two lines starting v=spf1 in the TXT results, merge them into one.

Sources