In the early days of the internet, a researcher at MIT tried to send an email to a colleague at Stanford. The message bounced. After hours of debugging, they discovered the problem: Stanford had just set up a new mail server but hadn't updated their DNS records to point to it. The old server was gone; the new server existed but was invisible to the outside world.
This is what MX records do—they make your mail servers visible. They're the signposts that tell the rest of the internet "if you want to send email to this domain, deliver it here."
Without MX records, email to your domain simply fails. With incorrect MX records, email goes to the wrong place or nowhere at all. Getting them right is fundamental to email working at all.
What MX records actually are
MX stands for Mail Exchanger. An MX record is a type of DNS record that specifies which mail servers accept email for a domain.
When someone sends an email to [email protected], their mail server needs to know where to deliver it. It performs a DNS lookup for MX records on yourdomain.com. The response tells it which servers handle mail for that domain.
An MX record contains two pieces of information: a priority number and a hostname. The priority determines which server to try first (lower numbers = higher priority). The hostname identifies the actual mail server.
A domain can have multiple MX records with different priorities. This provides redundancy—if the primary server is down, senders try the backup. It also enables load balancing across multiple servers.
How mail delivery uses MX records
Let's trace what happens when you send an email to [email protected].
Your mail server extracts the domain from the recipient address: example.com. It then queries DNS for MX records for that domain. DNS returns one or more MX records, each with a priority and hostname.
Your server sorts the MX records by priority, lowest first. It then tries to connect to the highest-priority server (lowest number). If that connection succeeds, it delivers the email there. If it fails—server down, connection refused, timeout—it tries the next server in priority order.
If all MX servers fail, your server queues the message and retries later. Most servers retry for several days before giving up and bouncing the message back to the sender.
This process happens for every email sent to every domain. It's invisible to users but fundamental to email working. The MX lookup is one of the first steps in every email delivery.
Reading MX records
You can look up any domain's MX records using command-line tools or online DNS checkers. The output shows you exactly where that domain's email goes.
A typical MX record set might show multiple entries with different priorities. Priority 10 might point to the primary mail server, priority 20 to a secondary, and priority 30 to a tertiary backup. The numbers themselves don't matter—only their relative order. Priority 1, 2, 3 works the same as 10, 20, 30.
When you see MX records pointing to services like Google (aspmx.l.google.com) or Microsoft (outlook.com), you know that domain uses those providers for email. When you see custom hostnames (mail.company.com), the domain runs their own mail servers or uses a dedicated email service.
Some domains have just one MX record. This works but provides no redundancy—if that server goes down, all incoming email fails until it recovers. Production email systems typically have at least two MX records for reliability.
Setting up MX records
When you set up email for a domain, configuring MX records is one of the first steps.
If you're using an email provider like Google Workspace, Microsoft 365, or a dedicated email service, they'll give you the exact MX records to create. You add these records in your DNS management interface (wherever you manage your domain's DNS).
The records typically include the provider's mail server hostnames and recommended priority values. You create one MX record for each hostname they specify, with the priorities they recommend.
After adding the records, DNS propagation takes time—anywhere from minutes to 48 hours, depending on TTL settings and DNS infrastructure. During this period, some senders might still use old records. Plan email migrations accordingly.
If you're running your own mail server, you create MX records pointing to your server's hostname. Make sure the hostname itself has an A record (or AAAA for IPv6) pointing to the server's IP address. MX records point to hostnames, not IP addresses directly.
Priority and failover
The priority system in MX records enables sophisticated mail routing.
Equal priorities mean load balancing. If you have two MX records both with priority 10, sending servers will distribute connections between them roughly equally. This spreads load across multiple servers.
Different priorities mean failover. Priority 10 gets tried first; priority 20 only if priority 10 fails. This lets you designate primary and backup servers. The backup might be a less powerful server, a different data center, or even a third-party backup service.
Some organizations use priority for geographic routing. Lower priority servers in the sender's region, higher priority servers elsewhere. This can reduce latency, though it's less common now that cloud email services handle this automatically.
Backup MX servers need careful configuration. They must be able to accept and queue mail for your domain, then forward it to your primary server when it recovers. Misconfigured backups can become spam magnets or create mail loops.
Common MX record mistakes
Several MX configuration errors cause email problems.
Pointing MX records to IP addresses instead of hostnames doesn't work. MX records must contain hostnames. Those hostnames then need A records pointing to IP addresses. This two-step resolution is how the protocol works.
Pointing MX records to CNAMEs is technically invalid, though some DNS servers tolerate it. The MX hostname should have an A record, not a CNAME. This can cause subtle delivery problems with strict mail servers.
Forgetting to create the A record for your mail server hostname breaks delivery. The MX record points to mail.yourdomain.com, but if mail.yourdomain.com doesn't resolve to an IP address, senders can't connect.
Leaving old MX records after migration causes split delivery. Some email goes to your new provider, some to the old one. Remove old MX records promptly when migrating email services.
Setting all MX records to the same priority when you want failover means servers get tried randomly rather than in order. Use different priorities if you have primary and backup servers.
MX records and email security
MX records interact with several email security mechanisms.
SPF records often reference MX records using the "mx" mechanism. This automatically authorizes your MX servers to send email for your domain. If you change MX records, your SPF might need updating too.
MTA-STS policies specify which MX hostnames are valid. If your MTA-STS policy lists specific hostnames and your MX records point elsewhere, there's a mismatch that can cause delivery failures.
DANE/TLSA records are published at hostnames derived from MX records. If you're using DANE for email security, changing MX records means updating TLSA records too.
Attackers sometimes try to exploit backup MX servers, which may have weaker security than primary servers. Ensure all your MX servers have equivalent security configurations.
MX records for subdomains
Subdomains can have their own MX records, separate from the parent domain.
Email to [email protected] looks up MX records for mail.company.com, not company.com. If mail.company.com has no MX records, the email fails—it doesn't fall back to the parent domain's MX records.
This enables routing different subdomains to different mail systems. Marketing emails might use marketing.company.com with one provider; transactional emails might use notifications.company.com with another.
If you want a subdomain to use the same mail servers as the parent domain, you need to explicitly create MX records for that subdomain pointing to the same servers. There's no automatic inheritance.
Some organizations create MX records for subdomains that point to null or invalid servers, effectively disabling email for those subdomains. This can be a security measure for subdomains that should never receive email.
Frequently asked questions
What happens if a domain has no MX records?
Sending servers fall back to the domain's A record and try to deliver directly to that IP address. This is legacy behavior and unreliable. Always configure explicit MX records for domains that receive email.
How long do MX record changes take to propagate?
It depends on TTL (Time To Live) settings. Changes can propagate in minutes or take up to 48 hours. During migration, some senders may use old records while others use new ones. Plan for overlap.
Can I have MX records pointing to different providers?
Technically yes, but it's unusual and can cause confusion. All your MX servers should be able to handle mail for your domain consistently. Split routing between providers is complex to manage.
Do I need MX records if I only send email, never receive?
Strictly speaking, no—MX records are for receiving. But having valid MX records improves your sending reputation. Some spam filters check whether senders can receive replies. Consider setting up basic receiving capability even for send-only domains.