What happens if DNSSEC is misconfigured?

Here's a scenario that should make you nervous. You're sending emails, your SPF and DKIM are set up correctly, everything looks fine from your end. But recipients are getting SERVFAIL errors when their mail server tries to look up your domain. Your emails aren't arriving. Neither is your website. And you have no idea why.

That's what a broken DNSSEC setup looks like from the outside.

DNSSEC adds a layer of cryptographic trust to your DNS records. When it works, resolvers verify that your DNS responses are authentic. When it breaks, validating resolvers don't just skip the verification and move on. They refuse to resolve your domain entirely, returning a SERVFAIL error to whoever asked.

That's the key thing to understand about DNSSEC failure. It's not like a missing SPF record, where the worst case is a soft fail. A misconfigured DNSSEC setup is worse than having no DNSSEC at all. Without it, everything resolves normally. With a broken setup, your domain becomes unreachable for any resolver that validates DNSSEC signatures. That includes a significant share of corporate mail servers, ISPs, and increasingly, consumer mailbox providers too.

So what actually breaks? Four things come up most often.

Expired signatures. DNSSEC signatures (called RRSIGs) have expiry dates. If your DNS provider doesn't renew them automatically, they go stale. Once they expire, every validating resolver will reject your DNS responses as untrusted.

Key mismatch between your DNS zone and your registrar. Your registrar holds a DS record that acts as a pointer to your DNSKEY. If you rotate your signing key but forget to update the DS record at the registrar, the chain of trust breaks. Resolvers can't verify anything downstream.

Missing DS record entirely. This often happens when someone moves a domain to a new registrar or a new DNS provider. They set up DNSSEC on the DNS side but never tell the registrar about it. The zone looks signed, but nothing anchors it to the parent zone. Broken.

Algorithm mismatch. If your registrar and DNS provider are using different signing algorithms and one doesn't support the other, validation fails silently from a configuration standpoint but loudly in practice.

The email-specific consequences are severe. When a receiving mail server tries to look up your MX records, SPF record, or DKIM public key, a SERVFAIL means those lookups don't complete. The mail server can't verify who you are or where to deliver replies. Depending on how strict the receiving side is, your messages either bounce or get dropped entirely.

Here's how to find the problem. Start by running your domain through a DNSSEC validator. DNSViz is the most thorough tool available. It maps out the entire chain of trust visually and flags exactly where it breaks. You can also use the dig command with +dnssec flags if you're comfortable on the command line.

If you've just moved DNS providers or changed your signing keys, check your registrar's DS record immediately. That's where most breaks actually happen. It's easy to sign the zone correctly and completely forget to update the delegation.

To prevent this going forward, the two most important habits are automating key rotation (most modern DNS providers handle this, but confirm it's actually on) and testing after any DNS migration or registrar change. Treat a DNSSEC setup as something that needs a health check, not a one-time configuration.

If this is breaking for you right now and you're not sure where the chain snapped, you can reach out via our SOS hotline. It's free and no-pitch. Sometimes you just need someone to read the DNSViz output with you.