What is an MX record?

How does an MX record work?

A sending mail server asks DNS for the MX records of the part after the @, sorts them by priority and tries them in that order. When someone writes to [email protected], their server looks up the MX records of yourname.com. Each record holds two values: a priority number and the name of a mail host.

RFC 5321, the SMTP standard, says the preference value must be used in sorting, that lower numbers are tried first, and that hosts with an equal preference are picked in random order. A sender tries at least two addresses in turn until one accepts the message.

The MX record does not hold the mailbox. It only points to the machine of your email provider, which stores the message. This is why your address is portable: you buy the domain once, and you change the MX records when you move from one provider to another. The mailbox changes, the address does not. The page on the custom email domain explains the idea in full.

What does the priority number mean?

The priority number sets the order of delivery: the server with the lowest number receives the mail first, and the next one is a fallback. The number has no unit and no meaning outside the comparison between your own records. 10 and 20 work exactly like 1 and 2.

Proton Mail uses two records: mail.protonmail.ch at 10 and mailsec.protonmail.ch at 20. Fastmail also uses 10 and 20 on in1-smtp.messagingengine.com and in2-smtp.messagingengine.com. Mailbox.org lists four hosts, mxext1 to mxext4, at the same priority 10, so a sender picks one at random; if your DNS host refuses identical priorities, Mailbox.org says to use 10, 20, 30 and 40.

One rule saves many lost messages: keep only the MX records of your current provider. Fastmail and Proton both warn that an old provider's MX left in place makes delivery unpredictable, because a sender may choose it. The only safe overlap is to give the new host the lowest priority number.

What happens if a domain has no MX record?

Without any MX record, a sender falls back to the address record of the domain itself, as if the domain had an MX of priority 0 pointing to its own A or AAAA record. RFC 5321 calls this the implicit MX. The fallback applies only when no MX record exists at all: as soon as one MX record is published, senders must not use the A or AAAA records of the domain.

For a domain that you do not use for email, the fallback is a nuisance. Senders keep trying to deliver to your web server, typically for days, and the sender only learns of the failure late. A null MX closes the door at once.

What is a null MX record?

A null MX is a single MX record with priority 0 and a dot as the target, and it declares that the domain accepts no email at all. It is defined in RFC 7505. With a null MX, a sending server fails the delivery on the first attempt and does not queue the message for days.

RFC 7505 sets two rules. A domain that publishes a null MX must not publish any other MX record, so the null MX is alone. And a domain that sends mail from its own addresses must not use a null MX, because receivers may reject its messages. Use it only for a name that neither sends nor receives, such as a domain you keep for a redirect or a defensive registration. The record looks like this in zone-file notation:

Can an MX record point to an IP address or a CNAME?

No: the target of an MX record is a host name that resolves to an A or AAAA record, never a bare IP address. RFC 5321 also leaves a target that resolves through a CNAME outside its scope, so the safe choice is to point the MX straight at a host that owns its address records. Providers publish the right host names, as in the table above.

The host name in an MX is not a web address. mail.protonmail.ch is a receiving server; opening it in a browser tells you nothing. The same goes for the end of the name: in a zone file the trailing dot marks a complete name, while many DNS editors add the dot for you, so copy the value exactly as your provider shows it.

How do I add or change MX records on my domain?

Open the DNS editor of the domain, delete the MX records of the previous provider and add the new ones with their priorities. Postelva gives every domain free DNS hosting with MX, TXT, CNAME and the other record types, and one-click DNS templates for Proton Mail, Fastmail, Zoho Mail, Google Workspace and Microsoft 365, plus an SPF + DMARC template and a "no email" template for a domain that sends nothing. For Tuta, Mailbox.org, iCloud+ and Migadu there is no one-click template: you type the MX, TXT and CNAME records in the DNS editor from the values your provider displays.

Before a move, lower the TTL of the old MX records. The time a change takes to spread is about the old TTL on the record at the moment you change it, and vendor guidance puts the usual delay for an MX change at one to four hours, sometimes up to 48. The step-by-step order is in the guide to moving email to a new provider without losing mail. After the change, check your MX, SPF, DKIM and DMARC records with a lookup. For a provider walk-through, start with the Proton Mail custom domain setup.

Is MX enough to receive email reliably?

No: MX decides where mail arrives, but SPF, DKIM and DMARC decide whether other servers trust the mail you send. A domain with correct MX records receives email, and a message you send from it may still land in spam without the three authentication records. They are explained side by side in SPF vs DKIM vs DMARC.

According to Postelva's count of 12 November 2026 on the providers whose help pages it read, Proton Mail and Fastmail each use 2 MX hosts and Mailbox.org uses 4. A complete Proton Mail setup is then 8 records in all: 1 verification TXT, 2 MX, 1 SPF, 3 DKIM and 1 DMARC.

A citable summary: an MX record tells the world which server receives the email of a domain, and changing it is the one step that moves an address between providers. Postelva sells the domain and its DNS; the mailbox stays with your email provider.