We Checked the DNS of 450 Top Websites. Here's What Most of Them Skip.

Key findings

How we did it

• The list. We started from the Moz Top 500, a public list of the most-linked domains and pages on the web (the version published in the open-source top-sites dataset, updated September 2026). Many entries are subdomains of the same site (docs.google.com, maps.google.com, and so on), so we reduced each entry to its registered domain and removed duplicates. That left 452 unique domains. Two (marketingplatform.google and xinhuanet.com) returned no nameserver records at the time of testing and were excluded, leaving 450 domains.
• The lookups. For each domain we queried A, AAAA (for the bare domain and for www), NS, DS, CAA, MX and TXT records, plus the TXT record at _dmarc.<domain>. Queries went through a recursive resolver from a single cloud location on October 4, 2026. Every query that timed out was retried up to six times; in the final run no lookups failed.
• Consistency check. We re-ran the IPv6, DNSSEC and CAA lookups for every domain a second time. Out of roughly 1,350 repeated lookups, 4 gave a different answer (mostly one-off timeouts), so the figures are stable to within about one domain.
• "Top-ranked" sites below means domains whose highest-ranking entry on the list is in the top 100. That is 84 unique domains, because Google alone holds many of the top 100 spots.

Limitations

• We checked whether records exist, not whether every value is correct. A domain with a CAA record can still have a badly written one.
• SPF could not be measured for 162 domains. Their TXT records were too large to come back in a single UDP response, and the network we tested from does not allow DNS over TCP. SPF percentages are therefore based on the 288 domains we could read, and we say so wherever SPF appears.
• We did not report TTLs. The network we tested from answers DNS through a caching resolver, so the TTLs we saw were "time left in cache", not what each site configured. Publishing them would have been misleading.
• DNS providers are identified from nameserver hostnames. A provider that hands out white-label nameservers under a customer's own domain is counted as "self-hosted", and a few "multi-provider" domains use two nameserver brands owned by the same company, so the multi-provider figure is an upper bound.
• This is one snapshot from one location on one day. DNS changes; check any individual site yourself before relying on it.

Finding 1: Only 1 in 8 top sites uses DNSSEC

DNSSEC adds cryptographic signatures to DNS answers so resolvers can detect tampering. We counted a domain as signed if its parent zone (for example .com) publishes a DS record for it.

Only 55 of 450 domains (12.2%) are signed. The most-linked sites are even less likely to use it: 9.5% of top-ranked domains (8 of 84) versus 12.8% of the rest (47 of 366). Many of the world's largest properties, including google.com, are not signed.

Who does sign? The list leans heavily toward government and institutional domains: nasa.gov, cdc.gov, nih.gov, state.gov, loc.gov, house.gov and europa.eu, plus companies such as paypal.com, cloudflare.com, discord.com and ikea.com. U.S. federal .gov domains are required to use DNSSEC, which explains much of that cluster.

Why so few elsewhere? DNSSEC protects against a specific attack (forged DNS answers) but adds a real operational risk: an expired signature or a botched key rollover makes the domain fail outright for every validating resolver — the DNSSEC failure mode we describe in How DNS Fails: 12 Failure Modes. Large sites with their own security teams have evidently decided that risk outweighs the benefit, at least for now.

What to take from it: if you enable DNSSEC, use a DNS provider that signs and rolls keys automatically, and never change DNS providers without removing or migrating the DS record first.

Finding 2: More than half the bare domains don't answer over IPv6

We checked for AAAA (IPv6) records on both the bare domain (example.com) and the www name.

• 171 of 450 (38.0%) have IPv6 on the bare domain.
• 233 of 450 (51.8%) have IPv6 on www.
• 76 domains have IPv6 on www but not on the bare domain — usually because the bare domain is a redirect handled by different infrastructure than the main site.
• 203 domains (45.1%) have no IPv6 on either name.

Top-ranked sites are further ahead: 50.0% of top-ranked domains answer over IPv6 at the bare domain, against 35.2% of the rest.

This matters because a large and growing share of mobile users reach the web over IPv6-first networks. Those users can still reach IPv4-only sites through translation, but it adds a hop that the site owner does not control.

What to take from it: check both your bare domain and www. It's common to enable IPv6 on one and forget the other. Our DNS checker shows A and AAAA results side by side.

Finding 3: Two-thirds don't restrict who can issue their certificates

A CAA record lists the certificate authorities allowed to issue certificates for a domain. Without one, any public CA may issue for it.

• 149 of 450 domains (33.1%) publish a CAA record.
• Top-ranked sites are twice as likely to have one: 56.0% versus 27.9% of the rest.

The certificate authorities most often authorized were Google Trust Services (pki.goog, 89 domains), DigiCert (89) and Let's Encrypt (88), followed by Amazon (51) and GlobalSign (42). Most domains authorize several CAs, which is sensible: it keeps a backup issuer available if one CA has an outage or revokes certificates. A handful of domains — wordpress.org, wordpress.com, automattic.com and gravatar.com, all run by the same company — authorize only Let's Encrypt, and wordpress.org goes further by locking issuance to a specific ACME account.

What to take from it: CAA is one of the cheapest security records to add. List the CA you use today plus one backup. If your certificates renew automatically, confirm your provider's CA is on the list before you publish it, or renewals will fail — one of the patterns in SSL Certificate Expiry Patterns.

Finding 4: Very few sites spread their DNS across providers

In October 2016 a large attack on the DNS provider Dyn made many well-known sites unreachable for hours, and "use more than one DNS provider" became standard advice. A decade later, few sites follow it.

• 56 of 450 domains (12.4%) use nameservers from more than one provider. Examples include linkedin.com (NS1 and Azure DNS), github.com and nytimes.com (NS1 and Route 53) and spotify.com (NS1 and Google Cloud DNS).
• The other 394 (87.6%) rely on a single provider.

NS1 shows up repeatedly as the "second provider" in multi-provider setups. Two providers — Route 53 and Cloudflare — between them serve DNS for 201 of the 450 domains (44.7%).

What to take from it: a second DNS provider is a real cost (both zones have to be kept in sync), and for most small sites a single reputable managed provider is fine. If you do run two, check that both answer identically; mismatched zones cause the intermittent failures described in our DNS failure modes guide.

Finding 5: Email authentication is the one area the big sites get right

• 423 of 450 domains (94.0%) publish a DMARC record. Of those, 56.5% use the strictest policy, p=reject, 23.6% use p=quarantine, and 19.9% (84 domains) use p=none, which reports on spoofed mail but does not block it.
• Among the 288 domains whose TXT records we could read in full, 92.4% publish SPF. Of those with SPF, 55.6% end it with a hard fail (-all) and 36.5% with a soft fail (~all).
• Two domains publish more than one SPF record, which the SPF standard treats as an error: indiatimes.com and eonline.com. eonline.com's records also use ip: where the standard requires ip4:. Receiving mail servers may treat SPF for these domains as broken.
• 36 domains (8.0%) have no MX record at all, and only 2 publish a "null MX" record that explicitly says the domain never receives mail. Many of the 36 are link shorteners, content-delivery and app-hosting domains (t.co, goo.gl, gstatic.com, vercel.app and similar) that never send mail. A null MX plus v=spf1 -all and a DMARC reject policy would make it explicit that mail claiming to come from them is fake.

Large-site email authentication is probably this strong because Google and Yahoo began requiring DMARC from bulk senders in 2024.

What to take from it: if your domain sends no email, publish SPF v=spf1 -all and a DMARC p=reject record anyway; it costs nothing and stops spammers using your name. If it does send email, make sure you have exactly one SPF record.

A five-minute checklist for your own domain

1. Look up AAAA for both example.com and www.example.com. If your host supports IPv6, enable it on both.
2. Add a CAA record listing your current certificate authority and one backup.
3. Confirm you have exactly one SPF record and a DMARC record, even if you don't send mail.
4. Before enabling DNSSEC, confirm your DNS provider handles signing and key rollovers automatically.
5. Write down which provider hosts your DNS and who has the login. Most of the outages in our guides start with nobody knowing.

You can run the lookups above with our free DNS checker.

Download the data

The full results for all 450 domains are available as a CSV file (one row per domain, with the record types we checked). You're welcome to reuse it with a link back to this page. If you think we've misclassified a domain or a provider, tell us through the contact page and we'll correct it.

Columns: moz_rank (highest position the domain held on the source list), domain, apex_ipv6, www_ipv6, dnssec_signed, has_caa, caa_issuers, dns_providers, dns_provider_count, has_mx, null_mx, has_spf ("unknown" where the record could not be read), spf_all_qualifier, has_dmarc, dmarc_policy.