MX (Mail eXchange) records and mail delivery health checks

1. MX Records

This block lists the MX records returned by your nameservers, including priority and target hostname, and often the resolved IPs.

Why this matters

If MX records are missing or pointing to the wrong hostnames, remote mail servers do not know where to send e-mail for your domain. Everything else in the MX section depends on this basic list.

How DNSprobe checks it

DNSprobe queries all authoritative nameservers for MX at your domain and displays the unique set of records it finds. It also notes when some uncommon MX records appear only on a subset of servers.

Typical problems detected

• No MX records at all for the domain, forcing senders to fall back to bare A/AAAA records if allowed.
• MX records pointing to hostnames that do not exist or are obviously placeholders.
• MX records left over from a previous provider that no longer accepts mail for your domain.

Best practices

• Always define explicit MX records, even if mail is handled by the same server as your website.
• Use clear, dedicated hostnames for mail servers (for example, mail.example.com or mx1.example.com).
• Remove obsolete MX entries when you migrate to a new mail platform.

2. Different MX records at nameservers

This test checks whether all your authoritative nameservers publish the same set of MX records.

Why this matters

If different nameservers list different MX entries, some senders will deliver mail to one server while others try a different path. This can cause random bounces, greylisting behaviour or unexpected routing.

How DNSprobe checks it

DNSprobe asks each nameserver for MX records and compares the results record by record. It reports whether the sets match exactly or if any server has missing or extra MX entries.

Typical problems detected

• One nameserver still advertises an old MX host from a previous configuration.
• Hidden primary vs. public secondary DNS zones that are not synchronized for MX records.
• Manual edits on individual nameservers instead of using a central zone file.

Best practices

• Ensure all authoritative nameservers serve the exact same zone data for MX.
• Use automatic replication or a provider that manages the zone centrally.
• After any MX change, verify that every NS answers with the new records.

3. MX name validity

This test validates the syntax of your MX target hostnames and checks for common mistakes.

Why this matters

MX targets must be fully qualified domain names, not bare labels, not e-mail addresses and not IP literals. Invalid names can confuse senders or be ignored altogether.

How DNSprobe checks it

DNSprobe inspects each MX target to ensure it is a valid hostname, does not exceed length limits and does not contain obvious typos like spaces or "@" symbols.

Typical problems detected

• MX pointing directly to an e-mail address (for example, [email protected]).
• MX targets that are not fully qualified or contain unsupported characters.
• Accidental extra dots or truncated hostnames that do not match real DNS entries.

Best practices

• Always use valid, fully qualified hostnames as MX targets.
• Avoid generic or temporary names; use stable hostnames that match your TLS certificates.
• Let your DNS or mail provider generate MX hostnames when possible to avoid typos.

4. MX IPs are public

This test verifies that the IP addresses behind your MX hostnames are routable on the public Internet.

Why this matters

Mail servers must be reachable from other networks. If MX hosts resolve to private or reserved IP ranges, external systems cannot deliver e-mail to you.

How DNSprobe checks it

DNSprobe resolves A and AAAA records for each MX hostname and checks whether the resulting addresses fall into private, loopback or otherwise non-routable ranges.

Typical problems detected

• MX records pointing to RFC1918 private IPs such as 10.x.x.x or 192.168.x.x.
• MX hostnames that resolve only to IPv6 link-local or loopback addresses.
• Temporary internal IPs accidentally published to public DNS.

Best practices

• Publish only globally routable IPs for MX hostnames.
• Separate internal and external DNS views if you need private MX addresses internally.
• Coordinate with your ISP or hosting provider to ensure reverse DNS also matches these public IPs.

5. MX CNAME Check

This test verifies that your MX targets are not CNAME records, which is forbidden by DNS standards.

Why this matters

According to RFCs, MX records must point directly to A/AAAA records, not to aliases. While some resolvers will follow CNAMEs, others may treat them as errors, causing inconsistent behaviour.

How DNSprobe checks it

DNSprobe performs MX lookups and then checks the record type of each MX target. If any of them is a CNAME, the report flags it.

Typical problems detected

• MX target hostname defined only as a CNAME to another host.
• Indirect CNAME chains where the MX points to a CNAME which then points to another CNAME.
• Migration setups where CNAMEs were used for convenience instead of direct A/AAAA records.

Best practices

• Define MX targets as hostnames that have direct A/AAAA records.
• If you need indirection, use separate hostnames that you can repoint at the A/AAAA level instead of relying on CNAMEs.
• Review MX hostnames whenever you change underlying mail infrastructure.

6. MX A request returns CNAME

This test checks whether A/AAAA lookups for your MX hostnames unexpectedly return CNAMEs.

Why this matters

Even if the MX itself is not a CNAME, some DNS setups respond to A/AAAA queries with a CNAME first. This can confuse certain resolvers, monitoring tools or TLS setups.

How DNSprobe checks it

DNSprobe sends A/AAAA queries for each MX hostname and inspects whether the first answer is a direct address or a CNAME that then points elsewhere.

Typical problems detected

• MX hostnames that resolve via extra CNAME hops instead of direct A/AAAA records.
• Load-balancing or CDN-style configurations reused for mail hosts where they are not appropriate.
• Legacy indirections left in place after moving the real mail server.

Best practices

• Prefer simple, direct A/AAAA records for MX hostnames.
• Avoid sharing web/CDN hostnames with mail service endpoints.
• If you must use a CNAME internally, hide that complexity behind a stable external A/AAAA record.

7. MX is not IP

This test confirms that your MX records do not point directly to numeric IP addresses.

Why this matters

MX records must reference hostnames, not raw IP literals. Using IP addresses breaks some DNS rules and removes flexibility because you cannot later change the IP without editing all MX records.

How DNSprobe checks it

DNSprobe inspects each MX target and flags any value that looks like an IPv4 or IPv6 address rather than a hostname.

Typical problems detected

• MX records configured directly with IPv4 addresses.
• MX records configured directly with IPv6 addresses.
• Mixed configurations where some MX are hostnames and others are IPs.

Best practices

• Always point MX records to hostnames that you control.
• Change the IP by updating the A/AAAA record instead of the MX itself.
• Use DNS names that match your TLS certificates and reverse DNS.

8. Number of MX records

This test counts how many distinct MX entries your domain publishes and comments on redundancy.

Why this matters

Having only one MX host creates a single point of failure. Additional MX entries with proper priorities provide backup routes for incoming mail.

How DNSprobe checks it

DNSprobe counts the distinct MX records in the zone and highlights cases where there is only one entry or an unusually large number.

Typical problems detected

• Only one MX record, meaning no redundancy if that server goes down.
• Multiple MX entries that all resolve to the same single machine, providing little real redundancy.
• Very large numbers of MX entries with unclear priority planning.

Best practices

• Use at least two MX records on independent infrastructure when possible.
• Assign lower preference numbers (higher priority) to primary servers and higher numbers for backup servers.
• Ensure backups are truly separate machines or providers, not aliases of the same host.

9. Mismatched MX A

This test compares the A/AAAA records for each MX hostname as seen from different nameservers.

Why this matters

If different nameservers map the same MX hostname to different IPs, mail can be routed unpredictably or even towards the wrong server.

How DNSprobe checks it

DNSprobe resolves each MX hostname via every authoritative nameserver and compares the returned IP sets to see if they match.

Typical problems detected

• Out-of-sync A/AAAA records between DNS servers for the same MX hostname.
• Hidden internal IPs leaking from one nameserver but not the others.
• Partial migration where only some NS were updated with the new mail server IP.

Best practices

• Maintain identical A/AAAA records for MX hostnames across all authoritative nameservers.
• Use a single source of truth for DNS and propagate changes automatically.
• After IP changes, verify that all NS respond with the same new addresses.

10. Duplicate MX A records

This test looks for situations where different MX hostnames resolve to the exact same IP address.

Why this matters

Using multiple MX names that all point to one single server does not provide real redundancy. It can also confuse diagnostics and load-balancing logic.

How DNSprobe checks it

DNSprobe resolves all MX hostnames, groups them by IP and reports cases where several names share the same address.

Typical problems detected

• Two or more MX records that all resolve to the same lone mail server.
• Old MX hostnames kept online but still pointing to the same IP after consolidation.
• Misleading priority values that suggest redundancy where none exists.

Best practices

• When advertising multiple MX, back them with distinct servers and IPs.
• If you use several MX names for branding, consider real load-balancing or clustering behind them.
• Periodically review MX records to remove unused names that still point to active servers.

11. Reverse MX A records (PTR)

This test checks whether the IPs behind your MX records have reverse DNS (PTR) entries and whether they look consistent with the hostname.

Why this matters

Many receiving servers use PTR as one of several signals for spam and abuse filtering. Missing or mismatched reverse DNS will not always block mail, but it can hurt reputation and deliverability.

How DNSprobe checks it

DNSprobe performs PTR lookups on each MX IP, then displays the PTR hostname and compares it loosely with your MX name to see if they appear related.

Typical problems detected

• No PTR record defined for the MX IP address.
• PTR pointing to a generic ISP name unrelated to your domain.
• PTR pointing to a hostname that does not resolve back to the same IP (lack of forward–reverse consistency).

Best practices

• Configure PTR records that reference a hostname you control, usually the same name (or very close) as your MX host.
• Ensure the PTR hostname has a matching A/AAAA record pointing back to the same IP.
• Align PTR, MX hostname and SMTP greeting with each other to maximise e-mail deliverability.

12. Test MX records manually from your own terminal

The MX section in DNSprobe checks which mail exchangers are published for your domain, whether they use public IPs, and if reverse DNS is correctly configured. You can reproduce most of these checks from a terminal by querying MX and A records and optionally testing SMTP connectivity on port 25.

Linux: using dig (BIND utilities) and nc

On most Linux distributions, the dig and nc (netcat) tools are available in the default repositories. The commands below show the MX records for your domain, resolve the hostnames used as MX targets, and optionally test whether the main mail host accepts SMTP connections on port 25:

                dig example.com MX
                dig example.com MX +noall +answer
    
                # List MX records and their preference values for example.com    
                dig mail.example.com A +noall +answer
    
                # Resolve the A record of your mail host (for example mail.example.com), then optionally test TCP port 25    
                nc -vz mail.example.com 25
        

macOS: using dig and nc from the built-in tools

macOS ships with dig and nc in the standard command-line tools. Open Terminal and run the same commands as on Linux to display MX records, resolve the mail host and check basic SMTP reachability on port 25:

                dig example.com MX
                dig example.com MX +noall +answer
    
                # List MX records and their preference values for example.com    
                dig mail.example.com A +noall +answer
    
                # Resolve the A record of your mail host (for example mail.example.com), then optionally test TCP port 25    
                nc -vz mail.example.com 25
        

Windows: using nslookup and PowerShell

On Windows, you can use nslookup to query MX and A records, and PowerShell’s Test-NetConnection cmdlet to test whether the MX host is reachable on port 25. Run the following commands from a Command Prompt or PowerShell window:

                nslookup -type=MX example.com
    
                REM Show the MX records and their priorities for example.com    
                nslookup -type=A mail.example.com
    
                REM Resolve the A record of your mail host (for example mail.example.com), then test TCP port 25 with Test-NetConnection    
                Test-NetConnection mail.example.com -Port 25
        

Important: only test mail hosts and domains that you own or are authorised to analyse. Repeated SMTP connectivity tests or port scans against third-party systems without permission may be treated as abusive behaviour by some providers.