DNS records tell internet services what to do with a domain. They can point a website to a server, route email, verify ownership, and publish security policies. Understanding the record types makes routine changes safer and makes outages much easier to diagnose.

A record: point a name to IPv4

An A record maps a hostname to an IPv4 address, such as 203.0.113.10. It is commonly used for the root domain and sometimes for subdomains. When you move a site to a new host, the A record is often the setting that changes.

Confirm that the destination server is configured to serve the hostname; pointing a record at an IP alone does not configure the web server or certificate.

AAAA record: point a name to IPv6

An AAAA record is the IPv6 equivalent of an A record. If it is present, IPv6-capable visitors may use it instead of IPv4. An outdated AAAA record can cause a site to work for some users while failing for others, so remove it only if IPv6 is not intentionally supported.

CNAME record: create an alias

A CNAME makes one hostname an alias for another hostname. For example, www.example.com can point to a host name supplied by a platform or CDN. The DNS resolver follows the alias until it reaches an address record.

Traditional DNS does not allow a CNAME at the zone apex (the bare domain) alongside other necessary records, though some providers offer special flattened or alias-style records. Follow your provider’s documented behavior rather than assuming all dashboards handle apex aliases the same way.

MX record: route email

MX records tell sending mail servers where to deliver email for a domain. Each has a priority value; lower values are tried first. A website migration should not require changing MX records, but switching nameservers or recreating a DNS zone can accidentally remove them.

After a DNS migration, run an MX record lookup and compare the result with your email provider’s required settings.

TXT record: publish verification and policies

TXT records hold text values. They are widely used to verify a domain with services and to publish email authentication:

• SPF identifies services allowed to send mail for a domain.
• DKIM publishes a public key used to validate signed messages.
• DMARC tells receiving servers how to handle authentication failures and where to send reports.

TXT values can be long, and an extra quote, missing character, or duplicate SPF policy can break a setup. Copy provider values exactly and verify them after saving.

NS and SOA records: identify the DNS authority

NS records list the authoritative nameservers for a DNS zone. They tell the internet which provider’s DNS answers should be trusted. The SOA record contains zone-level information, including the primary nameserver and timing values used by DNS systems.

When records appear correct in a DNS dashboard but look wrong publicly, check whether the domain’s registrar delegates to those same nameservers.

TTL: how long answers can be cached

The Time to Live (TTL) is a caching instruction, expressed in seconds. A lower TTL can make planned changes take effect sooner after caches refresh, while a higher TTL can reduce repeated DNS lookups. Lower the TTL ahead of a migration, not after it starts; existing cached answers retain the TTL they received.

A safe DNS-change checklist

1. Export or document the existing zone before editing.
2. Change only the record required for the task.
3. Check the root domain and every important subdomain separately.
4. Preserve mail-related MX and TXT records during nameserver changes.
5. Verify the public result with a DNS lookup, not just the provider dashboard.
6. Keep the old hosting configuration available until the new route is confirmed.

DNS changes are powerful because one record can affect an entire site or mail system. A careful record-by-record check keeps the change controlled and gives you a reliable starting point when something does not resolve as expected. For fault diagnosis, follow our DNS troubleshooting guide.