10-07-2026, 05:56 PM
DNS records connect names to services. Knowing which record to change prevents accidental website, mail and certificate outages.
Examples use example.com and documentation-only IP addresses. Replace them with your provider's real values; do not publish these examples as a working zone. DNS dashboard labels differ: @ often means the zone's root, and some dashboards append the domain to a short record name automatically.
Start with authority, not the record editor
The registrar delegates your domain to authoritative nameservers. Edit records at the DNS provider serving that delegation. A record saved at a former provider does nothing for users who query the current provider. A recursive resolver caches answers; it is not usually where you edit your zone.
Before changing anything, export/copy your current zone and record the existing nameservers. Protect registrar and DNS accounts with MFA. A DNS change can affect mail and domain verification even if your goal is only to move a website.
A — name to IPv4
An A value is an IPv4 address, not a URL, path or port. Multiple A records can return multiple addresses, but they do not automatically provide application-aware failover. Every returned address should serve the intended workload.
AAAA — name to IPv6
Publish AAAA only when the service, routing and firewall work over IPv6. A stale AAAA can make a website fail for some visitors while IPv4 tests look healthy. Test both families before a migration.
CNAME — one name aliases another
The target is a hostname. A CNAME does not redirect a browser or change its URL; the web server still needs to recognize www.example.com and present a matching certificate. Avoid alias loops and unnecessarily long chains.
A conventional CNAME cannot coexist at the same name with A, MX, TXT or other ordinary data. The zone apex needs SOA/NS records, so it cannot be a conventional CNAME. Some providers offer ALIAS/ANAME or CNAME flattening; those are provider-specific features with their own behavior. Check the provider's documentation before using them.
MX — where incoming email is delivered
The smaller preference number is tried first. The target must be a hostname with address records, not an IP literal or a CNAME alias. Copy the complete MX set from your email provider. Changing MX does not migrate mailboxes and does not authorize outgoing email. Do not replace working hosted-mail MX records when you only move the website.
If you use an HTTP reverse proxy/CDN, the mail hostname normally needs DNS-only resolution unless that provider explicitly supplies the relevant mail proxy service.
TXT — verification and email policy data
TXT carries text used by services such as domain verification, SPF, DKIM and DMARC. The owner name and exact value both matter. Keep unrelated TXT records; adding a verification token is not a reason to delete email policy.
An illustrative SPF policy for a domain whose only authorized sender is 192.0.2.20:
Do not copy this onto a real domain. Build your policy from all legitimate senders' official instructions. There must be only one SPF policy beginning v=spf1 at the evaluated name; do not add a second one for another sender. SPF also has DNS-lookup limits.
DKIM is published at the selector name provided by the sender, often as TXT or a provider-specified CNAME. DMARC belongs at _dmarc.example.com. Roll out enforcement deliberately after inspecting reports and sender alignment. DNS verification tokens are publicly readable; never put passwords or API secrets in TXT.
NS — which nameservers are authoritative
Changing the registrar's nameservers moves delegation. Adding NS entries in an arbitrary DNS dashboard is not a substitute for that registrar change. NS records can also delegate a subdomain to another DNS service.
Before switching providers, copy all required A/AAAA, MX, TXT, CAA and other records to the new zone. Check DNSSEC and the registrar's DS record with both providers; an incompatible stale DS can cause validating resolvers to return SERVFAIL. Follow a documented DNSSEC migration plan rather than randomly toggling it. In-zone nameserver hostnames may require registrar glue records.
PTR — IP address back to a name
PTR lives in a reverse-DNS zone, usually controlled by the VPS/IP provider. An ordinary PTR you add to example.com's forward zone does not change public reverse DNS for your VPS address.
For a mail server, arrange a meaningful PTR and corresponding forward address record as required by your provider and mail setup. PTR is one part of deliverability; it does not guarantee good reputation or inbox placement.
CAA — constrain certificate issuance
An example permitting Let's Encrypt:
Use the actual CA identifiers required by your certificate/CDN provider. issue controls normal issuance; issuewild can set a separate wildcard policy. CAA lookup rules can involve parent domains and aliases, so examine the effective policy rather than one dashboard row. A restrictive CAA policy can break a future renewal if your provider uses another CA. CAA does not install TLS, revoke an existing certificate or remove a CA's normal domain-validation requirements.
TTL — how long answers may be cached
TTL is expressed in seconds. A 300-second TTL is five minutes, but changing a TTL does not purge answers already cached under the old value. Lower the TTL sufficiently before a planned migration, keep the old service available during the overlap, and restore a normal value afterward. Negative answers and delegation can have different cache lifetimes. There is no single guaranteed "propagation time" for every DNS change.
Read-only checks with dig
Run from a workstation with dig installed; Ubuntu/Debian package it in dnsutils:
Use normal dig output too when you need status codes; +short alone hides useful context. Query a nameserver returned by the NS lookup to compare authoritative data with a resolver's cached answer:
Do not use ANY as a reliable inventory of a zone. Export records from the provider instead.
Troubleshooting decision points
References
When asking for help, give the affected public hostname, expected record type, DNS provider and a sanitized dig response. Keep account credentials and private information out of the post.
Examples use example.com and documentation-only IP addresses. Replace them with your provider's real values; do not publish these examples as a working zone. DNS dashboard labels differ: @ often means the zone's root, and some dashboards append the domain to a short record name automatically.
Start with authority, not the record editor
The registrar delegates your domain to authoritative nameservers. Edit records at the DNS provider serving that delegation. A record saved at a former provider does nothing for users who query the current provider. A recursive resolver caches answers; it is not usually where you edit your zone.
Before changing anything, export/copy your current zone and record the existing nameservers. Protect registrar and DNS accounts with MFA. A DNS change can affect mail and domain verification even if your goal is only to move a website.
A — name to IPv4
Code:
example.com. 300 IN A 192.0.2.10
mail.example.com. 300 IN A 192.0.2.20AAAA — name to IPv6
Code:
example.com. 300 IN AAAA 2001:db8::10CNAME — one name aliases another
Code:
www.example.com. 300 IN CNAME example.com.A conventional CNAME cannot coexist at the same name with A, MX, TXT or other ordinary data. The zone apex needs SOA/NS records, so it cannot be a conventional CNAME. Some providers offer ALIAS/ANAME or CNAME flattening; those are provider-specific features with their own behavior. Check the provider's documentation before using them.
MX — where incoming email is delivered
Code:
example.com. 300 IN MX 10 mail.example.com.If you use an HTTP reverse proxy/CDN, the mail hostname normally needs DNS-only resolution unless that provider explicitly supplies the relevant mail proxy service.
TXT — verification and email policy data
TXT carries text used by services such as domain verification, SPF, DKIM and DMARC. The owner name and exact value both matter. Keep unrelated TXT records; adding a verification token is not a reason to delete email policy.
An illustrative SPF policy for a domain whose only authorized sender is 192.0.2.20:
Code:
example.com. 300 IN TXT "v=spf1 ip4:192.0.2.20 -all"DKIM is published at the selector name provided by the sender, often as TXT or a provider-specified CNAME. DMARC belongs at _dmarc.example.com. Roll out enforcement deliberately after inspecting reports and sender alignment. DNS verification tokens are publicly readable; never put passwords or API secrets in TXT.
NS — which nameservers are authoritative
Changing the registrar's nameservers moves delegation. Adding NS entries in an arbitrary DNS dashboard is not a substitute for that registrar change. NS records can also delegate a subdomain to another DNS service.
Before switching providers, copy all required A/AAAA, MX, TXT, CAA and other records to the new zone. Check DNSSEC and the registrar's DS record with both providers; an incompatible stale DS can cause validating resolvers to return SERVFAIL. Follow a documented DNSSEC migration plan rather than randomly toggling it. In-zone nameserver hostnames may require registrar glue records.
PTR — IP address back to a name
PTR lives in a reverse-DNS zone, usually controlled by the VPS/IP provider. An ordinary PTR you add to example.com's forward zone does not change public reverse DNS for your VPS address.
For a mail server, arrange a meaningful PTR and corresponding forward address record as required by your provider and mail setup. PTR is one part of deliverability; it does not guarantee good reputation or inbox placement.
CAA — constrain certificate issuance
An example permitting Let's Encrypt:
Code:
example.com. 300 IN CAA 0 issue "letsencrypt.org"TTL — how long answers may be cached
TTL is expressed in seconds. A 300-second TTL is five minutes, but changing a TTL does not purge answers already cached under the old value. Lower the TTL sufficiently before a planned migration, keep the old service available during the overlap, and restore a normal value afterward. Negative answers and delegation can have different cache lifetimes. There is no single guaranteed "propagation time" for every DNS change.
Read-only checks with dig
Run from a workstation with dig installed; Ubuntu/Debian package it in dnsutils:
Code:
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer
dig example.com NS +noall +answer
dig example.com CAA +noall +answer
dig -x 192.0.2.20 +noall +answerCode:
dig @YOUR_AUTHORITATIVE_NAMESERVER example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answerTroubleshooting decision points
- Old address still appears: Compare the active authoritative server with recursive resolvers. Check delegation, the old TTL and whether you edited the right zone.
- NXDOMAIN: The queried name does not exist according to the answer. Check spelling, duplicated domain suffixes and negative caching. NOERROR with no answer can mean the name exists but that record type does not.
- SERVFAIL: Investigate authoritative availability, delegation and DNSSEC; do not assume waiting will fix it.
- Only IPv6 users fail: Compare AAAA with the service's actual IPv6 reachability.
- Mail broke after moving the website: Check preserved MX, mail-host address records, SPF/DKIM/DMARC and provider proxy settings.
- Certificate issuance fails: Check public DNS, CAA and the actual validation method (HTTP or DNS challenge). Do not weaken TLS validation to hide the symptom.
References
- Cloudflare: DNS record overview
- RFC 2181: DNS aliases and MX/NS constraints
- RFC 7208: SPF
- RFC 8659: CAA
When asking for help, give the affected public hostname, expected record type, DNS provider and a sanitized dig response. Keep account credentials and private information out of the post.