An MX record, short for Mail Exchange record, is a DNS record that tells the internet which mail server should receive email for a specific domain. That is how a sending mail server knows where to deliver a message when someone writes to an address such as name@yourdomain.com. Without a properly configured MX record, a website can still work normally, but email delivery will sooner or later start to fail.

At first glance, an MX record may look like a small technical detail hidden somewhere in DNS administration. In reality, it is one of the most important records connected to any domain that uses email. As soon as you rely on business email, hosted mail, Google Workspace, Microsoft 365 or another mail platform, the MX record becomes one of the key settings that decides whether incoming email reaches the right place at all.

What an MX record actually does in practice

When someone sends an email to an address on your domain, the sending server has to work out where that message should physically go. It does not deliver the email to “the domain” in a vague sense. It has to deliver it to a real mail server. That is exactly what the MX record is for.

In practical terms, an MX record acts like a routing instruction for incoming mail. If it is configured correctly, the message goes to the right mail server. If it is configured incorrectly, delivery may fail or the message may be sent to a different mail server than the administrator intended.

This is one of the important differences between web traffic and email traffic. A website usually points to an IP address through an A or AAAA record. Email delivery, however, normally works through MX records, which define which mail servers should be tried for the domain and in what order.

What an MX record looks like

An MX record usually contains two key pieces of information:

• the hostname of the mail server that should receive the email,
• the priority value that tells sending systems which server should be tried first.

The priority value is often the part that confuses people at the beginning. With MX records, a lower number means a higher priority. So if a domain has two MX records with values 10 and 20, the sending server will first try the server with priority 10. Only if that does not work will it move on to the server with priority 20.

In other words, an MX record does not only define where mail goes. It also defines the order in which mail servers should be attempted. That makes it possible to have a primary mail server and one or more backup servers.

Why a domain can have more than one MX record

A domain does not have to use only one MX record. In fact, it is common to use more than one. The reason is simple – reliability and delivery logic.

Sometimes multiple MX records are used as backup. If the main mail server is not available, the sending system can try the next one in the list. In other cases, some servers may be configured with the same priority so that delivery can be spread across multiple mail servers.

That is why checking MX records is not only about whether “some MX record exists”. It is also about whether the priorities make sense and whether the full set of MX records matches how the domain’s email infrastructure is actually supposed to work.

An MX record does not store email – it only tells other servers where to send it

This distinction matters. The MX record itself does not receive, store or manage email.

It is only a DNS instruction that tells other systems which mail server should receive the message. The actual mail handling is done by the mail server the MX record points to.

Put simply, the MX record is routing data, not the mailbox and not the mail application. If it is configured incorrectly, the problem is not that the email account itself is broken. The problem is that incoming mail may never reach the correct server in the first place.

What to watch out for when configuring MX records

One common mistake is assuming that any MX record will do as long as one exists. In reality, what matters is whether it points to the correct mail server, whether it matches the requirements of the mail provider you are using, and whether the priority values are set properly.

Another important technical point is that an MX record should not point to a CNAME. In practice, the MX target should be a hostname that resolves through its own A or AAAA record. This may sound like a small detail, but it matters a great deal in email operations. If the MX target is configured incorrectly, delivery and compatibility problems can follow.

A further common issue appears during migration. An administrator changes the MX records while moving to a new email service, but the new mail environment is not fully ready yet. The domain then starts routing mail to the new destination before the rest of the mail setup is in place.

What if a domain is not supposed to receive email at all?

Not every domain has to accept incoming email. Some domains exist only for a website, for technical purposes or for redirection, and there is no reason for anyone to send mail to them.

For these cases, there is also the concept of a null MX. This is an explicit DNS statement that the domain does not accept email. It is a more advanced configuration detail, but a useful one. If a domain truly does not receive mail, it is cleaner to say so explicitly than to leave sending servers guessing or attempting delivery unnecessarily.

In practical terms, null MX is about making the domain’s intent clear. It does not make mail work better – it tells the internet that the domain is not meant to receive mail in the first place.

What happens if an MX record is missing?

If a domain has no MX record, that does not automatically mean email can never be delivered. Under SMTP rules, a sending system may in some cases fall back to the A or AAAA record of the domain itself. But that is not a state a normal mail setup should rely on.

In practical terms, the rule is simple: if a domain is supposed to receive email, it should have correct MX records. Depending on fallback behaviour is unnecessary risk and often leads to confusion when something breaks in real operation.

One especially important point is this: a website can still work even if MX records are missing or wrong. Your email cannot. That is why MX records are one of the first things checked when mail on a domain is not arriving properly.

How MX records relate to other email DNS records

An MX record handles the routing of incoming mail, but that is not the whole DNS layer of email. In practice, it is closely connected to other records, especially SPF, DKIM and DMARC.

This matters because healthy email operation is not only about where a message should be delivered. It is also about how the sender is authenticated, how domain abuse is limited and how the domain’s trustworthiness is communicated to receiving systems. The MX record solves one critical part of the mail setup, but not the whole thing.

Why MX record changes do not take effect immediately

Like other DNS changes, MX record updates do not become visible across the whole internet instantly. The reason is caching and the TTL value, which stands for Time to Live. DNS resolvers keep previous answers in memory for a limited period and only fetch the new version when that period ends.

This means that after changing mail provider or moving to a new mail server, some parts of the world may still deliver mail based on the old settings for a while. That is why these changes should be handled carefully, ideally only when the new mail servers and the rest of the supporting mail setup are already fully prepared.

Where MX records most often come up in real life

MX records are most often dealt with when setting up business email, moving to Google Workspace or Microsoft 365, changing hosting provider or troubleshooting delivery problems. These are exactly the moments when it becomes clear that a website and email are two different services and that each relies on a different part of the DNS setup.

For a website owner, company administrator or business founder, the practical lesson is simple: if the domain uses email, MX records are among the most critical settings to keep under control.

Why this term is worth understanding even outside technical roles

MX records are one of those DNS terms that most people only run into when mail stops working. Yet they are one of the clearest examples of the fact that a domain is not only about the website. It is also about other services that need to be pointed correctly and kept in sync.

If you understand what an MX record does, it becomes much easier to understand why the website can work normally while email does not. And in everyday business reality, that is often more important than people expect – especially on company domains, where reliable email delivery may matter even more than the website itself.

That is why MX records are worth understanding even outside technical professions. They are a quiet part of DNS, but one of the most important ones whenever a domain is expected to receive email reliably.

Related terms

• DNS – an MX record is one type of DNS record, and its role only makes full sense within the wider logic of DNS.
• Nameservers – MX records are stored on the authoritative nameservers for a domain, and sending systems look them up there through DNS resolution.
• TTL (Time to Live) – defines how long systems may keep MX records in cache before they fetch an updated version.
• Hostname – the specific server name the MX record points to. In practical terms, this is the mail server hostname that should receive email for the domain.
• CNAME – a DNS record type that points one name to another name. For MX, this matters because the MX target should not be a CNAME alias, but a hostname with its own A or AAAA record.
• SMTP – the protocol used for email transport, which relies on MX records to decide where incoming mail should be delivered.
• SPF, DKIM, DMARC – related email authentication records that show email setup is not only about routing, but also about verification, trust and domain protection.