MX Record Security: Misconfigured Mail Routing and Its Risks

What are MX records and how email routing works

MX (Mail Exchanger) records are DNS records that tell the world which mail servers accept email for your domain. When someone sends an email to user@yourcompany.com, their mail server:

1. Queries DNS for the MX records of yourcompany.com
2. Gets a list of mail servers with priority values
3. Attempts delivery to the server with the lowest priority number first
4. Falls back to higher-numbered servers if the primary is unavailable

A typical MX configuration looks like this:

yourcompany.com.  IN  MX  10  mx1.mail-provider.com.
yourcompany.com.  IN  MX  20  mx2.mail-provider.com.

Priority 10 is tried first. If mx1 is down, the sender retries with mx2 (priority 20). Lower numbers mean higher priority.

Common MX misconfigurations

Wrong priority values

If priorities are set incorrectly, email may be routed to a backup server that is not intended to be the primary handler:

# Problem: backup server has higher priority than primary
yourcompany.com.  IN  MX  10  backup-mx.yourcompany.com.
yourcompany.com.  IN  MX  20  mx.mail-provider.com.

In this case, all email goes to backup-mx first. If that server is a legacy system or a security appliance that is not fully configured, email may be delayed, lost, or processed incorrectly.

Stale MX records pointing to decommissioned servers

This is the most dangerous misconfiguration. If an MX record points to a server that:

• No longer exists (IP released back to the cloud provider)
• Has been decommissioned but the DNS was not updated
• Belongs to a cancelled hosting account

Then email is either bounced (best case), lost silently (bad), or intercepted by whoever now controls that IP or hostname (worst case).

This is the email equivalent of orphan DNS records -- and the consequences are worse because email often contains sensitive information.

Missing MX records entirely

If your domain has no MX records at all, sending servers fall back to the A record of the domain. This means email is delivered to whatever server responds on port 25 at your domain's IP address -- which is probably your web server, not a mail server.

MX pointing to a CNAME

The DNS specification (RFC 2181) states that MX records must not point to CNAME records. While some mail servers tolerate this, others reject it, causing intermittent delivery failures that are difficult to debug.

# WRONG -- MX points to a CNAME
yourcompany.com.  IN  MX  10  mail.yourcompany.com.
mail.yourcompany.com.  IN  CNAME  mx.mail-provider.com.

# RIGHT -- MX points directly to the hostname
yourcompany.com.  IN  MX  10  mx.mail-provider.com.

Too many MX records

While having backup MX servers is good practice, having too many (especially outdated ones) increases the attack surface. Each MX server is a potential target, and backup servers often receive less security attention than the primary.

Security risks of MX misconfigurations

Email misdirection

If an MX record points to a server you do not control, all email sent to your domain goes to that server. The operator can read, copy, or modify every message.

Data exposure

Email routinely contains sensitive information -- contracts, invoices, credentials, personal data, confidential business communications. Misdirected email exposes all of it.

Backup MX exploitation

Attackers specifically target backup MX servers because they are often less hardened than primary servers. A backup MX with weak authentication can be used to relay spam or phish as your domain.

SPF bypass via secondary MX

If your SPF record does not account for all MX servers, email processed by a secondary MX may fail SPF checks, causing legitimate email to be marked as spam or rejected.

How to check MX records

Using dig

# View MX records with priorities
dig MX yourcompany.com +short

# Example output:
# 10 mx1.mail-provider.com.
# 20 mx2.mail-provider.com.

# Verify each MX server resolves and is reachable
dig +short mx1.mail-provider.com
dig +short mx2.mail-provider.com

Using MXToolbox

MXToolbox MX Lookup provides a detailed view including:

• All MX records with priorities
• Whether each MX server responds
• Whether the MX points to a CNAME (problem)
• Reverse DNS check on each mail server

Using nslookup

nslookup -type=MX yourcompany.com

Testing email delivery

Send a test email to your domain from an external account and check:

• Does it arrive?
• Do the headers show the correct receiving server?
• Are there unexpected delays?

# Check email headers for the Received: chain
# Look at which server actually processed the email

MX records and SPF interaction

Your SPF record and your MX records must be consistent. All servers listed in your MX records send email (at minimum, bounce messages and delivery status notifications), so they need to be covered by your SPF record.

If your MX servers are mx1.mail-provider.com and mx2.mail-provider.com, your SPF record should include them:

yourcompany.com.  IN  TXT  "v=spf1 mx include:_spf.mail-provider.com -all"

The mx mechanism in SPF automatically includes the IP addresses of your MX servers. See How to set up SPF records for the full guide.

Best practices for MX record management

Use redundant MX servers

Always have at least two MX records for redundancy. If your primary server goes down, email should still be delivered:

yourcompany.com.  IN  MX  10  mx1.mail-provider.com.
yourcompany.com.  IN  MX  20  mx2.mail-provider.com.

Set priorities correctly

The primary server should have the lowest number. Backup servers should have progressively higher numbers:

yourcompany.com.  IN  MX  10  primary-mx.mail-provider.com.
yourcompany.com.  IN  MX  20  secondary-mx.mail-provider.com.
yourcompany.com.  IN  MX  30  tertiary-mx.mail-provider.com.

Remove stale entries

If you have switched mail providers, remove MX records pointing to the old provider. A stale MX record is a ticking time bomb -- the old provider may reassign the hostname, or the server may be decomissioned and its IP recycled.

# Audit: do all your MX records resolve to servers you control or trust?
for mx in $(dig MX yourcompany.com +short | awk '{print $2}'); do
  echo "$mx -> $(dig +short $mx)"
done

Never use MX with CNAME targets

Point MX records directly to A/AAAA hostnames, not to CNAMEs. This avoids compatibility issues with strict mail servers.

Secure every MX server equally

Your backup MX is your weakest link. Ensure all MX servers have:

• Current TLS certificates
• Strong cipher configurations
• Proper authentication
• Up-to-date software
• Consistent DMARC enforcement

Use MTA-STS for transport security

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending servers to only deliver email to your MX servers over TLS. This prevents downgrade attacks on email in transit:

_mta-sts.yourcompany.com.  IN  TXT  "v=STSv1; id=20260527"

Combined with a policy file hosted at https://mta-sts.yourcompany.com/.well-known/mta-sts.txt.

For a broader view of how to protect your domain from email-based attacks, see our email spoofing prevention guide.

How SurfaceScan helps

SurfaceScan checks MX records for every domain in your attack surface on each scan. It detects stale MX records pointing to unresponsive or uncontrolled servers, MX records targeting CNAMEs, missing MX records, and inconsistencies between MX records and SPF configuration. Findings appear in the Email Security section with the specific misconfiguration and guidance on how to fix it, so your email routing stays secure and reliable.