A website can be fully built, hosted on a fast server, and ready for customers – yet still appear offline because one DNS setting points to the wrong place. DNS record management is the work of maintaining those settings so browsers, email servers, verification services, and other systems can reliably find your business online.
For a small business, a bad DNS change can mean lost inquiries or undelivered email. For an agency or developer, it can disrupt multiple client sites. The good news is that DNS is manageable once you understand what each record does, who controls it, and how to make changes without creating avoidable downtime.
What DNS Record Management Controls
The Domain Name System, or DNS, acts like the internet’s address directory. When someone enters your domain in a browser, DNS tells that browser which server should receive the request. It also tells other services where to deliver email, how to verify domain ownership, and whether a subdomain such as `shop`, `app`, or `support` should lead somewhere different.
DNS record management includes creating, editing, reviewing, and removing those instructions. Records are generally managed at the DNS provider that hosts your domain’s nameservers. That may be your domain registrar, your hosting provider, a cloud platform, or a specialized DNS service. The company where you purchased the domain is not always the company currently controlling DNS, which is a common source of confusion.
Before changing anything, confirm where your nameservers are pointed. That is the system where your active DNS zone lives. Editing records in an inactive zone will not affect the live website or email service.
The DNS Records Most Businesses Need
You do not need to memorize every DNS record type. Most websites and business email setups rely on a small group of records, each with a distinct job.
A records and AAAA records
An A record connects a domain or subdomain to an IPv4 address, such as the public IP address of a hosting server. It is often the primary record used for a website. For example, the record for `example.com` may point to the server hosting the site.
An AAAA record does the same job for an IPv6 address. Not every hosting setup requires one. If your provider has not supplied an IPv6 address, do not add an AAAA record just because it is available. A conflicting or outdated AAAA record can send some visitors to the wrong destination.
CNAME records
A CNAME record makes one hostname an alias of another hostname. It is commonly used for `www`, so `www.example.com` follows the destination configured for the main domain. It is also widely used for third-party services, including stores, appointment platforms, verification tools, and content delivery networks.
A CNAME cannot normally coexist with other record types at the same hostname. That limitation matters when connecting outside services. If a provider asks for a CNAME at `www`, check whether one already exists before replacing it.
MX records
MX records direct incoming email for your domain. If your business uses Microsoft 365, Google Workspace, a hosted email platform, or mailboxes supplied with hosting, the correct MX records are essential.
Email problems often happen after a website migration because someone replaces the entire DNS zone with records from the new web host. Your website may begin working while business email stops arriving. Website records and mail records are separate, so a hosting move does not automatically require changing MX records.
TXT records
TXT records store text-based information used by many services. They are especially common for domain verification and email authentication. SPF, DKIM, and DMARC are usually published as TXT records and help receiving mail systems evaluate whether messages sent from your domain are legitimate.
Treat email authentication records carefully. An SPF record, for instance, should generally be consolidated into one record per hostname. Adding a second SPF record instead of updating the existing one can weaken validation and lead to delivery issues.
NS, SRV, and CAA records
NS records identify the authoritative nameservers for a domain. They are foundational records and should not be changed casually. Changing nameservers transfers DNS control to another provider, which may require recreating every active DNS record first.
SRV records are used by certain communication and application services that need a hostname and port. CAA records state which certificate authorities may issue SSL certificates for your domain. Many small sites will not need to edit either record often, but both can affect service setup when they are in use.
A Safe Process for DNS Record Management
The safest DNS work starts before you open the editor. Make a complete record of the current zone, including hostnames, record types, values, priorities, and TTL settings. A screenshot can help, but a copyable text record is better when you may need to restore a setting quickly.
Next, identify the exact outcome you need. If you are pointing a site to a new hosting account, ask for the required A record value or nameserver details. If you are connecting email, use the provider’s complete MX and authentication instructions. Avoid guessing based on an old setup or a record from another domain.
Then make the narrowest possible change. A website migration might require updating one A record and the `www` CNAME, not deleting all existing records. Preserving unrelated records reduces the chance of interrupting email, verification tools, subdomains, or application connections.
After saving the change, test the service that was affected. Load the site with and without `www`, send a test email to the domain, and confirm that expected subdomains still resolve. Testing from a mobile connection can also help because it uses a different network path and may reveal whether cached results are masking the update.
TTL and DNS Propagation: What to Expect
TTL, or time to live, tells resolvers how long they may cache a DNS answer. A record with a TTL of 3600 may be cached for up to an hour before a resolver checks for a new value. DNS propagation is not a single event where every device updates at once. It depends on TTLs, resolver behavior, and local caching.
For a planned migration, lower the TTL on the record you expect to change several hours or a day in advance, if practical. A lower value such as 300 seconds can reduce the time that old answers remain cached after the change. Once the migration is stable, raise the TTL to a more typical value to reduce unnecessary DNS queries.
Lower TTLs are useful during a transition, but they are not a guarantee of instant updates. Some networks and devices may retain old information longer than expected. Keep the old hosting environment available until you have verified that traffic is reaching the new destination consistently.
Common DNS Mistakes That Cause Outages
The most damaging DNS errors are often simple. Replacing nameservers without copying the active zone can take down a website and email at the same time. Deleting MX records during a web-hosting change can stop incoming mail. A typo in an IP address can point visitors to a server that has nothing to do with your business.
Another frequent issue is mixing up the root domain and a subdomain. In most DNS editors, the root may appear as `@`, blank, or the full domain name. `www` is a separate hostname. Updating one does not always update the other.
Duplicate records can also create inconsistent behavior. If two A records for the same hostname point to different servers, traffic may alternate between them. That can be intentional for load balancing, but it is a problem when one value is an old server. Review existing entries before adding a new one.
Protect DNS Access Like a Critical System
DNS has direct control over where customers go and how your organization receives email. Limit access to people who need it, use strong unique passwords, and enable multi-factor authentication wherever it is offered. For agencies, define who owns DNS access when a client relationship changes so domain control does not become an emergency later.
Keep a simple change log with the date, person responsible, records modified, reason for the change, and previous values. This is useful even for a single-site business. When an email provider, developer, or security service asks what changed, a clear history shortens troubleshooting.
If you manage several domains, standardize record naming and review inactive services regularly. Old verification records are usually harmless, but forgotten subdomains and outdated destinations can create confusion or security exposure. Remove records only after confirming that no active system depends on them.
When Hosting Support Should Be Part of the Plan
Some DNS changes are straightforward. Others involve a website migration, business email, SSL issuance, a cloud application, or multiple subdomains with different destinations. In those cases, support can prevent a small configuration issue from becoming a customer-facing outage.
A full-service provider such as Charter Hosting can be especially useful when your domain, hosting, email, security services, and migration support need to work together. The goal is not to make DNS more complicated than it is. It is to make sure every record supports the services your business depends on.
Before making your next DNS change, document the current records, confirm the active nameservers, and change only what the new service requires. That disciplined approach keeps your website reachable, your email flowing, and your next growth step from turning into an avoidable support emergency.
