An MX record tells other mail servers which host accepts email for a domain and in what order they should try them. Administrators use it to route inbound mail and provide resilience with multiple targets. Misconfigured MX records can interrupt delivery, expose dead endpoints, or send mail to unintended systems.
How MX records route email delivery
An mx record is a DNS instruction that points sending mail servers to the host names responsible for receiving mail for a domain. When more than one target exists, senders try them in priority order, so the record can provide resilience as well as routing. The key practical point is that MX records identify mail handlers, not mailbox contents or users.
Because MX records are part of email routing, they sit at the intersection of DNS hygiene and mail security architecture. DNS Security Guide helps explain why accurate delegation, logging, and takeover prevention matter for records like MX, while Email Security Guide shows how MX routing fits into the wider controls that handle inbound mail, filtering, and remediation.
Why MX priorities and fallback targets matter
Senders do not treat every MX target as equal. A lower-numbered priority is tried first, and higher numbers act as backup routes if the preferred host is unavailable. That design is useful, but it only works when every listed host is reachable and intended to receive mail for the domain.
Operators often underestimate the difference between resilience and exposure. A backup MX that is forgotten after a migration can become a dead endpoint, while an overly broad or stale target can route mail to a system that is no longer meant to process it. In practice, MX hygiene is about making sure the failover path is still trusted, owned, and monitored.
Mail routing depends on the rest of DNS being clean and intentional. The DNS Security Guide is useful here because the same mistakes that affect MX records, such as stale zones, dangling delegation, or poor change control, often appear across other mail-related DNS records too.
What goes wrong when MX records are misconfigured
Misconfiguration usually shows up in one of three ways: delivery stops, delivery lands on the wrong system, or delivery becomes unreliable. If the MX record points to a host that is offline or unreachable, inbound mail may queue or bounce. If it points to an unintended host, messages may be accepted by a system that cannot process them properly or that should not receive them at all.
The security consequence is not limited to mail loss. A misrouted MX can expose an old mail gateway, create shadow email ingress, or send sensitive inbound traffic to a system with weaker controls than the intended mail platform. For domains that rely on email for account recovery, vendor communication, or alerts, the operational impact can quickly spread beyond the mail team.
Email Security Guide is the better starting point when the question is how MX routing interacts with authenticated mail flows, filtering, and post-delivery controls, because MX alone does not secure the message path end to end.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | MX misrouting often follows stale ownership and change control gaps. |
| Recommendation — Review DNS-owned service accounts and retire stale mail routes promptly. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | MX routing determines where inbound email traffic is delivered and protected. |
| Recommendation — Verify mail transport and routing controls for each MX destination. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | MX records are part of networked mail delivery and its controlled routing paths. |
| Recommendation — Control and monitor DNS-based mail routing paths. | ||
Practitioner Guidance
What to verify: Confirm that every MX target is current, intentional, and able to accept mail for the domain. Check that each hostname resolves correctly, that the backup path is still monitored, and that no retired hostnames remain in production DNS.
Common mistake: Teams often update the primary mail service but leave old MX entries in place. That can create false fallback behavior, confuse troubleshooting, or route mail to a stale system during an outage.
What good looks like: The published MX set matches the intended mail architecture, the priority order is documented, and failover targets are tested rather than assumed. Good MX hygiene means you can explain exactly where inbound mail will land if the preferred service is unavailable.
Practitioner takeaway: Treat MX records as an availability and trust control, not just a DNS pointer. If the routing target is wrong, stale, or unmonitored, the domain may still “have mail,” but not in a way you can safely rely on.