SMTP MX Record

What an MX record does in SMTP delivery

An MX record is the routing instruction that lets sending mail servers find the right destination for a domain. It does not carry the email itself. Instead, it points SMTP traffic to one or more mail exchangers, creating a controlled entry point for inbound mail and a clear failover path when a preferred host is unavailable.

That design makes MX records a core part of mail transport rather than message content or mailbox security. If the record set is wrong, missing, stale, or overwritten, delivery can fail even when the mail system behind it is healthy. For a broader view of how MX routing fits into mail protection and delivery architecture, see the Email Security Guide.

How MX preference and failover work

Multiple MX records allow administrators to publish more than one accepting host for the same domain. Sending systems typically try the lowest-priority value first, then move to the next choice if the preferred target cannot accept mail. That makes MX records a resilience mechanism as well as a routing mechanism.

Because SMTP delivery is opportunistic and asynchronous, this preference order matters operationally. A misordered or overly narrow set of MX hosts can create bottlenecks, while a well-designed set can absorb temporary outages without interrupting inbound delivery. The surrounding DNS design also matters, because a mail exchanger record is only as trustworthy as the zone that publishes it.

Why MX records are security-sensitive

MX records are attractive to attackers because they sit at the boundary between public DNS and your mail infrastructure. If an attacker can alter the record, they can redirect mail flow, intercept inbound messages, or create a denial of service for email delivery. If a record points to a decommissioned or dangling service, the domain can also inherit takeover risk.

That is why MX hygiene is not just a deliverability task. It is part of protecting routing trust, preventing accidental exposure of mail flow, and reducing the chance that a stale record becomes an entry point for abuse. The same control plane issues show up in broader DNS compromise scenarios, including DNS Hijack Playbook and Subdomain Takeover and Dangling DNS Guide.

MX records in operational mail architecture

In practice, MX records sit alongside SPF, DKIM, DMARC, TLS policy, and inbound filtering controls. The MX record answers the question “where should mail go?”, while the other controls answer whether mail should be trusted, authenticated, or filtered once it arrives. That separation is important because MX alone does not prove sender legitimacy or message safety.

For domains that do send mail, MX records should align with the organization’s actual inbound mail path, not just a theoretical design. For domains that should not receive mail, the safer pattern is to avoid publishing a misleading live mail exchanger at all and instead use a deliberate non-delivery stance. The Domain Without Email guide covers the defensive side of that decision, including null MX and related posture choices.

Exposure checks and remediation when MX routing is wrong

When MX routing looks suspicious, the first question is whether the DNS data matches the intended mail architecture and whether the published hosts are still owned, reachable, and monitored. Administrators should compare the zone file against current mail infrastructure, vendor advisories, registrar status, and any recent decommissioning or migration work.

If a bad MX record is found, remediation usually means restoring the intended mail host, removing stale entries, and validating that failover paths still resolve correctly. Where the misconfiguration came from a takeover or recovery event, the cleanup should include a full DNS review and mail-flow verification. The Subdomain Takeover Response Playbook and Domain Registrar Compromise Playbook are useful references when the problem extends beyond a simple typo into domain-control recovery.

Related resources from NHI Mgmt Group

• Guide: Network Ports and Protocols Security Guide
• How should security teams evaluate cloud email security controls that rely on API integration instead of MX record changes?
• How does Mail Exchanger (MX) record work?
• What attacks target a Mail Exchanger (MX) record?
• How do attackers use MX record enumeration?