Mail Exchange is the DNS record that tells other mail systems which server should receive email for a domain. If it is misconfigured, mail can be diverted, blocked or delayed, so defenders should check record accuracy, priority values and the reachability of the listed servers.
How Mail Exchange Records Work
Mail Exchange records are the DNS control point that tells sending mail systems which host is authorised to receive email for a domain. The record’s priority values matter because they create an ordered delivery path, with lower numbers generally preferred first.
In practice, the record is not a mailbox and does not store mail itself. It is a routing instruction for SMTP delivery, so accuracy and server availability both affect whether inbound messages reach the intended environment or fail before they are accepted.
Why Mail Exchange Records Matter for Email Delivery
Because MX records sit in the path between the sending system and the receiving domain, they shape deliverability, resilience and failover. A valid record set can help spread delivery across multiple hosts, while a bad one can send traffic to the wrong place or leave no reachable target at all.
Mail operators should think of the MX layer as part of the trust boundary for inbound mail: if the listed hosts are stale, mis-typed or unreachable, other systems may defer, bounce or reroute delivery. That makes record hygiene a routine dependency for business email continuity.
Common Misconfigurations and Failure Modes
The most common problems are simple but disruptive: wrong hostname, missing trailing target in the DNS zone, incorrect priority ordering, no reachable listener on the referenced server, or inconsistent records between authoritative DNS and the actual mail platform. Any of these can interrupt delivery without changing the domain name itself.
Defenders also need to watch for shadow mail paths created by forgotten records or inherited DNS entries. The DNS Security Guide covers adjacent DNS risks such as record hygiene, DNS logging and related zone exposure, which are all useful context when validating mail routing.
Checking and Protecting Mail Routing
Validation starts with an accurate asset inventory and a review of the authoritative DNS zone, the mail gateway or provider, and any DNS changes that may have altered delivery behaviour. The sending perspective matters too: external parties only see what DNS publishes, not what the internal team intended.
For broader DNS hardening, RFC 8693: OAuth 2.0 Token Exchange is not about mail routing itself, but the same operational discipline applies: understand the exact handoff point, the authoritative source of truth, and the delegation path that other systems will trust.
Risk and Threat Considerations
MX records are a high-value configuration because they directly influence where inbound mail goes. If an attacker can alter them, or if defenders publish incorrect values, email can be diverted, blocked or silently delayed, which creates both availability impact and a potential interception path.
Failure mechanism: The attack or failure usually works by changing DNS routing, exploiting weak zone control, or leaving a misconfigured record in place long enough for senders to trust it.
Impact: Messages may be lost, delayed or delivered to an unintended server, and the resulting disruption can affect authentication flows, business correspondence and incident response visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | MX records direct email transport to the receiving host. |
| Recommendation — Protect email transport and routing to preserve message delivery integrity. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | MX routing exposes a network boundary that must only accept intended mail traffic. |
| Recommendation — Restrict inbound mail paths to the approved receiving hosts. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | MX accuracy depends on controlled DNS and mail infrastructure changes. |
| Recommendation — Manage DNS and mail infrastructure changes through controlled review and verification. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network Security | Mail routing via MX records is part of secure network service configuration. |
| Recommendation — Harden mail-routing infrastructure and validate published DNS targets. | ||
Practitioner Guidance
Why practitioners should care: MX records are small but operationally critical, so ownership should sit with whoever can verify both DNS intent and mail platform readiness. Treat them as part of service continuity, not as a one-time setup task.
What to watch for: Review changes to priority values, newly added hosts, expired migration records and any mail delivery errors that coincide with DNS edits. If mail starts failing after a DNS update, confirm the published record set before troubleshooting the mail server itself.
Practitioner takeaway: The safest posture is to keep the DNS entry set minimal, current and continuously aligned with the actual systems that should receive mail.
Related resources from NHI Mgmt Group
- Why do application permissions for Mail.Send create higher risk than a traditional service account in Exchange Online?
- What are the signs that Exchange Online mail flow rules are being misused or drifting out of control?
- How should security teams configure Exchange Online Protection for organisations with multiple domains and hybrid mail flow?
- What is the difference between Exchange Online mail sending and a secure email relay for outbound transactional email?