6 min read

DNS Security Trends 2026: A Research Summary

Updated Published by Kishan Prajapat, SEO & Content Lead

This is a summary of public sources, listed under Data Sources at the end, not original research. Figures are only given where we can link to where they came from.

Summary

The Domain Name System (DNS) underpins almost everything online, and much of it still runs without the protections that exist for it. The DNS root and most top-level domains are signed with DNSSEC, but signing at the level of individual domains remains low, especially for .com. Email authentication has improved, driven by Google and Yahoo requiring SPF, DKIM and DMARC for bulk senders since 2024, but many domains still publish no DMARC policy or one that only monitors. This summary explains what those gaps expose domains to — cache poisoning, spoofed email, slow failover — and what domain owners can do about each one.

Key Findings

  • 1DNSSEC is signed at the top, rarely below: the root zone and most TLDs are signed, but only a small share of second-level domains are, so most lookups still can’t be validated end to end.
  • 2Email authentication is uneven: bulk-sender requirements pushed many large senders to adopt DMARC, but a policy of “p=none” only reports spoofing — it doesn’t stop it.
  • 3Long TTLs slow recovery: records cached for a day or more mean a changed IP or failover can take that long to reach every user.

Methodology

This is a summary of public standards and published statistics (see Data Sources), not an original scan of domains. You can check any domain’s records yourself with our DNS lookup and TXT lookup tools.

Analysis

Without DNSSEC, a resolver has no way to check that an answer really came from a domain’s authoritative servers. That leaves room for cache poisoning, where an attacker gets a resolver to store a forged record and send users to the wrong server. The Kaminsky attack, disclosed in 2008, showed how practical this is. Source-port randomisation made it harder, and DNSSEC fixes it properly by signing records so validating resolvers reject forged answers. Adoption is held back by operational effort: keys have to be rolled without breaking validation, and a mistake can take a domain offline. Many registrars and DNS hosts now automate signing, which removes most of that risk. Email spoofing is a related but separate problem, handled by SPF, DKIM and DMARC records published in DNS. Our guide to DNSSEC explains the mechanics.

Industry Insights

Banks and government domains tend to adopt DNSSEC and strict DMARC policies first, often because regulators or their own security teams require it. Smaller businesses and SaaS platforms lag, usually because their DNS or email is spread across several providers and nobody owns the configuration.

Actionable Recommendations

  • ✓Enable DNSSEC: turn on signing at your DNS host and publish the DS record at your registrar. Choose a provider that automates key rollovers.
  • ✓Move DMARC beyond monitoring: once reports show your legitimate mail passes SPF and DKIM, move your policy to p=quarantine and then p=reject.
  • ✓Keep TTLs moderate: 300–3600 seconds suits most records, and lower TTLs ahead of planned changes.
  • ✓Publish CAA records: restrict which certificate authorities may issue certificates for your domain, and check the certificates you have with our SSL checker.
  • ✓Keep SPF under the lookup limit: SPF allows at most 10 DNS lookups; exceeding it causes failures at receiving servers.

Data Sources

Frequently Asked Questions