DNS records connect your domain to a website, email provider, verification service, or other online system. This guide explains which records a new website usually needs, how to point a domain to web hosting without interrupting email, and how to monitor DNS changes during launches, migrations, and routine maintenance.
Overview
The Domain Name System, or DNS, translates a readable domain such as example.com into the destinations used by browsers, mail servers, and third-party services. Your domain registrar, DNS hosting provider, website builder, and web host may be different companies, so the first step is identifying where DNS is actually managed.
A new website does not require every possible DNS record. Most launches involve a small set of records:
- A record: Sends a hostname to an IPv4 address.
- AAAA record: Sends a hostname to an IPv6 address, when the hosting service provides one.
- CNAME record: Points one hostname to another hostname.
- MX record: Tells email systems where to deliver mail for your domain.
- TXT record: Stores text used for verification, email authentication, and service configuration.
- CAA record: Restricts which certificate authorities may issue TLS certificates for the domain, when supported and deliberately configured.
DNS changes are separate from changes made inside a website builder or managed cloud hosting account. A site can be fully built but remain inaccessible at the domain until its DNS records direct visitors to the correct platform.
Before editing anything, export or copy the current DNS zone if your provider allows it. Record the existing values for email, subdomains, verification services, and any integrations. This simple inventory reduces the risk of replacing a working record with an incomplete new configuration.
What to track
1. The authoritative DNS provider
Find the nameservers assigned to your domain. The service listed by those nameservers is generally authoritative for DNS changes. Editing records at your domain registrar will not affect the website if the domain uses a separate DNS provider.
2. The website destination
Ask your hosting provider or website builder for its required DNS values. Some platforms provide an IP address for an A record; others provide a target hostname for a CNAME. Follow the platform's exact instructions rather than guessing.
For the root domain, often written as @, the provider may require an A record or a platform-specific method for connecting the domain. For www, a CNAME is commonly used, but the correct choice depends on the host. This is the practical distinction in the question “A record vs CNAME”: an A record points directly to an IP address, while a CNAME aliases one hostname to another.
3. Existing email records
Website DNS setup and email DNS setup are related but separate. MX records control where incoming mail goes; changing an A record does not normally redirect email. Do not delete MX records when pointing a domain to new web hosting unless you are intentionally changing email providers.
Also review TXT records used by your email provider. These may support sender authentication or domain verification. If you add a new email service, use the provider's requested MX and TXT values and check whether it requires removal of older records.
4. Verification and subdomains
Website builders, analytics platforms, search tools, payment services, and other systems may request a TXT record or a CNAME for verification. Keep a short register containing the hostname, record type, value, purpose, owner, and date added.
Track important subdomains separately, such as shop.example.com, app.example.com, or status.example.com. A migration that updates only the main domain can leave a subdomain pointing to an old server or an abandoned service.
| Record | Typical purpose | Important caution |
|---|---|---|
| A | Root domain to an IPv4 address | Use the exact IP supplied by the host. |
| AAAA | Root domain to an IPv6 address | Do not add one unless the destination supports IPv6 correctly. |
| CNAME | Hostname to another hostname | Check whether the provider supports it at the root domain. |
| MX | Mail delivery | Changing it can interrupt incoming email. |
| TXT | Verification and email-related settings | Preserve unrelated TXT records. |
Cadence and checkpoints
DNS usually needs attention when something changes, not every day. A practical monitoring rhythm is:
- Before launch: Confirm the authoritative provider, lower the TTL only if your migration plan calls for it, and document every planned change.
- During launch: Check the root domain,
www, key subdomains, HTTPS, and email delivery. Test from more than one network or DNS resolver where possible. - After a migration: Recheck the records after the planned DNS transition window and confirm that the old hosting account is no longer receiving meaningful traffic before cancelling it.
- Monthly or quarterly: Review the DNS inventory, remove records for retired services, confirm that verification records still have an owner, and check that domain and DNS accounts use strong authentication.
- Before a major campaign or release: Verify that the intended website is live, certificates cover the domain, and critical third-party integrations still resolve correctly.
TTL, or time to live, tells resolvers how long they may cache a response. A low TTL can make planned changes easier to adjust, while a higher TTL can reduce repeated lookups. TTL does not force every resolver to update at exactly the same moment, so include verification time in your launch plan.
For a broader launch sequence, use the small business website launch checklist. If you are changing infrastructure, the cloud hosting backup and disaster recovery plan can help separate DNS work from backup and rollback decisions.
How to interpret changes
When a domain fails after a DNS edit, start with the scope of the problem. If the root domain fails but www works, compare their records and confirm that both hostnames are configured by the hosting platform. If the website works but email fails, inspect MX and related TXT records rather than changing the web records again.
If some users see the old site and others see the new site, cached DNS responses may still exist, but the cause could also be inconsistent records across DNS providers or an incomplete migration. Check the authoritative answer first, then compare results from multiple resolvers. Avoid repeatedly changing records before establishing which value is currently published; frequent edits can make diagnosis harder.
A “DNS error” can also hide an application problem. Once the hostname resolves to the expected destination, investigate TLS certificate coverage, host configuration, redirects, firewall rules, and the application itself. DNS only determines where a request should go; it does not guarantee that the server is ready to answer.
For security, remove obsolete verification records and unused subdomains. Limit access to the registrar and DNS provider, keep a change log, and treat DNS values as operational configuration. Some TXT values are public by design, but they should still be managed carefully because they can affect email trust and service verification.
When to revisit
Revisit this guide whenever you connect a domain to a website builder, move to new web hosting, add or replace an email provider, create a subdomain, verify a third-party platform, or change the infrastructure behind an existing site. Schedule a monthly or quarterly DNS review even when nothing appears broken; unused records and undocumented services become harder to assess over time.
Use this action list for your next change:
- Identify the authoritative DNS provider and export or document the current records.
- Obtain the exact A, AAAA, or CNAME values from the new hosting or site builder platform.
- Preserve MX and relevant TXT records unless email is intentionally moving.
- Record the planned change, TTL, time, purpose, and rollback value.
- Test the root domain,
www, important subdomains, HTTPS, and email separately. - Recheck the zone after the migration and remove obsolete records only after confirming they are no longer needed.
If your next step is deploying or updating the site, compare this DNS process with the one-click website deployment guide. Keeping domain configuration, hosting changes, and application releases documented separately makes future launches easier to troubleshoot and safer to repeat.
