How to Check Your DNS and MX Records Are Set Up Right

You've finished configuring DNS — but how do you know it's correct? Often when a site won't load or email won't send, the root cause is a single record that was mistyped or forgotten. Checking your DNS and MX records after setup is just as important as the setup itself. This article shows you how to check, using both online tools and the command line.

The DNS records you need to check

Record	Role	What you should see
A	Points the domain to the server's IPv4	An IP like 203.0.113.10
AAAA	Points the domain to IPv6	An IPv6 like 2400:cb00::1 (if any)
CNAME	Makes one name point to another	Target domain, e.g. www → root
MX	Specifies the mail-receiving server	Mail server name + priority value
TXT	Stores text such as SPF, verification	SPF, DKIM, service verification
NS	Specifies the nameservers managing the domain	The provider's ns1/ns2

Method 1 — Check DNS with an online tool

The easiest method for anyone who'd rather not open a terminal is an online DNS checker. Just type in a domain name and the tool pulls every record type, showing where each value points.

A domain health tool like dnsxray.com bundles DNS, mail server, SSL and WHOIS checks in one place — a single lookup shows your A, MX, NS and TXT records together. It's ideal for an overview check of whether every record is present and pointing correctly, with no commands to memorize.

Method 2 — Check DNS from the command line

If you want more detail or you're debugging a specific issue, dig (macOS/Linux) and nslookup (all systems) are the standard tools.

Check the A record

dig example.com A +short
# or
nslookup example.com

Check the MX record

dig example.com MX +short
# Result: 10 mail.example.com.

Check TXT (including SPF)

dig example.com TXT +short

Check the NS record

dig example.com NS +short

How to check MX records and the email system

A correct MX record is only "half" of working email. The other half is the anti-spoofing records — you need to check all four.

1. MX record

It must point to the correct mail server with the priority ordered right (lower number = first). If the MX points to the wrong place or is missing, incoming mail bounces immediately.

2. SPF (TXT record)

SPF declares which servers are allowed to send mail on your domain's behalf. Example: v=spf1 include:_spf.example.com ~all. There should be only one SPF record.

3. DKIM (TXT record)

DKIM is a digital signature attached to each message, which recipients use to verify the mail wasn't altered in transit. Check it under the selector name your mail provider specifies.

4. DMARC (TXT record)

DMARC tells recipients what to do with mail that fails SPF/DKIM. Check it at _dmarc.example.com; a typical value is v=DMARC1; p=quarantine;

Understanding DNS Propagation in Depth

When you change a nameserver or update an important record, DNS propagation is the process by which recursive resolvers around the world refresh their cache to reflect the new value. Understanding this process helps you predict how long to wait — and where to look.

Factors that control propagation speed

• TTL (Time-to-Live) — a low TTL (300 seconds) means resolvers re-fetch every 5 minutes; a high TTL (86,400 seconds = 1 day) lets them hold the old value for up to 24 hours. Before changing DNS you should lower the TTL at least 24–48 hours in advance.
• Resolver layers — your ISP's resolver, your company resolver, and public resolvers (8.8.8.8, 1.1.1.1) each maintain separate caches, so they may see the new value at different times.
• Nameserver change — swapping NS records requires the registry to update first (up to 24–48 hours), and no amount of TTL lowering can speed that up.

Check propagation from multiple points at once

Rather than querying only your own resolver (which may still cache the old value), ask several different DNS servers:

# Query Google Public DNS (8.8.8.8)
dig example.com A @8.8.8.8 +short

# Query Cloudflare DNS (1.1.1.1)
dig example.com A @1.1.1.1 +short

# Query OpenDNS (208.67.222.222)
dig example.com A @208.67.222.222 +short

# If all three agree, propagation is complete

See remaining TTL with dig

# Show full output including TTL
dig example.com A
# The second column (number before IN A) is the remaining TTL in seconds

Checking DKIM in Detail and Troubleshooting It

DKIM is more complex than SPF because the record name starts with a "selector" that each mail provider defines differently. Here is how to find the correct selector and verify the record.

Find the selector name first

The selector lives in the header of any email your system sends. Forward a test message to a mailbox you can read, then view the raw headers and find the line starting DKIM-Signature:. For example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
# The value after s= is the selector — "mail" in this example

Check the DKIM record with dig

# Format: [selector]._domainkey.[domain]
dig mail._domainkey.example.com TXT +short

# Google Workspace often uses the selector "google"
dig google._domainkey.example.com TXT +short

# A correct result starts with "v=DKIM1; k=rsa; p=..."

Common DKIM errors

Advanced dig Techniques for Debugging Email and Web Issues

When problems get complex — mail bouncing, or the site loading in some countries but not others — dig has advanced options that go much deeper than a basic lookup.

Fetch all record types at once

dig example.com ANY +noall +answer

Trace the full delegation path

# Shows the resolution path from the root down
dig example.com +trace

# Useful for verifying NS delegation is correct
# and that glue records are in place

Check reverse DNS (PTR record)

# For the IP address 203.0.113.10
dig -x 203.0.113.10 +short

# The PTR should match the mail server's hostname
# A missing or mismatched PTR causes outgoing mail to be blocked by spam filters

Check the SOA record to see the zone version

dig example.com SOA +short
# The third number is the serial — incremented every time the zone changes
# If the secondary nameserver's serial is behind, zone transfer has a problem

Comparing DNS Check Tools

There are several types of DNS checking tools — choose the right one for your situation.

Common DNS / MX problems

Symptom	Common cause
Site won't load	A record points to the wrong IP, or NS is still the old one
www works but the root domain doesn't (or vice versa)	Forgot to set the A or CNAME for the other one
Incoming mail never arrives	MX points to the wrong place, or there is no MX record
Every outgoing email lands in spam	No SPF or DKIM
Multiple SPF records	The domain has two stacked SPF TXT records — they must be merged into one

Frequently asked questions

Q: After setting DNS, how long before a check shows it?

It depends on the TTL — with a low TTL (300 seconds) you'll see the new value within minutes; with a high TTL (1 day) you may wait longer. Meanwhile different DNS servers may still show the old value.

Q: What's the difference between dig and nslookup?

They work similarly — dig gives more detailed output and is favored by system administrators, while nslookup ships with Windows and is simpler for basic checks.

Q: My MX is correct but mail still lands in spam — why?

MX only governs receiving mail. Your outgoing mail landing in others' spam comes from missing SPF/DKIM/DMARC — you need to check those TXT records too.

Q: Where do I edit DNS?

In the DNS Management panel of the provider that runs your domain's nameservers. With AsiaGB Hosting you can edit it in DirectAdmin, or open a ticket for the team to help.