Why do external senders keep delivering mail to my old server after I updated my MX records?

This usually happens due to high Time To Live (TTL) values cached by external recursive DNS resolvers. If your old MX record had a 24-hour TTL, remote mail servers will continue referencing the cached entry until that timer expires.

Can an MX record point directly to an IP address instead of a hostname?

No. Standard DNS specifications require that the target of an MX record must be a domain name, never a raw IPv4 or IPv6 address. You must define a hostname in your zone file and assign that hostname to an A or AAAA record.

What does a 5.4.1 Relay Access Denied error mean during troubleshooting?

This error indicates that the receiving mail server successfully accepted the connection on port 25, but refused to process or forward the message because it does not recognize the destination domain as a valid recipient or local mailbox.

How do priority numbers affect mail delivery when I have multiple MX records?

Sending mail servers attempt delivery starting with the lowest numerical priority value (e.g., priority 10). If that server is offline or unreachable, the sender falls back to higher numerical values (e.g., priority 20) in order of preference.

Why is it dangerous to use CNAME records for mail exchangers?

RFC standards prohibit CNAME targets in MX records because intermediate alias resolution introduces ambiguity, lookup delays, and compatibility failures with strict MTAs across the global email infrastructure.

Sysadmin Email Troubleshooting DNS MX: Fix Outages Fast

When corporate email suddenly stops flowing, the root cause is frequently misconfigured Domain Name System (DNS) mail exchanger records or broken authentication chains. As a systems administrator, you need a methodical approach to isolate whether the failure lies in public name resolution, routing preferences, or receiving server availability. By leveraging reliable diagnostic workflows and tools like the MX Lookup utility on XiaTools—which instantly queries authoritative nameservers to display active mail servers, priorities, and potential misconfigurations—you can pinpoint and resolve routing bottlenecks in minutes rather than hours.

Understanding the Email Routing Chain and DNS

When a sender outside your organization dispatches a message to user@example.com, their mail transfer agent (MTA) performs a series of DNS lookups to determine where to deliver the payload. The sending server queries the root servers, then the Top-Level Domain (TLD) servers for .com, and finally your domain's authoritative nameservers to fetch the MX records.

Your MX records dictate the mail servers authorized to accept inbound mail for your domain, complete with an integer priority value where a lower number indicates a higher preference. If these records point to decommissioned IP addresses, fail to resolve, or lack proper backup routes, messages bounce with delivery status notifications (DSNs) such as 5.4.1 Relay Access Denied or 4.4.1 Connection Timed Out.

The Anatomy of an MX Record

An MX record consists of a host name, a preference number, and a target mail server. For instance, a resilient mail architecture using documentation domains might look like this:

example.com.     3600    IN    MX    10 mail-primary.example.com.
example.com.     3600    IN    MX    20 mail-backup.example.com.

Beyond basic routing, modern email delivery relies heavily on auxiliary DNS records that validate sender authenticity. Without corresponding SPF, DKIM, and DMARC records, messages routed correctly by your MX configuration may still land straight in recipient spam folders or be rejected outright by strict receiving policies at major cloud providers.

Step-by-Step Diagnostic Workflow

When faced with an inbound email outage, follow this structured diagnostic sequence to isolate the failure point systematically.

Step 1: Query Authoritative MX Records

Start by checking what the public internet sees when querying your domain's mail exchangers. Avoid relying solely on your local recursive resolver, as DNS caching can mask recent changes.

Using the command line, query public resolvers directly using dig:

dig example.com MX +trace

Alternatively, query Google's public DNS at 8.8.8.8 or Cloudflare at 1.1.1.1:

dig @8.8.8.8 example.com MX

Sample output from a healthy lookup:

; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 example.com MX
;; global options: +cmd
;; Gotswering:
;; ->>HEADER<<- opcode: QUERY, NOERROR
;; query section:
;;   example.com. IN MX
;; ANSWER SECTION:
example.com.    300 IN MX   10 mail.example.com.

;; ADDITIONAL SECTION:
mail.example.com. 300 IN A 192.0.2.25

If this returns SERVFAIL, NXDOMAIN, or points to outdated infrastructure, you have immediately isolated a DNS publication error.

Step 2: Validate Target IP Addresses and Reachability

Once you have the hostnames from your MX records, verify that those hostnames resolve to valid, reachable IPv4 (A) or IPv6 (AAAA) addresses.

nslookup mail.example.com

Next, test network layer connectivity to port 25 (SMTP) on those target IP addresses from an external network or a test harness using nc or telnet:

nc -zv 192.0.2.25 25

If the TCP handshake times out, check your corporate firewall rules, perimeter security gateways, and cloud provider security groups to ensure inbound port 25 is not blocked.

Step 3: Simulate an Inbound SMTP Handshake

Verifying that DNS points to the right server is only half the battle. You must ensure the mail server is actively accepting connections and responding with the correct SMTP banner.

Connect manually using OpenSSL for encrypted sessions or netcat for plain text:

openssl s_client -connect mail.example.com:25 -starttls smtp

Once connected, issue a basic EHLO command and verify that the server responds with a 220 service ready code and your correct fully qualified domain name (FQDN):

EHLO test.example.com
MAIL FROM:<sender@example.com>
RCPT TO:<recipient@example.com>

If the server drops the connection or returns a 4xx/5xx error code, inspect your mail transfer agent logs (such as Postfix, Exim, or Exchange transport logs) for internal queue or database connection failures.

Step 4: Verify Complementary DNS Security Records

If mail is arriving sporadically or getting quarantined, inspect your anti-spoofing DNS records.

Check your Sender Policy Framework (SPF) record:

dig example.com TXT

Ensure you do not have multiple SPF records, which invalidates the entire policy per RFC specifications. Next, verify your DMARC policy publishing status:

dig _dmarc.example.com TXT

Comparing Diagnostic Approaches

Method / Tool	Best Used For	Limitations	Speed	CLI / Web
Command Line (`dig`)	Deep protocol inspection, tracing auth servers	Requires terminal access, command syntax knowledge	Fast	CLI
Web Utilities (`MX Lookup`)	Quick overview, client demonstrations, remote checks	Dependent on browser and web network access	Instant	Web
PowerShell (`Resolve-DnsName`)	Windows-native scripting and automation	Windows ecosystem specific, verbose output	Fast	CLI
Online SMTP Testers	End-to-end delivery simulation and TLS handshake test	Can trigger rate limits or security alerts on firewalls	Moderate	Web

Windows PowerShell Alternatives

If you are troubleshooting from a Windows Server or workstation without native Unix utilities, use PowerShell to query your mail records:

Resolve-DnsName -Name example.com -Type MX

To test port connectivity from PowerShell:

Test-NetConnection -ComputerName mail.example.com -Port 25

Common DNS Misconfigurations and Fixes

1. Pointing MX Records to CNAME Targets

The Problem: According to RFC 1912 section 2.4, an MX record must point directly to a machine address (an A or AAAA record), never to an alias (CNAME). Many public MTAs will reject mail outright if an MX target resolves through a CNAME.

The Fix: Update your DNS zone file to replace the CNAME target with the literal hostname that resolves directly to an IP address.

2. High TTL During Planned Migrations

The Problem: When migrating mail servers to a new hosting provider, keeping a high Time To Live (TTL) of 86400 seconds (24 hours) means external senders will continue attempting delivery to your decommissioned server for an entire day.

The Fix: Lower your MX record TTL to 300 seconds at least 48 hours prior to executing a planned migration.

3. Missing Reverse DNS (PTR) Records

The Problem: While your inbound MX records may be correct, if your outbound mail server lacks a properly configured PTR (Pointer) record matching its HELO hostname, receiving anti-spam gateways will drop your mail.

The Fix: Log into your IP subnet provider or cloud management portal and set up a reverse DNS pointer matching your mail server's public IP address (e.g., 192.0.2.25 mapping to mail.example.com).

Sysadmin Email Troubleshooting Checklist

Query authoritative nameservers directly to confirm correct MX hostnames and priorities.
Verify that every MX target resolves successfully to an active A or AAAA record.
Ensure no MX records point to CNAME aliases.
Test inbound network connectivity on TCP port 25 from an external external network.
Connect via SMTP or STARTTLS to verify the mail server responds correctly.
Check SPF, DKIM, and DMARC records for syntax errors or policy failures.
Validate that reverse DNS (PTR) records match your sending mail server IPs.

Sysadmin Toolkit: Diagnosing Corporate Email Outages via DNS