DNS Security — SPF, DMARC, DNSSEC Guide

Published: April 8, 2026 · Reading time: 15 min

1. How DNS works

DNS (Domain Name System) is the system that translates human-readable domain names (e.g., google.com) into IP addresses (e.g., 142.250.185.78) that computers use to communicate. It is often called the "phone book of the internet."

DNS hierarchy

DNS uses a hierarchical structure with four levels:

1. DNS Resolver (Recursive) — your ISP or a public resolver (8.8.8.8, 1.1.1.1) that receives your queries and finds answers
2. Root servers — 13 root server clusters (a.root-servers.net through m.root-servers.net) that direct to TLD servers
3. TLD servers — servers for top-level domains (.com, .org, .net) that know where authoritative servers for each domain are
4. Authoritative DNS servers — the final servers that store actual DNS records for the domain (A, AAAA, MX, TXT, CNAME, etc.)

DNS query step by step

User types: www.example.com
  |
  v
1. Browser checks local cache
2. OS checks hosts file and local DNS cache
3. Sends query to DNS resolver (e.g., 8.8.8.8)
4. Resolver asks root server: "Where is .com?"
5. Root responds: "Ask a.gtld-servers.net"
6. Resolver asks TLD server: "Where is example.com?"
7. Resolver asks authoritative server: "What's the IP for www.example.com?"
8. Authoritative responds: "93.184.216.34"
9. Resolver caches the response and returns it to the browser

2. DNS attacks

DNS Cache Poisoning

An attacker injects fake DNS records into a resolver's cache, causing all users of that resolver to be redirected to a malicious server. For example, an attacker could redirect bank.com to their own server hosting a fake copy of the banking site.

DNS Spoofing

Similar to cache poisoning, but the attacker intercepts DNS queries directly (e.g., on the same network via ARP spoofing) and returns a fake response before the legitimate server can respond.

DNS Hijacking

The attacker takes control of a domain's DNS records — either by compromising the DNS provider or by stealing access to the domain registrar. This is the most dangerous type because the attacker has full control.

Notable example: In 2019, the "Sea Turtle" campaign compromised DNS registrars in the Middle East and North Africa, redirecting email and web traffic of government organizations.

Source: Cisco Talos Intelligence, "Sea Turtle" DNS Hijacking Campaign, 2019

3. Kaminsky attack (2008)

In July 2008, security researcher Dan Kaminsky publicly disclosed a fundamental vulnerability in the DNS protocol. This vulnerability allowed an attacker to poison the cache of any DNS resolver within just 10 seconds.

The problem was that DNS used predictable Transaction IDs (only 16 bits, i.e., 65,536 possibilities). Kaminsky demonstrated that an attacker could send thousands of fake responses with different Transaction IDs and statistically guess the correct ID before the legitimate response arrived.

Source: "An Illustrated Guide to the Kaminsky DNS Vulnerability", unixwiz.net, 2008

4. SPF — Sender Policy Framework

SPF (defined in RFC 7208) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. When a recipient gets an email from your domain, they check the SPF record and reject the email if it didn't come from an authorized server.

How to configure SPF

# Basic SPF record — allow only your MX servers
v=spf1 mx -all

# SPF with specific IP addresses
v=spf1 ip4:93.87.12.34 ip4:93.87.12.35 -all

# SPF with included providers (Google Workspace + Mailchimp)
v=spf1 include:_spf.google.com include:servers.mcsv.net -all

# Mechanism explanation:
# v=spf1     — SPF version
# ip4:       — allow IP address
# include:   — include another domain's SPF
# mx         — allow domain's MX servers
# a          — allow domain's A record
# -all       — REJECT everything else (hard fail)
# ~all       — mark everything else as suspicious (soft fail)

SPF limitations

• Maximum of 10 DNS lookups per SPF record (include, a, mx each count)
• SPF does not protect the "From" header visible to the user — it only protects the envelope sender
• SPF breaks with email forwarding because the IP changes

5. DMARC — Domain-based Message Authentication

DMARC (defined in RFC 7489) builds on SPF and DKIM. It tells the receiving server what to do if an email fails SPF/DKIM checks, and enables receiving reports about non-aligned emails.

DMARC policies

DMARC record example

# DNS TXT record for _dmarc.yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com;
  ruf=mailto:dmarc-forensic@yourdomain.com; adkim=s; aspf=s; pct=100

# Explanation:
# v=DMARC1  — version
# p=reject  — reject non-aligned emails
# rua=      — address for aggregate reports (daily)
# ruf=      — address for forensic reports (per-email)
# adkim=s   — strict DKIM alignment
# aspf=s    — strict SPF alignment
# pct=100   — apply to 100% of emails

6. DNSSEC — DNS Security Extensions

DNSSEC (defined in RFC 4033, 4034, 4035) adds cryptographic signatures to DNS responses. This allows a resolver to verify that a response genuinely came from the authoritative server and has not been modified in transit.

How DNSSEC works

1. DNSKEY record — the authoritative server publishes its public key
2. RRSIG record — each DNS record is signed with the private key
3. DS record — a hash of the public key is registered at the parent zone (chain of trust)
4. The resolver verifies the signature using the public key from the DNSKEY record

# Check DNSSEC status of a domain
$ dig +dnssec example.com
;; flags: qr rd ra ad;   # "ad" flag = Authentic Data (DNSSEC valid)

# Display DNSKEY records
$ dig DNSKEY example.com +short
256 3 8 AwEAAd...   # ZSK (Zone Signing Key)
257 3 8 AwEAAc...   # KSK (Key Signing Key)

# Display RRSIG signatures
$ dig A example.com +dnssec
example.com. 300 IN A 93.184.216.34
example.com. 300 IN RRSIG A 8 2 300 20260501 20260401 12345 example.com. abc123...

Why is DNSSEC important?

Without DNSSEC, there is no way to verify the authenticity of DNS responses. An attacker who successfully performs cache poisoning can redirect users to a malicious site, and neither the user nor the resolver can detect it.

7. Frequently asked questions

8. References

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 7489 — DMARC: Domain-based Message Authentication
• RFC 4033-4035 — DNS Security Extensions (DNSSEC)
• APNIC DNSSEC Deployment Statistics
• Verizon Data Breach Investigations Report (DBIR)
• Cisco Talos: Sea Turtle DNS Hijacking Campaign