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

23 June 2026 · 6 min read

DNSSEC proves that a DNS answer is the one the domain owner published and that nobody altered it on the way. For email, that protects the records mail depends on, such as MX, SPF, DKIM, DMARC and MTA-STS, from forgery in transit, and it is the foundation DANE for SMTP is built on. DNSSEC does not authenticate email messages, does not encrypt anything, and does not stop someone spoofing your From address. That is DMARC's job.

What DNSSEC does

Plain DNS answers are not authenticated. A resolver asks a question and accepts the reply, so an attacker who can inject a forged reply (cache poisoning) can, for example, point your MX record at their own server or swap the DKIM key a receiver sees.

DNSSEC, described in RFC 4033, adds signatures to DNS data so a validating resolver can check where an answer came from and that it is intact:

• RRSIG records hold the signatures over each set of records.
• DNSKEY records publish the public keys, usually a key-signing key and a zone-signing key.
• DS records sit in the parent zone and hold a hash of your key-signing key, linking your zone into the chain of trust.
• NSEC or NSEC3 records prove that a name or record does not exist, so a forged "no such record" answer fails too.

Trust runs from the signed DNS root, through your top-level domain, to your zone. If every link verifies, the answer is authentic. If a link fails, a validating resolver returns an error (SERVFAIL) rather than data it cannot trust.

Enabling DNSSEC takes two steps: turn on signing at your DNS host, then publish the DS record at your registrar. Signing without the DS record leaves the chain broken and resolvers treat the zone as unsigned. The DNSSEC checker shows whether the chain validates all the way from the root.

What it protects for email

• MX records. A forged MX answer could route your inbound mail through an attacker's server. With DNSSEC, a validating resolver rejects it.
• SPF, DKIM and DMARC records. Receivers fetch these during every check. DNSSEC makes sure they read the values you published.
• MTA-STS discovery and TLSA records. The DNS parts of mail transport security are covered as well.
• Negative answers. An attacker cannot fake "this domain has no DMARC record".

What it does not do

• It does not authenticate messages. A spammer can sign their own zone. DNSSEC only proves their DNS records are theirs. Whether a message may use your domain in its From address is decided by SPF, DKIM and DMARC. The DMARC checker shows what your domain enforces today.
• It does not encrypt. DNS queries and answers stay readable on the network; DNS over HTTPS and DNS over TLS address query privacy separately. Email in transit is protected by STARTTLS, enforced by MTA-STS or DANE.
• It does not protect a compromised DNS account. If an attacker logs in to your DNS provider and edits your records, the provider signs the attacker's changes. Account security and registrar locks still matter.
• It only helps where the resolver validates. A resolver that ignores DNSSEC accepts forged answers whatever you sign.
• It does not improve deliverability by itself. Receivers judge mail on authentication results, reputation and content, not on whether your zone is signed.

DNSSEC and DANE

SMTP encryption between mail servers is opportunistic by default: a sending server uses STARTTLS if offered and otherwise falls back to plain text, and it has nothing to check the receiving server's certificate against. An attacker on the network path can strip the STARTTLS offer or present a false certificate.

DANE for SMTP, defined in RFC 7672, fixes this by publishing a TLSA record for your mail server that says which certificate or public key it will present. A DANE-capable sender looks it up, insists on TLS and checks the certificate against it. The scheme only works if the TLSA record itself cannot be forged, so RFC 7672 applies DANE only to TLSA records that are DNSSEC-validated. A TLSA record in an unsigned zone is treated as if DANE were not there. Check yours with the DANE checker.

MTA-STS reaches a similar goal without DNSSEC. It publishes a policy file over HTTPS and relies on ordinary web certificates. Because a sender has to discover your policy before it can apply it, RFC 8461 notes that an attacker who intercepts that first discovery can block it, and that DANE resists this because it uses DNSSEC. MTA-STS is easier to deploy; DANE needs a signed zone. The two can run side by side. MTA-STS versus DANE compares them in detail.

Where DNSSEC sits among the email records

DMARC does not require DNSSEC, and a domain can enforce p=reject without it. DNSSEC closes the remaining gap at the DNS layer and makes DANE possible.

Should you enable DNSSEC?

Enable it when:

• you want DANE for SMTP, which cannot work without it;
• SPF, DKIM and DMARC are already enforced and you want to harden the DNS layer next;
• your DNS host signs automatically and your registrar publishes the DS record easily.

It can wait when:

• DMARC is not yet at p=quarantine or p=reject. Enforcing DMARC stops domain spoofing; DNSSEC does not;
• your DNS host only offers manual signing or awkward DS publication.

The operational risk is real. Signatures expire and keys roll over, and if the chain breaks, validating resolvers stop resolving your domain altogether, including your MX records. Choose a provider that signs and rolls keys automatically, and monitor the chain.

A short checklist

1. Confirm your DNS host and registrar both support DNSSEC.
2. Turn on signing at the DNS host.
3. Publish the DS record at the registrar.
4. Check the chain with the DNSSEC checker.
5. Only then add TLSA records for DANE, if you want it.
6. Keep DMARC enforcement and MTA-STS in place; DNSSEC complements them.

If you are choosing what to do first, get DMARC to enforcement: p=none vs quarantine vs reject explains the stages. For encrypted delivery without signing your zone, hosted MTA-STS publishes the policy and collects the TLS reports for you.