10 DNS Mistakes That Break Your Website (And How to Fix Them)

DNS is the address system of the internet. Every time someone types your domain name into a browser, DNS translates it into the IP address of your hosting server. Get it wrong, and your site goes offline, emails stop working, or visitors land on the wrong page entirely.

These are the 10 most common DNS mistakes that take websites down, along with the exact steps to fix each one.

1. Pointing Your Domain to the Wrong IP Address

This is the most basic DNS mistake, and it happens constantly. You set up an A record with the wrong IP address, or you forget to update it after migrating to a new host. Your domain resolves, but to a server that does not have your site.

Symptoms: Browser shows a default server page, a different website entirely, or a connection refused error.

How to fix it:

1. Log into your domain registrar or DNS management panel (often at Namecheap, Cloudflare, or your hosting provider)
2. Find the A record for your domain (both @ and www)
3. Verify the IP matches what your hosting provider shows in your account dashboard
4. Save the changes and wait for propagation (typically 5-30 minutes, up to 48 hours)

Pro tip: Use dig yourdomain.com +short in your terminal or an online DNS lookup tool to see what IP your domain currently resolves to.

2. Forgetting the www CNAME Record

You set up the A record for yourdomain.com but forget to create a CNAME record for www.yourdomain.com. Half your visitors type "www" before the domain, and they get a DNS resolution error.

Symptoms: yourdomain.com works fine, but www.yourdomain.com shows "site not found" or a DNS error.

How to fix it:

1. Create a CNAME record with the name www pointing to yourdomain.com
2. Alternatively, create a second A record for www pointing to the same IP as the root domain
3. Most hosting providers like Hostinger and SiteGround handle this automatically when you add a domain through their panel

3. Setting TTL Too High Before a Migration

TTL (Time to Live) tells DNS resolvers how long to cache your records before checking for updates. A typical TTL is 3600 seconds (1 hour). If your TTL is set to 86400 seconds (24 hours) and you change your DNS records, some visitors will still see the old IP address for an entire day.

Symptoms: After a migration, some visitors reach the new server while others still hit the old one. The issue resolves itself after hours or days.

How to fix it:

1. Before migrating: Lower your TTL to 300 seconds (5 minutes) at least 24-48 hours before the planned DNS change
2. Perform the migration and update DNS records
3. After everything is confirmed working, raise the TTL back to 3600 or higher

Many hosting providers like Cloudways and Kinsta include migration guides that specifically mention this TTL step. It is easy to overlook, but it makes the difference between a zero-downtime migration and hours of partial outage.

4. Mixing Up A Records and CNAME Records

An A record points to an IP address (like 192.168.1.1). A CNAME record points to another domain name (like host.provider.com). Using one where you need the other causes resolution failures.

Common mistake: Creating a CNAME record for the root domain (@). The DNS specification does not allow CNAME records at the zone apex. Some DNS providers support it through workarounds (Cloudflare calls it "CNAME flattening"), but many do not.

How to fix it:

• Root domain (@): Always use an A record with an IP address
• Subdomains (www, blog, shop): Use CNAME records pointing to the hosting provider's domain
• If your host gives you only a hostname (not an IP), use Cloudflare's free DNS which supports CNAME flattening at the root

5. Deleting MX Records When Changing Hosting

This is a classic. You switch hosting providers, update your A records, and accidentally delete or overwrite your MX records. Your website works perfectly on the new server, but all your email stops arriving.

Symptoms: Emails to your domain bounce with "host not found" or "no MX record" errors. Senders get delivery failure notifications.

How to fix it:

1. Before making any DNS changes: Screenshot or export your current DNS records, especially MX records
2. If you use third-party email (Google Workspace, Microsoft 365, Zoho Mail), your MX records should point to their servers, not your web host
3. If your web host provides email, make sure the MX records point to the correct mail server after migration
4. Verify with dig yourdomain.com MX +short after any DNS changes

Providers like Namecheap and IONOS offer bundled email hosting. If you are using their email service and switch web hosting elsewhere, keep the MX records pointing to their mail servers.

6. Not Setting Up SPF, DKIM, and DMARC Records

These three DNS TXT records control email authentication. Without them, emails sent from your domain are more likely to land in spam folders or be rejected entirely. In 2024, Gmail and Yahoo started requiring DMARC records for bulk senders, and this standard has become the norm in 2026.

Symptoms: Emails you send end up in recipients' spam folders. Email deliverability drops. You get reports of spoofed emails appearing to come from your domain.

How to fix it:

• SPF record: A TXT record specifying which servers are authorized to send email on behalf of your domain. Example: v=spf1 include:_spf.google.com ~all
• DKIM record: A TXT record containing a public key that receiving servers use to verify email signatures. Your email provider generates this.
• DMARC record: A TXT record telling receiving servers what to do with emails that fail SPF/DKIM checks. Start with: v=DMARC1; p=none; rua=mailto:[email protected]

Most hosting providers include tools to set these up. SiteGround and Hostinger both offer one-click email authentication setup in their control panels.

7. Using Your Registrar's Default DNS Instead of Your Host's

Many people register a domain at one company and host at another. If you leave the nameservers pointing to the registrar's default DNS instead of updating them to your hosting provider's nameservers, DNS records you create in your hosting panel will have no effect.

Symptoms: You add records in your hosting control panel, but they do not take effect. The domain resolves to a "parked" page from your registrar.

How to fix it:

1. Decide where to manage DNS: at your registrar, at your host, or at a third-party DNS provider like Cloudflare
2. If using your host's DNS: Update nameservers at your registrar to the ones provided by your hosting company
3. If keeping DNS at your registrar: Create A records and other records manually pointing to your hosting server's IP

Which approach is better? Using Cloudflare as your DNS provider gives you free CDN, DDoS protection, and fast DNS resolution regardless of where you host. It is the approach most professionals use.

8. Creating Conflicting DNS Records

Having two A records for the same hostname pointing to different IPs, or having both a CNAME and an A record for the same name, causes unpredictable behavior. DNS resolvers may return either record, meaning your site works sometimes and fails other times.

Symptoms: Site loads intermittently. Some visitors see the correct site while others get errors. Behavior changes randomly.

How to fix it:

• Audit all your DNS records. Remove duplicate or conflicting entries
• A hostname should have either A records OR a CNAME, never both
• Multiple A records for the same hostname are valid only for round-robin load balancing (rare for small sites)
• Use a DNS audit tool or check records with dig yourdomain.com ANY

9. Not Configuring DNS for a CDN Correctly

CDNs like Cloudflare, Bunny, and KeyCDN require specific DNS configuration. The most common mistake is proxying records through Cloudflare that should not be proxied (like MX records or records used for domain verification).

Symptoms: SSL errors, email delivery failures, or domain verification failing for third-party services (Google Search Console, email providers).

How to fix it:

• In Cloudflare: Only proxy (orange cloud) A and CNAME records for web traffic
• MX records should never be proxied (they are not proxyable anyway, but related A records used for mail servers should be DNS-only)
• Domain verification TXT records do not need proxying
• If you are on a managed host like Kinsta or WP Engine that includes its own CDN, check if using an external CDN causes conflicts

10. Letting Your Domain Expire Without Noticing

This is not strictly a DNS configuration mistake, but it kills your DNS instantly. When your domain expires, DNS stops resolving, and your site goes completely offline. Some registrars give a grace period (typically 30-45 days), but during that period your site is already down.

Symptoms: Complete site outage. DNS returns NXDOMAIN (non-existent domain). If the domain enters redemption, recovering it costs $100-200+.

How to fix it:

• Enable auto-renewal on every domain you own
• Keep payment information current at your registrar
• Set calendar reminders 30 days before expiration as a backup
• Register domains for 2-3 years at a time to reduce renewal risk
• Use a registrar like Namecheap that sends multiple renewal reminders by email

DNS Troubleshooting Toolkit

Bookmark these tools for diagnosing DNS problems quickly:

Tool	What It Does	Free?
dig (command line)	Query DNS records directly from authoritative servers	Yes (built into macOS/Linux)
nslookup (command line)	Basic DNS lookup, available on all operating systems	Yes (built into Windows/macOS/Linux)
whatsmydns.net	Check DNS propagation from multiple global locations	Yes
MXToolbox	Comprehensive DNS, MX, SPF, DKIM, and DMARC checker	Free tier available
Cloudflare DNS Checker	Check records against Cloudflare's resolvers	Yes
intodns.com	Full DNS health report for any domain	Yes

Prevention: A DNS Change Checklist

Before making any DNS changes, run through this checklist to avoid the mistakes above:

1. Export current DNS records. Screenshot or download a copy of all existing records before touching anything
2. Lower TTL to 300 seconds at least 24 hours before planned changes
3. Identify which records to change and which to keep. A records for web, MX records for email, TXT records for verification
4. Make changes during low-traffic hours. Early morning or late night in your primary audience's time zone
5. Verify immediately after changes. Use dig or whatsmydns.net to confirm records are correct
6. Test email delivery. Send a test email to and from your domain after any DNS change
7. Monitor for 24-48 hours. DNS propagation can take time. Check periodically until fully propagated

DNS mistakes are fixable, but they cause real downtime while you figure out what went wrong. Taking five minutes to follow this checklist before every DNS change will save you hours of troubleshooting afterward.

If DNS management feels overwhelming, consider a managed hosting provider like Kinsta (from $29.17/mo) or Cloudways (from $14/mo) that handles DNS configuration as part of the setup process. For budget-friendly options with good DNS tools, Hostinger (from $1.99/mo) and SiteGround (from $2.99/mo) both include intuitive DNS management panels.