How DNSSEC Protects SPF, DKIM, and MX Records

Email Authentication Depends on DNS Integrity

SPF, DKIM, and DMARC form the foundation of email authentication. All three protocols rely on DNS records — TXT records that the receiving server queries for every incoming message. MX records determine where email gets delivered. If an attacker can forge these DNS responses, the entire email authentication stack becomes meaningless.

DNSSEC solves this problem by adding cryptographic signatures to DNS responses. A validating resolver verifies these signatures before passing data to the application. DNSSEC matters more for email than for the web — TLS certificates, which protect web traffic, are largely absent from email delivery.

How DNS Cache Poisoning Threatens Email

DNS cache poisoning is an attack where an adversary injects a forged DNS response into a resolver's cache. The resolver stores it and returns the forged data to all clients for the duration of the record's TTL.

For web traffic, there is a safety net — the TLS certificate. Even if an attacker redirects DNS to their server, the browser validates the certificate and refuses the connection. Email lacks this safety net:

• SMTP does not mandate encryption. Most mail servers use opportunistic STARTTLS — if the other side does not support TLS, the message is sent in plaintext.
• Mail server certificates are often not validated. Unlike web browsers, many mail servers accept invalid or self-signed certificates.
• Email DNS records are higher-value targets. A forged MX record can redirect all incoming mail. A forged SPF record can legitimize spoofed messages.

Email is therefore far more sensitive to DNS integrity than the web. DNSSEC provides that integrity.

SPF Record — Sender Authorization

The SPF record (RFC 7208) defines which servers are authorized to send email on behalf of a domain. The recipient queries this TXT record from DNS for every incoming message.

Attack Without DNSSEC

An attacker poisons the SPF record for example.com and replaces it with their own version:

example.com.  IN TXT  "v=spf1 include:attacker.example -all"

The recipient receives this forged record and treats messages from the attacker's server as legitimate. Genuine emails from the domain's authorized servers fail SPF — the forged record does not include them.

Protection With DNSSEC

When example.com is protected by DNSSEC, every TXT record carries a cryptographic signature (RRSIG). A validating resolver detects the forged record — the signature does not match — and rejects the response. The recipient either receives the genuine SPF record or a SERVFAIL error, which leads to a temporary deferral (temperror). In both cases, the attacker's email does not pass.

RFC 7208, Section 11.3, describes the risk of spoofed DNS data as a threat to SPF reliability — DNSSEC is the direct answer to this risk.

DKIM Record — Public Key for Signature Verification

DKIM (RFC 6376) signs emails with a digital signature. The public key for verification is published in DNS as a TXT record at selector._domainkey.example.com.

Attack Without DNSSEC

An attacker forges the DKIM record and replaces the public key with their own:

s1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=ATTACKER_KEY"

The attacker can now sign emails with their private key and the recipient validates them against the forged public key — DKIM passes. The attacker effectively signs messages as example.com.

Protection With DNSSEC

DNSSEC protects records on subdomains including _domainkey. A validating resolver verifies the RRSIG signature and rejects the forged key. The attacker cannot replace the public key because they cannot produce a valid RRSIG signature without access to the domain's DNSSEC zone-signing key.

MX Record — Inbound Mail Routing

The MX record specifies which servers receive email for a domain. Forging an MX record is one of the most severe attacks — the attacker redirects all incoming mail.

Attack Without DNSSEC

An attacker forges the MX record for example.com:

example.com.  IN MX  10 mail.attacker.example.

All incoming mail is delivered to the attacker's server. The attacker reads messages in real time, can modify them, and forward them onward — neither the sender nor the recipient may notice.

Research published in 2014 demonstrated that DNS cache poisoning can be used to redirect email without the knowledge of either party (Internet Society, 2014).

Protection With DNSSEC

MX records are protected by RRSIG signatures just like all other records in the zone. A validating resolver rejects the forged MX record. Email is delivered to the correct server — or not at all, which is preferable to silent interception.

DMARC Record — Policy and Reporting

DMARC (RFC 7489) defines what a recipient should do with messages that fail both SPF and DKIM. The record is published as a TXT record at _dmarc.example.com.

Attack Without DNSSEC

An attacker forges the DMARC record and changes the policy:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:rua@attacker.example"

Two things happen simultaneously:

1. The p=none policy tells recipients to let spoofed messages through — the actual reject policy is gone.
2. Aggregate DMARC reports are redirected to the attacker, who gains insight into the victim's email infrastructure.

Protection With DNSSEC

DNSSEC protects records on the _dmarc subdomain as well. A forged record with an invalid signature is rejected by the resolver. The reject policy remains in effect and reports are sent to the correct addresses.

Why DNSSEC Matters More for Email Than for the Web

For web traffic, the TLS certificate acts as a second layer of defense. For email, DNS is often the only layer — and DNSSEC is the only way to secure it.

DANE — DNSSEC as the Foundation for Certificate Verification

DANE (DNS-Based Authentication of Named Entities, RFC 6698) takes email security further. It allows publishing a mail server's TLS certificate fingerprint directly in DNS as a TLSA record.

The sending server then verifies the recipient's certificate via DNS — without relying on certificate authorities. However, DANE requires functional DNSSEC — without cryptographically verified DNS responses, an attacker could forge the TLSA record and defeat the entire mechanism.

DANE for SMTP is defined in RFC 7672 and is actively deployed by major mail providers — Postfix has fully supported DANE since version 2.11. For more on DANE, see What Is DANE and How It Secures Email Transport.

dig _25._tcp.mail.example.com TLSA +short

If the command returns a TLSA record, the domain's mail server uses DANE.

How to Verify Your Domain's Protection

Online Check

Check your domain with our analyzer — the results include DNSSEC status along with SPF, DKIM, and DMARC checks. If DNSSEC is missing, you will see specific recommendations.

Terminal Check

Verify that your domain's DNS records carry valid DNSSEC signatures:

dig example.com TXT +dnssec +short | grep spf
dig s1._domainkey.example.com TXT +dnssec +short
dig example.com MX +dnssec +short
dig _dmarc.example.com TXT +dnssec +short

If the output of dig (without +short) includes the ad (Authentic Data) flag in the header, your resolver validated DNSSEC and the response is authentic. For a detailed verification walkthrough, see How to Verify DNSSEC for Your Domain.

Deployment Status and Practical Recommendations

As of 2025, only about 4% of .com domains have DNSSEC enabled. Many domains — including those with properly configured SPF, DKIM, and DMARC — do not use DNSSEC.

Practical recommendations:

1. Enable DNSSEC with your DNS provider. Most modern providers (Cloudflare, AWS Route 53, and others) support DNSSEC — activation takes a few clicks.
2. Verify the DS record with your registrar. Without a DS record in the parent zone, DNSSEC does not work even if your zone is signed. See What Is DNSSEC and How It Works for details.
3. Monitor continuously. DNSSEC can break during domain transfers, DNS server changes, or signature expiration — and broken DNSSEC is worse than no DNSSEC.
4. Consider DANE for your mail server. If you run your own mail server and have DNSSEC, DANE adds another layer of protection without relying on certificate authorities.

Check your domain's security — our analyzer verifies DNSSEC, SPF, DKIM, and DMARC and alerts you to problems before your recipients notice them.