Common DNS mistakes and how to fix them

Most DNS problems come down to a handful of repeat offenders: a record pointed at the wrong place, a typo in a value, an ignored TTL, or a change made in the wrong zone. This guide walks through the mistakes we see most often and gives you the exact fix for each, so your site, email, and subdomains resolve the way you expect.

1. Editing DNS at the wrong provider

Your authoritative DNS is controlled by whichever nameservers your domain currently points to, not necessarily where you bought the domain. If you edit records in cPanel but your domain still uses the registrar's nameservers (or Cloudflare's), your changes never take effect. Before you touch anything, confirm where DNS actually lives.

1. Check the domain's nameservers (NS records) at your registrar.
2. If they point to your hosting nameservers, edit records in cPanel under Domains > Zone Editor.
3. If they point elsewhere, make the change there instead, or repoint the nameservers first.

2. Confusing A, CNAME, and the naked domain

An A record maps a name to an IPv4 address. A CNAME maps a name to another name. A common mistake is putting a CNAME on the root (naked) domain, which the DNS specification does not allow because the root also carries SOA and NS records. Use an A record for the apex and reserve CNAME for subdomains.

example.com.       A       203.0.113.10
www.example.com.   CNAME   example.com.
blog.example.com.  CNAME   example.com.

3. Forgetting about TTL and propagation

The TTL (time to live) tells resolvers how long to cache a record. If your TTL is 86400 (24 hours), an old value can linger for a full day after you change it. Before a planned migration, lower the TTL to 300 (5 minutes) a day ahead, make the change, then raise it back once things are stable. Note that changing nameservers is governed by registry TTLs and can take longer regardless.

4. Broken or missing email records

Email is where DNS mistakes hurt most. Three records work together, and a typo in any one causes silent delivery failures.

• MX: points to your mail server, with a priority number (lower is preferred).
• SPF: a TXT record listing who may send for your domain, per RFC 7208. Publish exactly one SPF record; two SPF records is a common and fatal error.
• DKIM and DMARC: signing and policy records that improve deliverability and stop spoofing.

example.com.            MX   10 mail.example.com.
example.com.            TXT  "v=spf1 +mx +a ~all"
_dmarc.example.com.     TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

For more on getting mail settings right, see our email and deliverability guides.

5. Trailing dots and copy-paste errors

In a raw zone file, fully qualified names end with a dot (mail.example.com.). Leaving it off can cause the zone to append the domain again, producing mail.example.com.example.com. Most cPanel forms handle this for you, but if you edit zone files directly, watch the trailing dot. Also avoid pasting values with hidden spaces or smart quotes.

6. Overlooking dedicated IP and PTR records

On shared IPs you cannot control reverse DNS. A PTR record (the reverse of an A record) should map your sending IP back to your hostname, and mismatches hurt email deliverability. A dedicated IP lets you set consistent forward and reverse DNS and keeps your footprint isolated. This is footprint control and cleanliness, not a positive ranking signal on its own. Learn more about DNS and IP management or Class C IP hosting.

How to verify a change

1. Query the record directly, for example dig example.com A +short or dig example.com MX.
2. Compare the answer against the value you set in the Zone Editor.
3. If it is wrong, confirm you edited the correct provider (mistake 1) and wait for the old TTL to expire.

Work through these one at a time and most DNS issues resolve quickly. If a record still will not behave after propagation, contact our support team and we will inspect the zone with you.