1. Keep a DNS inventory
Document every important DNS record, what it does, who owns it, and which service depends on it.
DNS Best Practices
DNS controls how your domain points to websites, email, apps, certificates, subdomains, and services. Good DNS habits help keep your site online, your email working, your domain safer, and your changes easier to troubleshoot.
Quick answer
Good DNS management is about clean records, safe changes, strong account security, and clear documentation.
DNS can look simple, but one wrong record can break a website, stop email, damage search traffic, or send visitors to the wrong place. The safest approach is to keep records organized, protect the accounts that can edit DNS, test changes before and after, and document what each record does.
DNS best practices checklist
2. Use MFA on DNS accounts
Protect registrar, DNS hosting, cloud, and email accounts with strong passwords and multifactor authentication.
3. Clean up old records
Remove unused subdomains, forgotten TXT records, stale verification records, and old vendor records.
4. Plan TTL before changes
Lower TTL before major changes, make the change carefully, test it, then raise TTL again after the change is stable.
5. Back up your DNS zone
Export or copy your DNS records before major edits so you can recover if a change breaks something.
6. Monitor important records
Watch key A, AAAA, CNAME, MX, NS, TXT, CAA, SPF, DKIM, and DMARC records for unexpected changes.
Why DNS best practices matter
DNS is one of the most important parts of a website or online business. It tells browsers where your website lives, tells email systems where to deliver mail, and helps prove that your domain is allowed to use certain services.
If DNS is wrong, users may think your site is down even when your server is working. Email may bounce. SSL certificates may fail. Apps may stop connecting. Search engines may see errors. Customers may lose trust.
Reliability
Correct DNS records help websites, email, apps, and subdomains keep working.
Security
Protected DNS accounts reduce the risk of hijacking, unauthorized redirects, fake services, and domain abuse.
Troubleshooting
Clean DNS makes problems easier to find when a site, email service, or app stops working.
Know the important DNS records
You do not need to memorize every DNS record type, but you should know the records that commonly affect websites, email, certificates, and domain security.
| Record | What it does | Common use |
|---|---|---|
| A | Points a name to an IPv4 address | Sending example.com or www.example.com to a web server |
| AAAA | Points a name to an IPv6 address | IPv6 website or service routing |
| CNAME | Points one name to another name | Connecting subdomains to apps, CDNs, or hosted services |
| MX | Tells the internet where email should be delivered | Google Workspace, Microsoft 365, mail servers, email providers |
| TXT | Stores text-based verification and policy data | SPF, DKIM, DMARC, site verification, vendor verification |
| NS | Identifies the nameservers for the domain | Delegating DNS control to a DNS provider |
| CAA | Limits which certificate authorities can issue certificates | Reducing certificate issuance risk |
| SOA | Stores authority and zone information | DNS zone control and refresh behavior |
Protect your registrar and DNS provider accounts
The most important DNS security control is protecting the accounts that can change DNS. If an attacker gets access to your registrar or DNS provider, they may be able to redirect your website, break email, or take control of domain-related services.
- Use multifactor authentication: turn on MFA for every account that can edit domains or DNS records.
- Use a password manager: create long, unique passwords that are not reused anywhere else.
- Limit who has access: only trusted people should be able to change DNS.
- Remove old users: delete or disable access for former employees, old contractors, and unused vendor accounts.
- Use role-based access: give people the lowest permission level they need.
- Secure the account email: the email address used for domain control should also have strong MFA.
Use registrar lock or registry lock when available
A registrar lock helps prevent unauthorized domain transfers. A registry lock can add stronger protection by requiring extra verification before critical domain changes are allowed.
For important domains, especially business domains, login portals, ecommerce sites, SaaS apps, media brands, or email-heavy domains, locking the domain can reduce the risk of unwanted transfers or dangerous changes.
Use DNSSEC carefully
DNSSEC helps protect DNS answers from certain types of tampering by adding cryptographic validation to DNS records.
DNSSEC can improve trust, but it must be configured carefully. Broken DNSSEC settings can make a domain fail to resolve, which can make a working website appear offline.
Use it when supported
If your registrar and DNS provider support DNSSEC well, it can be a useful security layer.
Document the setup
Keep track of DS records, key rollovers, provider changes, and who is responsible for DNSSEC management.
Test after changes
Always test DNSSEC after changing DNS providers, nameservers, DS records, or domain delegation.
Set sensible TTL values
TTL stands for time to live. It tells DNS resolvers how long they can cache an answer before checking again.
A lower TTL can help changes spread faster, but it can also increase DNS query load. A higher TTL can reduce repeated lookups, but it can make mistakes or planned migrations take longer to fully clear.
| Situation | TTL habit | Why it helps |
|---|---|---|
| Stable records | Use a normal, steady TTL | Good for records that rarely change. |
| Before migration | Lower TTL ahead of time | Helps visitors move to the new destination faster after the change. |
| During testing | Use shorter TTLs | Makes test changes easier to reverse if something is wrong. |
| After stable launch | Raise TTL again | Reduces unnecessary DNS lookups once the record is proven stable. |
Simple rule: lower TTL before planned changes, not after something has already gone wrong.
Clean up stale DNS records
Old DNS records can create security and troubleshooting problems. A forgotten subdomain can point to a service that no longer exists. An old TXT record can make email policies confusing. An abandoned CNAME can create takeover risk if the old service is no longer claimed.
- Remove records for old hosting providers.
- Remove vendor verification records that are no longer needed.
- Remove abandoned subdomains.
- Remove old app, staging, preview, or test records if they are no longer used.
- Review CNAME records that point to third-party services.
- Make sure every DNS record has a clear owner and purpose.
Use CAA records for certificate control
CAA records tell certificate authorities which providers are allowed to issue SSL/TLS certificates for your domain.
CAA records do not replace normal certificate validation, but they can reduce certificate issuance risk by limiting which certificate authorities should be trusted for your domain.
Allow your certificate provider
Set CAA records for the CA you actually use, such as your hosting provider, CDN, or certificate service.
Plan for wildcard certificates
If you use wildcard certificates, make sure your CAA setup allows the correct provider for wildcard issuance.
Review after provider changes
If you change hosting, CDN, or certificate provider, update CAA records so certificates still renew correctly.
Do not block yourself
A bad CAA setup can prevent your own certificate provider from issuing or renewing certificates.
Protect email with SPF, DKIM, and DMARC
Email depends heavily on DNS. SPF, DKIM, and DMARC are DNS-based email authentication tools that help protect your domain from spoofing and improve trust with receiving mail systems.
SPF
Lists which mail servers or services are allowed to send email for your domain.
DKIM
Adds a cryptographic signature so receiving systems can verify that email was not changed in transit.
DMARC
Tells receiving systems what to do when SPF or DKIM checks fail and can send reports back to you.
For business domains, do not skip these records. Even if you do not send marketing emails, attackers can still try to spoof your domain.
Avoid common record mistakes
Do not create multiple SPF records
A domain should normally have one SPF TXT record. Multiple separate SPF records can cause SPF errors. Combine authorized senders into one policy.
Do not point MX records to a CNAME
MX records should point to proper mail server hostnames, not aliases that create extra resolution problems.
Do not use CNAME records at the root unless your provider supports an alias-style feature
Traditional DNS does not allow a normal CNAME at the zone apex when other records must exist there. Many DNS providers offer ALIAS, ANAME, or flattening features to solve this.
Do not leave wildcard records unmanaged
Wildcard DNS can be useful, but it can also hide mistakes or send unexpected subdomains somewhere you did not intend.
Do not delete records you do not understand
Before deleting unknown records, check whether they are used for email, SSL certificates, verification, apps, CDN, or security tools.
Back up DNS before big changes
Before changing nameservers, moving hosting, changing email providers, adding a CDN, or cleaning old records, save a copy of the current DNS zone.
- Export the zone file if your DNS provider supports it.
- Take screenshots of important records if export is not available.
- Copy records into a plain text document or spreadsheet.
- Note the date, reason for change, and person making the change.
- Keep previous values until the new setup is tested and stable.
Document every DNS change
DNS problems are much easier to fix when you know what changed and why.
Record the purpose
Write down whether a record is for website hosting, email, CDN, verification, security, app routing, or another service.
Record the owner
Know who requested the record, which vendor uses it, and who can confirm whether it is still needed.
Record the date
Dates help you find records that were added for old projects, temporary tests, or abandoned services.
Record rollback steps
For major changes, write down how to undo the change if the site, email, or app breaks.
Monitor DNS health
DNS monitoring helps catch problems before customers or visitors complain. At minimum, monitor the records that control your main website and email.
- Monitor your root domain and www records.
- Monitor MX records for email delivery.
- Monitor nameserver changes.
- Monitor SSL certificate status and renewal.
- Monitor DNSSEC validation if enabled.
- Monitor important CNAME records to hosted apps, CDNs, and third-party platforms.
Use separate records for production, staging, and testing
Do not mix live production records with temporary testing records unless you have a clear reason.
Use naming that makes the purpose obvious, such as staging, dev, test, preview, beta, or internal. Remove those records when the test ends. This keeps your DNS zone cleaner and reduces accidental exposure.
Plan DNS changes like a real deployment
Treat important DNS changes like code deployments. A DNS change can affect real users, email, payments, logins, SSL certificates, and search visibility.
| Step | What to do | Why it matters |
|---|---|---|
| Before | Back up DNS, lower TTL, confirm target values, prepare rollback | Reduces risk before the change starts. |
| During | Change one thing at a time when possible | Makes mistakes easier to identify. |
| After | Test website, email, SSL, redirects, apps, and DNS propagation | Confirms the change actually worked. |
| Later | Raise TTL, update documentation, remove temporary records | Keeps the DNS zone clean and stable. |
Small business DNS best practices
Small businesses often rely on DNS more than they realize. A basic DNS mistake can affect the website, Google Workspace or Microsoft 365 email, booking tools, payment tools, CRMs, landing pages, and marketing platforms.
- Use a trusted registrar and DNS provider.
- Turn on MFA for the registrar, hosting, DNS, and email admin accounts.
- Keep DNS login credentials in a password manager.
- Document which records support the website, email, and key apps.
- Do not let random contractors keep permanent DNS access.
- Review DNS after changing hosts, agencies, developers, email providers, or marketing tools.
DNS troubleshooting habits
When something breaks, do not guess. Check DNS carefully and compare what should happen with what is actually happening.
Check the record type
Make sure you are editing the correct A, AAAA, CNAME, MX, TXT, NS, or CAA record.
Check the exact hostname
example.com, www.example.com, mail.example.com, and app.example.com are different names.
Check propagation
Some systems may still have older cached answers until TTL expires.
Check related services
A website issue may involve DNS, hosting, SSL, CDN, redirects, firewall settings, or the app itself.
Common DNS mistakes
Changing nameservers without copying records first
If you switch DNS providers without copying records, your website, email, and subdomains can break.
Forgetting email records during a website move
Website hosting and email hosting are often separate. Do not delete MX, SPF, DKIM, or DMARC records just because you are moving the website.
Using unclear record names
Records like test, temp, old, or random vendor names become confusing later unless they are documented.
Leaving old vendor verification records forever
Verification TXT records can pile up. Keep the ones you need and remove the ones tied to unused services.
Not knowing where DNS is hosted
The registrar and DNS host may be different companies. Always know where the active nameservers point.
DNS audit checklist
Registrar
Confirm domain ownership, registrar lock, renewal status, contact email, and account MFA.
Nameservers
Confirm the domain uses the correct authoritative nameservers.
Website records
Confirm root, www, CDN, redirect, and app records point to the right place.
Email records
Confirm MX, SPF, DKIM, and DMARC are present and match the actual mail provider.
Security records
Review CAA, DNSSEC, verification TXT records, and any vendor-specific security records.
Cleanup
Remove stale records, unused subdomains, old vendors, abandoned CNAMEs, and temporary test records.
Frequently asked questions
What are DNS best practices in simple terms?
DNS best practices are safe habits for managing DNS records so websites, email, certificates, apps, and subdomains keep working reliably.
What is the most important DNS best practice?
Protect the accounts that can change DNS. Use MFA, strong unique passwords, limited access, and registrar lock where available.
Should every domain use DNSSEC?
DNSSEC can be helpful, but it must be managed carefully. If your provider supports it well and you understand the setup, it can add protection against DNS tampering.
What does TTL mean in DNS?
TTL means time to live. It controls how long DNS answers can be cached before systems should check again.
Why should I clean up old DNS records?
Old records can cause security risks, routing mistakes, email problems, certificate issues, and confusion during troubleshooting.
What DNS records are needed for email?
Email usually needs MX records for delivery and TXT records for SPF, DKIM, and DMARC authentication.
What is a CAA record?
A CAA record limits which certificate authorities are allowed to issue SSL/TLS certificates for a domain.
What should I read next?
Learn about DNS, IP addresses, website hosting, SSL certificates, email authentication, CDN, and domain security.