A DNS MX record tells sending mail servers which server accepts email for your domain. Short for "mail exchanger," it is the routing instruction for messages sent to addresses like user@yourdomain.com. Without it, inbound email may fail, bounce, or follow an unreliable path. That makes MX records one of the most basic pieces of email infrastructure and one of the easiest to overlook until delivery problems appear.
Key Takeaways
- MX records direct inbound email to the correct mail server by providing a hostname and a priority value that sending servers use to determine delivery order.
- Priority numbers control failover and load balancing: lower numbers are tried first, and equal numbers distribute traffic across servers.
- Properly configured records are a requirement for every domain that receives email, because missing or misconfigured entries lead to delivery failures and increased spam risk.
- MX records work alongside DNS-based authentication mechanisms like Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). Accurate MX records support both deliverability and security.
How DNS MX Records Work
MX records work by telling sending mail servers where to deliver messages for a domain and in what order to try available servers.
The DNS Query and Server Selection Process
When an email is sent, the sender's email client forwards the message to an outgoing mail server known as a mail transfer agent (MTA). The sending MTA then queries the domain name system (DNS) to retrieve the MX records for the recipient's domain. These records identify which mail servers accept email for that domain, along with a priority value for each one. The MTA sorts the results by priority, with the lowest number representing the preferred server, and attempts to establish SMTP connections with that server.
If the preferred server responds and accepts the message, delivery is complete. If it returns a temporary error or is unreachable, the sending MTA moves to the next server in priority order and tries again. This retry behavior continues through the list until either a server accepts the message or all options are exhausted. Temporary failures cause the sending MTA to queue the message and retry before generating a final bounce, while permanent failures result in an immediate bounce notification to the sender.
Backup Servers and Traffic Distribution
An MX record configuration can list multiple mail servers for two purposes. The first is redundancy: if the primary mail server goes offline during maintenance or outages, email routes to a backup server, so delivery continues without interruption. The second is load balancing: when two or more servers share the same priority value, RFC-compliant sending MTAs randomize which one they contact. This distributes traffic across both.
Many organizations combine these approaches by assigning equal priority to a pair of primary servers and progressively higher numbers to backup servers. This configuration achieves both load distribution and failover simultaneously. A domain with a single MX record gains no failover protection.
DNS MX Record Structure and Fields
A DNS MX record consists of a preference value and an exchange hostname, along with the standard DNS attributes that control where the record applies and how long it is cached.
An MX record consists of two data fields: a preference value and an exchange hostname.
The preference, or priority, field is a 16-bit unsigned integer ranging from 0 to 65,535. Only relative ordering matters; the absolute numbers carry no special meaning. The exchange field contains the fully qualified domain name (FQDN) of the mail server that should receive email for the domain.
Beyond these two fields, MX records share standard DNS record attributes: a domain name indicating which domain the record belongs to, the record type (MX), and a time to live (TTL) value that controls how long other DNS servers cache the record before requesting a fresh copy. The exchange hostname must resolve to an A record (IPv4) or AAAA record (IPv6), never to a CNAME.
MX Records vs. Other DNS Record Types
MX records are different from other DNS records because they control inbound mail routing, while other record types map addresses, create aliases, or publish authentication data.
Address Records and CNAME Restrictions
A records map a domain name to an IPv4 address, while AAAA records map to an IPv6 address. An A record named mail.example.com tells the internet which IP address hosts that server. MX records identify the hostname that accepts mail for the domain, and that hostname resolves through its own A or AAAA record. If a domain has no MX records at all, sending servers may fall back to the domain's A or AAAA record as a last resort, but this fallback is unreliable. Domains without MX records can reduce deliverability, and the lack of priority-based failover means a single server outage can halt all inbound email.
A CNAME, or canonical name, record creates an alias from one domain name to another. While useful for web hosting, CNAME records cannot be used as MX targets. The SMTP standard requires that the hostname in an MX record resolve directly to an address record. Pointing an MX record at a CNAME creates an extra redirection step that many mail servers refuse to follow, which can lead to silent delivery failures. This restriction is one of the most frequently violated rules in MX configuration.
TXT Records and Authentication Standards
TXT records hold arbitrary text data and are the container for several email authentication standards.
SPF records, DKIM public keys, and DMARC policies are all published as TXT records. MX records control where email goes; TXT-based authentication records control who can legitimately send on behalf of the domain and how receivers handle messages that fail verification. SPF's mx mechanism creates a direct link between these two record types: it automatically authorizes the IP addresses of every server listed in the domain's MX records as legitimate senders. When MX records change, the set of authorized sending IPs changes automatically, which simplifies administration but requires careful coordination during email migrations.
DKIM adds a separate layer of verification by attaching a cryptographic signature to outgoing messages, with the corresponding public key published in a TXT record at a specific subdomain. DMARC ties SPF and DKIM results together with a domain-level policy specifying whether receiving servers should quarantine or reject messages that fail both checks. The two record types work in tandem: MX records handle routing, and TXT records handle trust.
How to Find and Configure DNS MX Records
Finding and configuring MX records means checking what the public DNS currently shows and making sure your DNS console matches the mail service you intend to use.
Command-Line and Web-Based Lookup Tools
Web-based MX lookup tools provide the simplest way to check a domain's MX records. Entering a domain name returns the associated mail servers, their priority values, the TTL, and the record type. For administrators who prefer command-line tools, standard DNS utilities on Linux, macOS, and Windows can query MX records directly and return each record on a separate line with its priority and mail server hostname.
When interpreting results, administrators should confirm that each returned hostname, priority value, and TTL matches the expected configuration. Discrepancies may indicate stale cached records or unauthorized changes. These lookups are a first step when diagnosing email deliverability problems, because they confirm whether the outside world sees the same records the administrator expects.
MX Record Configuration in DNS Consoles
MX record configuration in a DNS console centers on the host, mail server hostname, priority, and TTL values that determine how mail reaches your domain.
Setting up MX records involves accessing the DNS management console provided by your domain registrar or hosting provider. Most consoles present a form with several fields: the host or name field, often left blank or set to "@" for the root domain; a record type selector set to MX; the mail server hostname provided by your email service; a priority value; and a TTL. Before adding new records, review any existing MX entries and remove conflicting or outdated ones to prevent split delivery between old and new servers.
Some registrars automatically append the domain name to the hostname field. After saving changes, propagation depends on the previous TTL setting. Administrators can verify the new records are live by using the lookup tools described above.
DNS MX Records and Email Security
MX records affect email security because they define the receiving infrastructure that authentication and transport protections rely on.
SPF and MX Record Authorization
SPF can use MX records as part of sending authorization, which makes MX integrity relevant to both routing and spoofing protection.
SPF allows domain owners to publish a list of servers authorized to send email on their behalf. One of the mechanisms available in an SPF record is mx, which automatically authorizes the IP addresses of every server listed in the domain's MX records. When a receiving server encounters the mx mechanism, it resolves the domain's MX hostnames to IP addresses and checks whether the sending server's IP appears among them. This creates a direct link between the domain's inbound mail infrastructure and its outbound sending authorization. The link is convenient because it keeps SPF aligned with MX changes automatically. It also means that a compromised or incorrectly configured MX record can authorize an attacker-controlled server as a legitimate sender. That can defeat spoofing protections at the authentication layer. Organizations that use the mx mechanism in their SPF records must treat MX record integrity as a security control for routing and sender authorization.
Transport Security and Domain Protection
MX records also influence transport security by defining which receiving hosts encrypted mail delivery policies are allowed to trust.
Beyond authentication, MX records play a role in encrypted transport. SMTP MTA Strict Transport Security, or MTA-STS, lets a domain publish a policy specifying which MX hostnames are authorized to receive mail and requiring that connections use TLS. Sending servers that support MTA-STS validate the receiving server's hostname against this policy and refuse to deliver over an unencrypted connection. This directly prevents downgrade attacks where an attacker strips TLS from the SMTP connection to intercept messages in transit.
DNS-Based Authentication of Named Entities, or DANE, provides an alternative by publishing TLS certificate information in TLSA records. CISA guidance recommends STARTTLS on all internet-facing mail servers, and enabling SPF, DKIM, and DMARC to support a layered email trust framework. Domains that intentionally do not receive email can publish a null MX record with a preference value of 0 and a single dot (".") as the exchange hostname. When a sending server encounters this record, it knows immediately that the domain does not accept email and can abandon delivery without wasting resources on retry attempts. Organizations with multiple registered domains that only use one for email should consider publishing null MX records on the unused domains to prevent A-record fallback and misdirected delivery.
Common MX Record Misconfigurations in DNS
Most MX record problems come from a small set of repeatable mistakes that break routing, weaken resilience, or create security gaps.
Even small errors in MX record configuration can cause widespread delivery failures. The problems below can break routing, weaken resilience, or create security gaps.
- Missing MX Records Entirely: A domain without any MX records forces sending servers into A-record fallback, which can reduce deliverability. Messages may be rejected outright or sent to junk folders, and the domain loses all failover and load-balancing capability.
- MX Records Pointing to Decommissioned Hosts: When an organization migrates to a new email provider but forgets to update its MX records, the old entries may point to servers that no longer exist. If another party later claims that IP address or hostname, they could receive email intended for the original domain, as shown in USENIX research on dangling DNS resources.
- MX Records Pointing to CNAME Targets: Internet standards require MX records to resolve to A or AAAA records, never to CNAMEs. This misconfiguration causes intermittent or total delivery failures depending on the sending server's tolerance for the extra indirection.
- Inconsistent Security Across Backup Servers: If a primary MX server enforces strict TLS and authentication checks but a backup server does not, attackers can deliberately trigger failover to the weaker server. NIST SP 800-177 recommends maintaining consistent security controls across all mail infrastructure, including backup servers.
- Mixing Providers at the Same Priority: Assigning MX records from two different email providers at the same priority level causes messages to split unpredictably between services that do not share mailbox data. This can lead to lost or undeliverable email.
The Foundation Every Email Depends On
MX records are a small DNS setting with outsized impact. They determine where inbound mail goes, how backup servers are used, and how closely routing aligns with security controls. Keeping them accurate, current, and consistent across your mail infrastructure is one of the simplest ways to support reliable email delivery.
Frequently Asked Questions
What Does MX Stand For?
MX stands for "mail exchanger." The term refers to the DNS record type that identifies which servers accept inbound email for a domain.
What Happens If My Domain Has No MX Record?
Sending mail servers fall back to the domain's A or AAAA record as a delivery target, per RFC 5321. In practice, domains without MX records can face rejection, junk-folder placement, and the loss of backup servers or load distribution.
How Long Does It Take for MX Record Changes to Propagate?
MX record changes propagate according to the TTL value set on the previous record.
How Do MX Records Relate to SPF, DKIM, and DMARC?
MX records handle email routing, while SPF, DKIM, and DMARC handle email spoofing prevention and authentication, all published as TXT records in DNS. SPF's mx mechanism can directly reference the domain's MX record hostnames as authorized senders. DMARC ties SPF and DKIM together with a policy that tells receiving servers how to handle messages that fail authentication checks.
