MX Records Explained: How Email Finds Your Mail Server

Short answer: An MX (mail exchanger) record is a DNS record that tells other mail servers which host accepts e-mail for your domain. Each MX record has a priority number and a host name; senders try the lowest number first and fall back to higher ones. Correct MX records must point to host names (not IP addresses or CNAMEs), list only your current mail provider, and be checked after every provider or DNS change.

What MX records do

When someone sends a message to [email protected], their mail server needs to know where to deliver it. It asks DNS for the MX records of yourdomain.com, gets back one or more host names with priorities, looks up the IP addresses of those hosts and connects to the best one. Without MX records, delivery either fails or falls back to the domain’s A record, which usually points to a web server that does not accept mail.

MX records only concern incoming mail. They do not decide which servers send your outgoing mail; that is the job of your mail provider, and SPF describes which servers are allowed to do it. The two often point to the same provider, but they are separate settings, and confusing them causes many support tickets.

A typical set of MX records for a hosted provider looks like this:

• yourdomain.com. MX 10 mx1.mailprovider.example.
• yourdomain.com. MX 20 mx2.mailprovider.example.

Some providers use a single MX record with a highly available host behind it. Others give you several. Always copy exactly what the provider’s documentation lists for your account.

How priority numbers work

The number in front of the host name is the preference value. Lower means more preferred. A sending server tries the lowest value first; if that host is unreachable, it tries the next. If several records share the same value, senders spread the load between them roughly at random.

The actual numbers do not matter, only their order. 1 and 5 behave the same as 10 and 50. Providers pick values that make room for inserting records later.

A backup MX with a higher number used to be common for self-hosted mail: if the main server went down, a backup would queue mail until it came back. With hosted providers that run redundant infrastructure, a separate backup MX is rarely needed, and a poorly maintained backup server is a well-known path for spam, because attackers deliver to the backup to bypass the main server’s filtering.

Rules MX records must follow

• Point to a host name, not an IP address. An MX value like 203.0.113.10 is invalid. Create an A record for a host such as mail.yourdomain.com and point the MX to it.
• Do not point MX to a CNAME. The standards say the MX target must have its own A or AAAA record. Many servers tolerate a CNAME, but some do not, and it is a common cause of intermittent delivery failures.
• Put MX records on the right name. Records for yourdomain.com are published at the root, often written as @. Subdomains that receive mail need their own MX records.
• Include the trailing dot where your DNS panel expects it. In raw zone files, a host name without a final dot gets the domain appended, producing mx1.mailprovider.example.yourdomain.com. Web panels usually handle this, but check the result from outside.
• Remove records you no longer use. Mixed MX records from two providers mean some mail goes to the old provider, where nobody reads it.

Checking your MX records

From a terminal, run dig MX yourdomain.com +short on macOS or Linux, or nslookup -type=MX yourdomain.com on Windows. You should see only the host names your current provider specifies, with their priorities. Then confirm that each host resolves to an IP address with dig A hostname +short.

Also check from the provider’s side. Google Workspace, Microsoft 365 and most hosting control panels show whether they detect correct MX records for the domain. And send a test message from an external account, such as a personal Gmail address, to a mailbox on your domain. If it arrives, the route works end to end.

Changing MX records when you switch provider

Moving mail from one provider to another is the moment when MX mistakes cost the most. A safe order:

1. Create the mailboxes at the new provider first, and verify the domain there.
2. Lower the TTL of the existing MX records a day or two before the switch, for example to 300 seconds, so the change spreads quickly.
3. Replace the MX records with the new provider’s values in a single edit. Do not leave the old ones “just in case”: senders would keep delivering to them.
4. Keep the old mailboxes active for a few days. Some senders cached the old records, and mail may still arrive there until the old TTL expires.
5. Update SPF and DKIM for the new provider’s outgoing mail. MX handles incoming mail only.
6. Migrate or export old mail once the flow has moved.
7. Raise the TTL again when everything is stable.

Common MX problems and their symptoms

Subdomains, split delivery and gateways

Larger setups sometimes need more than one simple provider. Three patterns are common:

• Subdomains with their own mail. A support system may receive replies at help.yourdomain.com, or a newsletter platform may handle bounces on news.yourdomain.com. Each of these subdomains needs its own MX records, pointing to the service that processes that mail, while the root domain keeps pointing to your mailbox provider.
• Security gateways. Some organisations route incoming mail through a filtering service first. In that case the MX records point to the gateway, and the gateway forwards clean mail to the mailbox provider. The provider must then be configured to accept mail from the gateway and, ideally, reject direct delivery that bypasses it.
• Split delivery during migrations. Some providers support routing unknown recipients to a second system while mailboxes move in stages. This is configured inside the provider, not by mixing MX records from two providers.

In all three cases, write down what each record is for. MX records that nobody can explain are usually the ones removed by mistake during the next cleanup.

Domains that should not receive mail

Many businesses own extra domains: old brand names, typo variants, campaign domains. If they never receive mail, say so explicitly with a null MX record, defined in RFC 7505: a single MX record with priority 0 and a host of just a dot (MX 0 .). Senders then know immediately that the domain accepts no mail and bounce messages quickly instead of retrying for days.

Combine the null MX with an SPF record of v=spf1 -all and a DMARC record with p=reject. Together they tell the world that the domain neither sends nor receives mail, which makes it much less useful for spoofing.

MX records and deliverability

It may seem that incoming routing has nothing to do with whether your outgoing mail reaches the inbox. In practice there is a connection. Some receivers check that the sender’s domain can receive mail, because a domain that cannot accept replies or bounces looks disposable. Bounce handling also depends on it: if your envelope sender domain has no working MX, bounces vanish, and you keep sending to dead addresses, which hurts reputation. And DMARC reports sent to an address on your domain need working MX records to arrive.

Site AI Audit includes MX records in its e-mail checks next to SPF, DKIM and DMARC, so a domain with missing or broken MX records shows up in the same report as its website findings. Paid plans repeat the checks and alert you when something changes unexpectedly, such as MX records disappearing after a DNS migration. A free check is the quickest way to see the current state.

Related reading

• SPF Record Explained: What It Does and How to Set It Up
• Why Are My Emails Going to Spam? 12 Causes and Fixes
• DMARC Explained: Policies, Alignment and a Safe Rollout

The bottom line

MX records are a few lines of DNS that decide whether anyone can e-mail you. Point them to host names with their own A records, list only your current provider, lower the TTL before changes and test from outside afterwards. For domains that never receive mail, publish a null MX, and remember that MX covers incoming mail only: outgoing mail still needs SPF, DKIM and DMARC.

FAQ

How many MX records should my domain have?

As many as your mail provider specifies, often one to five. What matters is that they all belong to the same current provider and point to valid host names.

What does the MX priority number mean?

It is a preference value: lower numbers are tried first. Records with equal numbers share the load. The absolute values do not matter, only their order.

Can an MX record point to an IP address?

No. An MX record must point to a host name that has its own A or AAAA record. Create a host name for the server and point the MX record to that name.

How long does an MX change take to work?

It depends on the TTL of the old records, commonly from a few minutes to a day. Senders that cached the old values keep using them until the TTL expires, so keep the old mailboxes running briefly.

Do MX records affect outgoing e-mail?

Not directly. MX records control where incoming mail goes. Outgoing mail is authorised by SPF and signed by DKIM, but a working MX is still needed for replies, bounces and DMARC reports.

What is a null MX record?

A single MX record with priority 0 and a host of “.” that declares the domain accepts no mail. It is useful for parked or brand-protection domains, together with a strict SPF and DMARC record.