What is an MX record?

Every email sent to your domain starts with a DNS question: where does mail for this domain go? The answer is your MX records. Get them right and mail flows to the server, or the filter, you chose. Get them wrong and mail goes somewhere you didn't intend, or nowhere.

What does an MX record do?

MX stands for mail exchanger. When someone sends a message to you@example.com, their mail server looks up the MX records for example.com. Each record names a host that accepts mail for the domain and gives it a priority number. The sending server then connects to one of those hosts and hands the message over using SMTP.

An MX record has three parts you care about:

A fourth value, the TTL (time to live), tells resolvers how many seconds they may cache the answer. It matters when you change records, because old answers stay in caches until the TTL runs out.

Your MX records only control inbound mail. They don't decide how your outgoing mail is sent, and they don't affect SPF unless you use the mx mechanism in your SPF record. Outbound mail is covered by your SPF and DKIM setup instead.

How do MX priority values work?

The rules come from RFC 5321, section 5.1. In plain terms:

1. The sender looks up all MX records for the domain.
2. It sorts them by priority. The RFC says "lower numbers are more preferred than higher ones."
3. If several records share the lowest number, the sender must pick among them at random. That spreads the load.
4. It tries the preferred host. If it can't connect, or gets a temporary error, it tries the next host in the list.
5. If every host fails, it queues the message and tries again later.

The numbers are relative. Priorities 1 and 2 behave exactly like 10 and 20. What matters is which number is lowest and which records share the same value.

What if a domain has no MX record?

If there are no MX records at all, RFC 5321 says the sender treats the domain as if it had an implicit MX with priority 0, pointing at the domain itself. In practice, the sender tries the domain's own A or AAAA address. That can send mail to your web server by accident, which is rarely what you want.

What is a null MX?

A domain that never receives email can say so with a null MX, defined in RFC 7505. It's a single record with priority 0 and a target of .:

example.org.  MX  0 .

Senders then know straight away that mail can't be delivered, instead of retrying for days. A domain with a null MX must not publish any other MX record. In our scan of the top 1,000 domains in October 2026, 9 domains published a null MX.

What happens when the main server is down?

Less than people fear. SMTP was built to retry. RFC 5321 (section 4.5.4.1) says the retry interval should be at least 30 minutes and the give-up time "generally needs to be at least 4-5 days." So when your primary host is unreachable for a few hours, a well-behaved sender keeps the message and delivers it later.

That's why most domains don't need a backup MX host. Large providers already run many servers behind a single host name. If you want more detail, read what happens to email when your server is down.

Why is a backup MX risky with a spam filter?

A backup MX is a second record with a higher priority number, meant to catch mail when the primary is down. With a filtering service in front of your mailboxes, a backup MX that doesn't run the same filtering is a hole.

Spammers don't have to follow the priority order. Some deliver straight to the highest-numbered host, because backup servers are often filtered less, or not at all. Whatever reaches that host skips your filter.

Common ways this happens:

• The old MX record was never removed. You pointed MX at a filter but left the Microsoft 365 or Google host as a "backup" at priority 20.
• A hosting company's default backup MX still sits in the zone from years ago.
• The mailbox provider accepts mail from anyone. Even without a second MX record, an attacker who knows your Microsoft 365 host name can send directly to it.

Microsoft's own guidance is clear. Its DNS records reference says you can have multiple MX records, "however, that can cause problems for mail delivery," and that a single MX record directing mail to one system "removes many potential problems." Its third-party filtering guide says your MX record must point to the filtering service, and that you should lock down Exchange Online so it only accepts mail from that service.

The fix has two parts:

1. Every MX record points to the filter. No record should point directly at your mailbox provider.
2. The mailbox provider only accepts mail from the filter. In Microsoft 365, that's a Partner inbound connector restricted to the filter's certificate or IP addresses. In Google Workspace, it's an inbound gateway with the option to reject mail from other senders. Our guide on blocking direct-to-tenant bypass walks through both.

If you're worried about outages, solve that at the filter instead. A filtering service that holds mail while your server is down gives you the benefit of a backup MX without the bypass. iBlockSpam spools mail for up to 5 days when your mail server is unreachable.

MX record examples for Microsoft 365 and Google Workspace

These are the formats each provider documents. Always copy the exact value from your own admin console.

Microsoft 365

Microsoft's DNS reference gives a single MX record whose target is <MX token>.mail.protection.outlook.com, with a TTL of 3600 and a priority lower than any other MX record:

example.com.  3600  MX  0 example-com.mail.protection.outlook.com.

The token is specific to your domain. You find it in the Microsoft 365 admin center under Domains, by selecting your domain and opening its DNS records. Microsoft also notes that when you change the MX record, all mail for the domain starts arriving at Microsoft 365.

Google Workspace

Google's MX setup page recommends a single record, smtp.google.com, with priority 1:

example.com.  3600  MX  1 smtp.google.com.

Google says "the legacy MX record values are still supported," so older domains with five aspmx records keep working.

With an inbound filtering service

When a filter sits in front of either platform, the MX records point to the filter's hosts and nothing else:

example.com.  3600  MX  10 mx1.filter.example.net.
example.com.  3600  MX  20 mx2.filter.example.net.

Here both hosts belong to the same filtering service and apply the same rules, so the second record is redundancy, not a bypass. The filter then delivers clean mail to your Microsoft 365 or Google host. Our platform guide for Microsoft 365 and platform guide for Google Workspace cover the connector and gateway steps.

How do you check your MX records?

You can check from any computer in a minute.

1. Use a lookup tool. Enter your domain in the MX Lookup tool. It lists each record, its priority, and the addresses each host resolves to.
2. Or use the command line. On macOS or Linux, run dig MX example.com +short. On Windows, run nslookup -type=mx example.com.
3. Read the priorities. Note which host has the lowest number. That's where most mail goes.
4. Look for strays. Any record pointing somewhere you don't recognize, or straight to your mailbox provider when you use a filter, needs a decision.
5. Check that each host resolves. A target host with no A or AAAA record is a dead end. A target that is a CNAME breaks RFC 2181, section 10.3, which says an MX value must not be an alias, and some senders will refuse it.
6. Check the TTL. If you plan a change, lower it to 300 seconds a day ahead.

Remember what a lookup can't tell you. It shows where senders deliver mail first. It can't prove that your mailbox provider rejects mail sent straight to it, or that your filter actually scanned a given message. For that, open a recent message's headers in the Email Header Analyzer and check which servers it passed through.

Common MX mistakes

If you're planning a move, read how to change MX records without losing email first.

Next steps

1. Run your domain through the MX Lookup and write down every record and priority.
2. Remove any record that points to a retired system or skips your filter.
3. If you use a filtering service, confirm your mailbox provider only accepts mail from it.
4. For a wider view of MX, SPF and DMARC together, run the free Email Health Check. If you're weighing a filter for the whole domain, how iBlockSpam works explains the MX change and setup steps.

MX records are easy to change by accident, for example during a website move. The Free Domain Watch checks your public MX, SPF, DMARC and MTA-STS records weekly and emails you when they change.

Read more email security basics.