DNS records direct visitors, email, verification tools, and other services to the right systems. This practical guide explains which record to use, how nameservers differ from DNS records, how to change settings safely, and how to troubleshoot propagation without accidentally interrupting your website or email.
Overview
When you buy a domain name, the domain itself does not automatically know where your website or mailboxes are hosted. The Domain Name System (DNS) supplies that information. DNS management is usually available through your domain registrar, hosting provider, or a dedicated DNS provider, depending on where the domain’s nameservers point.
A DNS record is an instruction for a particular hostname. For example, example.com may point to a web server, while www.example.com may use a separate record. Email services commonly use MX records, and service providers often ask you to publish TXT or CNAME records to verify domain ownership or improve email authentication.
DNS record reference table
| Record | Purpose | Typical value | Important consideration |
|---|---|---|---|
| A | Points a hostname to an IPv4 address. | 203.0.113.10 | Use the server IP supplied by your hosting provider. Do not enter a URL. |
| AAAA | Points a hostname to an IPv6 address. | An IPv6 address | Only add it when the destination supports IPv6 and the address is correct. |
| CNAME | Points one hostname to another hostname. | target.example-host.com | Use a hostname, not an IP address. A CNAME generally cannot coexist with other records at the same name. |
| MX | Specifies which mail servers receive email for a domain. | mail.example-provider.com with a priority | Preserve every required MX record and follow the mail provider’s priority instructions. |
| TXT | Stores text used for verification and email policies. | v=spf1 ... or a verification token | Follow the provider’s exact value. Multiple TXT records may be valid, but policies must be configured carefully. |
| NS | Identifies the authoritative nameservers for a domain or delegated subdomain. | ns1.example-dns.com | Changing NS records changes where the DNS zone is managed. |
Nameservers versus DNS records
Nameservers and DNS records are related but are not the same thing. Nameservers tell the internet which DNS service is authoritative for your domain. The DNS records inside that service then tell visitors where the website, email, and other services are located.
If you change an A record in the active DNS zone, you change the destination for that hostname. If you change the domain’s nameservers, you move DNS management to a different provider. The new provider must contain a complete, accurate copy of the existing zone before the nameserver change. Otherwise, website, email, verification, or subdomain records may disappear from the authoritative zone.
As a practical rule, change individual records when you are connecting a service and change nameservers only when you intend to move DNS management or delegate a part of the domain.
Checklist by scenario
To connect a root domain to web hosting
- Confirm the hosting provider’s required destination, such as an IPv4 address or an assigned hostname.
- In the active DNS zone, find the A record for the root domain, often displayed as
@. - Replace or update the value only if you are intentionally moving the website. Record the old value first.
- Check whether an AAAA record exists. Remove or update it only if it points to an obsolete or incompatible server.
- Confirm that the hosting account recognises the domain and that an SSL certificate can be issued after DNS resolves correctly.
To configure a www subdomain
- Use a CNAME when the hosting provider gives you a hostname, such as
site.example-host.com. - Use an A record when the provider gives you a fixed IPv4 address instead.
- Check that there is not already a conflicting A record, CNAME, or forwarding rule for
www. - Test both the root domain and
www; they may use different records and can behave differently.
To set up business email
- Obtain the mail provider’s complete MX record list, including hostnames and priority values.
- Remove obsolete MX records only when you are sure the old service is no longer receiving mail.
- Add the provider’s requested TXT records for verification or email authentication exactly as supplied.
- Check whether the provider requires a separate SPF, DKIM, or DMARC configuration. These are email DNS settings, but each has a different role and syntax.
- Send test messages in both directions and check whether messages are delivered, delayed, or rejected.
To verify a third-party service
- Copy the requested record type, host or name, and value into a temporary working note.
- Enter the host exactly as required by the DNS panel. Some panels append the domain automatically, while others expect the full hostname.
- Do not add quotation marks unless the provider or DNS interface specifically requires them.
- Wait for the record to become visible, then use the service’s verification button or an independent DNS lookup.
For a broader domain connection sequence covering DNS, SSL, and email, see How to Connect a Domain to Web Hosting.
What to double-check
Before changing DNS
- Identify where the authoritative nameservers point. Editing records at the registrar will not help if another provider hosts the active DNS zone.
- Export, copy, or photograph the current zone records, including A, AAAA, CNAME, MX, TXT, and any records used by subdomains.
- Confirm whether the change affects the root domain,
www, a subdomain, email, or all of them. - Check the hosting or service provider’s current instructions rather than relying on an old setup note.
- Lower the relevant record’s TTL in advance if you expect to make a planned migration. TTL changes also take time to be observed, so they are not an instant switch.
TTL and propagation
TTL, or time to live, tells DNS resolvers how long they may cache a response. A shorter TTL can make a planned change easier to roll back, while a longer TTL can reduce repeated DNS queries. The practical effect depends on existing caches, resolver behaviour, and the previous TTL. Do not assume that every user will see a change at the same moment.
Propagation troubleshooting should begin with scope. Check the authoritative nameserver first, then compare results from more than one public resolver or network. Confirm that the record type, hostname, and value are correct. Also check for an old AAAA record, a conflicting CNAME, cached browser results, local DNS caching, or a hosting panel that has not yet attached the domain to the correct site.
Rollback checklist
- Keep the previous record values and timestamps in a change note.
- Decide what failure looks like: website errors, missing email, failed verification, or an SSL issuance problem.
- Revert only the affected record where possible instead of restoring an entire zone blindly.
- After rollback, verify the authoritative answer and test the affected service again.
- Do not repeatedly switch records while caches still contain different answers; document each change to avoid confusion.
Common mistakes
- Editing the wrong DNS provider: The registrar may sell the domain while a hosting or DNS provider controls the active zone.
- Using a URL in an A record: An A record requires an IP address. A hostname belongs in a CNAME or the record type specified by the provider.
- Replacing all MX records with one unconfirmed value: This can interrupt mail delivery or remove required backup mail servers.
- Creating a CNAME conflict: A hostname cannot normally have a CNAME alongside other records at the same name.
- Forgetting IPv6: An outdated AAAA record may send some visitors to the wrong server even when the A record is correct.
- Changing nameservers without copying the zone: The website may work at the new provider while email, verification records, or subdomains stop resolving.
- Assuming DNS changes repair SSL automatically: DNS must point to the correct service, but the hosting platform may still need the domain added and an SSL certificate issued.
- Testing only from one device: Local cache can hide a successful change or make an old value appear current.
If a DNS change is part of a website move, use a documented migration plan such as the WordPress Website Migration Checklist. For HTTPS symptoms after a change, the HTTPS Errors guide can help separate DNS issues from certificate or mixed-content issues.
When to revisit
Return to this checklist whenever you connect a new hosting plan, add a subdomain, move DNS management, change email providers, renew or replace an SSL setup, or transfer a domain to another registrar. Revisit it before planned migrations and seasonal business changes, particularly when several systems depend on the same domain.
Also review the zone when a service provider changes its setup instructions, when a website or mailbox stops resolving, or when an old campaign, verification token, or third-party integration is retired. Keep a current inventory of records, their purpose, the responsible provider, and the date of the last change. That small maintenance step makes future DNS management safer and reduces the chance of deleting a record that still supports an essential service.
Before you finish, confirm the authoritative nameservers, verify the changed record from an external lookup, test the website and email separately, check HTTPS, and save the final configuration. This process turns DNS changes from a guess-and-wait exercise into a controlled website operations task.
