MX Records Explained: How Email Routing Works

When someone sends an email to you@yourdomain.com, their mail server needs to know where to deliver it. Your domain’s website might be hosted on one server, but your email might be handled by Google Workspace, Microsoft 365, or a completely different provider on a different continent. The MX record is the DNS record that tells sending mail servers exactly where to deliver email for your domain.

MX stands for Mail Exchanger. It is a DNS record that maps a domain name to one or more mail servers responsible for receiving email on behalf of that domain. Without MX records, email sent to your domain has nowhere to go.

How MX records work#

The email delivery process:

1. Someone sends an email to user@yourdomain.com
2. Their mail server extracts the domain (yourdomain.com) from the recipient address
3. The sending server performs a DNS lookup for MX records on yourdomain.com
4. DNS returns one or more MX records, each pointing to a mail server hostname
5. The sending server connects to the mail server with the highest priority (lowest number) and delivers the email
6. If that server is unavailable, the sending server tries the next one in priority order

This is why you can host your website on one provider and your email on another. The A record points web traffic to your web server. The MX record points email traffic to your mail server. They are independent.

MX record structure#

An MX record has two parts: a priority value and a mail server hostname.

yourdomain.com.    MX    10    mail.yourdomain.com.

The priority value determines the order in which servers are tried. A server with priority 10 is tried before a server with priority 20. If the priority-10 server is down, the sending server falls back to the priority-20 server.

Priority and failover

Most email providers give you multiple MX records with different priorities:

yourdomain.com.    MX    1     aspmx.l.google.com.
yourdomain.com.    MX    5     alt1.aspmx.l.google.com.
yourdomain.com.    MX    5     alt2.aspmx.l.google.com.
yourdomain.com.    MX    10    alt3.aspmx.l.google.com.
yourdomain.com.    MX    10    alt4.aspmx.l.google.com.

How the sending server handles this:

1. Try the server with the lowest priority number first (priority 1: aspmx.l.google.com)
2. If it is unavailable, try the next level (priority 5: alt1 or alt2, chosen randomly since they have equal priority)
3. If those are also unavailable, try the next level (priority 10: alt3 or alt4)
4. If all servers are unavailable, queue the email and retry later (typically for up to 5 days before bouncing)

When multiple records share the same priority value, the sending server picks randomly among them. This distributes load across servers – a basic form of load balancing.

MX records point to hostnames, not IP addresses

An MX record must point to a hostname (like aspmx.l.google.com ), not an IP address. The hostname must then have its own A record that resolves to an IP. This extra layer of indirection lets the email provider change their server IPs without requiring you to update your DNS.

Setting up MX records for Google Workspace#

Google Workspace (formerly G Suite) uses five MX records:

To set these up:

1. Go to your DNS provider’s management panel
2. Delete any existing MX records (they will conflict with Google’s)
3. Add all five records with the priorities shown above
4. Save and wait for DNS propagation

On GoDaddy

1. Go to My Products > DNS
2. Find the MX section or click Add Record and select MX
3. For each record: set Host to  @ , Points to to the server hostname, Priority to the value shown above
4. Delete any old MX records that do not point to Google

On Namecheap

1. Go to Domain List > Manage > Advanced DNS
2. Add each MX record: Host is  @ , Value is the server hostname, Priority as shown
3. Remove any pre-existing MX records

On Hostney

Go to Hosting > DNS Zone Editor in the control panel. Add the MX records with the correct priorities and hostnames. Remove any default MX records that were created during initial setup, as they will conflict with Google’s mail servers.

Setting up MX records for Microsoft 365#

Microsoft 365 typically uses a single MX record that points to a domain-specific hostname:

Replace yourdomain-com with your actual domain, using hyphens instead of dots. For example, if your domain is example.com , the MX hostname is example-com.mail.protection.outlook.com .

Microsoft provides the exact record in the Microsoft 365 admin center under Settings > Domains > DNS records.

Setting up MX records for other providers#

Zoho Mail

ProtonMail

Self-hosted mail server

If you run your own mail server:

Make sure mail.yourdomain.com has an A record pointing to your mail server’s IP address. Without the A record, the MX record resolves to nothing and email delivery fails.

Verifying MX records#

Using the Hostney MX lookup tool

Go to tools.hostney.com/mx and enter your domain. The tool queries DNS and shows all MX records with their priorities and the IP addresses they resolve to.

Using dig

dig MX yourdomain.com +short

Output:

1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

The number before each hostname is the priority.

Using nslookup

On Windows:

nslookup -type=mx yourdomain.com

Verify the mail server responds

After confirming the MX records exist, verify the mail server is actually accepting connections:

dig +short aspmx.l.google.com

This resolves the mail server hostname to an IP address. If it returns an IP, the hostname is valid.

To test the actual mail server connection:

telnet aspmx.l.google.com 25

If the connection succeeds, you see a greeting line from the mail server (something like 220 mx.google.com ESMTP ). Type quit to disconnect. If the connection times out or is refused, the mail server is not accepting connections from your network, which could indicate a firewall issue or incorrect hostname.

How MX records interact with SPF, DKIM, and DMARC#

MX records handle inbound email routing – where email for your domain is delivered. SPF, DKIM, and DMARC handle outbound email authentication – proving that email sent from your domain is legitimate.

They are separate concerns but often configured at the same time when setting up email for a domain:

1. MX records tell the world where to deliver email addressed to your domain
2. SPF tells the world which servers are allowed to send email from your domain
3. DKIM proves that outgoing email was not tampered with
4. DMARC ties SPF and DKIM together with a policy

A common mistake is setting up MX records for Google Workspace but forgetting to add Google’s SPF include ( include:_spf.google.com ). Inbound email works fine, but outbound email from your Google Workspace account fails SPF checks at the receiving end.

Common MX record mistakes#

Pointing MX records to an IP address

yourdomain.com.    MX    10    203.0.113.50    # WRONG

MX records must point to a hostname, not an IP address. This is defined in the DNS specification (RFC 5321). Some DNS providers silently accept an IP address, but many receiving mail servers reject it or handle it unpredictably.

The correct approach:

yourdomain.com.    MX    10    mail.yourdomain.com.
mail.yourdomain.com.    A    203.0.113.50

Pointing MX records to a CNAME

An MX record should not point to a hostname that is itself a CNAME. While some mail servers tolerate this, the RFC explicitly prohibits it, and some strict mail servers reject email when the MX target is a CNAME.

yourdomain.com.    MX    10    mail.yourdomain.com.     # Good - if mail.yourdomain.com has an A record
yourdomain.com.    MX    10    alias.yourdomain.com.    # Bad - if alias.yourdomain.com is a CNAME

Forgetting to remove old MX records

When switching email providers (for example, from a default mail server to Google Workspace), you must remove the old MX records. If old records remain alongside the new ones, some email is delivered to the old server and some to the new one, depending on which priority the sending server picks. This results in missing emails with no error messages – the email is delivered successfully, just to the wrong place.

Wrong priority values

Priority values are relative, not absolute. The actual numbers do not matter – only their relationship to each other. Priority 1 and priority 10 work the same as priority 10 and priority 100. The lower number is always tried first.

A common confusion: people assume higher numbers mean higher priority (like a ranking). In MX records, it is the opposite. Lower numbers mean higher priority.

Missing A record for the mail server hostname

If your MX record points to mail.yourdomain.com but that hostname has no A record, DNS resolution fails at the last step. The sending server finds your MX record, tries to resolve the hostname to an IP, gets nothing, and the email bounces.

Verify that every hostname in your MX records resolves to an IP:

dig +short mail.yourdomain.com

If this returns nothing, the A record is missing.

TTL too high during migration

When migrating email providers, lower the TTL on your MX records before making the change. A TTL of 3600 (1 hour) means DNS resolvers cache the old records for up to an hour after you change them. During that window, email is still delivered to the old server.

Before migration:

1. Lower the TTL on existing MX records to 300 (5 minutes)
2. Wait for the old TTL to expire (up to the previous TTL duration)
3. Change the MX records to the new provider
4. Email starts flowing to the new provider within 5 minutes
5. After confirming everything works, raise the TTL back to a normal value (3600 or higher)

MX records and email delivery without MX#

What happens if a domain has no MX records at all? According to the DNS specification, the sending server falls back to the domain’s A record and attempts to deliver email directly to that IP address. In practice, this rarely works because web servers are not configured to accept email.

Some domains intentionally have no MX records because they do not receive email. But this fallback behavior means they might still receive connection attempts on port 25. To explicitly prevent email delivery to a domain that should not receive email, add a null MX record:

yourdomain.com.    MX    0    .

The single dot means “no mail server.” This tells sending servers that the domain does not accept email, and they should not attempt delivery. This is defined in RFC 7505.

DNS propagation and email#

After changing MX records, there is a propagation period where different DNS servers around the world may return different results. Some may have the old records cached, others may have the new ones. During this period:

• Email sent from servers that have cached the old records goes to the old mail server
• Email sent from servers that have the new records goes to the new mail server
• No email is lost (assuming both old and new servers are running)

The propagation time depends on the TTL. With a TTL of 3600 (1 hour), most DNS servers update within 1-2 hours. With a TTL of 86400 (24 hours), it can take up to a full day.

If you recently changed your DNS servers or flushed your local DNS cache and are not seeing the updated records, see How to flush DNS cache on Linux, Mac, and Windows for clearing cached records on your local machine.

MX records on Hostney#

On Hostney, MX records are managed through Hosting > DNS Zone Editor in the control panel. Since Hostney does not provide email services, you will configure MX records to point to your email provider (Google Workspace, Microsoft 365, or whichever service you use).

When setting up a new domain on Hostney, check whether any default MX records were created automatically. If they exist and you are using an external email provider, remove them before adding your provider’s MX records to avoid routing conflicts.

Verify your MX configuration at tools.hostney.com/mx after making changes.