DNS Lookup: How to Check TXT Records, MX Records and Other DNS Records

Checking TXT records and checking MX records are the most common DNS tasks: TXT holds SPF, DKIM, DMARC and domain verification records, while MX tells the world where to deliver your mail. The quickest way to check a domain's DNS records online is to run it through a DNS lookup: the free tool, with no sign-up, shows A, AAAA, CNAME, MX, NS, TXT, SOA and SRV records along with their values and TTL. The MX lookup goes deeper into mail servers and priorities, and from the command line nslookup -type=txt example.com and nslookup -type=mx example.com show the same. Below: how to read the results and what to do when your records "won't update".

How to check DNS records online

1. Open the DNS lookup and enter the domain: example.com. No need to strip the protocol or path — the tool extracts the hostname from the URL itself.
2. For a subdomain, enter it in full: www.example.com, shop.example.com. Each name has its own records, and a CNAME usually lives on the subdomain.
3. Compare the results with what your hosting or email provider gave you: the IP in the A record, the hostnames in MX, the strings in TXT.
4. Check the TTL column — it tells you in how many seconds caches will refresh if you have just changed something.

The tool queries records through our server's resolver, so it shows what one point on the network sees right now. To check whether changes have propagated, compare that answer with public resolvers using the commands in the next section.

Names with an underscore, such as _dmarc.example.com, are not entered into the general lookup — email records have dedicated tools: the MX lookup shows mail servers with priorities and IPs, the SPF checker breaks down mechanisms and include chains, and the DMARC checker shows the policy and report addresses.

How to check DNS with nslookup and dig

nslookup is available on Windows, macOS and Linux; dig ships with macOS and most Linux distributions. The last nslookup parameter, or the @ argument in dig, sets which DNS server to ask.

nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CNAME www.example.com

dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

In PowerShell, Resolve-DnsName example.com -Type MX does the same. To see what is actually in the zone, with no caches along the way, query the authoritative server directly: first dig example.com NS +short, then dig @ns1.your-provider.net example.com A. dig +trace example.com walks the whole chain from the root servers and shows at which step the answer differs from what you expect.

DNS record types and what to check

How to check a CNAME record

A CNAME says: "this name is an alias for another name — ask over there." It is used on subdomains that point to an external service: a website builder such as Shopify, Wix or Squarespace, a CDN, a hosted store. You can check a domain's CNAME record online by entering the subdomain in the DNS lookup, or with dig www.example.com CNAME +short.

• A CNAME cannot coexist with other records on the same name. That is why you cannot put a regular CNAME on the root domain (example.com, which always has NS and SOA). Some DNS providers offer a substitute — ALIAS, ANAME or CNAME flattening: from the outside, such a record looks like a normal A record.
• CNAME → CNAME → CNAME chains work, but they slow down resolution and make debugging harder.
• A CNAME pointing to a name that no longer exists is a common reason a subdomain "won't load" after an external service is switched off.
• The trailing dot. Some control panels require the value to end with a dot; otherwise your domain gets appended and you end up with shop.example.net.example.com.

How to check a domain's TXT record

1. Work out which name the record belongs on. SPF and the Search Console verification live on the domain itself (usually "@" in a DNS panel), DMARC on _dmarc.example.com, DKIM on selector._domainkey.example.com. Other services' verification records go wherever the service tells you.
2. Look it up online. For the domain itself, use the DNS lookup: the TXT tab lists every TXT record with its TTL. Names with an underscore are not accepted by the general lookup — use the SPF checker, DKIM checker and DMARC checker for those.
3. Or from the command line:

   nslookup -type=txt example.com
   nslookup -type=txt _dmarc.example.com 8.8.8.8
   dig TXT example.com +short
   dig TXT _dmarc.example.com +short
   dig @ns1.your-provider.net TXT example.com +short

   The last command asks the authoritative server directly, so you see the record right after adding it without waiting for caches.
4. Compare the value character by character with what the service gave you: a stray space, a truncated key or quotes inside the value will break validation.

Do not delete the Google verification record once the property is verified: without it, verification can be lost.

Common TXT record mistakes

• Two v=spf1 records. Under the SPF standard that is an error, and SPF stops working altogether. Merge the second service's mechanisms into the existing record. Note that our SPF checker parses the first v=spf1 record it finds, so look for duplicates in the TXT list of the DNS lookup or with dig TXT example.com +short.
• Quotes inside the value. Most panels expect the value without quotes and add them for you. Paste it with quotes and they sometimes become part of the text — dig then shows "\"v=spf1 ...\"".
• Strings longer than 255 characters. A single string inside a TXT record is capped at 255 characters, so a long value — typically a 2048-bit DKIM key — is stored as several quoted strings in one record: "v=DKIM1; k=rsa; p=MIIB..." "...continued". The receiver joins them with no spaces. Many panels split the value for you; the mistake is creating two separate TXT records instead.
• Wrong name. The full domain was typed into the "Name" field and the panel appended it again, producing _dmarc.example.com.example.com.

How the records work and how to set them up: SPF, DKIM and DMARC explained and what a DKIM record and selector are.

TXT records: SPF, DKIM and DMARC

If email from your domain lands in spam, check three TXT records:

example.com.                     TXT  "v=spf1 include:_spf.google.com ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.              TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• SPF — the list of servers allowed to send mail for the domain. There must be only one v=spf1 record: two SPF records invalidate the check. SPF evaluation is limited to ten DNS lookups, and long include chains easily exceed it.
• DKIM — the public signing key, published at selector._domainkey.domain. The selector is set by your email service; without it you cannot find the record.
• DMARC — the policy for messages that fail SPF and DKIM: none (reports only), quarantine (send to spam), reject (refuse).

TXT records also hold ownership verifications: for example, a Domain property in Search Console is verified with a TXT record — see the article on connecting a property.

How to check MX records

An MX record tells senders which server accepts mail for the domain. It has two fields: a priority and a server name. The lower the number, the higher the priority: senders try the server with 10 first and fall back to 20 if it is unreachable. Several MX records with the same priority share the load — senders pick between them, which is normal load balancing.

1. Enter the domain in the MX lookup: it lists mail servers by priority with their IPv4 and IPv6 addresses and PTR records, and recognises the mail provider.
2. Or run nslookup -type=mx example.com or dig MX example.com +short — the answer looks like 10 mx1.example.net.
3. Make sure every MX hostname resolves to an address: dig A mx1.example.net +short.
4. Compare the list with your mail provider's instructions: they usually require removing all old MX records, not adding theirs alongside.

No MX records? Under RFC 5321 senders will try the domain's own A/AAAA address — the so-called implicit MX. A domain that receives no mail at all should publish a null MX, 0 . (RFC 7505), so senders bounce the message straight away. With neither MX nor A, mail to the domain cannot be delivered.

MX only covers receiving. Keeping your own mail out of recipients' spam folders is the job of SPF, DKIM and DMARC, and the route of a specific message is in its headers — see how to read email headers.

TTL and DNS propagation

TTL is the time in seconds that resolvers cache an answer. With a TTL of 3600, an ISP that once asked for your A record will keep serving the old value for an hour, even if you have already changed it. So-called "DNS propagation" is simply caches expiring gradually around the world. Changing nameservers at the registrar usually takes longer: records in the top-level domain zone have their own, typically long, TTL.

• Before planned changes, lower the TTL to 300 seconds — at least one old TTL period in advance.
• If you queried a name before the record was created, the negative answer is cached too — for the time set in the zone's SOA record.
• Your local cache can also get in the way: on Windows, clear it with ipconfig /flushdns; on macOS, with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• If the authoritative server answers correctly but public resolvers do not, nothing is broken: you just need to wait out the TTL.

When you need to check DNS

• The site loads for some people but not others. A common cause is records changed recently, with some ISPs still holding old data.
• Email goes to spam. Check SPF, DKIM and DMARC in your TXT records.
• Moving to a new host. Record your current DNS before switching.
• Connecting an external service — email, a CDN, a site builder: it is almost always a CNAME or a TXT record.

Common mistakes

• Editing records in the wrong place. If the domain's NS records point to one provider, changes in another provider's panel (your registrar's, for example) have no effect. Check NS first.
• Two SPF records after adding a second email service, instead of merging them into one.
• A CNAME on the root domain that breaks MX and TXT.
• Forgotten MX records during a migration: the site works, but email stops arriving.
• An old IP on www: the root A record was updated, but www still points to the old one.

Checklist for moving to a new host

1. A day ahead, lower the TTL on your records so the switch is picked up quickly.
2. Write down your current records: A, MX, TXT and NS should be documented before any changes.
3. Set up the site on the new server and test it by IP without touching the domain.
4. Switch the A record and watch the answers from different resolvers.
5. Make sure email still works: MX and SPF are the records most often forgotten during a move.
6. Restore the original TTL and check the SSL certificate at the new address.