How to Check for DNS Security

Why DNS Security Matters#

DNS is the foundation of how your domain is found, verified, and trusted on the internet. When DNS records are missing or misconfigured, attackers can send emails that appear to come from your domain, issue fraudulent SSL certificates for your site, or intercept traffic intended for your servers.

Most domain owners focus on HTTP headers and TLS certificates but overlook DNS records entirely. A properly configured DNS setup includes email authentication (SPF, DMARC, DKIM), certificate controls (CAA), cryptographic validation (DNSSEC), and redundant nameservers.

DNS records live on the apex domain

SPF, DMARC, CAA, and NS records should be configured on your root domain (example.com), not on subdomains like www.example.com. Most DNS providers manage this automatically when you add records to the root zone.

SPF: Sender Policy Framework#

SPF tells receiving mail servers which IP addresses and mail servers are authorized to send email on behalf of your domain. Without SPF, anyone can send an email that claims to be from your domain and most mail servers will accept it.

How SPF works

You publish a TXT record on your domain that lists all authorized senders. When a receiving server gets an email from your domain, it checks the sending server's IP against your SPF record. If it doesn't match, the email fails SPF validation.

Example SPF record

v=spf1 include:_spf.google.com include:mail.zendesk.com ip4:203.0.113.0/24 ~all

v=spf1 identifies this as an SPF record

include: authorizes another domain's SPF senders (e.g., Google Workspace)

ip4: authorizes a specific IP range

~all softfail: mark unauthorized senders as suspicious but still deliver

SPF mechanisms explained

-all

Hardfail. Reject email from unauthorized senders. Strictest setting.

~all

Softfail. Mark unauthorized email as suspicious. Most common starting point.

?all

Neutral. No opinion on unauthorized senders. Provides no protection.

+all

Pass all. Allows any server to send. Never use this, it defeats the purpose of SPF.

SPF has a 10 DNS lookup limit

Each include: and redirect= counts as a DNS lookup. If your SPF record exceeds 10 lookups, it will permanently fail validation. Use SPF flattening tools to consolidate includes into IP addresses if you hit this limit.

DMARC: Domain-based Message Authentication#

DMARC builds on SPF and DKIM to give domain owners control over what happens when an email fails authentication. It also provides reporting so you can see who is sending email on behalf of your domain.

How DMARC works

DMARC is published as a TXT record at _dmarc.yourdomain.com. It tells receiving servers to check SPF and/or DKIM alignment, and specifies whether to reject, quarantine, or allow messages that fail.

Example DMARC record

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com

v=DMARC1 identifies this as a DMARC record

p=reject the policy: reject emails that fail authentication

pct=100 apply the policy to 100% of messages

rua= where to send aggregate reports about authentication results

DMARC policies

p=none

Monitor only. Collect reports but take no action on failing messages. Use this to start and understand your email flow.

p=quarantine

Send failing messages to the spam folder. A good intermediate step after you have reviewed your reports and confirmed legitimate senders are passing.

p=reject

Block failing messages entirely. The strongest protection against email spoofing. Only enable after confirming all legitimate senders pass SPF/DKIM.

Recommended rollout path

Start with p=none and a rua= address to collect reports for 2 to 4 weeks. Review the reports to identify all legitimate senders, ensure they pass SPF and DKIM, then move to p=quarantine and eventually p=reject.

DKIM: DomainKeys Identified Mail#

DKIM adds a cryptographic signature to outgoing emails. The receiving server uses a public key published in your DNS to verify the signature, confirming that the email was actually sent by your domain and was not modified in transit.

How DKIM works

Your mail server signs each outgoing email with a private key

The signature is added as a DKIM-Signature header in the email

The receiving server looks up the public key at selector._domainkey.yourdomain.com

If the signature validates, the email is confirmed authentic and unmodified

DKIM is typically configured through your email provider (Google Workspace, Microsoft 365, SendGrid, etc.) rather than manually. Each provider gives you a specific DNS record to publish.

Example DKIM DNS record

Host: google._domainkey.example.com

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

How SPF, DKIM, and DMARC work together

SPF verifies the sending server is authorized (IP based)

DKIM verifies the message content is authentic and unmodified (cryptographic)

DMARC ties them together: requires at least one to pass with domain alignment, and tells receivers what to do when both fail

For the strongest protection, configure all three. SPF alone can be bypassed by forwarded email. DKIM alone doesn't tell receivers what to do with failures. DMARC alone has nothing to enforce without SPF or DKIM results to evaluate.

CAA: Certificate Authority Authorization#

CAA records specify which certificate authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. Without CAA records, any CA in the world can issue a certificate for your domain if someone can prove control (which attackers sometimes fake through DNS hijacking or social engineering).

Example CAA records

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

issue authorizes a CA to issue certificates for this domain

issuewild authorizes a CA to issue wildcard certificates

iodef specifies where to send violation reports

Since 2017, all CAs are required to check CAA records before issuing certificates (per the CA/Browser Forum Baseline Requirements). If a CAA record exists and the CA is not listed, the CA must refuse to issue the certificate. This makes CAA a low effort, high value security control.

DNSSEC: DNS Security Extensions#

DNSSEC adds cryptographic signatures to DNS responses, allowing resolvers to verify that the DNS data they receive is authentic and has not been tampered with. Without DNSSEC, an attacker who can intercept DNS traffic (through cache poisoning, BGP hijacking, or man in the middle attacks) can redirect your domain's traffic to their own servers.

How DNSSEC works

Zone signing: Your DNS provider signs your zone records with a private key (ZSK). Each record gets an RRSIG signature record.

Chain of trust: A DS (Delegation Signer) record in the parent zone (.com for example.com) references your zone's key. This creates a chain of trust from the root zone down to your domain.

Validation: Resolvers that support DNSSEC follow the chain of trust and verify signatures at each level. If any signature fails, the response is rejected.

Enabling DNSSEC

DNSSEC is enabled at two levels: your DNS provider must sign your zone, and your domain registrar must publish the DS record in the parent zone. Most modern DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) support DNSSEC with a single toggle.

Cloudflare

Dashboard > DNS > DNSSEC > Enable. Cloudflare handles DS record submission automatically for domains registered with Cloudflare Registrar.

AWS Route 53

Enable DNSSEC signing in the hosted zone, then add the DS record to your registrar manually.

Google Cloud DNS

Enable DNSSEC in Cloud DNS settings. If using Google Domains, DS records propagate automatically.

Other providers

Check your DNS provider documentation for DNSSEC signing, then add the DS record through your domain registrar.

DNSSEC requires careful key management

If DNSSEC keys expire or the DS record becomes out of sync, your entire domain can become unreachable. Use a managed DNS provider that handles key rotation automatically. Never enable DNSSEC without understanding your provider's key management process.

Nameserver Best Practices#

Your nameservers are the entry point for all DNS lookups. If they go down, your entire domain becomes unreachable. Proper nameserver configuration ensures availability and reduces the risk of DNS-based attacks.

Use at least 2 nameservers

A single nameserver is a single point of failure. Most registrars require a minimum of 2, and 4 or more is recommended for critical domains.

Use different networks

Your nameservers should be on different physical networks. If both nameservers are in the same data center, a single outage takes down your entire domain.

Keep TTLs reasonable

Short TTLs (300 seconds) allow fast failover but increase DNS query volume. Long TTLs (86400 seconds) reduce load but slow down changes. 3600 seconds (1 hour) is a good default for most records.

Monitor nameserver health

Use external monitoring to verify your nameservers respond correctly. DNS issues can be silent and only surface when users cannot reach your site.

Implementation Checklist#

Use this checklist to verify your domain's DNS security configuration. Each item can be checked with the SiteSecurityScore scan tool.

SPF record published

TXT record starting with v=spf1 on your root domain. Ends with ~all or -all.

DKIM configured for all senders

Each email service (Google, Outlook, transactional email) has its own DKIM key published in DNS.

DMARC record at _dmarc subdomain

TXT record starting with v=DMARC1. Policy set to quarantine or reject after monitoring period.

DMARC reports configured

rua= tag pointing to a mailbox where you actively review aggregate reports.

CAA records restricting certificate issuance

At least one CAA issue record listing your approved certificate authority.

Multiple nameservers on different networks

At least 2 NS records pointing to servers on separate infrastructure.

DNSSEC enabled

Zone signed by your DNS provider with DS record published at your registrar.