How to Perform DNS Lookup? Understanding A, CNAME, MX, and TXT Records

When your website suddenly goes down, a domain change doesn't take effect, you've connected a CDN but aren't sure if it's actually active, or you've configured business email but still aren't receiving messages—these issues may seem different, but troubleshooting often leads to the same step: DNS lookup. A DNS lookup lets you see what resolution results a domain is currently returning. Common website records like A and CNAME, as well as MX and TXT records used for business email, can all be checked via DNS lookup.

For site owners, the key isn't memorizing every DNS term but understanding one thing: after you retrieve these records, how do you know if the results are correct? This article takes a practical troubleshooting approach, explaining how to perform DNS lookups and how to interpret A, CNAME, MX, and TXT records.

1. What Exactly Does a DNS Lookup Check?

When you visit a website, the browser doesn't directly use a domain like example.com to find the server. Before establishing a connection, DNS must first translate the domain into an address the server can recognize or identify the next service target. A simplified process looks like this:

Enter domain
↓
DNS lookup
↓
Get resolution records
↓
Find corresponding server or service address
↓
Establish connection

So when website access fails, DNS is a great place to check first. For example, if you've just migrated your site from an old server to a new one, but DNS still returns the old IP, users will continue accessing the old environment no matter how well the new server is configured.

Similar issues include:

• CDN is configured, but the domain still doesn't point to the CDN CNAME

• MX record for business email is incorrect, preventing external mail delivery

• TXT verification record isn't published correctly, causing third-party platforms to keep failing verification

• After DNS changes, some regions still return old records

In these cases, you can first use DNS lookup to confirm the currently active records.

2. How to Perform a DNS Lookup?

The easiest way to check if a domain's resolution is correct is to use the chahu DNS lookup tool. Just enter the domain, and you'll get results in minutes.

The process is simple:

Enter domain ➔ Select record type (e.g., A, CNAME) ➔ Submit query ➔ Check the returned IP, mail exchange (MX), or TXT records.

However, beginners often stumble on two details:

First, don't paste the entire URL. DNS queries the domain itself, so [www.example.com](https://www.example.com) is enough. Don't include the https:// prefix or the path like /product/123—those are web addresses, not DNS.

Second, with and without www are different. example.com (root domain) and [www.example.com](https://www.example.com) may be configured separately in DNS. For instance, the root domain might point directly to a server IP, while the www subdomain might use a CDN or CNAME. Query the exact address you use to access your site, not just the root domain.

3. How to Interpret A Records?

A records are the most common type in website DNS configuration. They resolve a domain to an IPv4 address. For example:

www.example.com
↓
203.0.113.20

When a user visits www.example.com, DNS returns 203.0.113.20, and the browser then connects to that IP's server.

When checking A records, the most important thing is whether the IP is correct

Suppose your site just moved to a new server with IP 203.0.113.20, but the DNS lookup still shows 198.51.100.15. This means the current resolution still points to the old server. You should then check:

• Whether the DNS record was actually modified successfully

• Whether you modified it at the correct DNS provider

• Whether the TTL cache hasn't expired

• Whether you queried the correct hostname

If the lookup now shows the new IP, the DNS layer is essentially switched, and you can continue troubleshooting the server, website code, or cache.

Is it normal for a domain to have multiple A records?

Yes. Some websites use multiple IPs for load balancing, failover, or DNS round-robin. For example:

203.0.113.20
203.0.113.21
203.0.113.22

Seeing multiple A records doesn't mean an error. What matters is whether these IPs belong to your infrastructure and whether any old addresses are still present but no longer in use.

4. How to Interpret CNAME Records?

The main difference between CNAME and A records is that CNAME points to another domain rather than directly to an IP.

For example:

www.example.com
↓
abc123.cdn.example.net
↓
CDN node IP

This setup is common with CDNs, SaaS platforms, cloud services, and third-party hosting.

Why do CDNs often use CNAME?

Because CDN node IPs aren't static. Providers can dynamically route the same CNAME to different edge nodes based on user location, network conditions, and node load. If you hardcode an A record, this flexibility is lost. So when integrating a CDN, you'll often see requirements like:

www.example.com
CNAME
abc123.provider.net

How to determine if CNAME is active?

The most direct way is to query the actual business domain. Suppose the CDN console requires:

www.example.com
CNAME
abc123.provider.net

Then the DNS lookup should show the corresponding CNAME target. If it still shows an old record or no CNAME at all, the DNS switch may not be complete.

Common reasons include:

• Cache hasn't updated after DNS changes

• Incorrect CNAME host record

• The domain actually uses a different DNS hosting service

• Conflicting existing resolution rules

• You modified the root domain but actually access www

After integrating a CDN, don't just rely on the console showing "configured successfully."

A more reliable approach is to query the actual business domain to confirm that public DNS returns the CDN-provided CNAME.

5. How to Interpret MX Records?

While A and CNAME records are mainly for website access, MX records handle email. MX stands for Mail Exchange, and it tells the internet: which mail server should handle emails sent to this domain.

For example:

example.com

MX 10 mail1.example.com
MX 20 mail2.example.com

Here, mail1.example.com and mail2.example.com are the mail servers.

What does the number before MX mean?

The number indicates priority.

Generally:

The lower the number, the higher the priority.

For example:

MX 10 mail1.example.com
MX 20 mail2.example.com

It will typically try mail1.example.com first, and if that server is unavailable, it will try other MX servers based on configuration.

However, you should always follow the record requirements provided by your email service provider and not modify the priority yourself.

When business email isn't receiving messages, what should you focus on with MX?

If your business email suddenly stops receiving external messages, check:

• Whether the MX record exists

• Whether the mail server address is correct

• Whether old email provider records are still present

• Whether the MX priority matches the provider's requirements

• Whether you recently changed DNS or email platforms

For example, if you switched from email provider A to B but didn't remove the old MX records, some emails may fail to deliver. This kind of issue isn't always obvious in the email console, but a DNS lookup makes it clearer.

6. How to Interpret TXT Records?

TXT records are often the hardest for beginners to understand.

Because the query result isn't as simple as an A record; it's a long string of text.

For example:

v=spf1 include:_spf.example.com ~all

This is typically an SPF email verification record.

TXT records have many uses, including:

• SPF

• DKIM

• DMARC

• Google Search Console verification

• Microsoft 365 domain verification

• Third-party SaaS platform verification

• SSL or domain ownership verification

So when querying TXT, you don't need to understand every parameter immediately.

In most cases, what matters is:

Whether the queried value exactly matches what the platform asked you to add.

For example, if a platform requires:

google-site-verification=abc123xyz

If the DNS lookup doesn't show this content at all, the record may not have been published correctly.

If it appears but verification still fails, check:

• Whether the TXT content is missing characters

• Whether there are extra spaces or quotes

• Whether the host record is correct

• Whether it was added to the wrong domain

• Whether DNS is still propagating

7. What's the Difference Between A, CNAME, MX, and TXT?

Looking at these record types together makes it clearer.

To remember simply:

• Website IP issues: check A first

• CDN or alias resolution: check CNAME first

• Email sending/receiving issues: check MX first

• Email authentication or domain verification: check TXT first

This way, when troubleshooting, you won't be overwhelmed by a pile of DNS records.

8. Why Does the Lookup Still Show Old Records After I've Modified DNS?

This is a very common issue in domain resolution.

You saved the changes in the backend, but external queries still show old records—this doesn't necessarily mean the operation failed.

1. DNS cache hasn't expired

DNS records typically have a TTL, which is the cache duration.

For example:

TTL = 3600

This means the DNS cache may be stored for a certain period.

After modifying resolution, different regions and recursive DNS servers won't update their caches simultaneously, so you might see:

• Some places return new records

• Others still return old records

This is common during DNS transitions.

2. You modified the wrong DNS provider

Where you buy the domain and where DNS is actually hosted are two different things.

For example, the domain was purchased at registrar A, but the NS records have been changed to DNS provider B.

If you're still modifying records in registrar A's panel, the changes may not take effect externally.

In this case, query the domain's NS records to confirm which provider is authoritative.

3. You queried the wrong hostname

For example, you modified:

www.example.com

But you queried:

example.com

These are different DNS records.

Similarly, api.example.com, mail.example.com, shop.example.com should each be queried separately.

4. Local cache hasn't updated

If online DNS lookup shows new records, but your computer still accesses the old server, the issue may not be with authoritative DNS but with local cache.

Common cache locations include:

• Operating system DNS cache

• Browser cache

• Router cache

• Recursive DNS used by your local network

In this case, try a different network or DNS server to see if results differ.

9. For Website and Email Issues, Follow This DNS Troubleshooting Order

If your website is down or CDN isn't working, follow this order:

Website access issue
↓
Query A / CNAME
↓
Confirm resolution target is correct
↓
Check if NS belongs to current DNS provider
↓
Check TTL and propagation
↓
After DNS is normal, continue checking server or CDN

For business email issues, this order is better:

Email issue
↓
Query MX
↓
Confirm mail server
↓
Query TXT
↓
Verify SPF / DKIM / DMARC
↓
Then check email platform configuration

The benefit of this approach is that you first confirm the basic resolution layer, then move on to servers, CDN, email systems, or website code, avoiding wasted time in the wrong direction.

DNS lookup itself isn't complicated; the challenge is knowing which record relates to your current problem. If your website resolves to the wrong server, focus on A; after integrating a CDN, focus on CNAME; if business email isn't receiving messages, check MX first; for SPF, DKIM, or third-party domain verification, focus on TXT.

If you've just modified resolution, don't just rely on the backend showing "saved successfully." Confirm via actual DNS lookup that public networks return the correct records—that's when the step is truly complete. For site owners and operators, developing the habit of checking DNS before other troubleshooting steps will make many website access, CDN integration, and business email issues easier to pinpoint.

Related Q&A

1. Q: How big is the difference between TTL 300 and 86400? Should I lower TTL before changing resolution?
   A: The difference is significant. TTL=300 means the record is cached for only 5 minutes on recursive DNS, so changes propagate quickly; TTL=86400 means waiting 24 hours for cache expiry. If you plan to change IPs or switch CDN, it's recommended to lower TTL to 300 or 600 a day or two in advance, so the impact window is smaller during the actual switch. After resolution stabilizes, you can raise TTL back to normal to reduce DNS query load.

2. Q: The DNS lookup returns a new IP, but some users still access the old server. Is DNS still propagating?
   A: It's likely that local recursive DNS caches haven't updated, not that authoritative DNS hasn't propagated. Different ISPs have different refresh policies; some follow TTL, others force longer caching. You can test with public DNS like 1.1.1.1 or 8.8.8.8. If public DNS returns the new IP, the authoritative side is fine. The rest is waiting for caches to expire naturally or having users manually flush their local DNS cache.

3. Q: Can I set a CNAME for the root domain (@ record)? Why do some registrars disallow it?
   A: According to DNS protocol standards, the root domain (example.com itself) can theoretically have a CNAME, but many registrars and hosting platforms restrict it because the root domain also needs SOA and NS records, which conflict with CNAME. If the root domain must point to a CDN or third-party service, you typically use an A record to bind the IP directly, or use "CNAME flattening" (supported by some DNS providers). For ordinary users, it's not recommended to force a CNAME on the root domain.

4. Q: I found the MX record, but emails still aren't arriving. What could be wrong?
   A: If MX returns the correct mail server address, it only means DNS routing is fine. Other common blind spots include: whether the mail server's firewall allows ports 25, 465, 587; whether the receiving domain has completed domain ownership verification in the email platform; whether SPF/DKIM/DMARC TXT records strictly match the sending IP; and whether the recipient's mail gateway has anti-spam policies blocking test emails. DNS only confirms routing; server policies and content filtering are another layer.

5. Q: Do A and CNAME records conflict if both exist? How do I know which one takes effect?
   A: Yes, they conflict. RFC standards state that the same hostname cannot have both A and CNAME records; CNAME must point to another domain and cannot coexist with any other record type. If your backend allows adding both, typically only the CNAME takes effect, and the A record is ignored or causes unstable resolution. If you see both A and CNAME for the same hostname, the configuration is non-compliant, and you should delete the redundant one.

6. Q: Whois information and DNS records are different data. Can DNS lookup replace whois?
   A: No, they query entirely different things. DNS lookup returns technical resolution records (A, CNAME, MX, etc.) to answer "what service does the domain point to"; whois returns registration information (registrant, registrar, expiration date, NS record source) to answer "who owns the domain and when does it expire." When troubleshooting domain suspension or resolution issues, first check DNS for technical status, then check whois to see if the domain has expired or is in serverHold status. Both lines are necessary.