MX (Mail Exchanger) records tell the world which servers accept email for your domain. When someone sends mail to [email protected], their mail server looks up the MX records of example.com and delivers to the listed host. Get them wrong, and mail silently goes nowhere, or to the wrong place. Here’s how they work and how to set them up.

Anatomy

example.com.   3600   IN   MX   10   mail.example.com.
                                ^^   ^^^^^^^^^^^^^^^^^
                           priority  mail server hostname
mail.example.com. 3600 IN  A        203.0.113.25
  • Priority (preference): a lower number is tried first.
  • Target: a hostname with its own A/AAAA records.

Priorities and multiple MX records

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

Senders try mx1 first, and fall back to mx2 if it’s unreachable. Equal priorities spread the load between servers randomly.

A backup MX (a lower-priority server that accepts and queues mail when the primary is down) used to be common. Today it often causes more spam problems than it solves, because spammers target backup MXs that have weaker filtering. Sending servers queue and retry for days anyway, so for most small setups a single MX (or the provider’s own redundant set) is fine.

Common setups

Google Workspace

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

(Older setups list five aspmx.l.google.com records. Both work. Follow Google’s current instructions.)

Microsoft 365

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

The exact hostname is shown in your Microsoft 365 admin centre.

Your own mail server on a VPS

example.com.        MX   10   mail.example.com.
mail.example.com.   A         203.0.113.25

Plus everything a mail server needs to get mail delivered, not just received: a PTR (reverse DNS) record matching mail.example.com, SPF, DKIM, DMARC and an open outbound port 25. See PTR records, SPF, DKIM and DMARC and Postfix and Dovecot mail server.

On VPS.DO, outbound mail and rDNS are available on USA VPS plans. See email VPS.

Website on a VPS, email elsewhere

Very common: the A record points to your VPS, and the MX records point to Google, Microsoft or a mail host. They’re independent, so moving the website doesn’t affect email, as long as you don’t delete the MX records when changing DNS providers.

Domain that sends no email

If a domain shouldn’t receive mail at all, publish a null MX (RFC 7505), and an SPF that allows nothing:

example.com.   MX    0   .
example.com.   TXT   "v=spf1 -all"

Rules MX records must follow

  • The target must be a hostname, not an IP address. MX 10 203.0.113.25 is invalid.
  • The target must not be a CNAME. It needs its own A/AAAA records. See A record vs CNAME.
  • MX is set on the domain (or subdomain) that appears after the @. For [email protected], support.example.com needs its own MX.
  • If a domain has no MX, senders fall back to its A record. Don’t rely on that.

Check your MX records

dig +short example.com MX
dig +short mail.example.com A
dig +short -x 203.0.113.25             # reverse DNS of the mail server

Test that the server answers on port 25:

nc -v mail.example.com 25          # expect a "220 … ESMTP" banner

See dig and netcat. Online tools (MXToolbox and similar) check MX, SMTP, blocklists and related records together.

Changing mail providers without losing mail

  1. Lower the MX TTL (e.g. to 300) a day before the switch. See DNS propagation.
  2. Create the mailboxes at the new provider, and migrate existing mail (IMAP sync).
  3. Update the MX records, and update SPF to include the new provider.
  4. Keep the old mailboxes active for a few days. Some senders deliver to the old MX until caches expire, and queued mail retries. Check them for stragglers.
  5. Raise the TTL again.

Troubleshooting

Symptom Likely cause
No mail arrives at all MX missing or wrong, target has no A record, port 25 blocked by a firewall
Some mail arrives, some doesn’t Old MX cached somewhere, or multiple MX with one broken server
Mail bounces “relay access denied” The MX server doesn’t know it’s responsible for the domain (not in its domain list)
Your outgoing mail lands in spam Not an MX issue: check SPF, DKIM, DMARC and PTR

Quick reference

Task Command / record
Show MX dig +short example.com MX
Basic own-server setup MX 10 mail.example.com. + A record
Disable mail for a domain MX 0 . + v=spf1 -all
Test SMTP nc -v mailhost 25

Related: DNS records explained and SMTP security.

  • DNS
  • Email
  • Networking