Most Common DNS Mistakes: 10 Records to Check Before You Break Your Website or Email

DNS looks simple on the surface: a few records, some hostnames, click save and you are done. In reality, most website or email outages we see at dchost.com are not caused by web servers, PHP, or databases—they are caused by tiny DNS mistakes. One wrong IP, a misplaced CNAME, an outdated MX record, and suddenly your homepage stops loading or invoices never reach your customers. The frustrating part is that these problems are usually 100% avoidable if you know which records to review before hitting “Save”.

In this guide, we will walk through the 10 DNS records you must double‑check before you change hosting, move a domain, switch email providers, or play with a CDN. We will focus on real‑world scenarios we handle every week: website moves, email migrations, rebrands, and security hardening. If you want a deeper fundamentals refresher first, you can also read our article “DNS Records Explained Like a Friend”.

The 10 DNS Records That Most Often Break Sites and Email

Before we dig into details, here is the short list of records you should always review when touching DNS:

• A / AAAA – Website IP addresses (IPv4 / IPv6)
• CNAME – Aliases, CDNs, and www handling
• NS – Nameserver delegation at the domain level
• MX – Email routing for your domain
• SPF (TXT) – Who is allowed to send email for your domain
• DKIM (TXT) – Cryptographic signatures for email
• DMARC (TXT) – Policy for failed SPF/DKIM checks
• CAA – Which certificate authorities may issue SSL for your domain
• PTR (Reverse DNS) – IP to hostname mapping for outbound email
• Service & verification TXT/SRV records – Autodiscover, VoIP, SaaS and “mystery” TXT entries

Let’s look at the most common mistakes for each—and how to avoid them on your own domains or on projects you manage for clients.

1. A and AAAA Records: Wrong IP, Wrong Server, Wrong Version

Typical mistakes

• Pointing the root domain (example.com) or www.example.com to the wrong server IP
• Copying only A records (IPv4) and forgetting AAAA (IPv6), or vice versa
• Leaving old A/AAAA records in place after a migration, causing traffic to split between old and new servers
• Pointing production domains to staging or development servers by accident

The A record is the backbone of your website: it tells browsers which IPv4 address to connect to. AAAA does the same for IPv6. A single typo here can send all your traffic into a black hole or to a completely different server. We see this frequently when people move from shared hosting to a new VPS or dedicated server and copy only half of their records.

How to double‑check A/AAAA safely

• Confirm with your hosting provider (for example, your shared hosting, VPS or dedicated server panel at dchost.com) which exact IP(s) your site should use.
• Ensure both the bare domain (example.com) and www subdomain point to the same, correct IPs, unless you intentionally separate them.
• If you use IPv6, verify that the AAAA record points to the correct IPv6 assigned to your server. Our guide “IPv6 Setup and Configuration for Your VPS Server” explains this in detail.
• Before a migration, temporarily lower TTLs as described in our DNS TTL best practices guide so you can switch IPs and recover quickly if something is wrong.

2. CNAME Records: Aliases Used Where They Should Not Be

Typical mistakes

• Putting a CNAME at the apex/root of the domain (where only A/AAAA are allowed on many DNS providers)
• Using CNAMEs for mail.example.com that conflict with MX records or break SMTP
• Creating CNAME chains (A → B → C → D) that slow resolution and are hard to debug
• Forgetting to update CNAMEs when changing CDN, WAF, or SaaS providers

CNAME records act as aliases: “this hostname actually uses the records of that other hostname”. They are very convenient for CDNs, marketing tools, and third‑party landing pages. The danger is that they are sometimes used in places where an A record is required, or left pointing at providers you no longer use.

How to double‑check CNAME records

• Never place a CNAME on the root (example.com) unless your DNS provider explicitly supports ALIAS or ANAME style records. If in doubt, use an A/AAAA instead.
• Do not put CNAMEs on hostnames that are also used for MX or other critical records.
• For each CNAME, open the referenced target in a browser or check it via dig/nslookup to verify that it still resolves and points where you expect.
• If you decommission a service (old CDN, old landing‑page provider), remove its corresponding CNAMEs to avoid dangling DNS that could be abused. Our guide “Preventing Subdomain Takeover and Dangling DNS” walks through this risk in depth.

3. NS Records: Delegating to the Wrong Nameservers

Typical mistakes

• Changing nameservers at the registrar but forgetting to copy existing records to the new DNS provider
• Having inconsistent NS records between the parent (registry/registrar) and the zone itself
• Pointing to nameservers that no longer host your zone (common after provider changes)
• Misconfigured private nameservers (ns1.yourdomain.com) without proper glue records

NS records define who is authoritative for your domain. If these point to the wrong place, your carefully configured A, MX, and TXT records simply never get used. This is a classic failure when moving domains between control panels or registrars.

How to double‑check NS records

• At your domain registrar, ensure your domain uses the correct nameservers (those actually hosting your zone).
• Inside the zone itself, confirm the NS records match what the registrar shows and that all listed nameservers respond consistently.
• If you use private nameservers on your own VPS or dedicated server, follow a detailed process like in our article “The Friendly Guide to Private Nameservers and Glue Records”.
• When changing NS, keep old nameservers serving the zone for a while and avoid making other big changes until DNS propagation is complete. We explain how propagation works in “What Is DNS Propagation and How to Speed It Up”.

4. MX Records: Email Going Nowhere (or to the Wrong Mailbox)

Typical mistakes

• Removing MX records entirely, assuming email is “not used” (until someone remembers a catch‑all address)
• Pointing MX records to IP addresses instead of hostnames
• Keeping MX records pointing at an old mail server after migrating to a new email provider
• Misunderstanding MX priorities and leaving a low‑priority “backup” that actually belongs to a previous provider

MX records control where inbound email for @example.com is delivered. Many DNS panels auto‑create some MX entries, and manual edits on top of that can be confusing. During email migrations (for example from self‑hosted mail to a new platform), leaving old MX records in place is one of the fastest ways to lose messages.

How to double‑check MX records

• Verify exactly which MX records your current email provider requires. Hostnames must match, and priorities (numbers) should follow their recommended values.
• Remove any MX entries that reference old providers or servers you no longer operate.
• Make sure every MX record points to a hostname that itself has a valid A/AAAA record, not directly to an IP.
• After a change, send a test email from an external mailbox (e.g. a personal email) and inspect full headers to confirm the message hit the correct MX server.

If you are planning an email migration, it is worth reading our step‑by‑step email deliverability guide “Inbox or Spam? SPF, DKIM, DMARC and rDNS Explained”, which shows how MX and authentication records work together.

5. SPF (TXT) Records: Too Many Lookups or Conflicting Policies

Typical mistakes

• Creating multiple SPF records for the same domain (only one is allowed)
• Exceeding the 10 DNS lookup limit with too many include: mechanisms
• Forgetting to add new email services (transactional mail, newsletters, CRM) to SPF
• Using -all (hard fail) too early and blocking legitimate servers

SPF (Sender Policy Framework) tells receiving mail servers which IPs and hosts are allowed to send mail as @yourdomain. It lives in a TXT record that usually looks like v=spf1 include:provider.com -all. The moment you add a second SPF TXT line or chain too many includes, you risk breaking authentication.

How to double‑check SPF records

• Ensure there is only one SPF TXT record for the domain (or for a specific subdomain used in the MAIL FROM address).
• List all systems that send email on behalf of your domain: hosting account, VPS, newsletter tools, CRM, support desk, etc., and confirm they are represented inside the SPF mechanisms.
• Use an SPF checker to count DNS lookups; if you are close to the limit, consider flattening includes or simplifying the policy. Our advanced guide on SPF management provides patterns for complex setups.
• When unsure, start with ~all (soft fail) instead of -all, then tighten later once you are confident everything is covered.

6. DKIM (TXT) Records: Missing or Mismatched Keys

Typical mistakes

• Enabling DKIM in the mail server but never publishing the corresponding TXT record in DNS
• Publishing DKIM under the wrong selector (e.g. default._domainkey vs mail._domainkey)
• Rotating DKIM keys on the server and forgetting to update DNS
• Accidentally truncating the public key when copy‑pasting into the DNS panel

DKIM signs outgoing emails with a cryptographic signature; the public key is stored in DNS under a TXT record like selector._domainkey.example.com. If the DNS key does not match the private key on the sending server, signatures fail and your messages can lose trust with major providers.

How to double‑check DKIM records

• Use the DKIM test or “show DNS record” feature in your email platform or hosting panel and copy the exact key it provides.
• Confirm the selector name matches what your mail server uses. Many services use default, but some generate random selectors like s1, k2024, etc.
• Send a test email to a mailbox where you can view full headers and verify that DKIM shows as pass.
• If you rotate keys, keep old DKIM records for a while if your provider sends from multiple data centers or queues emails for later delivery.

7. DMARC (TXT) Records: Over‑Strict Policies Too Soon

Typical mistakes

• Jumping straight to p=reject without first monitoring reports
• Publishing DMARC with typos, wrong tags, or missing v=DMARC1
• Pointing aggregate report emails (rua=) to an address that does not exist
• Forgetting that DMARC evaluates alignment with the domain in the From: header, not just SPF/DKIM pass/fail

DMARC is a policy layer on top of SPF and DKIM that tells receivers what to do when authentication fails: nothing, quarantine, or reject. Configured well, it is a powerful shield against spoofing. Configured too aggressively, it can block your own legitimate traffic—especially when you have multiple sending systems.

How to double‑check DMARC records

• Start with a monitoring policy such as v=DMARC1; p=none; rua=mailto:[email protected] and review reports before enforcing stricter actions.
• Ensure the DMARC TXT is published under _dmarc.example.com, not just example.com.
• Create and monitor the mailbox you use in rua= (or use a dedicated DMARC report tool) to actually read aggregate reports.
• After confirming all your sending sources pass and align correctly, gradually move to p=quarantine and later p=reject if needed.

For a deeper discussion on using DMARC reports effectively, see our article “DMARC in Context: Why the Reports Matter More Than the Record”.

8. CAA Records: Accidentally Blocking Your Own SSL certificates

Typical mistakes

• Adding CAA records for one certificate authority (CA) and forgetting to allow others you actively use
• Migrating from one SSL provider to another but keeping old, restrictive CAA entries
• Misunderstanding issue vs issuewild (single‑domain vs wildcard certificate permissions)
• Assuming no CAA means “deny all”, when in fact no CAA means allow any CA

CAA records tell the world which CAs are allowed to issue SSL/TLS certificates for your domain. They are excellent for security in larger organizations or multi‑team environments, but can block certificate issuance or renewal if not kept in sync with your real usage.

How to double‑check CAA records

• List all CAs you use: free certificates (e.g. ACME‑based) and any commercial SSL providers. Ensure your CAA records allow each of them.
• Remember to include both issue and issuewild if you use wildcard certificates.
• When you change hosting or automate SSL on a new VPS or dedicated server, verify that your existing CAA records do not block the new ACME client.
• If you are not ready to manage CAA strictly, it is safer to have none than to have incorrect ones. Once your SSL automation is stable, you can harden with a clear CAA policy.

We went deep on real‑world CAA strategies in “The CAA Records Deep Dive”, including multi‑CA setups and monitoring.

9. PTR (Reverse DNS): The Hidden Record That Breaks Outbound Email

Typical mistakes

• Sending email directly from a VPS or dedicated server IP without any PTR record
• Having a reverse DNS hostname that does not match the HELO/EHLO identity or SPF policy
• Leaving the default PTR set by the data center (e.g. a generic hostname) instead of a domain you control

PTR (reverse DNS) maps an IP address back to a hostname. Many receiving mail servers use this as one of several spam and reputation checks. A missing or generic PTR does not always cause outright rejection, but it weighs against you—especially combined with other issues like missing SPF or DKIM.

How to double‑check PTR records

• For any server that sends mail directly (Postfix, Exim, etc.), configure a PTR that resolves to a hostname under a domain you own, such as mail1.example.com.
• Ensure that hostname has matching A/AAAA records and is included appropriately in your SPF policy.
• Align the HELO/EHLO name your MTA announces with the PTR hostname where possible.
• Ask your hosting or network provider to set the PTR if you do not have direct control over reverse DNS.

We explain reverse DNS and its impact on deliverability step‑by‑step in “What Is a PTR (Reverse DNS) Record?”.

10. Service & Verification TXT/SRV Records: Little Entries, Big Surprises

Typical mistakes

• Deleting mysterious TXT records that actually belong to important services (e.g. Google/Microsoft verification, SaaS tools, DMARC reporting services)
• Overwriting SRV records used by VoIP, chat, or email autodiscover (e.g. _sip._tcp, _autodiscover._tcp)
• Leaving old SRV/TXT records pointing to decommissioned providers, increasing attack surface and confusion
• Not documenting why a given TXT or SRV record exists, leading to accidental removal during “cleanup”

Not all DNS records are obvious. TXT is a free‑form field now used for SPF, DKIM, DMARC, verifications, and vendor‑specific settings. SRV records often support SIP, XMPP, and autodiscover/autoconfig. These are the first to be deleted when someone decides to “tidy up” DNS—and that is exactly when certain logins or APIs stop working.

How to double‑check service and verification records

• Before deleting any TXT or SRV record, search your email and documentation for the hostname or value—it might be part of a domain verification or SaaS integration.
• Keep a simple internal document listing each non‑obvious record, which service added it, and whether it is still in use.
• When you remove or migrate a service (for example, changing a VoIP provider), update or remove related SRV/TXT records in the same change window.
• Be especially careful with records under prefixes like _sip, _xmpp, _autodiscover, _mta-sts, or vendor‑specific hostnames.

A Practical Pre‑Change DNS Checklist

When you are about to move a website, switch email providers, or change hosting, use this simple checklist before pressing “Save”:

1. Snapshot current DNS: Export the zone file or screenshot all records so you can roll back quickly.
2. Lower TTLs in advance: 24–48 hours before cutover, reduce TTLs on key records (A/AAAA, MX, TXT) as described in our DNS TTL strategy guide.
3. Review the 10 records: Go through A/AAAA, CNAME, NS, MX, SPF, DKIM, DMARC, CAA, PTR, and special TXT/SRV entries and confirm each one has a clear, current purpose.
4. Plan propagation time: Understand that some users will hit the old IP or MX for a while. Our article on DNS propagation explains realistic timelines.
5. Test from multiple networks: After making changes, check from mobile data, home, and office networks, and use tools like dig or online DNS checkers.
6. Monitor logs and email deliverability: Watch web server logs and email bounces closely for 24–48 hours.

If you routinely onboard new clients or manage many domains, you may also find our “Hosting and DNS Audit Checklist for Agencies” helpful as a broader framework around these technical checks.

Bringing It All Together (and How We Think About DNS at dchost.com)

Most DNS disasters do not come from exotic corner‑cases. They come from very ordinary situations: moving to a new hosting plan, adding a marketing tool, enabling automatic SSL, or migrating email. In each of those, a handful of records—A/AAAA, CNAME, NS, MX, SPF, DKIM, DMARC, CAA, PTR and a few TXT/SRV entries—decide whether your website and email keep working or quietly fall over.

At dchost.com, we design our shared hosting, VPS, dedicated server and colocation services with this in mind. When we help customers move sites or email, we always start from a DNS review based on exactly the 10 record types we have just covered, combined with smart TTL planning and propagation monitoring. The result is far fewer surprises and much cleaner cutovers.

If you are planning a migration, consolidating domains, or just want a second pair of eyes on your DNS layout, use this article as a checklist and combine it with our in‑depth pieces on DNS record types, TTL strategy and email authentication. And if your site or email is already having issues after a DNS change, do not panic: work through the 10 records one by one. In most cases, the fix is just a few precise edits away.