Common DNS mistakes

Quick answer: The classics: editing DNS at the wrong provider, CNAME at the zone apex, MX pointing to a CNAME or IP, two SPF records, forgetting www, migrating with a high TTL, and expecting changes to be instant. Each has a simple prevention.

Overview

DNS fails quietly: a wrong record does not throw an error, it just sends traffic (or mail) to the wrong place — sometimes only for some users, which makes it maddening to debug. Knowing the standard traps up front saves hours.

Before you start

• Confirm which provider is authoritative before touching anything: dig +short NS example.com.

Step-by-step guide

The mistakes, and what to do instead:

1. Editing a non-authoritative zone. Records changed at the registrar do nothing if NS points elsewhere — always check NS first.
2. CNAME on @. Forbidden alongside other apex records; use an A record or your provider's ALIAS/ANAME (details).
3. MX → CNAME or MX → IP. Both invalid; point MX at an A-resolvable hostname (details).
4. Two SPF records. Merge into one v=spf1 string or SPF fails outright (details).
5. Forgetting www (or the bare domain) when pointing a site — half your visitors get an error (both records).
6. Migrating with TTL 86400. Lower TTL a day ahead, or the old server serves traffic for another day (cutover guide).
7. Pasting the full hostname into the “host” field, creating www.example.com.example.com.
8. Deleting records you do not recognize. Verification TXTs and DKIM selectors look like junk but are load-bearing — audit before cleanup.

Common issues

• “It works for me but not for clients”: split caches during TTL expiry — compare answers from several resolvers.
• Fixed the record, still broken: negative/positive caches; verify against the authoritative NS to confirm the fix landed.

When to contact support

Unsure whether a record change is safe, or seeing weird resolution toward your Cloud2Y server after an edit? Open a ticket with the domain and what you changed — a second pair of eyes is cheap insurance.

Frequently asked questions

What is the most common DNS mistake?

Editing records at a provider that is not authoritative for the domain. Always check the NS records first — changes made anywhere else are silently ignored by the internet.

Is deleting unknown DNS records safe?

Risky: verification TXT strings and DKIM selector records look like leftovers but actively protect mail and integrations. Identify each record's purpose before removing it.

Why should TTL be lowered before changes and raised after?

A low TTL makes mistakes and migrations recover in minutes; a higher TTL afterwards reduces resolver load and speeds up lookups once the zone is stable again.

Related articles

• How DNS works
• How to reduce DNS propagation issues
• How to troubleshoot a domain that does not open
• DNS FAQ

Need a hand? Contact Cloud2Y support →