DNSSEC for email: why your DNS records need protecting

Why does email security depend on DNS?

A receiving mail server looks up almost everything it needs to judge your mail in DNS. It reads your SPF record to see which servers may send for you, your DKIM public key to verify signatures, and your DMARC record to decide what to do when those checks fail. Senders look up your MX records to find where to deliver mail to you, and the _mta-sts record to find your TLS policy.

Plain DNS has no way to prove that an answer came from your zone unchanged. An attacker who can spoof or poison DNS answers on the path to a receiver's resolver can hand it a different SPF record, a DKIM key they control, a DMARC record with p=none, or an MX record that points to their own server. None of those checks would notice, because each one trusts whatever DNS returns.

What does DNSSEC protect, and what does it not?

DNSSEC (RFC 4033, 4034 and 4035) adds digital signatures to DNS. Your zone is signed with keys whose public half is published as DNSKEY records, and every set of records gets an RRSIG signature. A hash of your key is published as a DS record in the parent zone, such as .com or .se, which in turn is signed by the root. A validating resolver follows that chain of trust and rejects any answer whose signature does not check out. DNSSEC also proves when a name or record does not exist, so an attacker cannot fake a missing record either.

• It protects the integrity and origin of DNS answers: what the resolver receives is what you published.
• It does not encrypt DNS. Queries and answers are still visible on the network; DNS over TLS and DNS over HTTPS address privacy, not authenticity.
• It does not protect against someone who logs in to your DNS provider or registrar and changes the records there. The forged records would be signed like any others, so protect those accounts with strong authentication.
• It only helps when the receiving side validates. Many large mail providers and public resolvers do, but not every receiver does.

How do I switch on DNSSEC for my domain?

Switching on DNSSEC has two parts, and they are often handled by two different companies. Your DNS provider, the company that hosts your zone, signs it. Your registrar, the company you registered the domain through, publishes the DS record in the parent zone. If one company does both, it may connect the two for you.

1. Enable DNSSEC signing in your DNS provider's control panel. Most providers handle the keys and re-signing automatically. ECDSA P-256 with SHA-256, algorithm 13, is a common modern choice and keeps answers small.
2. Copy the DS record the provider shows you. Some registrars ask for the DNSKEY instead and calculate the DS themselves.
3. Add the DS record at your registrar. It then appears in the parent zone, usually within minutes to a few hours, depending on the registry.
4. Check that the chain validates with a DNSSEC analysis tool before you build anything on top of it.

example.com. 3600 IN DS 12345 13 2 (
    3B2A1F0E9D8C7B6A59483726150F4E3D2C1B0A99887766554433221100FFEEDD )

The four fields are the key tag, the algorithm (13 is ECDSA P-256 with SHA-256), the digest type (2 is SHA-256) and the digest of your key. Copy the values exactly as your provider gives them; the example above is made up.

The free Email Security Check looks for a DS record for your domain in the parent zone. A domain without one is reported as needing attention, because every other setting in the report could be replaced without anyone noticing.

How does DNSSEC relate to DANE and TLSA records?

DANE for SMTP (RFC 6698 and RFC 7672) uses DNSSEC to tell sending servers which certificate or key your MX hosts will present. You publish a TLSA record for port 25 on each MX host:

_25._tcp.mail.example.com. TLSA 3 1 1 (
    0D1C2B3A49586776859403A2B1C0D9E8F7A6B5C4D3E2F1009988776655443322 )

3 1 1 means: match the server's own certificate (3), by its public key (1), using a SHA-256 hash (1). This is the form RFC 7672 recommends for most mail servers. Because the key is pinned, publish the TLSA record for a new key before the server starts using it.

DANE gets all of its security from DNSSEC. Senders only use TLSA records when they can validate them, which requires the zone that holds the MX host to be signed, and your own MX records to be signed too. TLSA records in an unsigned zone are ignored, and the Email Security Check reports them as a failure because they give a false sense of protection.

DANE is optional. If no TLSA records are published, the check reports DANE as not in use, which is fine. If your mail is hosted by a provider, the MX hosts are usually in the provider's zone, so whether DANE is possible depends on them.

Do I need DNSSEC for MTA-STS?

No. MTA-STS fetches its policy over HTTPS and relies on the web certificate system, so it works without DNSSEC. That is the main reason it exists alongside DANE: many domains and mail providers could not sign their zones.

The two complement each other. DNSSEC protects the records MTA-STS cannot: SPF, DKIM, DMARC and the TLS-RPT record. DANE and MTA-STS can be used together, and a sender that supports both must not let MTA-STS override a failed DANE check.

What can go wrong with DNSSEC?

A broken DNSSEC chain is worse than no DNSSEC. When the DS record in the parent does not match a valid key in your zone, or the signatures have expired, validating resolvers return SERVFAIL instead of an answer. To everyone who uses such a resolver, your domain disappears.

• Mail to you is delayed and eventually bounced, because sending servers cannot look up your MX records.
• Receivers cannot read your SPF, DKIM or DMARC records, so your outgoing mail may fail authentication or be deferred.
• Your website and other services under the domain become unreachable for users behind validating resolvers.

The usual causes are a key change that was not reflected in the DS record, moving to a DNS provider that does not sign the zone with the same keys, and switching off signing while the DS record is still published.

How do I roll over keys or change DNS provider safely?

1. Let your DNS provider handle routine key rollovers. Keys that only sign the zone change without any action from you. A change of the key the DS record points to does need a new DS record at the registrar, unless your provider and registry support automatic updates through CDS records (RFC 7344 and 8078).
2. Before you change DNS provider, remove the DS record at your registrar while the old provider is still serving the signed zone.
3. Wait until the old DS record has expired from resolver caches. Check its TTL in the parent zone; a day or two is usually enough.
4. Move the zone to the new provider and check that every record, including SPF, DKIM, DMARC, MX and _mta-sts, answers correctly.
5. Enable signing at the new provider and publish its DS record at the registrar.

The same order applies if you ever want to switch DNSSEC off: remove the DS record first, wait, and only then stop signing. Providers that support multi-signer DNSSEC (RFC 8901) can move a zone without an unsigned period, but that requires careful coordination between both providers.