A DNS MX record is a mail exchange record that tells other mail servers which hosts accept email for a domain. It lists the priority and hostname of the destination mail servers, and senders use it during SMTP routing to choose where to deliver messages.
How DNS MX Records Work
An mx record is the part of DNS that tells mail senders where to deliver messages for a domain. It does not carry the email itself; instead, it points SMTP clients and servers to the destination hosts that are prepared to accept mail.
That routing role makes MX records a foundational mail-discovery mechanism. If the record is absent, stale, or misconfigured, external senders may fail over to the wrong host, deliver inconsistently, or treat the domain as unreachable for email.
Priority, Preference, and Mail Delivery Behaviour
MX records are usually published as a set, not a single entry. Senders compare the preference values and try the lowest-numbered target first, then move to higher values if delivery fails. That structure supports redundancy and orderly failover across multiple mail hosts.
Because the MX list is part of the public routing picture for a domain, it should align with the mail architecture the organisation actually operates. A record that still points to retired infrastructure can send mail flow into a dead end, while inconsistent priorities can create unpredictable delivery behaviour during outages or migration.
The record also sits next to other DNS and mail controls that influence trust and reachability. For example, the broader email path may also depend on SPF, DKIM, DMARC, and transport security policies, but MX remains the routing lookup that gets a sender to the right destination in the first place. For a protocol-level view of how records, resolution, TTLs, and transport interact, see the DNS Protocol Fundamentals for Defenders Guide.
Why MX Records Matter for Email Security
MX records are security-relevant because they define which hosts the internet is allowed to treat as email endpoints for a domain. If an attacker can alter them, or if they point to a decommissioned service, they may redirect inbound mail, intercept password resets, or create a path for domain impersonation.
Operationally, the MX record is also a control surface for mail resilience and domain hygiene. A domain that should not receive email should not leave ambiguous routing in place, and a domain that does receive email should publish a stable set of destinations that match its current mail infrastructure.
For defenders, the practical question is often whether the MX targets are still owned, intended, and reachable. A DNS review should include the zone itself, the registrar path, and the mail platform behind the hostname so that routing, delegation, and decommissioning stay aligned. The DNS Security Guide covers the wider controls around DNS integrity, logging, and takeover prevention.
MX Records in Incident Response and Change Management
MX changes are high-impact changes because they affect every inbound message to a domain. That means migrations, provider swaps, and decommissioning events should be treated as security-sensitive, not as routine cosmetic DNS edits.
During a compromise investigation, MX records deserve immediate review alongside nameserver delegation and registrar settings. If mail delivery has been diverted, the record history can show whether a malicious change created the redirection, or whether a stale entry is simply pointing to a vanished service.
When a domain is being retired from email use, the safer pattern is explicit closure rather than ambiguity. Domains that no longer accept mail should be configured so senders receive a clear signal instead of silently guessing where to deliver. The Domain Without Email guide explains the defensive pattern for non-sending domains, while the Email Security Guide places MX routing in the wider mail security architecture.
Risk and Threat Considerations
MX records are attractive to attackers because they control where inbound mail is delivered, and email remains a common recovery channel for account access, alerts, and business workflows. A compromised or stale MX target can expose messages, interrupt delivery, or support phishing and account takeover attempts that depend on controlling mail flow.
Failure mechanism: A malicious or mistaken DNS change can point a domain’s mail routing to an unintended host, or leave a dead destination in place, causing mail interception, delivery failure, or trust erosion in downstream email processes.
Impact: The result can include missed messages, exposed communications, broken password resets, and a wider compromise if the attacker uses mail access to reset other accounts or impersonate the organisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | MX routing changes affect who can receive business email, so inventory and control domain ownership. |
| Recommendation — Track mail-routing domains as managed assets and review DNS changes before they alter inbound delivery. | ||
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | MX records identify a critical internet-facing mail asset and its delivery path. |
| PR.PS-01 — Configuration Management | MX records are configuration data whose integrity determines external mail routing. | |
| Recommendation — Inventory MX hosts and domain dependencies so mail-routing changes are visible before they break delivery. Control DNS change management for MX records and validate that published mail targets match intended infrastructure. | ||
| MITRE ATT&CK | T1584.001 — Compromise Infrastructure: Domains | MX tampering and dangling DNS can support infrastructure abuse and mail redirection. |
| Recommendation — Monitor DNS changes for domain-infrastructure abuse and investigate unexpected mail-routing edits. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | MX records are part of the baseline DNS configuration that should be defined and controlled. |
| Recommendation — Establish and protect a baseline for authoritative DNS records, including MX entries and approved targets. | ||
Practitioner Guidance
What to watch for: Treat MX records as part of the asset inventory for every domain that can receive mail. Review them whenever mail infrastructure changes, a provider is retired, or a domain is repurposed, and compare the published targets with the systems that are actually authorised to receive email.
Governance implication: Ownership should sit with the team that manages both DNS and mail delivery, because routing changes affect security, availability, and user trust at the same time. For defensive patterning around mail routing, the Subdomain Takeover and Dangling DNS Guide and DNS Hijack Playbook are useful references when DNS ownership or delegation is in doubt.
Related resources from NHI Mgmt Group
- How should security teams plan for DNS outages that block record updates?
- What should identity and security teams review after a DNS record change?
- Why can DMARC policy discovery change even when the DNS record seems unchanged?
- Why does a stale DNS record create such a high-risk takeover path for attackers?