A Mail Exchange record, or MX record, is a DNS record that tells other mail servers which host accepts email for a domain. It points to one or more mail servers and uses priority values to choose the delivery path when multiple servers are listed.
How MX Records Direct Email Delivery
An MX record is the DNS mechanism that tells sending mail servers where to deliver messages for a domain. It does not carry email itself; instead, it maps a domain to one or more accepting mail hosts and gives senders a routing preference when several are available.
That routing layer matters because mail delivery is decentralized and opportunistic. If an MX target is unreachable, misprioritised, or absent, inbound mail may queue, fail over unexpectedly, or be rejected, which makes the record a small but high-value control point in everyday email reachability.
Why Priority, Fallback, and Host Design Matter
MX records commonly use multiple targets so mail can continue flowing during outages or maintenance. Lower-numbered priorities are tried first, so the published order is part of operational resilience rather than a cosmetic DNS setting.
Good MX design usually pairs the record set with the broader email architecture behind it, such as a secure email gateway, cloud mail service, or smart host path. NHIMG’s Email Security Guide covers how MX routing fits into that wider delivery stack, including remediation and mail flow controls.
Because MX answers are public, they also reveal where a domain expects inbound mail to land. That visibility is normal and necessary, but it means the chosen mail hosts, their priorities, and the surrounding DNS hygiene become part of the organisation’s exposed email surface.
What MX Records Depend On in DNS
MX records sit inside the DNS namespace, so their correctness depends on the integrity of the zone, the accuracy of the hostnames they reference, and the availability of the authoritative DNS infrastructure. A valid MX entry that points at a broken hostname still breaks mail delivery.
They also depend on adjacent DNS controls that reduce spoofing, tampering, and operational error. NHIMG’s DNS Security Guide is useful for understanding the protective controls around DNS logging, DNSSEC, sinkholing, and related name-resolution risks that can affect mail routing.
In practice, MX records are only one part of mail trust. Sending systems also evaluate SPF, DKIM, DMARC, and TLS-related email controls, so a correct MX record helps with reachability but does not by itself establish sender authenticity or message integrity.
How MX Records Are Checked and Validated
Organisations usually verify MX exposure by comparing the published DNS records with their actual mail service inventory. That means checking which hosts are authoritative for mail, whether they are intentionally internet-facing, and whether the listed priorities still reflect the intended failover order.
Vendor mail-service documentation and DNS zone reviews are the two most practical sources of truth. If the MX target list does not match the current mail platform, the result can be misdelivery, missed mail during migration, or routing to retired infrastructure that still appears valid in DNS.
Validation also includes confirming that the mail hosts answer on the expected delivery path and that defensive controls such as spam filtering, quarantine, and encryption enforcement are being applied where intended. The MX record tells senders where to go, but the receiving stack determines what happens next.
Risk and Threat Considerations
MX records are attractive to attackers because they expose the domain’s inbound mail path and can become a point of disruption if DNS is misconfigured or tampered with. A wrong or hijacked MX target can divert mail, suppress delivery, or create a path for phishing, interception, or business email compromise.
Failure mechanism: Attackers exploit weak DNS governance, stale records, or compromised registrar and DNS accounts to alter where mail is delivered, while defenders may miss the change if they do not monitor authoritative zone updates and mail-flow behaviour.
Impact: The result can be loss of inbound mail, silent redirection of sensitive messages, delayed incident detection, and downstream compromise of accounts, workflows, or secrets that are distributed through email.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | MX routing defines an inbound trust boundary for email delivery. |
| Recommendation — Review MX-facing mail paths under SC-7 and restrict inbound exposure to the required mail hosts. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | MX administration depends on tightly governed DNS and mail-service administrative access. |
| Recommendation — Govern administrative access to DNS and mail platforms so MX changes are authorized and auditable. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | MX records often point to cloud mail services whose exposure depends on correct deployment and DNS configuration. |
| Recommendation — Validate mail-service deployment and DNS settings so published MX targets do not expose insecure endpoints. | ||
| MITRE ATT&CK | T1565 — Data Manipulation | MX tampering changes message routing and can redirect or suppress email delivery. |
| Recommendation — Monitor for unauthorized DNS modifications that alter email routing and delivery paths. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | MX and DNS changes need traceable logging to detect unauthorized routing changes. |
| Recommendation — Log and review DNS and registrar changes that affect MX records and email routing. | ||
Practitioner Guidance
What to watch for: Treat MX changes as operationally sensitive DNS changes, not routine metadata updates. Any change in mail provider, failover design, or mail security gateway should be checked against the live zone, the registrar, and the actual delivery path before it is considered complete.
Governance implication: Keep ownership of MX records aligned with both DNS administration and mail-platform administration, because drift between those teams is a common source of delivery failures and unplanned exposure. In mature environments, MX records are reviewed alongside adjacent email controls so the published routing still matches the intended security posture.
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?
- Why do patient consent models for electronic medical record exchange create governance risk for hospitals and health networks?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org