Every email you send or receive depends on DNS records working behind the scenes. One of the most important is the MX record, a small piece of configuration that tells other mail servers where they should deliver email for your domain.
When an MX record is missing, outdated, or misconfigured, the consequences land on incoming mail directly: messages may be rejected, delayed, or eventually returned to the sender. For businesses that rely on email every day, that can turn a small DNS mistake into a very real communication problem.
In this guide, we’ll explain what an MX record is, how MX records work, what MX record priority means, and how they relate to email deliverability. We’ll also look at what the largest companies actually use, based on Allegrow’s analysis of the primary domains of the Fortune 500.
One important finding stands out: an MX record does not necessarily tell you where a company’s mailboxes are actually hosted. It often tells you which security gateway filters the company’s incoming email first.
Key takeaways
- An MX record tells other mail servers where to deliver email for your domain. It does not store messages, authorize outbound sending, or decide inbox placement. Those are separate jobs belonging to the receiving server, to SPF and DKIM, and to sender reputation.
- Lower priority numbers are tried first. A record at priority 1 is preferred over one at 10, and records sharing a value spread delivery attempts between them. Priority is an ordering system, not a quality ranking.
- An MX record does not prove a mailbox exists. A domain can publish perfectly valid MX records while individual addresses on it are inactive, unmonitored, secondary aliases, or simply wrong. The lookup answers a question about the domain, not about the person.
- For most large companies, the MX record names the filter rather than the mailbox host. In our census of all 500 Fortune 500 primary domains, 276 published a secure email gateway as their MX endpoint, 222 of those Proofpoint, while 412 of the same companies (82%) run Microsoft 365 as their actual mailbox platform.
- Most MX failures come from a short list of causes: a missing record, a typo in the hostname, an MX pointing at a CNAME, the wrong priority order, obsolete records left behind after a provider migration, and TTL or propagation delay.
What is an MX record?
An MX (Mail Exchange) record is a DNS entry that tells other mail servers which server receives email for your domain. Think of an MX record as the mailing address for a domain’s email. If someone wants to send a message to person@example.com, their mail server needs to know where example.com accepts incoming email. It finds that information by looking up the domain’s MX record.
MX records are part of the Domain Name System, or DNS. While an A record maps a hostname to an IP address, an MX record specifically identifies the mail server responsible for receiving email.
Importantly, an MX record does not store the messages themselves. It simply tells the sending mail server where to hand them off. The receiving server then filters, scans, routes, and delivers the message to the appropriate mailbox.
Google describes the process similarly for Google Workspace: when someone sends an email, the sender’s system looks up the recipient domain’s MX records to determine where the message should be delivered. That is the basic MX record meaning: it is the DNS instruction that directs incoming email to the appropriate mail-handling server.
What does an MX record look like?
An MX record usually contains several fields. The exact interface varies between DNS providers, but the underlying information is the same. For example, a traditional Google Workspace configuration can look like this:
Google now recommends smtp.google.com as the MX value for new Google Workspace configurations, while domains using the older aspmx records can continue using them if their email is working. The example above therefore represents the widely used legacy Google Workspace format rather than the current default for new setups.
Type identifies the DNS record as an MX record, while Name/Host identifies the domain or subdomain the record applies to, with @ commonly representing the root domain. As for Priority, that determines which mail server should be tried first. Lower numbers have higher priority, so a server with priority 1 is preferred over one with priority 10.
Mail server or Value is the hostname of the server that should receive the email. TTL, or Time to Live, tells DNS resolvers how long they can cache the record before checking for an updated version.
The exact TTL you should use depends on your provider and configuration. For example, Microsoft documents 3600 seconds as the TTL for Microsoft 365 MX records, and separately caps the maximum supported value at six hours (21,600 seconds) for domains hosted on Exchange Online.
How do MX records work?
When someone sends an email, the sender’s mail server uses DNS to find out which server is responsible for receiving messages for the recipient’s domain.
The process involves two key steps: determining which receiving server should be tried first and then establishing a connection to deliver the message. The sections below break down how MX priority controls that order and what happens during the actual email delivery process.
How does MX record priority work?
MX record priority determines the order in which receiving servers are attempted. The lower the number, the higher the priority. For example, imagine a domain has these two records: 10 mail.primary-example.com and 20 mail.backup-example.com.
The sending mail server will normally try mail.primary-example.com first because it has the lower priority value. If that server is unavailable, the sender can try mail.backup-example.com.
This is why MX records provide redundancy. A domain specifies a primary mail server and one or more backups, so a temporary outage does not stop incoming mail.
Equal priorities spread the load. When multiple MX records share a preference value, sending systems distribute delivery attempts between them rather than treating one as the sole primary. The important point is that MX priority is not a ranking where a larger number means a better server. It is an ordering system where lower numbers are preferred.
What happens when you send an email?
Suppose you send an email to alex@example.com. Your email application hands the message to an outgoing mail server, which then needs to determine where example.com accepts email.
The sending server performs a DNS lookup for the domain’s MX records. It receives one or more mail server hostnames along with their priority values, sorts them according to preference, and attempts to connect to the highest-priority server.
The mail server then communicates with the recipient server using SMTP, the protocol used for transferring email between mail systems. At a high level, the receiving server identifies the recipient, decides whether it will accept the message, and either accepts it for further processing or rejects it.
If the preferred MX server cannot be reached, the sender can attempt another MX server with a higher numerical priority. If the receiving system is temporarily unavailable, the sending server may retry later rather than immediately returning the message.
Only when delivery ultimately fails does the sender receive a bounce or other delivery failure notification. This distinction matters because an unavailable server does not necessarily mean the email has been permanently lost.
What MX records do and do not do
MX records are often discussed alongside SPF, DKIM, and DMARC, but these DNS records serve different purposes. An MX record routes incoming email. It tells other mail servers where to deliver messages addressed to your domain.
As for the SPF record, it identifies which servers are authorized to send email on behalf of your domain. Microsoft, for example, describes SPF as a DNS record used to identify valid senders for a domain. DKIM adds a cryptographic signature to outgoing messages so receiving systems can verify that the message was signed by an authorized domain and that important parts of the message have not been altered.
DMARC builds on SPF and DKIM by allowing a domain owner to publish a policy for messages that fail authentication checks. It also provides reporting mechanisms that can help domain owners understand authentication activity. This means an MX record does not authorize someone to send as your domain, sign your messages, or define what happens when authentication fails.
An MX record also does not confirm that a particular mailbox exists. Knowing that example.com accepts email tells you where email for the domain goes, but it does not prove that alex@example.com is a real or monitored mailbox. In our experience this is where B2B list hygiene most often goes wrong, because an MX lookup is fast, free, and comes back clean on every domain that accepts mail at all. It answers a question about the domain. The question you actually have is about the person.
Why do MX records matter for email deliverability?
MX records matter because they determine whether a domain has a functioning destination for incoming email. They are therefore foundational to email infrastructure, even though they are only one part of the broader deliverability picture.
Two questions get conflated here: can the recipient domain receive email, and will my outbound email reach the inbox? MX records are directly relevant to the first question, but they do not determine the second on their own.
What happens when MX records are broken or missing?
If a domain has no valid MX record, a sending mail server may not have a valid destination for the message. Depending on the DNS configuration and the receiving domain’s other records, the sender may eventually receive a delivery failure.
A typo can create the same problem. For example, if an MX record points to a hostname that does not resolve correctly, the sending server may be unable to establish the SMTP connection needed to deliver the message.
Old MX records can cause problems during an email provider migration, too. Microsoft specifically recommends removing previous MX records that point to an old mail system after moving email to Exchange Online so that incoming messages are routed to the intended service.
These failures are especially disruptive because they affect incoming mail directly. A company may still be able to send messages while being unable to receive new ones, making the problem easy to miss until someone reports that replies are not arriving.
Do MX records affect whether your emails reach the inbox?
MX records don't directly affect whether an email reaches an inbox in the way many people assume. What they do is tell a receiving domain where incoming email should go. Whether an outbound message is accepted and placed in the inbox depends on many other factors, including SPF and DKIM authentication, DMARC policy, sender reputation, recipient engagement, message content, and the filtering policies of the receiving organization.
In other words, an MX record is necessary for normal email reception but not sufficient for good inbox placement. A useful analogy is a physical office building. The MX record gives the delivery driver the building’s address, but it does not determine whether the receptionist accepts the package, whether the package is flagged for inspection, or whether it ultimately reaches the intended employee.
That distinction is particularly important when evaluating B2B email addresses. A domain can have perfectly valid MX records while individual addresses on that domain are inactive, unmonitored, secondary aliases, or otherwise unsuitable for outreach.
What MX records do the biggest companies actually use?
MX records can also reveal something unexpected about how large organizations structure their email infrastructure. In our census of all 500 Fortune 500 primary corporate domains, run across 4.9 million validations between April and June 2026, we looked at which providers appeared as MX endpoints. Because it is a census rather than a sample, there is no margin of error. The results show that the MX record frequently identifies an email security gateway rather than the service that ultimately hosts the company’s mailboxes.
Of the 500 primary domains, 276 published a secure email gateway as their MX endpoint rather than a mailbox provider. The remaining 224 published a mailbox provider directly. Within the gateway group:
The more interesting finding is what sits behind those numbers. Of the same 500 companies, 412 (82%) run Microsoft 365 and 17 (3%) run Google Workspace as their actual mailbox platform. Proofpoint is the single most common endpoint an MX lookup returns; Microsoft is the most common place the mail actually ends up. That apparent contradiction makes sense once you understand the role of a secure email gateway.
A company may use Microsoft 365 to host its employee mailboxes while routing incoming messages through Proofpoint first. In that setup, the public MX record points to Proofpoint because Proofpoint is the system receiving and filtering the message at the edge. After filtering, legitimate mail can be passed onward to Microsoft 365, where the mailbox is ultimately hosted.
The same principle can apply to other security providers such as Mimecast. As a result, an MX lookup does not always answer the question, “Which provider hosts this company’s mailbox?” It more reliably answers, “Which mail-handling system does this domain publish as its inbound destination?”
Meaning that for 276 of the Fortune 500, a tool reading the MX record is describing the filter rather than the mailbox. Therefore anything that infers how a mailbox behaves from an MX lookup on those domains is inferring it from the wrong system, which is exactly the population a B2B team spends its time on.
Common MX record problems and how to fix them
Most MX problems come from a relatively small number of configuration mistakes. The table below summarizes the most common ones.
The safest approach is to use the exact DNS values provided by your email service rather than copying records from another domain. Microsoft and Google both provide provider-specific MX configuration instructions because the correct values can change over time.
Conclusion
An MX record is the DNS instruction that tells other mail servers where to deliver incoming email for a domain. Getting it right is foundational because without a functioning destination, normal email reception can fail.
But an MX record only gets the message to the domain’s mail-handling infrastructure. It does not prove that a specific mailbox exists, authorize outbound sending, or guarantee inbox placement.
For teams working with B2B contact data, that gap is where the cost sits. A clean MX lookup is the easiest thing in the world to mistake for a usable contact.
If you send email at scale, keeping your domain infrastructure healthy is only one part of maintaining list quality. You also need accurate email verification that can distinguish genuinely valid addresses from addresses that merely belong to a functioning mail domain.
You can test Allegrow’s B2B email verification with a 14-Day Free Trial, including verification for up to 1,000 addresses. It can identify catch-all contacts with conclusive Valid or Invalid statuses, detect spam traps, unmonitored aliases, disposable and inactive mailboxes, and identify primary email addresses through CSV upload.
Frequently asked questions about MX records
What is an MX record in simple terms?
An MX record is a DNS record that tells the internet which mail server receives email for a domain. When someone sends a message to you@example.com, the sender’s mail server looks up the MX record for example.com to find where the message should go.
What is MX record priority?
MX record priority determines the order in which mail servers are tried. The lower the number, the higher the priority. For example, a record with priority 10 is normally tried before one with priority 20. The higher-numbered record can act as a backup if the preferred server is unavailable.
How does a mail server decide which MX record to use?
When an email is sent, the sending mail server looks up the recipient domain’s MX records in DNS. It identifies the server with the lowest priority number and attempts to deliver the message there. If that server is unavailable, the sender can try another MX server. Once a receiving server accepts the message, it can process and deliver it to the appropriate mailbox.
Can I send email without an MX record?
Yes, technically. MX records control receiving email rather than the basic ability to send email. However, a domain without a valid MX configuration may not reliably receive replies. For a business that uses email for communication or outreach, having a properly configured inbound mail system is therefore important.
Does an MX record prove that an email address exists?
No, an MX record only identifies the mail server responsible for receiving email for the domain. For example, if example.com has valid MX records, that does not prove that person@example.com exists. Confirming an individual address requires email verification that examines the mailbox itself and other relevant signals.
How many MX records should a domain have?
A domain needs at least one valid MX record, while multiple records can provide redundancy. The right number depends on the email provider. Google, for example, currently recommends a single smtp.google.com record for new Google Workspace setups. More records do not necessarily mean better reliability. Outdated or duplicate records can complicate email routing.
.jpg)