An MX record is a DNS record that tells senders which mail servers accept email for a domain. It lists the destination hostnames and their priority order, so SMTP can route messages to the correct server and fail over to another one if needed.
MX records as email routing instructions
An mx record is the DNS mechanism that tells remote mail systems where to deliver email for a domain. It does not carry message content; it publishes the domain’s mail-handling endpoints and their preference order so SMTP can select a target and retry elsewhere if needed.
This makes MX records part of the basic trust and availability model for email. If the record points to the wrong host, is missing, or is altered by an attacker, mail delivery can fail, be redirected, or become dependent on an untrusted destination.
How MX records are used in delivery
When a sending server looks up a domain, it reads the MX set and uses the advertised priorities to choose which mail exchanger to contact first. Lower-priority values are typically preferred first, so the record set acts as a routing policy for inbound email.
MX records are only one part of email routing. The target hostnames still have to resolve correctly, accept SMTP connections, and be operational when the sender attempts delivery. If the routing chain is broken at any step, the result is bounced mail, delayed messages, or fallback to a less-preferred exchanger.
Because the MX record is published in public DNS, it becomes a visible dependency for every external sender. That visibility makes it easy to inspect and operationally important to keep accurate, especially during mail platform changes, mergers, migrations, or failovers.
MX records and email security controls
MX records are often discussed alongside SPF, DKIM, and DMARC because those controls depend on a correctly understood mail flow. The MX set tells senders where mail should arrive, while the other controls help verify whether that mail path and the sending identity are legitimate.
A domain that intentionally does not send email may still need deliberate MX handling, such as a null MX policy, so that receivers do not guess at a destination. The Domain Without Email guide covers that defensive pattern, while the Email Security Guide places MX routing in the broader context of mail authentication and delivery architecture.
DNS integrity also matters because an MX record is only as trustworthy as the zone that publishes it. The DNS Security Guide is relevant here because DNS controls such as logging, DNSSEC, and safe zone management help protect the record from tampering or misconfiguration.
Common failure modes and operational changes
MX records become fragile during domain changes, decommissioning, and mail-service migrations. A record that still points at an old platform can create a delivery gap, while a record that is removed too early can make the domain appear unreachable for mail.
They also matter during takeover and recovery scenarios. If a domain’s DNS is exposed to compromise, the MX set can be altered to divert mail, interrupt delivery, or support phishing and interception. In response, teams usually need to restore authoritative DNS, verify the mail path, and review related trust relationships.
For that reason, MX records should be treated as a change-controlled asset rather than a static DNS detail. Even a small edit can affect every inbound message flow for the domain.
What practitioners should verify
Practical review starts with the domain’s authoritative zone, current mail provider, and intended delivery path. Confirm that the MX targets are correct, the priorities reflect the desired failover order, and the advertised hosts are still live and meant to receive mail.
It is also worth checking whether the domain is supposed to receive mail at all, whether the MX set aligns with SPF, DKIM, and DMARC policy, and whether the zone has any stale references from an earlier provider. For domains that should never accept email, a deliberate null MX or equivalent defensive configuration is safer than leaving assumptions to chance.
Practitioner note: MX records are simple to read but easy to mismanage, so mail reliability and spoofing resistance often depend on getting the surrounding DNS and email policy details right, not just the record itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-13 — Data Protection | MX records shape email delivery paths that support protection of mail transport and domain routing. |
| Recommendation — Harden DNS and mail routing so outbound and inbound email destinations cannot be silently altered. | ||
| NIST CSF 2.0 | PR.DS-2 — Data-in-transit is protected | MX routing determines how email traffic is directed to protected mail transport endpoints. |
| Recommendation — Protect mail transport and validate routing so email is sent only to intended exchangers. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | MX records are configuration items whose changes affect a domain's mail delivery behaviour. |
| Recommendation — Control DNS and mail-routing changes through managed configuration review and approval. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | MX records define the external entry points used for mail delivery into organizational systems. |
| Recommendation — Restrict and monitor mail ingress paths so only approved mail exchangers are reachable. | ||
Related resources from NHI Mgmt Group
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