The site won't load and the browser says DNS_PROBE_FINISHED_NXDOMAIN. Or transactional emails land in the spam folder and the customer says "the order confirmation email never arrived." In both cases, before touching the server, you need to figure out which DNS record you entered wrong. This article gives the exact syntax of each record with real examples so you can close the issue today.
First of all: what tool to use to view a DNS record
Before making changes, record the current state. If you don't, after the change you won't know what was broken.
dig +short A example.com
dig +short MX example.com
dig +short TXT example.com @8.8.8.8
dig +trace example.com
The dig +trace command shows the full path from the root down to the authoritative server, and when you're stuck wondering "I added the record but it hasn't taken effect," this is the only real tool. If dig isn't installed, use nslookup -type=MX example.com. For a quick check from inside the browser, you can also use ServerNet's free DNS and domain lookup tools.
A and AAAA records: IPv4 and IPv6 addresses
An A record maps a domain name to an IPv4 address. It's the simplest record, and it's also where most mistakes happen.
example.com. 3600 IN A 185.10.20.30
www.example.com. 3600 IN A 185.10.20.30
The number 3600 is the TTL, in seconds. That means resolvers keep the cached version for up to an hour. If you want a migration to take effect quickly, lower the TTL to 300 24 hours before the change, then make the change, and raise it again once things are stable. Here's the mistake people make: they lower the TTL at the moment of migration and then find that for an hour the site still goes to the old server. Nobody clears the previous cache for you.
An AAAA record does the same thing for IPv6. If your server doesn't have IPv6, don't add an AAAA record. Adding an AAAA record pointing to an address with no return path causes some users to experience a several-second delay, because the client tries IPv6 first, fails, and then falls back to IPv4.
CNAME record: an alias, with one important limitation
A CNAME points one name to another name, not to an IP. Its main use is for subdomains that connect to an external service.
shop.example.com. 3600 IN CNAME example.myshopify.com.
mail.example.com. 3600 IN CNAME mail.provider.net.
Notice the trailing dot at the end of the line. If you leave it out, some panels interpret the name as relative and the record becomes example.myshopify.com.example.com. The result is an NXDOMAIN error, and you think the external service is broken.
The real limitation of CNAME is this: at the apex record (that is, example.com itself with no subdomain), the standard doesn't allow a CNAME, because it conflicts with MX and NS. Some DNS providers make this possible with a "CNAME flattening" trick, but the result is no longer a real CNAME; it's an A record that gets generated behind the scenes. If you have full control over your own DNS and want the main domain to connect to a cloud service, this trick works. If not, use an A record.
MX record: why email doesn't arrive
The MX record tells you which server receives the domain's email. The number in front of it is the priority; a lower number means higher priority.
example.com. 3600 IN MX 10 mail1.provider.net.
example.com. 3600 IN MX 20 mail2.provider.net.
Two common mistakes. First, putting a dot at the end of the MX value; if you write mail1.provider.net without a dot, some panels append your own domain to it and email goes to the wrong server. Second, using a CNAME instead of an MX. The standard explicitly says the MX value must be a hostname, not an alias. Some mail servers tolerate this and some don't; and when they don't, email is silently lost.
If email is being sent but lands in spam, the problem isn't MX. You need to check SPF and DKIM in the TXT record.
TXT record: SPF, DKIM, and ownership verification
TXT holds free-form text, and today it's mostly used for email authentication.
example.com. 3600 IN TXT "v=spf1 include:_spf.provider.net -all"
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
Only one SPF record is allowed. If you have two v=spf1 records, the result is permerror and the recipient rejects the message. Here's the mistake people make: when adding a new email service, they create a second TXT instead of adding an include to the existing record. The symptom is that emails go to spam irregularly and the destination server log shows SPF permerror.
The DKIM value is long and some panels break it into multiple strings. If you're copying the record by hand, make sure the full key is entered without extra spaces; one missing character invalidates the signature.
SRV and CAA records: rarely used but critical
SRV announces the port number and service host together. Its syntax has four numbers and a name:
_sip._tcp.example.com. 3600 IN SRV 10 5 5060 sipserver.example.com.
The order of the numbers: priority, weight, port, target. Swapping weight and port is a common mistake that only shows itself when a VoIP or XMPP service won't connect and you're hunting for the problem in the firewall.
The CAA record specifies which certificate authority is allowed to issue SSL for your domain:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
If you lock down CAA strictly and later want to get a certificate from another authority, issuance fails and the error message in the ACME log is something like CAA record forbids issuance. This is a security restriction, not a bug. If your team gets certificates from multiple authorities, either don't add CAA or authorize both authorities.
Which record to add where
| Record | What it points to | Main use | Common mistake |
|---|---|---|---|
| A | IPv4 address | Main domain and www | Old IP after migration |
| AAAA | IPv6 address | Only if IPv6 is enabled | Adding without a return path |
| CNAME | Another name | Subdomains of an external service | Using it at the apex |
| MX | Mail server | Receiving the domain's email | Missing trailing dot |
| TXT | Free-form text | SPF, DKIM, DMARC | Two SPF records |
| SRV | Host and port | VoIP, XMPP, some games | Swapping weight and port |
| CAA | Certificate authority | Restricting SSL issuance | Locking to one authority for no reason |
If you have a WordPress site and after changing the A record you run into a database connection error, the problem isn't DNS; follow the troubleshooting path in the WordPress database connection error guide. For projects hosted on Linux infrastructure where you want full control over the DNS zone, Linux hosting is a more sensible option than closed panels. And if you work with WordPress and want to check records and cache from the terminal without opening a panel, essential WP-CLI commands will save you a lot of time.
The order of operations when something is broken
- Record the current state with
dig +short. - Determine which record is responsible for that symptom: NXDOMAIN means A or CNAME, email not arriving means MX and TXT, an SSL error means CAA or the certificate.
- Lower the TTL before the change, not after.
- After the change, check from two different resolvers (
@8.8.8.8and@1.1.1.1). - If it still hasn't taken effect after the TTL, use
dig +traceto see which server is returning the old answer.
One last point that's rarely mentioned: a DNS record change is never instant, and there's no way to make it instant. If someone tells you they'll clear the cache and it'll take effect immediately, they've only cleared their own cache. The cache of intermediate resolvers isn't under your control. So make DNS changes during low-traffic windows and with patience, and always save a copy of the current zone before touching anything.
Frequently asked questions
What's the difference between an A record and a CNAME?
An A record connects a name directly to an IP address, while a CNAME points one name to another name and the resolver has to make one more query. Always use A for the main domain; CNAME is for subdomains that connect to an external service.
Why doesn't the site load after changing the DNS record?
Because resolvers keep the old version cached until the TTL expires. If the TTL is set to 3600, you may see the old site for up to an hour. With dig +trace example.com you can see which server is returning the old answer.
Can I add a CNAME for the main domain?
In the DNS standard, no, because a CNAME at the apex conflicts with MX and NS records. Some providers simulate this with CNAME flattening, but in reality an A record is generated behind the scenes.
How many SPF records can I have?
Only one. If you add two TXT records with v=spf1, the result is permerror and receiving servers will reject or spam your email. Add the new service to the same existing record with include.
Comments 0
No comments yet — be the first!