DNS Records & Concepts
What is an MX record?
An MX record, Mail Exchanger record, is a DNS record that specifies the mail server or servers responsible for receiving email addressed to a domain. When someone sends an email to contact@example.com, the sending mail server does not guess where to deliver it, it looks up the MX record for example.com in DNS and finds the address of the mail server that should receive the message.
Without MX records, email addressed to a domain has nowhere to go. The sending server performs the MX lookup, finds no record, and the email bounces. MX records are as fundamental to email as A records are to web traffic, they are the DNS layer that makes email delivery possible for a domain.
MX records are relevant to anyone managing domains alongside redirect management because connecting a domain to redirect infrastructure must be done in a way that does not break existing email delivery. A domain redirect that accidentally disrupts MX records stops all incoming email, a serious consequence that requires careful DNS management to avoid.
How an MX record works
When a mail server needs to deliver an email to contact@example.com it follows a specific process rooted in DNS.
The sending mail server extracts the domain from the recipient address, example.com. It performs a DNS lookup specifically for MX records at example.com. The authoritative nameserver for example.com returns the MX records, one or more entries each containing a mail server hostname and a priority value.
The sending server reads the priority values and attempts delivery to the mail server with the lowest priority number first, lower numbers indicate higher preference. If that server is unavailable or rejects the connection it tries the next lowest priority. This continues until delivery succeeds or all options are exhausted.
Once the sending server identifies which mail server to use it performs a separate DNS lookup, an A record or AAAA record lookup, for the mail server hostname to find its IP address. It then connects to that IP address on port 25, the standard SMTP port, and delivers the email.
A typical MX record lookup for example.com might return:
The sending server tries mail1.emailprovider.com first. If it is unavailable it falls back to mail2.emailprovider.com.
MX record format and components
An MX record has three key components beyond the standard DNS record fields of name and TTL.
Name: the domain the record applies to. Almost always the root domain, example.com: rather than a subdomain. Email addressed to @example.com is routed by the MX records for example.com. Email addressed to @mail.example.com would use MX records for mail.example.com: a separate set of records that typically does not exist for most domains.
Priority: a number between 0 and 65535 that determines the order in which mail servers are tried. Lower numbers are tried first, they have higher priority. MX 10 is tried before MX 20. When multiple records have the same priority value the sending server chooses between them randomly, providing load balancing.
Priority values do not need to be consecutive or follow a specific pattern, they just need to establish a clear ordering when multiple MX records exist. Using multiples of 10, 10, 20, 30, is a common convention that leaves room to insert records between existing ones without renumbering.
Mail server hostname: the domain name of the mail server that should receive email. This must be a hostname that resolves to an IP address via its own A record, it cannot be an IP address directly and cannot be a CNAME record. The DNS specification explicitly prohibits MX records from pointing to CNAMEs. The mail server hostname must have its own A record.
MX records and priority
The priority mechanism in MX records serves two purposes, failover and load balancing.
Failover: multiple MX records with different priorities create a fallback chain. The primary mail server has the lowest priority number and receives all delivery attempts first. Secondary and tertiary servers have higher priority numbers and receive attempts only when the primary is unreachable. This ensures email delivery continues even when the primary mail server is down for maintenance or experiencing problems.
Load balancing: multiple MX records with the same priority value distribute delivery attempts across multiple servers. Sending mail servers randomly select among equally-prioritised records, spreading the incoming connection load across several servers. This is used by large email providers with high-volume domains.
Most standard domain configurations use a single primary MX record with one or two fallback records at higher priority values. Cloud email providers like Google Workspace and Microsoft 365 typically provide multiple MX records with specific priority values as part of their configuration instructions.
Google Workspace MX records for example look like:
Five records across three priority levels, one primary, two secondary, two tertiary, provide both load balancing and failover resilience.
MX records and redirect management
MX records interact with redirect management in ways that domain owners must understand to avoid accidentally breaking email delivery when connecting domains to redirect infrastructure.
MX records are independent of web traffic routing: the key principle is that MX records govern email delivery and A records or CNAME records govern web traffic. Changing A records or adding CNAME records to connect a domain to redirect infrastructure does not affect MX records, they continue to route email to the same mail servers as before.
This independence means a domain can simultaneously have A or CNAME records pointing to redirect management infrastructure for web traffic and MX records pointing to email servers for email delivery. Both can coexist without conflict.
The CNAME and MX conflict: the important exception is that CNAME records and MX records cannot coexist for the same domain name. This matters specifically for root domains.
If a domain’s root, example.com: is connected to redirect infrastructure via a CNAME record, that CNAME would conflict with the existing MX records for example.com. The DNS specification prohibits having both a CNAME and any other record type, including MX, for the same name.
In practice this conflict is why CNAME records cannot be used at the zone apex. The solution for connecting root domains to redirect infrastructure while preserving email delivery is to use A records or ALIAS/ANAME records rather than CNAME records at the root. The A records handle web traffic routing to the redirect service. The MX records continue to handle email delivery independently.
Subdomain CNAMEs do not affect root MX records: connecting www.example.com to redirect infrastructure via a CNAME record at the www subdomain has no effect on MX records for example.com. The CNAME applies to www.example.com only. Email to @example.com continues to use the MX records for example.com unchanged.
Nameserver changes can affect MX records: changing the nameservers for a domain, moving DNS to a different provider, transfers DNS authority to the new provider. If the new provider’s DNS zone does not include the existing MX records they will be missing after the nameserver change, breaking email delivery. When migrating DNS always export all existing records, including MX, and recreate them at the new provider before changing nameservers.
Common email authentication records alongside MX
MX records specify where to receive email but do not on their own authenticate that email sent from a domain is legitimate. Email authentication is handled by additional TXT records that work alongside MX records.
SPF: specifies which mail servers are authorised to send email on behalf of the domain. Stored as a TXT record at the root domain. Receiving servers check SPF to verify the sending server is authorised.
DKIM: uses cryptographic signatures to verify emails were sent by an authorised server and not modified in transit. Public keys are stored as TXT records at specific subdomains. Signing happens at the sending mail server.
DMARC: specifies what receiving servers should do with email that fails SPF or DKIM checks. Stored as a TXT record at _dmarc.example.com. Provides policy enforcement, reject, quarantine, or allow, and reporting.
These three systems together form the standard email authentication stack. MX records handle delivery routing. SPF, DKIM, and DMARC handle authentication and policy. All four record sets are typically configured together when setting up custom domain email.
MX records for subdomains
MX records are almost always configured at the root domain, example.com: to handle email for all addresses in the @example.com format. Configuring MX records for subdomains, @mail.example.com, @newsletter.example.com: is possible but uncommon for standard domain email.
Some specific use cases for subdomain MX records exist in enterprise and high-volume email environments:
Separate sending infrastructure: a marketing team using @newsletter.example.com for bulk email campaigns routed through a separate email service from the main business email at @example.com. Each subdomain has its own MX records pointing to the appropriate email infrastructure.
Inbound email routing for services: some services and integrations receive email at specific subdomains, a support system receiving email at @support.example.com, a ticketing system at @tickets.example.com. Each subdomain has MX records pointing to the appropriate service.
For most domains with standard business email the MX records at the root domain are the only email routing configuration needed.
Checking MX records
MX records can be checked using DNS query tools in the same way as other record types.
dig command: on Linux and macOS:
Returns all MX records for example.com showing the priority values and mail server hostnames. Adding +short returns a condensed view:
Returns lines like 10 mail1.emailprovider.com. for each MX record.
nslookup: on Windows and other platforms:
Online MX checking tools: specialised tools like MXToolbox perform MX record lookups and additional checks, verifying the mail server hostnames resolve correctly, testing SMTP connectivity to each mail server, and checking for common configuration issues. These tools are invaluable for diagnosing email delivery problems.
Checking mail server resolution: after verifying MX records exist with the correct hostnames also verify that the mail server hostnames resolve to valid IP addresses. An MX record pointing to a hostname that has no A record causes delivery failures even though the MX record itself is correct.
Common MX record mistakes
Missing MX records after DNS migration: the most damaging MX mistake. Changing nameservers without recreating MX records at the new DNS provider stops all incoming email immediately. Always verify MX records exist and are correct after any DNS migration before considering the migration complete.
MX record pointing to a CNAME: the DNS specification prohibits MX records from pointing to hostnames that are themselves CNAME records. Some DNS implementations silently accept this configuration but email delivery may fail unpredictably. MX hostnames must have their own A records.
MX record pointing to an IP address: MX records must contain hostnames not IP addresses. Some DNS management interfaces accept IP addresses in MX record fields without error but the resulting configuration is invalid and causes delivery failures.
Incorrect priority values: configuring a backup mail server with a lower priority number than the primary accidentally makes it the primary. Email is delivered to the backup server first. Ensure lower numbers are assigned to more capable primary servers.
Single MX record with no fallback: relying on a single MX record with no secondary means email delivery fails completely when the mail server is temporarily unreachable. Most email providers for custom domains provide multiple MX records for resilience, configure all of them.
TTL too low on MX records: a very low TTL causes constant DNS queries from mail servers worldwide on every email delivery attempt to the domain. MX records change infrequently, a TTL of 3600 to 86400 is appropriate for established email configurations.