A website can be fully built, hosted on a fast server, and ready for visitors – yet still appear offline because one DNS value points to the wrong place. To configure DNS records correctly, you need to match each record to the service it supports, enter the exact values supplied by that service, and allow for the way DNS caching works.
DNS is the control layer between a domain name and the services behind it. It tells browsers where to find your website, tells mail servers where to deliver email, and helps receiving servers verify that messages are legitimate. A small error can cause a broad business problem: a blank website, missed customer inquiries, failed order notifications, or email sent to spam.
Start With the DNS Authority
Before changing a single record, confirm where your DNS zone is hosted. Your domain registrar, web host, CDN, or a dedicated DNS provider may manage the authoritative zone. The authoritative provider is the one whose nameservers are assigned to your domain. That is the only dashboard where DNS edits will take effect.
This is where many changes go wrong. It is common to update records at a registrar while the domain is using nameservers from a hosting provider, or to edit an old hosting account after a site migration. The record may look correct in one control panel but never reach the public internet.
Check the domain’s assigned nameservers first. Then identify whether your website, email, and any third-party tools use the same DNS zone. If they do, keep a copy of every existing record before making changes. A screenshot is helpful, but a plain-text export with hostnames, record types, values, priorities, and TTLs is better.
Know Which DNS Record Does What
DNS records are not interchangeable. Each record has a specific job, and adding a new value without understanding its role can override a working configuration.
- A records connect a hostname to an IPv4 address. Your root domain, such as example.com, commonly uses an A record for the web server.
- AAAA records do the same for IPv6 addresses. Only add them when your hosting environment supports IPv6 and provides the correct address.
- CNAME records point one hostname to another hostname. They are frequently used for www, verification services, CDNs, and hosted applications.
- MX records tell other mail servers where to deliver incoming email. They use priority numbers, where lower numbers are tried first.
- TXT records store text-based instructions and verification data. SPF, DKIM, DMARC, domain ownership checks, and some security policies use TXT records.
Two rules prevent a large share of DNS mistakes. First, a CNAME cannot normally coexist with other record types on the same hostname. Second, the root domain, also called the apex, has special limitations in standard DNS and usually cannot use a conventional CNAME. Some DNS platforms offer ALIAS or ANAME-style records to handle this use case, but behavior depends on the provider.
Configure DNS Records Correctly for Your Website
Your hosting provider should supply the destination for your site: usually an IP address for an A record or a hostname for a CNAME. Use the value exactly as provided. Do not substitute an IP address found in an old email, another domain’s configuration, or a temporary preview environment.
For a typical website setup, the root domain points to the hosting server and the www hostname either points to the same server or aliases the root domain. For example, example.com may have an A record to the server IP, while www may use a CNAME to example.com. Whether both names work is not just a convenience issue. Visitors may enter either version, and search engines need a consistent destination before redirects can establish the preferred version.
If your site is behind a CDN, website builder, or managed application platform, follow its record instructions rather than assuming a direct server IP is required. A CDN may use a CNAME so it can route traffic, cache content, and apply security protections. Pointing the domain directly at the origin server can bypass those benefits or expose an address that was not meant for public traffic.
Avoid creating duplicate records for the same hostname unless the service specifically instructs you to do so. Multiple A records can be intentional for load balancing, but an accidental old IP and a new IP will send visitors to different places unpredictably.
Protect Email While You Make Changes
Website migrations and email changes are often treated as one DNS task, but they should be planned separately. Moving a website does not require replacing MX records. If business email is working, preserve the existing MX, SPF, DKIM, and DMARC records unless you are intentionally changing email providers.
MX records direct incoming mail, but authentication records affect whether your outgoing mail is trusted. SPF identifies servers allowed to send mail for the domain. DKIM adds a cryptographic signature to outgoing messages. DMARC tells receiving servers how to handle mail that fails alignment checks and can provide reporting.
These records deserve careful review because one domain should generally have only one SPF TXT record. If multiple services send email for the domain – such as Microsoft 365, Google Workspace, a CRM, an ecommerce platform, and a support desk – their authorized sources usually need to be combined into one valid SPF policy. Publishing separate SPF records may cause mail authentication failures.
DKIM records often use a selector in the hostname, such as selector1._domainkey. Copy the selector, record value, and quotation formatting exactly as your email provider supplies them. For DMARC, begin with a monitoring policy if you are still identifying every legitimate sender. A strict rejection policy can stop spoofing, but it can also block real mail when SPF or DKIM has not been fully configured.
Use TTLs to Control Change Timing
TTL, or time to live, tells resolvers how long they can cache a DNS response. A long TTL reduces lookup traffic and is fine for stable records. It is less convenient when you need to move a website, change an IP address, or switch email providers quickly.
For a planned migration, lower the TTL on the affected records 24 to 48 hours before the change. A value such as 300 seconds can make the transition easier to manage. After the migration is confirmed, raise the TTL to a more stable value. There is no universal best TTL: a high-traffic business with a stable setup may prefer longer caching, while an active development environment may need faster changes.
Lowering a TTL immediately before changing a record does not clear caches that already stored the old value. Those resolvers continue using the old TTL until it expires. This is why DNS changes can appear inconsistent for a period of time, even when the new record is correct.
Follow a Safe DNS Change Process
DNS work is safest when changes are deliberate and easy to reverse. Start by documenting the current zone and the intended end state. Confirm the new hosting account is ready, the website responds correctly on its temporary address or preview URL, and SSL is prepared for the live domain.
Then update only the records needed for the task. For a website migration, that may be the root A record and www CNAME or A record. Leave email and unrelated verification records alone. If you are changing nameservers instead of individual records, recreate the full zone at the new provider before switching delegation. Missing a single TXT or MX record can affect services that are not immediately visible.
After publishing changes, test from more than one network. Check both the root domain and www version in a browser, including key pages, forms, and checkout functions. Send test messages to and from addresses on the domain. If you use a command-line DNS lookup tool, query the expected record types directly and compare returned values with the values in your DNS zone.
Keep the prior hosting environment active until the new destination is consistently serving the right site. Canceling an old account too early can remove files, email routing, or a fallback path before cached DNS responses have expired.
Common Errors That Cause Avoidable Downtime
The most damaging problems are usually simple configuration errors, not complex network failures. A misspelled hostname, an extra character in a TXT record, or a record created under the wrong host field can be enough to break service. Control panels vary in how they display the root domain: some use @, some use a blank host field, and some expect the full domain name.
Another common issue is using an IP address from a shared hosting server without confirming that the domain has been added to the correct account. The address may be valid, but the server still needs to recognize the domain and have the correct site files, virtual host configuration, and SSL certificate in place.
Do not rely on browser results alone when troubleshooting. Browsers cache redirects, DNS answers, and site assets. A direct DNS lookup, a test from mobile data, and an email delivery check can reveal whether the issue is DNS, web hosting, SSL, or local caching.
For businesses that need help coordinating a migration, email setup, and hosting cutover, Charter Hosting support can help verify the records that belong to the hosting environment while preserving the services you intend to keep.
DNS is often invisible when it works, which is exactly the goal. Make changes with a documented plan, preserve the records that support critical services, and test the result before treating the job as complete. That discipline keeps your website available, your email deliverable, and your next infrastructure change far less stressful.
