When email isn't being delivered or received, one of the most common culprits is an incorrect or missing MX record. MXToolbox is a free tool used by developers and server administrators to comprehensively inspect email DNS configurations — covering MX, SPF, DKIM, DMARC, Blacklists, and live SMTP testing.
What Is an MX Record?
An MX (Mail Exchanger) record is a DNS record that tells the world which mail server accepts email for your domain. When someone sends email to [email protected], the sender's mail server looks up the MX record for company.com to find the receiving server's address. A missing or incorrect MX record causes immediate email bounces.
How to Check Your MX Record with MXToolbox
- Visit mxtoolbox.com
- Enter your domain in the search box, e.g.
company.com - Select MX Lookup and press Enter
- The tool displays all MX records with their Priority values
- Verify the Hostname is correct — lower Priority number = receives email first
Checking MX Records from the Command Line (dig MX, nslookup)
Besides the MXToolbox website, you can check MX records directly from your own terminal without relying on any external service. This is handy when you need speed or want to query a specific DNS server. The two main commands are dig (Linux/macOS) and nslookup (Windows and every platform). Both return the same data an MXToolbox MX Lookup would, but the query runs from your machine.
Check MX records with dig in short form, showing only the values you care about:
dig MX company.com +short
# Example output:
# 10 mail.company.com.
# 20 mail2.company.com.See the full result including TTL and all sections:
dig MX company.com
;; ANSWER SECTION:
company.com. 3600 IN MX 10 mail.company.com.
company.com. 3600 IN MX 20 mail2.company.com.On Windows or any machine without dig, use nslookup instead:
nslookup -type=mx company.com
# Or specify a DNS server to bypass cache:
nslookup -type=mx company.com 8.8.8.8To dig deeper, query the authoritative nameserver directly to avoid stale cached values:
dig MX company.com @ns1.yourhost.comHow to Read MX Results (Priority, Multiple Records, Fallback)
When an MX lookup returns several lines, the number before each hostname is the Priority (or preference). A lower number is chosen first. In the example above, 10 mail.company.com receives mail first, while 20 mail2.company.com is a backup that takes over when the first server is offline or full.
- Lowest priority = primary server — the sender's mail server always tries this one first.
- Higher priority = fallback — used when the primary can't respond, so mail isn't lost during maintenance.
- Equal priority values — the system load-balances randomly across those servers.
- A single MX — works fine but has no fallback; if that server goes down, mail queues on the sender's side until it returns.
Important tip: the hostname in an MX record must be an A/AAAA record that resolves to a real IP — it must not point to a CNAME. The RFCs forbid MX records pointing at a CNAME, and this is a very common reason some servers reject mail.
Problems MX Checks Catch (Blacklist, Reverse DNS/PTR, SPF, Open Relay)
A thorough MX check tells you more than whether the record is right or wrong — it surfaces the underlying issues that push mail to Spam or get it rejected:
IP Listed on a Blacklist (RBL/DNSBL)
If your mail server IP appears on a blacklist such as Spamhaus or Barracuda, mail is rejected or filed in Junk immediately. An MX check reports how many lists you're on and links to request delisting.
Reverse DNS / PTR Mismatch
Receiving servers often verify that the sending IP has a PTR record matching its hostname (FCrDNS). A missing or mismatched PTR lowers your reputation score. Check it with dig -x YOUR.IP +short.
SPF Missing or Syntactically Wrong
An SPF record that omits the sending IP, or has multiple records stacked, makes receivers treat mail as spoofed. MX checks warn when SPF is too loose (+all) or exceeds 10 DNS lookups (PermError).
Server Acting as an Open Relay
An SMTP test checks whether your server accepts and forwards mail for outsiders without authentication. An open relay is quickly abused to send spam and gets blacklisted fast — close it immediately.
Steps to Fix an Incorrect MX Record
When an MX check flags a problem, follow these steps to fix the root cause:
- Confirm the correct values first — check with your email/hosting provider which hostname and priority are correct (for AsiaGB it's
mail.yourdomain.comwith priority10). - Open DNS Management — DirectAdmin → DNS Management, or the actual nameserver the domain uses (run
dig NS company.comto see who controls the zone). - Remove the wrong old MX, then add a new one whose hostname resolves to a real A record, not a CNAME.
- Adjust SPF to cover your IP —
v=spf1 +a +mx +ip4:YOUR.IP ~alland make sure there is only one SPF record. - Lower the TTL temporarily to 300 seconds before editing so the new value propagates quickly, then set it back to 3600 once everything is stable.
- Wait for propagation and re-check — run
dig MX company.com +shortfrom several networks, or use a DNS Propagation Check until the value is consistent worldwide.
Other Useful MXToolbox Features
Email Health Check
Checks everything at once: MX, SPF, DKIM, DMARC, Blacklists, Reverse DNS — recommended before going live with any new domain setup.
Blacklist Check
Checks whether your server IP appears on any email blacklists. A blacklisted IP causes email to be rejected or land in Spam.
SMTP Test
Tests real SMTP server connectivity — shows Banner, EHLO, STARTTLS responses. Useful for debugging when email sending fails completely.
DNS Propagation Check
Verifies whether your newly changed MX records have propagated to DNS servers worldwide. Essential after changing nameservers.
Common Issues and How to Fix Them
MX Record Missing or Empty
Go to DirectAdmin → DNS Management → add an MX record. The standard value for AsiaGB Hosting is mail.yourdomain.com with Priority 10.
MX Points to the Wrong Server
Verify that the hostname in your MX record resolves to the correct server IP (use A Lookup on MXToolbox to check).
SPF Doesn't Cover Your Server IP
Add your server IP to the SPF record: v=spf1 +a +mx +ip4:YOUR.IP ~all
Tip: After modifying any DNS record, wait 24–48 hours for full propagation before re-testing. Setting a lower TTL value (e.g., 300 seconds) speeds up propagation but increases DNS query load on your server.
Alternatives to MXToolbox
- dnschecker.org — Check DNS propagation from multiple global locations
- mail-tester.com — Test spam score alongside SPF/DKIM verification
- Google Admin Toolbox — Check DNS records through Google's infrastructure
- dig (command line) —
dig MX company.comin Terminal for quick lookup
Frequently Asked Questions (FAQ)
Where can I check MX records for free?
Several options are free: the MXToolbox website (mxtoolbox.com), dnschecker.org, Google Admin Toolbox, or the command line with dig MX yourdomain.com +short on Linux/macOS and nslookup -type=mx yourdomain.com on Windows. All are free and return matching results.
How many MX records should I have?
At least one works, but two or more is recommended, each with a different priority (e.g., 10 and 20), so a backup can accept mail when the primary server is offline — preventing bounces during maintenance or outages.
How long after changing an MX record until it works?
It depends on the old record's TTL. Generally allow 24–48 hours for full global propagation. If you lower the TTL (to 300 seconds) before editing, the change propagates within minutes. Track progress with a DNS Propagation Check.
Why does email still bounce when the MX record is correct?
The cause is usually something other than the MX itself — a blacklisted IP, mismatched Reverse DNS/PTR, an SPF record that doesn't cover the sending IP, or an MX hostname pointing at a CNAME. Run an Email Health Check to find the real cause.
Email Problems? AsiaGB Support Can Help
Our team helps diagnose MX records and DNS configuration for all Hosting customers. Submit a ticket 24/7 and we'll respond promptly.
Submit Support Ticket