MX Records Explained: How Your Domain Tells the World Where to Send Email

When someone sends an email to [email protected], the message has to find the right mail server on the internet. Your domain does not magically know where that server is. Instead, it uses special DNS records called MX records to say, “Mail for this domain should go over there.”

If A and AAAA records tell browsers where to find your website, MX records tell mail servers where to deliver your emails. Understanding them makes it much easier to move email providers, add backups, or fix delivery problems.

What Is an MX Record?

An MX (Mail Exchanger) record is a DNS record that tells other mail servers which hostnames handle email for your domain and in what order they should try them.

An MX record has two main parts:

• Priority – a number that indicates which server should be tried first (lower number = higher priority).
• Mail server hostname – the name of the server that accepts mail (it must have its own A/AAAA records).

A simple example for example.com might look like this:

example.com.    MX    10 mail.example.com.

This line tells the world: “If you want to send email to @example.com, talk to mail.example.com first.”

How MX Records Work When Email Is Sent

Let’s walk through what happens when someone sends a message to [email protected].

1. The sender’s email server sees the domain part (example.com) and needs to know where to deliver the message.
2. It looks up MX records for example.com in DNS.
3. DNS returns one or more MX records, for example:

   example.com.    MX    10 mail1.example.com.
   example.com.    MX    20 mail2.example.com.

4. The sending server sorts them by priority and tries mail1.example.com first (priority 10).
5. To reach mail1.example.com, it does another DNS lookup to get its A/AAAA records (IP address).
6. If the connection succeeds, the email is delivered there.
7. If mail1.example.com is down, the sending server tries mail2.example.com (priority 20) as a backup.

All of this happens automatically. No human needs to pick mail servers during sending; the MX records do the routing.

MX Records Point to Hostnames, Not IPs

One important rule: the target of an MX record must be a hostname, not an IP address.

Correct pattern:

example.com.    MX    10 mail.example.com.
mail.example.com.  A  198.51.100.60

Incorrect pattern:

example.com.    MX    10 198.51.100.60    ; invalid

The mail server hostname itself should have A (and maybe AAAA) records with real IP addresses. This extra step makes it easier to change IPs later without touching the MX records.

Understanding MX Priority

The priority number in an MX record decides which server is used first. The lower the number, the higher the priority.

Example with one primary and one backup:

example.com.    MX    10 mail-primary.example.com.
example.com.    MX    20 mail-backup.example.com.

Mail delivery logic:

• Try mail-primary.example.com (priority 10) first.
• If it cannot be reached (server down, connection refused, etc.), try mail-backup.example.com (priority 20).

If you have multiple MX records with the same priority, sending servers will usually spread traffic between them, which can help with load balancing.

Common Real-World MX Setups

You will see MX records in a few typical patterns depending on how you host your email.

1. Email on the Same Server as Your Website

In smaller setups, the web server also handles email. The MX might look like:

example.com.    MX    10 mail.example.com.
mail.example.com.  A  198.51.100.60

Here, mail.example.com often has the same IP as your website. This works but can become limiting if your site grows or you need advanced spam protection.

2. Using a Hosted Email Service (e.g. Google Workspace, Microsoft 365)

Big providers usually tell you to create several MX records pointing to their servers. For example (simplified):

example.com.    MX    1   aspmx.l.example.com.
example.com.    MX    5   alt1.aspmx.l.example.com.
example.com.    MX    5   alt2.aspmx.l.example.com.

In this case, you do not manage the mail servers yourself. You just follow the provider’s instructions exactly. Any typo in the hostnames or priority can break delivery.

3. Using a Separate Mail Security Gateway

Some companies put a spam filter or email security service in front of their real mail server. In that case, MX points to the gateway, not directly to the internal mail server.

example.com.    MX    10 mx.email-security.com.
mx.email-security.com.   A   203.0.113.40

The gateway receives incoming mail, checks it for spam or malware, and then forwards clean messages to your internal server.

How to Set Up MX Records in a DNS Panel

Setting up MX records usually follows the same pattern across providers. The labels might differ a bit, but the idea is consistent.

1. Log into your DNS provider or registrar.
2. Open the DNS management or “Zone Editor” for the domain.
3. Click “Add record” and choose type MX.
4. Fill in the fields:
   • Name / Host: often @ for the root domain (for @example.com addresses).
   • Priority: the number given by your email provider (for example, 10).
   • Mail server / Value: the hostname of the mail server (for example, mail.example.com or your provider’s host).
   • TTL: how long other DNS servers should cache this record.
5. Save the record and repeat if you need additional MX entries.

After saving, give DNS some time to propagate. If you are switching from one email provider to another, there might be a short overlap where some messages still go to the old servers until caches expire.

Checking MX Records

To make sure everything is set correctly, it is a good idea to test your MX records.

• Use free online MX lookup tools to see what public DNS currently returns for your domain.
• On the command line, you can use tools like dig or nslookup. For example:

  dig MX example.com

• Check that the hostnames in the MX records also have valid A/AAAA records.

If the MX lookup shows old servers or no records at all, you know where to start troubleshooting.

Typical MX Record Problems and How to Avoid Them

MX misconfigurations are a common cause of email issues. Here are the mistakes that come up most often.

• No MX records at all – if there are no MX records, some servers fall back to the A record, but others will not, and deliverability becomes unreliable.
• Typos in hostnames – a missing letter in mail.provider.com means mail gets sent to a host that does not exist.
• Pointing MX directly to an IP address – this is against the rules; MX must point to a hostname.
• Wrong priorities – making the backup server a lower number than the primary means it will be used first, which may not be what you want.
• Forgetting to update MX when changing providers – email keeps going to the old service even though you switched.

Whenever you change MX records, it is wise to double-check with your email provider’s documentation and test with a lookup tool.

Security and Deliverability: MX Is Only Part of the Story

MX records decide where email is delivered, but not whether that mail is trusted. For good deliverability, your DNS should also include:

• SPF records – to list which servers are allowed to send mail for your domain.
• DKIM records – to publish keys for signing outgoing mail.
• DMARC records – to define policies for handling suspicious messages.

These records work together with MX. If MX points to a new provider but SPF or DKIM are still set up for the old one, your outgoing mail may land in spam or be rejected.

Key Takeaways for MX Records

• MX records tell the world which servers handle incoming email for your domain.
• They always point to hostnames, not IP addresses.
• Priority numbers control the order in which servers are tried.
• Multiple MX records allow for backups and load distribution.
• MX is about delivery; SPF, DKIM, and DMARC are about trust and authentication.

FAQ About MX Records

Related Topics to Explore Next

• SPF records: how to tell the world which servers may send email for your domain.
• DKIM records: using cryptographic signatures to prove your messages are legitimate.
• DMARC policies: controlling what happens to suspicious messages and getting reports.
• Reverse DNS (PTR): why some mail servers check the IP’s hostname before accepting mail.

Once you understand MX records, changing email providers or setting up a new domain becomes far less scary. Instead of hoping that messages “just work,” you know exactly which records to check and how they guide every email to the right mailbox.