Whether you are launching a new domain, migrating to a new mail provider, or doing routine security hygiene, running a structured DNS audit takes less than 15 minutes and can prevent days of troubleshooting later. Here is the complete checklist.
1. Verify your SPF record is correct and not over the 10-lookup limit
Check that your domain has exactly one SPF TXT record. Multiple SPF records cause a PermError and break authentication for all senders.
Count the number of DNS lookups in your SPF record (each include:, a, mx, and ptr mechanism counts). The limit is 10. Exceeding it causes a PermError that results in SPF failure for all your legitimate mail.
Always end with -all or ~all. An SPF record without a catch-all mechanism (e.g., ?all or missing entirely) is essentially open — any server can claim to send from your domain.
2. Confirm DKIM keys are published and match your mail provider
Verify that a DKIM public key exists in DNS for every selector your mail provider uses. Ask your provider which selectors they use (e.g., google, selector1, k1).
The record should return a v=DKIM1 value with a public key (p=). A missing or empty p= value means the key has been revoked.
3. Set a DMARC policy with actual enforcement (not just p=none)
Check for a DMARC record and verify the policy value. A p=none policy provides monitoring only — it does not stop spoofing.
For domains that are not used to send email at all (parked domains), use p=reject immediately to fully close the spoofing attack surface.
4. Confirm MX records point to the right mail servers with correct priority
If MX records are missing, incorrectly configured, or pointing to a decommissioned host, incoming email will bounce or be lost.
Verify that the hostnames in your MX records resolve to actual IP addresses (check with dig A on each MX hostname). Also confirm the priority values are correct if you have backup mail servers.
5. Verify A records resolve correctly and point to live servers
Check that your apex domain and www subdomain both resolve to the correct IP addresses. After any server migration, confirm old IP addresses have been removed.
6. Check that your mail server's IP has a matching PTR record
Reverse DNS (PTR records) map your mail server's IP address back to a hostname. Many receiving mail servers perform a PTR lookup on incoming connections and will reject or spam-score mail from IPs without a valid PTR record.
The PTR record is set by your hosting provider or ISP — not in your DNS zone. Contact your provider if it is missing or incorrect.
7. Set appropriate TTL values before making changes
If you are planning a migration or DNS change, lower your TTL values 24–48 hours before the change. A TTL of 300 seconds (5 minutes) allows changes to propagate quickly. After the migration is stable, raise the TTL back to 3600 or higher for better performance.
8. Audit CNAMEs for dangling references
A CNAME pointing to a service you no longer use (a deleted Heroku app, an old Zendesk domain, a decommissioned cloud bucket) is a subdomain takeover vulnerability. Anyone can register that service and take over your subdomain.
Remove or update every CNAME that no longer points to a service you control.
9. Enable DNSSEC if your registrar and DNS provider support it
DNSSEC adds cryptographic signatures to your DNS records, preventing cache poisoning attacks. Both your DNS provider and domain registrar need to support it. Check if it is already enabled by looking for DS records at your registrar.
10. Confirm you have at least two geographically distributed NS records
A single nameserver is a single point of failure. Verify your domain has at least two NS records pointing to servers at different providers or data centers. Most DNS providers handle this automatically, but it is worth confirming.
Run this audit quarterly. DNS configurations drift over time as services are added, removed, and migrated. A quarterly audit catches dangling CNAMEs and expired configurations before they become security incidents.