DNSSEC and Why It Matters for Email Security

DNSSEC (Domain Name System Security Extensions) is an extension to DNS that uses digital signatures to ensure DNS responses are authentic and haven’t been tampered with. In the context of email, DNSSEC protects against DNS spoofing attacks, where hackers redirect traffic to malicious servers or compromise authentication mechanisms like SPF, DKIM, and DMARC.

Why You Should Use DNSSEC

Let’s start with an example that highlights the risks of unsecured DNS: the 2018 attack on MyEtherWallet, a popular Ethereum wallet. Hackers used BGP hijacking to redirect traffic meant for Amazon’s Route 53 DNS servers, which hosted MyEtherWallet’s DNS records. By serving spoofed DNS responses, they redirected users to a fake version of the website. Unsuspecting users entered their credentials, leading to the theft of their Ethereum funds.

This attack was only possible because myetherwallet.com’s DNS records were not signed with DNSSEC. If DNSSEC had been in place, any DNSSEC-capable DNS resolver would have detected the tampering and discarded the response, resulting in a failed DNS query rather than a redirect to a malicious site.

DNS spoofing also threatens email security. Email depends on DNS for records like MX (Mail Exchange), DKIM (DomainKeys Identified Mail), SPF (Sender Policy Framework), and DMARC (Domain-based Message Authentication, Reporting, and Conformance). By spoofing MX records, attackers can redirect emails to their servers to steal sensitive information. By manipulating a domain’s DKIM, SPF, and DMARC records, attackers can make their fraudulent emails pass verification checks and appear legitimate for that domain.

While attacks involving BGP hijacking, like the one on MyEtherWallet, are certainly rare and require significant effort, they remain a real threat — especially to high-value targets. Signing DNS records with DNSSEC provides an additional layer of defense, ensuring DNS responses come from their authoritative sources and haven’t been altered in transit.

Why You Shouldn’t Use DNSSEC

So, enabling DNSSEC for your domain seems like a no-brainer, right? Well, not everyone agrees. An often-cited 2015 blog post, Against DNSSEC, raises arguments against it, arguing that DNSSEC is unnecessary, cryptographically outdated, overly complex, and ineffective at solving key security issues.

Let’s address two of these claims directly:

• DNSSEC is not unnecessary: As explained in the previous chapter, DNS spoofing is a real threat, and DNSSEC is the only practical solution for authenticating DNS responses. Without it, there’s no way to ensure DNS data hasn’t been tampered with.
• DNSSEC is not cryptographically weak: Nowadays, the Root zone uses 2048-bit RSA keys for both KSK and ZSK, as do most TLDs. Additionally, adoption of elliptic curve algorithms, such as ECDSA and EdDSA, is steadily growing.

For a thorough rebuttal of all the arguments in “Against DNSSEC,” I recommend reading the 2023 blog post For DNSSEC And Why DANE Is Needed. The author provides a detailed breakdown of each point and makes a compelling case for DNSSEC’s importance.

That said, some challenges associated with DNSSEC are worth considering:

• Enabling DNSSEC can be complex: In the best-case scenario, enabling DNSSEC is as simple as toggling a checkbox in a DNS provider’s admin interface. This is usually possible only when the same provider manages both the registrar and the nameservers, allowing them to automate key management and DS record updates. However, when the registrar and nameserver provider are different, the process becomes more complicated. The domain owner must manually retrieve the DS record from the nameserver provider and upload it to the registrar. Errors — like mismatched keys or delays in updating records — can break DNSSEC validation and make the domain unavailable. Regular key rotation, essential for security, adds another layer of complexity. Migrations, such as switching registrars or nameservers, are particularly risky. Both the DS records and DNSSEC keys must be carefully synchronized to avoid outages. Numerous DNSSEC-related outages have occurred due to these challenges.
• DNSSEC increases DNS response sizes: A DNSSEC-signed record set comes with a Resource Record Signature (RRSIG), which is used to authenticate the integrity and origin of the data. This often pushes response sizes beyond the 512-byte UDP packet limit. To handle this, DNS uses EDNS (Extension Mechanisms for DNS), which supports UDP packets up to 4096 bytes. However, despite EDNS being standardized for decades, some firewalls still block UDP packets larger than 512 bytes. Larger packets are also more prone to fragmentation, which can cause packet loss and lead to DNS resolution failures. Devices that perform deep DNS traffic inspections may also drop unfamiliar messages, posing a potential issue for DNSSEC.
• DNSSEC requires additional DNS queries: When a DNS resolver validates a DNSSEC-signed record, it must look up the DNSKEY record to verify the cryptographic chain of trust. This increases the total number of DNS queries made during the resolution process. Although DNSKEY records, like other DNS records, can be cached to reduce the overhead, the initial validation process still requires more lookups than resolving records without DNSSEC. However, in the context of email, which isn’t a real-time protocol, the extra query overhead is rather negligible.

While these challenges are valid, they are not significant enough to outweigh the benefits of enabling DNSSEC.

How DNSSEC Works

DNSSEC establishes a chain of trust by linking cryptographic signatures from the root zone to the queried domain. Here’s a step-by-step breakdown of how DNSSEC validates the resolution of example.com.

Step 1: Client sends query with DO flag

A DNSSEC-aware client sends a query for example.com to its resolver, including the DO (DNSSEC OK) flag to indicate support for DNSSEC validation.

Step 2: Resolver queries the root zone

The resolver queries a DNS root server (pre-configured in the resolver) for records related to example.com, also setting the DO flag. The server responds with:

• NS records for the .com top-level domain (TLD).
• A DS (Delegation Signer) record containing a cryptographic hash of the .com zone’s public KSK (Key Signing Key).
• An RRSIG (Resource Record Signature) with the DS record’s signature generated using the root zone’s public ZSK (Zone Signing Key).

The resolver then requests the DNSKEY records from the root nameserver, receiving:

• DNSKEY records containing the root zone’s KSK (for signing DNSKEY records) and ZSK (for signing other zone data).
• An RRSIG covering the DNSKEY records.

The resolver compares the root KSK against its locally stored trust anchor. If they match, the resolver uses the root ZSK to verify the DS record’s RRSIG.

Step 3: Resolver queries the .com TLD zone

Next, the resolver queries a .com TLD nameserver for records related to example.com, again using the DO flag. The TLD nameserver responds with:

• NS records for the example.com domain.
• A DS record containing a cryptographic hash of example.com’s KSK.
• An RRSIG for the DS record, signed with the .com zone’s ZSK.

The resolver then requests the .com zone’s DNSKEY records and receives:

• DNSKEY records containing the .com zone’s KSK and ZSK.
• An RRSIG covering the DNSKEY records.

The resolver hashes the .com KSK and compares the result to the DS record from the root zone. If they match, the resolver uses the .com zone’s ZSK to verify the DS record’s signature.

Step 4: Resolver queries example.com’s nameserver

The resolver queries an authoritative nameserver for example.com with the DO flag. The server responds with:

• The requested DNS records (e.g., A, AAAA, or CNAME).
• An RRSIG covering the requested records.

The resolver also requests example.com’s DNSKEY records and receives:

• DNSKEY records containing example.com’s KSK and ZSK.
• An RRSIG covering the DNSKEY records.

The resolver hashes example.com’s KSK and compares the result to the DS record from the .com zone. If they match, the resolver uses example.com’s ZSK to verify the RRSIG covering the requested records.

Step 5: Resolver returns validated records to client

After successfully validating all signatures, the resolver returns the requested DNS records to the client, confirming their authenticity and integrity.

Please note that in practice, DNSSEC validation can be more complex due to key rollovers, algorithm transitions, and the presence of multiple DS and DNSKEY records.

Also worth noting is that DNSSEC provides mechanisms to authenticate the nonexistence of records or domains using NSEC (Next Secure) and NSEC3 records. These records prevent spoofed responses that claim a domain or record doesn’t exist when it actually does.

• NSEC (Next Secure): The NSEC record points to the next valid domain name in the DNS zone, effectively creating a chain of all valid names. This allows the resolver to confirm that no domain exists between the queried name and the next valid name. However, NSEC records can unintentionally expose all domain names in a zone, leading to concerns about zone enumeration.
• NSEC3: To address zone enumeration issues, NSEC3 uses hashed domain names instead of plain-text names. The hashed names still link valid domain names in a zone, allowing resolvers to verify nonexistence without revealing the actual domain names.

Enabling DNSSEC for Your Domain

To check if DNSSEC is already enabled for your domain, use the following command:

$ dig +dnssec example.com A @8.8.8.8

This queries the Google Public DNS server for the A records of example.com with DNSSEC enabled. If the output includes the ad (Authentic Data) flag and returns an RRSIG record alongside the A records, DNSSEC validation is working.

For Windows users, the equivalent PowerShell command is:

> Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8 -DnsSecOk

Alternatively, you can use DNSSEC Debugger, a web-based tool by Verisign Labs. If DNSSEC is not enabled, it’s time to take action.

If your registrar also provides your nameservers, enabling DNSSEC might be as simple as checking an “Enable DNSSEC” option in their interface. The registrar should handle adding the necessary DNS records and regularly rotate keys for you.

For domains where the registrar and DNS service are separate, the process gets a bit more complicated. For example, our domain dmarcchecker.app is registered with Porkbun and uses AWS Route 53 for DNS. Enabling DNSSEC in this setup involved the following:

• Enabled DNSSEC signing in Route 53: This involved generating a Key Signing Key (KSK) using the ECDSA P-256 algorithm.
• Waited for resolver caches to flush: We allowed up to 24 hours (based on the domain’s SOA TTL) before proceeding. Publishing the DS record too early could have caused validation failures and resolution issues.
• Published the DS record at the registrar: We retrieved the DS record data from Route 53 and entered it into Porkbun’s interface.

Note: Route 53 automates Zone Signing Key (ZSK) rotation, but Key Signing Key (KSK) rotation must be performed manually.

The steps for enabling DNSSEC may vary depending on your setup, but the principles remain similar. If your registrar or DNS provider doesn’t support DNSSEC, consider switching to a provider that does.

Adoption of DNSSEC

Despite being introduced nearly three decades ago, DNSSEC adoption remains low — only 4% of .com domains use it as of February 2025. However, on the resolver side, adoption is stronger: 35% of internet users rely on resolvers that validate DNSSEC signatures.

We also analyzed major email providers for DNSSEC support, checking:

• Whether their own domain has DNSSEC enabled.
• If they reject sending emails to domains that fail DNSSEC validation.
• If they refuse emails from senders using DNSSEC-failing domains.

Ideally, all providers should use DNSSEC-validating resolvers for every DNS lookup, including MX records and authentication mechanisms like DKIM, SPF, and DMARC. SERVFAIL errors caused by failing DNSSEC should be treated as temporary and retried.

Conclusion

DNSSEC helps increase email security by preventing DNS spoofing attacks that can compromise records like MX, SPF, DKIM, and DMARC. While adoption may still be lacking, it’s an effective way to ensure DNS responses are authentic and tamper-proof.

Setting up DNSSEC isn’t as complicated as it might seem, particularly with many providers handling most of the technical complexities. Take the step to secure your domain — enable DNSSEC today.