DNS Security Checklist: SPF, DMARC, DKIM, and DNSSEC Explained

DNS: The Overlooked Foundation of Your Attack Surface

When teams think about security, they think about firewalls, patching, and maybe WAFs. DNS rarely makes the list. That is a mistake. DNS is the foundation of your entire public attack surface. Every domain you own, every email you send, every certificate you issue — it all starts with DNS records.

Misconfigured DNS does not throw errors. It does not break your website. It silently opens doors: spoofed emails passing authentication, fraudulent certificates issued for your domain, subdomains hijacked through dangling records. These are not theoretical risks. They are the exact techniques used in real-world phishing campaigns and supply chain attacks.

This guide walks through the five DNS security controls every organization should have in place: SPF, DKIM, DMARC, DNSSEC, and CAA records. For each one, you will get a clear explanation of what it does, how to set it up, and the mistakes to avoid. At the end, there is an eight-item checklist you can run through this week.

SPF: Authorizing Your Mail Senders

What it does: Sender Policy Framework (SPF) is a DNS TXT record that tells receiving mail servers which IP addresses and hosts are authorized to send email on behalf of your domain. When a server receives an email claiming to be from yourdomain.com, it checks the SPF record to see if the sending server is on the approved list.

How to set it up: Create a TXT record on your root domain. A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

This record says: Google Workspace, SendGrid, and the IP 203.0.113.10 are authorized senders. Everything else should fail (-all).

Common mistakes to avoid:

• Using +all instead of -all. The +all mechanism means "allow everyone to send as my domain." It completely defeats the purpose of SPF. Always use -all (hard fail) or at minimum ~all (soft fail).
• Exceeding the 10-lookup limit. SPF allows a maximum of 10 DNS lookups (including nested includes). Every include:, a:, mx:, and redirect= counts toward this limit. Exceeding it causes your entire SPF record to fail silently — meaning no sender is authorized. Use an SPF flattening tool if you are close to the limit.
• Forgetting subdomains. If you send email from notifications.yourdomain.com, that subdomain needs its own SPF record. The root domain SPF record does not cover subdomains automatically.
• Not having an SPF record at all. Without SPF, anyone can send email pretending to be your domain with no authentication check whatsoever.

DKIM: Cryptographically Signing Your Emails

What it does: DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing emails. The sending server signs each message with a private key, and the corresponding public key is published as a DNS TXT record. Receiving servers use the public key to verify the signature, confirming the email was not tampered with in transit and actually originated from an authorized system.

How to set it up: DKIM is typically configured through your email provider. Google Workspace, Microsoft 365, and transactional email services like SendGrid and Postmark all generate DKIM keys for you. You publish the public key as a TXT record at a selector-based subdomain:

google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

The selector (in this case google) is specific to the email provider. Each provider you use will have its own selector and key pair.

How to verify it is working:

• Send a test email and inspect the headers. Look for DKIM-Signature in the raw message headers and dkim=pass in the Authentication-Results header.
• Use a tool like dig TXT google._domainkey.yourdomain.com to confirm the public key is published and resolving correctly.
• If you use multiple email providers (e.g., Google for corporate mail and SendGrid for transactional), make sure each one has its own DKIM selector configured and published.

Key detail: DKIM does not tell receivers what to do when verification fails. That is what DMARC is for.

DMARC: Telling Receivers What to Do with Failures

What it does: Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together into an enforceable policy. It tells receiving mail servers what to do when an email fails both SPF and DKIM checks: deliver it anyway, quarantine it, or reject it outright. It also provides a reporting mechanism so you can see who is sending email as your domain.

How to set it up: Publish a TXT record at _dmarc.yourdomain.com:

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

The progression from monitoring to enforcement:

• p=none — Monitor only. Emails that fail authentication are still delivered, but you receive reports. This is the right starting point while you identify all legitimate senders.
• p=quarantine — Failed emails go to spam/junk. This is the intermediate step to catch issues before going to full enforcement.
• p=reject — Failed emails are dropped entirely. This is the goal. It prevents spoofed emails from reaching inboxes at all.

The biggest mistake: Setting p=none and never progressing beyond it. A DMARC record with p=none tells you what is happening but does nothing to stop it. Treat p=none as a temporary phase — review your aggregate reports, fix your SPF and DKIM alignment, and move to p=quarantine within 30 days and p=reject within 90.

Other things to get right:

• Set pct=100 to apply the policy to all messages, not just a percentage.
• Configure the rua tag to receive aggregate reports. Without it, you are flying blind.
• Make sure SPF and DKIM alignment passes. DMARC requires that the domain in the From: header aligns with the domain authenticated by SPF or DKIM. Misalignment is the most common reason DMARC fails for legitimate senders.

DNSSEC: Preventing DNS Spoofing

What it does: DNS Security Extensions (DNSSEC) adds cryptographic signatures to DNS responses. When a resolver queries your domain, DNSSEC lets it verify that the response actually came from the authoritative nameserver and was not modified in transit. Without DNSSEC, attackers can perform DNS cache poisoning — injecting forged records that redirect your visitors to malicious servers.

How it works: DNSSEC uses a chain of trust. Your domain's DNS records are signed with a private key, and the corresponding public key (the DNSKEY record) is published in DNS. A hash of that key (the DS record) is registered with the parent zone (e.g., .com). Resolvers walk this chain from the root zone down to your domain to verify authenticity.

Why many domains still do not have it:

• Registrar and DNS provider must both support it. If your registrar supports DNSSEC but your DNS provider does not (or vice versa), you cannot enable it. Not all providers make it easy.
• Risk of misconfiguration. A broken DNSSEC setup is worse than no DNSSEC. If the DS record at the registrar does not match the DNSKEY at the DNS provider, your domain will fail validation entirely — meaning resolvers that enforce DNSSEC will refuse to resolve your domain at all.
• Perceived complexity. Key rotation, algorithm choices, and the coordination between registrar and DNS provider can feel daunting. In practice, many modern DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) handle this with a single toggle.

The practical step: Check if your DNS provider supports one-click DNSSEC. If you use Cloudflare, it is a single button in the DNS settings. If your provider does not support it, that is worth considering as a reason to migrate.

CAA Records: Controlling Certificate Issuance

What it does: Certificate Authority Authorization (CAA) records specify which Certificate Authorities are allowed to issue SSL/TLS certificates for your domain. Without a CAA record, any CA in the world can issue a certificate for your domain if they follow their standard validation process. With a CAA record, CAs are required to check and refuse issuance if they are not on the list.

How to set it up: Add CAA records to your domain's DNS:

yourdomain.com. CAA 0 issue "letsencrypt.org"
yourdomain.com. CAA 0 issuewild "letsencrypt.org"
yourdomain.com. CAA 0 iodef "mailto:security@yourdomain.com"

This configuration says: only Let's Encrypt can issue certificates (including wildcards) for this domain, and violations should be reported to your security email.

Why it matters: CAA records are a defense against misissued certificates. If an attacker convinces a less rigorous CA to issue a certificate for your domain, they can perform man-in-the-middle attacks. CAA records reduce this risk by restricting issuance to CAs you trust. Since 2017, all CAs are required to check CAA records before issuing certificates.

• Use the issue tag for standard certificates and issuewild for wildcard certificates.
• If you do not use wildcard certificates, you can set issuewild ";" to explicitly prohibit them.
• Add an iodef tag to get notified of unauthorized issuance attempts.

Common DNS Security Failures

These are the issues we see most frequently when scanning domains. Each one represents a real, exploitable gap in your security posture:

• No SPF record at all. Anyone can send email as your domain with zero resistance. This is the most basic email authentication failure.
• SPF record with +all. Worse than no SPF in some ways — it explicitly tells receivers that every server on the internet is authorized to send as your domain.
• DMARC stuck on p=none for months or years. You are collecting data but taking no action. Attackers spoofing your domain face no consequences.
• No DMARC record at all. Without DMARC, even if you have SPF and DKIM, receivers have no policy guidance on what to do with failures.
• No DNSSEC. Your domain's DNS responses can be spoofed. This is especially dangerous for domains handling sensitive transactions.
• No CAA records. Any Certificate Authority can issue certificates for your domain, increasing the risk of unauthorized certificate issuance.
• Dangling CNAME records. A CNAME pointing to a service you no longer use (a decommissioned S3 bucket, a cancelled Heroku app, an expired Azure instance) is a subdomain takeover waiting to happen. An attacker can claim the target resource and serve content on your subdomain.
• Exposed internal DNS records. TXT records containing internal hostnames, version information, or debug data leak information that helps attackers map your infrastructure.

How FortWatch Checks All of This Automatically

FortWatch's DNS security scanner runs these checks automatically against every domain in your attack surface. When you add a domain to FortWatch, the scanner queries your DNS records and evaluates them against security best practices:

• SPF validation: Checks for the presence of an SPF record, verifies it uses -all or ~all (not +all), counts DNS lookups to flag records exceeding the 10-lookup limit, and checks for syntax errors.
• DKIM detection: Verifies that DKIM records are published for known selectors and that the public keys are valid.
• DMARC analysis: Checks for a DMARC record, evaluates the policy level (none, quarantine, reject), flags missing reporting addresses, and checks for alignment issues.
• DNSSEC verification: Tests whether DNSSEC is enabled and properly configured with a valid chain of trust from your domain to the root zone.
• CAA record audit: Checks whether CAA records exist and whether they appropriately restrict certificate issuance.
• Dangling record detection: Identifies CNAME records pointing to services that no longer resolve, flagging potential subdomain takeover vulnerabilities.

Each finding is categorized by severity — critical issues like +all SPF records surface immediately, while informational items like missing CAA records are tracked without cluttering your high-priority queue. The scanner re-checks automatically on a schedule, so you will know if a DNS record changes or degrades.

Your DNS Security Checklist

Run through these eight items this week. Each one takes minutes to check and addresses a real risk:

• 1. Verify you have an SPF record — run dig TXT yourdomain.com and look for a v=spf1 record. If it is missing, create one listing all your authorized senders.
• 2. Confirm your SPF record ends with -all — not ~all and definitely not +all. Hard fail unauthorized senders.
• 3. Check your SPF lookup count — use an online SPF validator to count lookups. If you are at or above 10, flatten your record or consolidate providers.
• 4. Verify DKIM is signing your emails — send a test email to an external address and inspect the raw headers for dkim=pass in the Authentication-Results.
• 5. Publish a DMARC record and progress the policy — if you do not have one, start with p=none and a rua address. If you have been on p=none for more than 30 days, move to p=quarantine. If you have been on p=quarantine for more than 30 days, move to p=reject.
• 6. Enable DNSSEC — check your DNS provider's dashboard. If they offer one-click DNSSEC, enable it. Verify with dig +dnssec yourdomain.com and look for the ad (authenticated data) flag.
• 7. Add CAA records — restrict certificate issuance to only the CAs you actually use. Block wildcard issuance if you do not need it.
• 8. Audit your CNAME records — review all CNAME entries and resolve each target. If any point to services you have decommissioned, remove the record immediately to prevent subdomain takeover.

None of these require a security team or an expensive tool. They require attention. DNS security is one of the highest-impact, lowest-effort improvements you can make to your security posture — but only if you actually do it.

If you want to automate these checks across all your domains and subdomains, FortWatch runs them continuously and alerts you when something changes or degrades. Add your first domain and see where you stand in under a minute.