What Is an MX Record? MX Records Explained Simply (2026)

What is an MX record? An MX record (MX stands for Mail Exchange) is a DNS entry that tells the world which server accepts email for a domain. When someone writes to hallo@getmind.io, their mail server first asks DNS: “Who takes mail for getmind.io?” The answer is the MX record. Without it, the sender has no idea where to deliver the message.

That makes the MX record a bit like the mailbox sign on a front door. A domain’s website can live on a completely different server than its mailboxes, and the MX record is exactly what separates the two: “where does the website live” versus “where does the post arrive”.

We run several domains and at least one mail server of our own, and for this article we wanted hard numbers rather than a textbook summary. On 10 November 2026, from our production server (Hetzner, Ubuntu 24.04), we queried the MX records of nine major mail providers and our own domains, and used our own Postfix mail server to test what happens when something is missing. Three findings up front:

1. Gmail has five MX records with five different priorities. Outlook.com has exactly one. Both are reliable, because the single Outlook name resolves to four IP addresses.

2. Two of our own domains have no MX record at all. Mail sent there does not vanish. It goes to the website’s IP address, and on that IP we actually had a mail server running that had to turn it away.

3. example.com uses a null MX (0 .) to say explicitly “no mail here”. Our own mail server rejected a test message with that sender domain instantly.

If DNS as a whole is still fuzzy, our article What is DNS? covers resolvers, nameservers and TTL from scratch. This one focuses on the single record your email depends on.

What is an MX record exactly? The anatomy of an MX entry

An MX record has a handful of parts. Here is ours, queried with dig:

$ dig MX getmind.io +noall +answer
getmind.io.    300    IN    MX    10 ff-web.de.

From left to right:

Two details regularly surprise beginners.

First, an MX record contains no IP address, only a hostname. The sending server has to make a second lookup to find out which address ff-web.de has. For us that is 89.22.110.102. An MX record that points straight at an IP is invalid according to the standard. Some DNS panels accept it anyway, and then people wonder why part of their mail never shows up.

Second, an MX record has a number in front of the target. That is the priority, also called preference. It is the reason an MX record is more than a signpost: it can describe a whole order of primary and fallback servers.

How does email delivery actually work?

When you send a message from Gmail to hallo@getmind.io, roughly this happens:

1. Gmail’s server takes the part after the @, which is getmind.io.
2. It asks DNS for the MX record of that domain and gets 10 ff-web.de.
3. It asks for the IP address of ff-web.de (A and AAAA records) and gets 89.22.110.102.
4. It opens a connection on port 25 and speaks SMTP to that server.
5. The receiving server checks sender, recipient, SPF, DKIM and spam signals, then accepts or rejects the message.

We replayed step 4 by hand for this article. Our mail server greets you like this:

$ (connection to ff-web.de on port 25)
220 ff-web.de ESMTP Postfix
EHLO test.getmind.io
250-ff-web.de
250-PIPELINING
250-SIZE 1024000000
250-STARTTLS
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 CHUNKING

That is the exact server our MX record points to. It offers STARTTLS for an encrypted connection and accepts messages up to roughly 1 GB. The MX record itself says none of this. It is only the address. What happens behind the door is up to the mail server.

One important point: the MX record only covers incoming mail. Which servers may send mail on your behalf is handled by other records, namely SPF, DKIM and DMARC. More on that below.

MX record priority: what do 5, 10 or 20 mean?

If a domain has several MX records, the priority decides the order. The rule is simple: the lowest number is tried first. If the sender cannot reach that server, it moves on to the next higher one. If several records share the same number, the sender picks among them at random.

The numbers themselves carry no meaning, only their relation to each other. 10 and 20 work exactly like 1 and 2 or 100 and 200. People tend to use steps of ten for a practical reason: you can slot another server in between later without renumbering everything.

Nine mail providers compared

How do the big players do it? On 10 November 2026 we queried the MX records of nine well-known providers. The TTL was taken directly from each provider’s authoritative nameserver, not from a cache.

Three strategies stand out.

The cascade (Gmail, Proton Mail): One primary server with the lowest number, then fallbacks with rising numbers. Gmail takes this to five levels. If gmail-smtp-in.l.google.com (priority 5) is unreachable, senders move on to alt1 (10), then alt2 (20), and so on.

Equal weight (WEB.DE, GMX, T-Online, Posteo, iCloud): Several servers sharing one number. Senders spread the load randomly, and if one server is down, they simply pick another from the group. Load balancing and redundancy in one.

The hybrid (mailbox.org): Four equal servers at 10 and a fifth at 50 as a last resort in case all four fail at the same time.

A single MX record is not automatically a risk

Outlook.com gets by with exactly one MX record. That sounds risky, but it is not. We checked: the name outlook-com.olc.protection.outlook.com resolves to four different IP addresses. The redundancy does not live in multiple MX records, but in multiple A records behind one name. A sending server simply tries them in turn.

For a small business or a side project, this is the most useful takeaway: one MX record is completely fine, as long as the mail provider behind it is properly set up. Our own 10 ff-web.de is a single record too. Adding a second, poorly maintained backup MX often makes things worse rather than better. More on that shortly.

The order in the DNS response does not matter

A detail we measured ourselves: we asked the resolver 1.1.1.1 for Gmail’s MX records twenty times in a row and noted which record appeared first in the response. Sometimes it was alt1 (priority 10), sometimes alt3 (30), sometimes the actual primary (5). The order changed on almost every query.

That is intentional and harmless. A correct mail server sorts the records by priority on its own. So if a lookup tool shows “the wrong” MX record at the top, there is nothing to fix. Only the number counts.

How to check the MX record of a domain

You can look up any domain’s MX record yourself in a few seconds. Depending on your system there are three tools.

On Linux and macOS with dig:

$ dig MX gmail.com +short
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

+short prints only the records. Without it you also see TTL, status and response time.

On Windows with nslookup:

nslookup -type=mx gmail.com

With host (short and readable):

$ host -t mx getmind.io
getmind.io mail is handled by 10 ff-web.de.

The output of host practically explains the MX record by itself: “mail is handled by”.

Ask the authoritative nameserver directly

If you have just changed an MX record, your usual resolver may still hand you the old answer from its cache. In that case, ask the authoritative nameserver directly. It always knows the current state:

$ dig NS getmind.io +short
launch1.spaceship.net.
launch2.spaceship.net.

$ dig @launch2.spaceship.net MX getmind.io +noall +answer
getmind.io.    300    IN    MX    10 ff-web.de.

If the new value shows up there, your change has landed correctly. Everything else is just waiting for old caches to expire.

Four possible answers and what they mean

During our lookups we ran into fundamentally different answers. Some look equally empty at first glance, but they mean completely different things:

Surprisingly few people know the difference between the second and third row, and it caught us out on our own domains.

Our finding: a domain without an MX record still receives mail

Two of our domains, heynyx.dev and nyx.fish, neither send nor receive email. So we never created an MX record for them. Makes sense, we thought: no MX, no mail.

That is wrong. The mail standard (RFC 5321, section 5.1) has a fallback rule for exactly this case, known as the implicit MX: if a domain has no MX record but does have an IP address (A or AAAA record), the sender should deliver the mail directly to that IP. The rule dates back to the early internet, when many domains had a single machine that did everything.

For heynyx.dev that means:

$ dig MX heynyx.dev +short
(no output)

$ dig A heynyx.dev +short
46.225.123.163

Any mail to anything@heynyx.dev would go to 46.225.123.163, the server that hosts the website. On most web servers port 25 is closed, so delivery fails after a few days and the sender gets a bounce. In our case it was different. On exactly that IP, a Postfix mail server runs for a shop project. We sent ourselves a test message to that address:

EHLO probe.getmind.io
MAIL FROM:<probe@getmind.io>
250 2.1.0 Ok
RCPT TO:<test@heynyx.dev>
454 4.7.1 <test@heynyx.dev>: Relay access denied

Our mail server did the right thing: it does not know heynyx.dev as one of its own domains and refuses the message instead of forwarding it. If it were misconfigured, it would be an open relay, and spammers could abuse it. Also note that 454 is a temporary error. A sending server will keep retrying for days before giving up (Postfix waits up to five days by default).

The lesson: “no MX record” does not mean “no mail”. If a domain really should not receive email, say so explicitly. That is what the null MX is for.

Null MX: how to say “no mail here” in DNS

A null MX (RFC 7505) is an MX record with priority 0 and a single dot as the target:

$ dig MX example.com +short
0 .

The dot means “no host”. A sender that sees this record knows immediately that there is no point in trying to deliver. Instead of days of retries, there is an instant, clear error.

The null MX also works in the opposite direction, and we tested that with our own mail server. We submitted a test message using the sender address probe@example.org. example.org has a null MX as well. The answer came back instantly:

MAIL FROM:<probe@example.org>
RCPT TO:<test@heynyx.dev>
550 5.7.27 <probe@example.org>: Sender address rejected:
    Domain example.org does not accept mail (nullMX)

Our Postfix rejected the message before even looking at the recipient. The logic: a domain that accepts no mail cannot receive replies or bounces either. A message claiming to come from such a domain is very likely forged.

So the null MX has two benefits for domains that only host websites:

• Senders find out immediately, instead of messages sitting in queues for days.
• Spammers have a harder time abusing your domain as a sender, because many mail servers reject such messages outright.

For a domain that does not use email at all, we recommend this set of three records:

example.de.          MX    0 .
example.de.          TXT   "v=spf1 -all"
_dmarc.example.de.   TXT   "v=DMARC1; p=reject;"

The null MX says “I receive nothing”, v=spf1 -all says “no server is allowed to send on my behalf”, and DMARC with p=reject asks every receiver to reject forged messages. example.com does exactly this and also publishes v=spf1 -all. For heynyx.dev and nyx.fish, this is now on our own to-do list.

How to set up an MX record step by step

How you create an MX record depends on your domain provider, but the steps are the same everywhere.

1. Get the values from your mail provider. Your mail provider (Google Workspace, Microsoft 365, Proton, Posteo, your web host or your own server) tells you which hostnames and priorities to enter. Copy them exactly, including every record if there are several.

2. Create a new record in your domain provider’s DNS settings. Type MX, name usually @ (meaning the domain itself, without a subdomain), the mail server’s hostname as the target, plus the priority.

3. Remove old MX records. This is the most common mistake during a migration: the new MX is added, the old one stays. If both have the same priority, part of the mail ends up at the old provider. If the old one has a lower number, all of it does.

4. Verify. Run dig MX yourdomain.com +short against the authoritative nameserver as shown above. Then send a test message from an outside account, for example a Gmail address.

5. Add SPF, DKIM and DMARC. The MX record only makes sure mail arrives. To keep your outgoing mail out of spam folders, you need the three protective records. Our own domain has them: v=spf1 a:ff-web.de mx ~all as SPF and a DMARC record that sends reports to a mailbox.

Lower the TTL before a migration

The TTL determines how long resolvers may cache the old answer. Gmail uses 3600 seconds (one hour), WEB.DE even 7200 seconds (two hours). Our own domain sits at 300 seconds.

If you plan to switch mail providers, set your MX record’s TTL to 300 seconds a day or two in advance. After the switch, every sender then moves to the new server within five minutes instead of knocking on the old one for hours. You can raise the TTL again afterwards.

Some comfort if you forgot: with email, a high TTL rarely loses anything. As long as the old server still accepts mail, messages simply land there and you fetch them via IMAP. It only gets critical once the old mailbox has already been cancelled.

Common MX record mistakes we see in practice

Most mail problems we have seen on our own and other people’s domains come down to a handful of mistakes.

The MX points to an IP address. The standard requires a hostname. Do not enter 10 89.22.110.102. Create an A record such as mail.example.com and point the MX at that.

The MX points to a CNAME. Also not allowed by the standard. The target of an MX record must have an A or AAAA record directly. Many mail servers follow the CNAME anyway, but you should not rely on it.

The target hostname does not exist. One typo in the hostname and the MX points into nothing. dig will still show the MX record just fine. You only notice when you look up the target’s IP and get nothing. Always check both steps: first dig MX, then dig A on the target.

The missing trailing dot. In zone files (BIND and friends), a hostname without a trailing dot is “relative to the zone”. mail.example.com becomes mail.example.com.example.com.. Web-based DNS panels usually add the dot for you. In zone files you have to set it yourself.

Subdomains do not inherit the MX. An MX record applies only to the exact name it sits on. We tested it: getmind.io has an MX, www.getmind.io does not. If you want to receive mail at info@shop.example.com, you need a separate MX record for shop.example.com.

The outdated backup MX. It used to be common to run a second mail server with a higher priority that queued mail while the primary was down. Today that is often more problem than solution. Spammers deliberately target backup MX servers, because they tend to have weaker spam filters and no list of valid recipients. Modern senders queue mail for up to five days and retry anyway. Only run a backup MX if it has the same filters and the same recipient list as the primary.

Changing the MX before the mailbox exists. A new MX record sends senders to the new server, but the mailbox has to exist there already. Otherwise the new server rejects messages with “user unknown”. Create mailboxes at the new provider first, then switch the MX.

MX record, SPF, DKIM and DMARC: who does what?

These four terms are often mentioned in the same breath and easily confused. Yet they have clearly separate jobs:

So the MX record is the only one of the four that concerns incoming mail. The other three protect your domain against people forging mail in its name and help your own messages get past spam filters. A classic mix-up: someone switches the MX to a new provider but forgets to update SPF. Mail keeps arriving, but outgoing messages from the new provider land in recipients’ spam folders.

If your MX points to your own mail server, it is worth looking at that server’s overall security. A mail server on port 25 is an attractive target. We show how to harden a Linux server in Linux server setup, and how to block repeated login attempts automatically in Fail2ban setup.

Checklist: is your MX record set correctly?

Before you start wondering why mail does not arrive, go through this list:

1. dig MX yourdomain.com +short returns the records your mail provider specifies, and no old ones.
2. Every target is a hostname, not an IP and not a CNAME.
3. dig A target-hostname +short returns an IP address for every target.
4. The priorities are right: the primary server has the lowest number.
5. Subdomains that should receive mail have their own MX.
6. Domains that should not receive mail have a null MX (0 .), plus v=spf1 -all and DMARC with p=reject.
7. SPF, DKIM and DMARC match the provider that actually sends.
8. Before a migration, the TTL has been lowered to 300 seconds.
9. A test message from an outside account has arrived.

MX record FAQ

What is an MX record in simple terms? An MX record is a DNS entry that says which server accepts email for a domain. It is the domain’s mailbox sign: senders look it up before delivering a message.

What does MX stand for? MX stands for Mail Exchange, meaning the server that receives mail on behalf of a domain.

What does the number in front of an MX record mean? That is the priority. Senders try the record with the lowest number first. If it is unreachable, they move on to the next higher one. Equal numbers mean the load is spread randomly across those servers.

Do I need more than one MX record? Not necessarily. Outlook.com uses a single one, because four IP addresses sit behind the name. For most domains, exactly what the mail provider specifies is enough. An extra, poorly maintained backup MX tends to do harm.

What happens if a domain has no MX record? Senders deliver mail to the IP address from the A or AAAA record (implicit MX under RFC 5321). If no mail server listens there, delivery fails after days. If you do not want to receive mail at all, set a null MX.

What is a null MX? An MX record with priority 0 and a dot as the target (0 .), defined in RFC 7505. It states explicitly that the domain accepts no mail. Senders give up immediately, and many mail servers reject messages that use such a domain as the sender. Our own Postfix did exactly that in our test with 550 5.7.27.

How long does it take for a new MX record to work? At the authoritative nameserver: immediately. Everywhere else: once the old TTL expires, usually somewhere between five minutes and a few hours. The often quoted “24 to 48 hours” is a worst-case rule of thumb, not the norm.

Can an MX record point to an IP address? Not according to the standard. The target must be a hostname with an A or AAAA record. Create a name such as mail.example.com for the IP and point the MX at it.

Can I host my website and email with different providers? Yes, that is exactly what the MX record is for. The A record points to the web server, the MX record to the mail server. The getmind.io website runs on a server at Hetzner, while its mail goes to an entirely different machine.

How do I find out which mail provider a domain uses? Look up its MX record. If the target ends in google.com, it is Google Workspace. outlook.com or protection.outlook.com means Microsoft 365. On Linux and macOS use dig MX domain.com +short, on Windows nslookup -type=mx domain.com.

Does the MX record affect whether my mail lands in spam? Only indirectly. For the deliverability of your outgoing mail, SPF, DKIM and DMARC are what matter. Some receivers do check whether the sender domain can accept mail at all, though. A domain without a working MX looks suspicious, and one with a null MX is often rejected outright.

Conclusion: what is an MX record, and what should you watch out for?

An MX record is the smallest DNS entry with the biggest impact on your inbox. It tells the whole world which server accepts your domain’s mail, and through its priority, in which order. The big providers show that there is no single right way to do it: Gmail uses a five-level cascade, Posteo four equal servers, Outlook.com a single name with four addresses behind it.

From our own tests we take away two points that hardly any quick explainer mentions. First: no MX record does not mean no mail. Without an MX, mail goes to the website’s IP, and if a mail server happens to run there, it had better be configured correctly. Second: if you do not want mail, say so. A null MX combined with v=spf1 -all and DMARC turns a silent domain into one that informs senders right away and makes life hard for forgers.

If you want to dig deeper into how DNS queries get answered at all and why changes sometimes take a while, continue with our article What is DNS?.