The Ultimate Checklist for Securing DNS Records & Email Auth

Introduction

A mis‑configured DNS zone can expose your brand to phishing, spam abuse, and even downtime. As a DevOps lead, you’re probably juggling CI pipelines, monitoring dashboards, and a growing list of services. This checklist gives you a practical, step‑by‑step way to lock down the most common attack surfaces in DNS and email authentication – all without breaking your existing workflow.

1️⃣ Verify Core DNS Records

Before you dive into security extensions, make sure the basics are solid.

• A / AAAA records – Point to the correct IPs, and avoid CNAME chains that increase latency.
• CNAME flattening – If your provider supports it, use flattening for apex domains to reduce extra lookups.
• MX records – Ensure they reference only mail servers you control.
• NS records – Keep them limited to the authoritative name servers you actually run.
• TTL values – Set a low TTL (300–600 seconds) during changes, then raise to 1 hour or more for stability.

2️⃣ Harden Email with SPF, DKIM, and DMARC

These three records work together to prove that your domain is the legitimate sender of email.

SPF (Sender Policy Framework)

Create a TXT record that lists every server allowed to send mail on behalf of your domain.

example.com.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"

• ip4/ip6 – List your own mail server ranges.
• include – Pull in third‑party services (Gmail, SendGrid, etc.).
• -all – Hard‑fail any unauthorized sender.

DKIM (DomainKeys Identified Mail)

Generate a public/private key pair and publish the public key as a TXT record.

default._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

• Rotate keys every 6‑12 months.
• Align the selector (default above) with your mail server configuration.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC tells receiving servers what to do when SPF or DKIM fail, and where to send aggregate reports.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

• p=reject – Instruct receivers to discard unauthenticated mail.
• rua / ruf – Collect daily reports to monitor abuse.
• Start with p=none for monitoring, then move to quarantine and finally reject.

3️⃣ Deploy DNSSEC

DNSSEC adds a cryptographic signature to each DNS response, preventing cache poisoning.

1. Generate ZSK and KSK keys on your authoritative server (BIND, PowerDNS, etc.).
2. Sign the zone and publish the DS record at your registrar.
3. Enable DNSSEC validation on recursive resolvers (e.g., Unbound, Cloudflare DNS).

# Example with BIND
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
dnssec-signzone -o example.com -k Kexample.com.+005+12345 example.com.zone

• Rotate keys annually.
• Verify signatures with dig +dnssec example.com.

4️⃣ Add CAA Records to Prevent Unauthorized Certificate Issuance

Certification Authority Authorization (CAA) tells CAs which ones are allowed to issue certs for your domain.

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

• Use issue for normal certificates.
• Use issuewild "" to block wildcard certs unless explicitly allowed.
• Add iodef tags to receive violation reports.

5️⃣ Harden the Resolver Layer

Even if your authoritative zone is locked down, a permissive resolver can leak information.

• Enable DNS over TLS (DoT) or DNS over HTTPS (DoH) on your recursive servers.
• Rate‑limit queries to mitigate amplification attacks (rate-limit in BIND).
• Block public resolvers from querying internal zones using allow-query ACLs.

options {
    rate-limit {
        responses-per-second 5;
        window 5;
    };
    allow-query { trusted; };
    listen-on { 127.0.0.1; };
};

6️⃣ Continuous Monitoring & Alerting

Automation is key. Integrate DNS checks into your CI/CD pipeline.

• Health checks – Use dig +short @ns1.example.com example.com in a cron job.
• Expiry alerts – Tools like certbot can also warn when DNSSEC keys are near rotation.
• Log analysis – Forward BIND logs to a SIEM (e.g., Elastic Stack) and set alerts for NXDOMAIN spikes.

7️⃣ Backup & Disaster Recovery

Never assume a zone file is immutable.

• Store signed zone files in version‑controlled storage (Git).
• Keep encrypted snapshots of your DNS server configuration.
• Test restoration by loading the zone on a staging resolver before a real incident.

Final Thoughts

Securing DNS and email authentication is a marathon, not a sprint. By following this checklist you’ll dramatically reduce the risk of spoofing, phishing, and DNS‑based attacks while keeping your infrastructure observable and recoverable. For teams that need a partner to review their DNS hardening strategy or provide on‑demand expertise, consider checking out https://lacidaweb.com for a low‑friction consultation.