NIST DNS update: What this means for your organization

Executive summary: On March 19, 2026, NIST published SP 800-81 Revision 3, the first update to its DNS security guidance since 2013. The new framework treats DNS as an active security enforcement layer, not background plumbing. For any organization running DMARC, SPF, or DKIM, this is directly relevant: every one of those protocols depends on DNS integrity to function.

Key takeaways:

• NIST now formally positions DNS as a policy enforcement point within zero-trust architectures, not just a resolution service.
• Dangling CNAME records and lame delegations are called out as high-risk attack vectors that enable subdomain takeover and email impersonation.
• Encrypted DNS protocols (DoT, DoH, DoQ) get detailed coverage for the first time, with warnings about applications bypassing enterprise DNS controls.
• DNSSEC cryptographic recommendations shift toward ECDSA and Ed25519, with shorter signature validity windows of five to seven days.

The last time NIST updated its DNS security guidance was 2013. That was before encrypted DNS went mainstream, before SubdoMailing showed how dangling records could be weaponized at scale, and before zero-trust became something teams actually had to implement rather than talk about.

SP 800-81r3, published on March 19, 2026, rewrites the playbook. The old version treated DNS as plumbing you configured once and forgot about. The new version treats it as a frontline security control that should be blocking threats, feeding your SIEM, and getting audited like your firewall rules.

That shift matters for anyone working on email authentication. DMARC, SPF, and DKIM all live in DNS. If your DNS is insecure, your email authentication is built on unstable ground.

The biggest conceptual change in the new guidance is the formal endorsement of Protective DNS (PDNS). That means DNS resolvers that don't just answer queries but actively filter them, blocking known-malicious domains, logging queries for forensic use, and feeding intelligence into your broader security stack.

NIST recommends a hybrid deployment: cloud-based DNS security services for scalability combined with on-premises DNS firewalls for resilience. And critically, the guidance stresses that DNS logs shouldn't sit in isolation. They need to correlate with SIEM platforms and asset tracking systems so you can tie suspicious queries back to specific devices and users.

This aligns with what we see at Red Sift. DNS isn't just where your records live. It's where misconfigurations, abandoned subdomains, and orphaned SPF create the attack surface that threat actors exploit.

One of the most important additions in SP 800-81r3 is the explicit call-out of dangling CNAME records and lame delegations as enterprise-level risks. These are DNS entries pointing to services that no longer exist, and they're exactly the kind of vulnerability that DMARC enforcement alone can't protect against.

We saw this play out at scale in February 2024 with SubdoMailing. Attackers hijacked abandoned subdomains and sent millions of fraudulent emails that passed SPF and DMARC checks. The domains had p=reject policies in place. It didn't matter. The attack operated at the DNS layer, below the level where authentication protocols could help.

Here's the typical pattern: a subdomain gets set up for a marketing campaign, pointed at a third-party hosting service via CNAME. The campaign ends, the hosting account gets cancelled, but the DNS record stays. An attacker reclaims that hosting slot, takes control of the subdomain, and sends emails that pass authentication checks because the DNS still legitimizes the subdomain.

NIST now recommends continuous monitoring of domain registrations, regular audits of DNS configurations, and maintaining control over retired domains. Fortunately, DNS Guardian is powered by Red Sift's proprietary discovery engine. This engine automatically captures every domain that reports to OnDMARC and performs continuous, internet-scale subdomain discovery. It uses a blend of real-time DNS lookups, certificate transparency monitoring, passive DNS data, and custom crawling techniques to build a constantly updating map of your DNS footprint, including risky or forgotten subdomains you may not even know exist.

The guidance covers DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) in depth for the first time. These protocols prevent eavesdropping on DNS queries, which is good for privacy. But they also mean that traditional network inspection tools can no longer see DNS traffic.

The practical risk is that browsers and applications can bypass your enterprise DNS controls entirely by using their own encrypted resolvers. DoH traffic runs over port 443 (standard HTTPS), making it particularly hard to detect. NIST recommends blocking unauthorized DoT traffic on port 853, restricting DoH endpoints via firewall rules, and enforcing configurations through device management.

For email security teams, encrypted DNS is a double-edged situation. Privacy improves, but so does the complexity of maintaining visibility into what your DNS infrastructure is actually doing.

NIST updates its DNSSEC recommendations to favor ECDSA (P-256, P-384) and Edwards-curve algorithms (Ed25519, Ed448) over older RSA methods. Smaller key sizes mean smaller DNS responses, which helps avoid the packet fragmentation issues that have historically caused problems with DNSSEC deployment.

The operational guidance tightens too. Signature validity should be five to seven days (not weeks or months). Signing keys should rotate every one to three years. Private keys should live in hardware security modules where practical.

One interesting note: while post-quantum cryptography is a growing concern across cybersecurity, NIST says quantum-resistant DNSSEC standards aren't ready yet. Organizations should prepare for the migration, but there's nothing to deploy today.