DNSSEC and email security: what it does and does not do

4 June 2026 · 17 min read

DNSSEC turns up in almost every conversation about hardening email, usually as a vague recommendation: "you should enable DNSSEC". The advice is rarely wrong, but it is almost never explained. People come away believing DNSSEC encrypts their mail, stops phishing, or somehow replaces SPF and DMARC. It does none of those things. DNSSEC solves one narrow, important problem: it lets a resolver prove that the DNS answer it received is the genuine answer the domain owner published, and that nobody tampered with it on the way. That is the whole job. Everything DNSSEC contributes to email security flows from that single guarantee about DNS data integrity, and everything it cannot do is a consequence of the fact that it only touches DNS.

This article draws a clean line between the two. We will look at what DNSSEC actually protects, what it leaves wide open, why it is the foundation that DANE for SMTP is built on, and how to decide whether you need it for your own domain. If you want to know your current state before reading, run your domain through the DNSSEC checker and keep the result to hand.

The problem DNSSEC was invented to solve

The Domain Name System is the internet's address book. When a mail server wants to deliver a message to example.com, it asks DNS for the MX records, then for the A or AAAA records of the mail host, and along the way it may ask for SPF, DKIM and DMARC TXT records too. Plain DNS has a structural weakness that has nothing to do with email specifically: the answers are not authenticated. A resolver asks a question and accepts whatever comes back, with no cryptographic way to tell a genuine answer from a forged one.

That gap is exploitable. The classic attack is cache poisoning, where an attacker races to inject a forged response into a resolver's cache before the real one arrives. If they win, every user of that resolver is silently pointed at the attacker's servers for as long as the poisoned record lives in the cache. For a website, that means traffic redirected to a fake login page. For email, the consequences are quieter and arguably worse. An attacker who can forge your MX record can route your inbound mail through their own server. An attacker who can forge your SPF or DKIM TXT record can change what receivers believe about which servers and keys are legitimate for your domain. An attacker who can forge your MTA-STS or TLSA record can undermine the very mechanisms meant to protect your mail in transit.

DNSSEC, the DNS Security Extensions, closes that gap. It adds digital signatures to DNS records so that a validating resolver can verify two things: that the data came from the authoritative source for the zone, and that it has not been altered. It does this without changing what the records say or how applications use them. A signed MX record is still an MX record. DNSSEC just attaches proof of authenticity alongside it.

How DNSSEC works, in plain terms

DNSSEC adds a small family of new record types that sit beside your normal DNS records and carry the cryptography.

RRSIG records hold the actual signatures. Every signed set of records (an "RRset", for example all the MX records for a name) gets an accompanying RRSIG that signs it.
DNSKEY records publish the public keys used to verify those signatures. A zone typically has a Zone Signing Key (ZSK) that signs the everyday records and a Key Signing Key (KSK) that signs the DNSKEY set itself.
DS records (Delegation Signer) live in the parent zone and contain a hash of your KSK. This is the link that ties your zone's keys to the chain of trust above you.
NSEC and NSEC3 records provide authenticated denial of existence: a signed, verifiable way of saying "this name does not exist" so that an attacker cannot forge a "no such record" answer either.

The trust does not come from any single signature. It comes from a chain that runs from the DNS root downward. The root zone is signed, and its key is trusted by validating resolvers everywhere. The root signs a DS record for .com, which proves .com's keys. The .com zone signs a DS record for your domain, which proves your keys. Your keys sign your MX, A, TXT and other records. A validating resolver walks this chain from the root to your records, checking each signature against the key proved by the level above. If every link verifies, the answer is authentic. If any link is missing or fails, a strict validating resolver returns a SERVFAIL rather than hand over data it cannot trust.

The crucial human step is the DS record at the parent. You can sign your zone perfectly, but until the DS record is published in the parent zone (usually by your registrar), the chain has a broken link and resolvers treat your zone as unsigned. Enabling DNSSEC is therefore a two-part action: turn on signing at your DNS host, and publish the matching DS record through your registrar. Many "I enabled DNSSEC but the checker says it is off" problems are simply a missing DS record. The DNSSEC checker will show you whether the chain validates end to end or stops partway. For background terminology, the DNSSEC glossary entry keeps the definitions in one place.

What DNSSEC actually protects

Be precise about the guarantee, because the precision is the point. DNSSEC gives you data origin authentication and integrity for DNS responses. When a validating resolver fetches a DNSSEC-signed record, it can prove the record is exactly what the zone's owner published. That is valuable in several specific ways for email.

Your MX records cannot be silently redirected

The MX record decides where your inbound mail is delivered. If an attacker forges it through cache poisoning, they can sit in the path of your mail, read it, alter it or drop it. With DNSSEC, a forged MX record fails validation at a validating resolver and is rejected. Your mail keeps flowing to the servers you actually designated. See the MX record glossary entry for how MX selection works.

Your authentication records cannot be tampered with in transit

SPF, DKIM and DMARC all live in DNS as TXT records, and receiving servers fetch them live during evaluation. If those answers can be forged, the whole authentication stack rests on shaky ground. DNSSEC ensures that when a receiver looks up your SPF record, your DKIM public key, or your DMARC policy, it gets the genuine published value. It does not make those records do their job; it makes sure the receiver reads the real ones rather than an attacker's substitution.

Authenticated denial protects you from forged "no record" answers

Because of NSEC and NSEC3, an attacker cannot fabricate a believable "this domain has no DMARC record" or "this name does not exist" response. Forged negative answers are a real attack class, and DNSSEC closes it.

It is the prerequisite for DANE

This is the big one, and it gets its own section below. DANE for SMTP only works on top of DNSSEC, because DANE's whole security model assumes that the TLSA records it depends on are themselves authentic. Without DNSSEC, DANE has nothing to stand on.

That is the complete list of what DNSSEC does for email. It is a guarantee about the integrity of DNS data, full stop.

What DNSSEC does not do

Here is where most of the confusion lives. DNSSEC is frequently oversold, so it is worth being blunt about its limits.

DNSSEC does not authenticate email messages

DNSSEC says nothing about whether a given email message is legitimate. It does not check who sent a message, whether the sending server was authorised, or whether the visible From address was forged. Those are the jobs of SPF, DKIM and DMARC, and DNSSEC neither performs nor replaces them. A spammer can sign their own domain with DNSSEC and still send you spam; all DNSSEC proves is that their DNS records are genuinely theirs. If your real goal is to stop people forging your domain in the From line, the mechanism you need is DMARC, not DNSSEC. We cover that distinction in why your domain can be spoofed, and you can test your domain's exposure with the DMARC checker.

DNSSEC does not encrypt anything

A common misconception is that DNSSEC keeps DNS queries private. It does not. DNSSEC signs records so their authenticity can be verified, but the queries and answers still travel in plaintext and are fully visible to anyone watching the network. Privacy for DNS queries is a separate concern handled by DNS over HTTPS (DoH) or DNS over TLS (DoT), which are unrelated to DNSSEC. Likewise, DNSSEC does not encrypt your email. Mail-in-transit encryption is the job of STARTTLS, and enforcing it is the job of MTA-STS and DANE. See the STARTTLS glossary entry for what opportunistic TLS does and does not guarantee.

DNSSEC does not protect against an attacker who controls your DNS account

DNSSEC defends the path between your authoritative DNS and the resolver. It does nothing against an attacker who has logged into your DNS provider and changed the records at source, because the attacker can re-sign the malicious records with your keys. Account security, strong credentials and registrar locks remain entirely your responsibility. DNSSEC is not a substitute for protecting the account that holds your zone.

DNSSEC does not improve deliverability by itself

Enabling DNSSEC will not move your mail from spam to inbox. Receiving mail systems judge deliverability on authentication results, sending reputation, content and engagement, not on whether your zone is signed. DNSSEC underpins the integrity of the records those systems read, which is genuinely useful, but it is not a deliverability lever in the way that passing DMARC alignment is. For the factors that actually move the needle, see email deliverability.

DNSSEC does not validate unless the resolver validates

DNSSEC only delivers its protection when the resolver doing the lookup performs validation. A resolver that ignores DNSSEC will happily accept forged answers regardless of how perfectly your zone is signed. Many large public resolvers validate, and most well-run mail receivers' resolvers do, but you cannot assume universal validation. Signing your zone is necessary but it protects only those users and receivers whose resolvers check the signatures.

Put together, the shape is clear. DNSSEC hardens the data layer that email security depends on. It does not participate in the message-authentication layer at all. The two layers complement each other; neither replaces the other.

DNSSEC and DANE: the relationship that matters most for email

If there is one place where DNSSEC stops being optional infrastructure and becomes load-bearing for email security, it is DANE. Understanding why explains the whole point of DNSSEC for mail.

The problem DANE solves

When one mail server connects to another to deliver mail, it normally uses STARTTLS to upgrade the connection to encryption. The catch is that classic SMTP TLS is opportunistic. The sending server has no prior knowledge of whether the receiver supports TLS or what certificate to expect, so it accepts whatever it is offered. That makes SMTP vulnerable to a downgrade attack: a network attacker can strip the STARTTLS offer so the connection falls back to plaintext, or present a fraudulent certificate that the sender, having no expectation to compare against, accepts. The mail goes through, the operators see nothing wrong, and the attacker reads or alters it.

Two technologies fix this by giving the sender a verifiable expectation in advance: MTA-STS and DANE. They solve the same downgrade problem with very different trust models.

How DANE uses DNSSEC

DANE (DNS-Based Authentication of Named Entities) publishes a TLSA record in your DNS that states, in effect, "the mail server for this domain will present this specific certificate or this specific public key, and you must require TLS". A sending server that supports DANE looks up the TLSA record, requires an encrypted connection, and checks the receiving server's certificate against what the TLSA record promised. A stripped STARTTLS or a swapped certificate now fails the check, and the sender refuses to deliver in the clear.

The entire scheme hinges on one assumption: the TLSA record must be trustworthy. If an attacker could forge the TLSA record, they could simply publish a record matching their own fraudulent certificate and the protection would evaporate. This is exactly the integrity guarantee DNSSEC provides. DANE therefore requires DNSSEC, with no exceptions. A TLSA record in an unsigned zone is meaningless, and DANE-aware senders will ignore it. You cannot do DANE for SMTP without first having a properly signed, validating DNSSEC chain. For the record format itself, see the TLSA glossary entry, and for the broader mechanism the DANE glossary entry. You can test your setup with the DANE checker.

DANE versus MTA-STS

MTA-STS reaches the same goal, enforced TLS for inbound SMTP, without DNSSEC. Instead of a signed DNS record, it publishes a policy file over HTTPS and relies on the web's certificate authority system plus a DNS TXT record to signal that the policy exists. Because it leans on web PKI rather than DNSSEC, MTA-STS is easier to deploy for organisations that have not signed their zones, which is why it has seen wider adoption among large providers. The trade-off is that MTA-STS uses a trust-on-first-use model and a longer-lived policy cache, whereas DANE's protection is anchored directly in DNSSEC and takes effect immediately.

The two are not mutually exclusive. A well-protected domain can run both: DANE for senders that validate DNSSEC, and MTA-STS for those that do not. If you are choosing where to start and have not signed your zone, MTA-STS gives you transit protection without the DNSSEC prerequisite. If you have DNSSEC in place, adding DANE layers a second, cryptographically anchored guarantee on top. Our MTA-STS product handles the policy hosting and the TXT record for you, and the MTA-STS checker shows what your domain currently advertises. The MTA-STS glossary entry compares the models in more depth, and TLS-RPT lets you collect reports on TLS failures from either mechanism.

The headline to carry away: DNSSEC is not directly an email-authentication technology, but it is the foundation that makes DANE for SMTP possible, and DANE is one of the strongest available defences against mail being silently downgraded to plaintext or intercepted with a forged certificate.

DNSSEC alongside the records that actually authenticate mail

It helps to see where DNSSEC sits relative to the records that do authenticate email, because they operate at different layers and answer different questions.

SPF answers: did this message come from a server the domain authorises in the SMTP envelope? Published as a TXT record. See SPF and the SPF checker.
DKIM answers: was this message cryptographically signed by the domain, and is its content intact? Published as a TXT record holding a public key. See DKIM and the DKIM checker.
DMARC answers: if SPF and DKIM do not align with the visible From domain, what should the receiver do, and where should reports go? Published as a TXT record. See DMARC and the DMARC checker.
MTA-STS and DANE answer: must the connection carrying this mail be encrypted, and to a server presenting the expected certificate?
DNSSEC answers a different question entirely: are all of the DNS records above genuinely the ones the domain owner published?

Notice that DNSSEC operates underneath the others. It does not authenticate messages; it authenticates the DNS data that the message-authentication records live in. A domain can pass DMARC at p=reject with no DNSSEC at all, and millions do, because DMARC does not require it. But that domain is trusting that the SPF, DKIM and DMARC records receivers fetch have not been tampered with in flight. For most domains, against most realistic attackers, that trust holds, because cache poisoning is harder to pull off than it once was and DMARC's own signatures limit the damage. DNSSEC removes the residual risk and, more importantly, unlocks DANE. For a tour of how the five core records lock together, see five records that protect email, and to understand the staged rollout to enforcement, see the enforcement journey.

Do you actually need DNSSEC for email?

This is the practical question, and the honest answer is: it depends on your threat model and your appetite for operational complexity. Here is a grounded way to decide rather than a blanket yes or no.

You should strongly consider DNSSEC if:

You want to deploy DANE for SMTP. This is non-negotiable. DANE requires DNSSEC, so if DANE is your goal, DNSSEC is a hard prerequisite.
You operate in a sector where DNS integrity is part of a compliance or regulatory baseline. Government, finance and critical-infrastructure domains are increasingly expected to sign their zones, and in some jurisdictions it is mandated.
You have already done the rest of the email-authentication work, SPF, DKIM and DMARC at enforcement, and you want to close the remaining gap at the DNS layer. DNSSEC is a sensible "last 10 percent" once the high-impact records are enforced.
Your DNS provider and registrar both support DNSSEC with one-click signing and automatic DS publication. When the tooling is good, the cost of enabling it is low.

You can reasonably defer DNSSEC if:

You have not yet deployed DMARC at p=quarantine or p=reject. Getting DMARC to enforcement stops far more attacks, for far less effort, than signing your zone. The order of operations matters: spoofing protection first, DNS-layer integrity after. If you are not yet enforcing, that is the priority, and why your domain can be spoofed explains the exposure.
Your DNS is hosted somewhere with awkward or manual DNSSEC support, especially where DS publication is fiddly. A misconfigured DNSSEC setup is genuinely dangerous: it can take your entire domain offline, mail included, if a key rolls and the chain breaks. The failure mode of broken DNSSEC is harsher than the failure mode of no DNSSEC.
You rely on DNS features that interact badly with signing, such as certain CNAME flattening or geo-routing setups. These are usually solvable, but they need checking before you sign.

The operational warning deserves emphasis. DNSSEC's strictness is its strength and its risk. Because a validating resolver returns SERVFAIL rather than serve data it cannot verify, a botched key rollover, an expired signature or a stale DS record does not degrade gracefully. It takes the name down hard. Expired RRSIG records are a recurring cause of major outages precisely because signatures have a validity window and someone has to keep them fresh. If you enable DNSSEC, use a provider that handles key management and signing automatically, and monitor the chain so you find out about a problem before your customers do.

A reasonable sequence for most organisations is: get SPF, DKIM and DMARC correct and enforced first; add MTA-STS for transit protection; then, if your provider makes it safe and you want DANE or the integrity guarantee, enable DNSSEC and finally layer DANE on top. The requirements page lays out the full picture of what receiving providers expect, and the getting started guide walks the early steps.

A short checklist

If you decide to proceed, here is the practical path.

Confirm both your DNS host and your registrar support DNSSEC, and that DS publication is automatic or straightforward.
Enable signing at your DNS host. This generates your KSK and ZSK and starts signing your zone.
Publish the DS record at your registrar so the parent zone links to your keys. This is the step people forget.
Validate the full chain with the DNSSEC checker. It should report a complete, valid chain from the root down to your records.
Prefer a provider that does automatic key rollovers and signature refreshes. Manual signature management is where outages come from.
Only once DNSSEC validates end to end, consider adding TLSA records for DANE, and verify them with the DANE checker.
Keep your DMARC enforcement, MTA-STS policy and reporting in place. DNSSEC complements them; it does not replace any of them.

While you are reviewing your DNS, it is worth confirming your CAA records too, since they constrain which certificate authorities can issue for your domain and round out the DNS-layer controls.

The bottom line

DNSSEC is one thing done well: it proves that the DNS answers a resolver receives are authentic and untampered. For email, that means your MX, SPF, DKIM, DMARC and MTA-STS records cannot be forged in transit, and forged "no such record" responses cannot be slipped past a validating resolver. Most importantly, it is the foundation DANE for SMTP is built on, and DANE is among the strongest defences against mail being downgraded to plaintext or intercepted with a fraudulent certificate.

What DNSSEC does not do is authenticate the messages themselves. It does not stop someone forging your From address, it does not encrypt your mail or your DNS queries, and it does not protect you from an attacker who has taken over your DNS account. Those problems belong to DMARC, to STARTTLS with MTA-STS or DANE, and to ordinary account security. Treat DNSSEC as the integrity layer beneath your email-authentication stack, deploy it when your tooling makes it safe, and never let it distract you from getting DMARC to enforcement first, because that is where the bulk of the real-world protection lives. If you want help getting the whole stack, from DMARC enforcement to MTA-STS and DANE, into a state where it all fits together, that is exactly what DMARC Engine does; start by checking where your domain stands today with the DMARC checker and the DNSSEC checker.