MX Records Explained: How Email Finds Your Mail Server

Q: Do I need an MX record if my domain doesn't receive email?

You should publish a null MX (MX 0 ., RFC 7505). Without any MX, senders fall back to your website's A record and may queue mail for days. A null MX makes them fail immediately and clearly.

An MX (mail exchanger) record is a DNS record that tells other mail servers which host accepts email for your domain. Each MX record has a priority number and a hostname; senders try the lowest number first. To receive email at you@example.com, your domain needs MX records pointing to your email provider, for example example.com MX 10 mx.zomail.io.

What an MX record is

When someone sends a message to anna@example.com, their mail server needs to know where to deliver it. It asks DNS for the MX records of example.com, gets back one or more hostnames, looks up the IP addresses of those hosts and opens an SMTP connection to deliver the message.

MX records only control incoming mail. They have nothing to do with which servers are allowed to send mail as your domain; that is the job of SPF, DKIM and DMARC. They also don't affect your website: you can host your site in one place and your email somewhere else, which is how most businesses work.

An MX record looks like this in a zone file:

example.com.   3600   IN   MX   10   mx.zomail.io.

Part	Example	Meaning
Name	`example.com.`	The domain receiving mail (`@` in most DNS panels).
TTL	`3600`	How long resolvers may cache the answer, in seconds.
Class and type	`IN MX`	Internet class, mail exchanger.
Priority	`10`	Preference value; lower is tried first.
Target	`mx.zomail.io.`	Hostname of the server that accepts mail.

How MX priority works

The number in an MX record is called the preference in RFC 5321, but most DNS panels label it "priority". Sending servers sort MX records by this number and try the lowest value first. If that host is unreachable or returns a temporary error, they move to the next one.

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

Here mx1 receives mail normally and mx2 is used only if mx1 cannot be reached. When two records share the same number, senders pick between them at random, which spreads load:

example.com.   MX   10   mx-a.example.net.
example.com.   MX   10   mx-b.example.net.

The actual values don't matter, only their order: 10 and 20 behave exactly like 1 and 2. Large providers usually give you the full set of records and priorities to copy.

Rules an MX record must follow

These come straight from the DNS and SMTP standards, and breaking them causes hard-to-diagnose delivery failures:

The target must be a hostname, not an IP address. MX 10 203.0.113.25 is invalid. Point the MX at a name that has A and/or AAAA records.
The target must not be a CNAME. RFC 2181 and RFC 5321 require the MX target to have address records directly. Many servers tolerate a CNAME, but some do not.
No MX means "try the A record". If a domain has no MX records at all, senders fall back to delivering to the domain's own A/AAAA address (the "implicit MX"). That is rarely what you want, which is why domains that should receive no mail publish a null MX.
Null MX (RFC 7505). A single record example.com. MX 0 . declares that the domain accepts no email. Senders fail immediately instead of retrying for days. It is ideal for parked or web-only domains, combined with SPF v=spf1 -all and DMARC p=reject (see our DMARC policy guide).
Subdomains are separate. MX records on example.com do not cover support.example.com. A subdomain that should receive mail needs its own MX records.

How to check your MX records

From a terminal:

dig +short MX example.com
nslookup -type=MX example.com

A correctly configured domain returns something like 10 mx.zomail.io.. If you see several providers mixed together, for example your old host and your new one, you have a problem to fix (see below). Online DNS lookup tools give the same answer if you prefer a browser.

Changing MX records when you switch email provider

Changing MX is the moment mail starts flowing to your new provider, so a little planning avoids lost messages.

Set up the new service first. Add your domain, verify it, and create every mailbox, alias and group before touching MX. In Zomail, the domain page lists the records to create and checks each one.
Lower the TTL a day ahead. Change the TTL of your existing MX records to 300 seconds at least one full old-TTL period before the switch, so caches expire quickly.
Replace the MX records. Delete the old provider's MX records and add the new ones. Don't keep the old records "as backup": senders would split mail between both systems.
Keep the old mailbox open for a few days. Some servers cache old answers or retry queued mail to the old host. Check it daily and move stragglers across.
Migrate existing mail. Copy old messages over IMAP; see the migration guide.
Update SPF and DKIM for the new provider at the same time, or outgoing mail may land in spam. Our guides on the SPF record and setting up DKIM cover both.

Common MX mistakes

Leftover MX records from the old provider mixed with the new ones. Some mail goes to each system; people swear they "never got" messages.
MX on the wrong name, such as mail.example.com instead of the root example.com (@).
DNS panel appending the domain twice, producing mx.zomail.io.example.com. In panels that do this, either add a trailing dot or follow the provider's instructions.
Proxying the mail host. If your MX points to a hostname on Cloudflare with the orange-cloud proxy on, SMTP traffic won't reach the server. Mail host records must be DNS-only.
Backup MX that accepts everything. A secondary MX run by a third party that doesn't know your valid addresses or apply the same spam filtering becomes a path for spam and backscatter. Modern providers run redundant MX hosts themselves; you rarely need a separate backup MX.
Expecting MX to fix sending problems. If your outgoing mail goes to spam, MX is not the cause; see why emails go to spam.

MX records with Zomail

For Zomail Cloud, your MX record points to mx.zomail.io; the exact record, priority and the rest of your DNS (verification, SPF, DKIM, DMARC, autoconfig and MTA-STS) are shown on your domain page, which checks each one live and warns you if your MX still points to another server. You can download a zone file or use one-click Domain Connect where your DNS provider supports it. Start with the getting started guide, and see plans on the pricing page.

FAQ

What does the number in an MX record mean?

It is the priority (preference). Sending servers try the lowest number first and use higher numbers only if the preferred host is unavailable. Records with equal numbers share the load randomly. Only the order matters, not the actual values.

Can an MX record point to an IP address?

No. An MX target must be a hostname with A or AAAA records. If your server only has an IP, create a hostname such as mail.example.com with an A record, then point the MX at that name.

How long does it take for an MX record change to work?

New lookups see the change as soon as caches expire, which is governed by the old record's TTL, often one hour and sometimes up to a day. Lowering the TTL to 300 seconds the day before the switch makes the change take effect within minutes.

Can I have two email providers on the same domain?

Not by mixing their MX records, because senders would deliver randomly to either. Split delivery between providers needs special routing on one of them. For most small businesses, the clean option is one provider per domain, or a separate subdomain for a different system.

Do I need an MX record if my domain doesn't receive email?

You should publish a null MX (MX 0 ., RFC 7505). Without any MX, senders fall back to your website's A record and may queue mail for days. A null MX makes them fail immediately and clearly.