When you send an email to `user@example.com`, your mail server does not just open a connection to `example.com` on port 25 and start talking SMTP. It cannot, because `example.com` might not run a mail server at all. The domain might delegate its email to Google, Microsoft, a dedicated email host, or a chain of backup servers spread across different continents. Your mail server needs to find out where to deliver, and it does that by querying the MX (Mail Exchanger) records for the destination domain.
MX records are the routing layer of email. They sit in the DNS zone for a domain and answer a specific question: which hosts accept email for this domain, and in what order should a sender try them? Without MX records, email delivery would require every domain to run its own mail server at the same IP address the domain's A record points to. MX records decouple the web presence of a domain from its email infrastructure, which is why a company can host its website on one provider and its email on an entirely different one.
This guide walks through how MX lookups work mechanically, how to read the output, the most common configurations you will encounter in the wild, how MX records interact with email security, and the specific failure modes that cause email to silently disappear. If you want to query MX records live while reading, DomScan's DNS Lookup Tool lets you pull records for any domain interactively.
How MX Records Work
An MX record has two components: a priority value (sometimes called preference) and a hostname. The priority is a 16-bit unsigned integer, meaning it can range from 0 to 65535. The hostname is the fully qualified domain name of a mail server that accepts email for the domain. Crucially, the hostname must be a domain name, never an IP address. This is an RFC requirement that matters for troubleshooting, as we will see later.
The priority value determines the order in which a sending mail server tries the available MX hosts. Lower numbers mean higher priority. If a domain has an MX record at priority 10 and another at priority 20, a sending server will always try the priority 10 host first. It only falls back to priority 20 if the priority 10 host is unreachable, refuses the connection, or returns a temporary error. This fallback behavior is what makes MX records a resilience mechanism, not just a routing one.
When multiple MX records share the same priority value, the sending server distributes connections across them randomly. RFC 5321 specifies that equal-priority MX hosts should be tried in random order, which provides basic load balancing. Google Workspace exploits this by assigning priority 5 to two of its five MX servers, effectively splitting traffic between them.
The full lookup chain for email delivery works like this. The sender's mail server extracts the domain from the recipient address (everything after the `@`). It queries DNS for MX records of that domain. The DNS response returns a list of MX records with priorities. The sender sorts them by priority (lowest first), groups equal-priority records, and begins connection attempts. For each MX hostname, the sender resolves the hostname to an IP address (a separate A or AAAA lookup), connects to port 25, and attempts the SMTP handshake. If the handshake succeeds and the recipient is accepted, the email is delivered. If not, the sender moves to the next MX host in the priority chain.
Reading MX Record Output
The best way to understand MX records is to look at real output. The `dig` command is the standard tool for DNS queries on Unix-like systems. Here is what a query for Gmail's MX records looks like:
$ dig MX gmail.com
;; ANSWER SECTION:
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.Each line in the answer section contains five fields. Let us break them down with the first record as an example.
- gmail.com. is the queried domain name, with a trailing dot indicating it is fully qualified.
- 3600 is the TTL (time to live) in seconds. Resolvers cache this answer for one hour before querying again.
- IN is the DNS class, which stands for Internet. This is always IN for practical purposes.
- MX is the record type, confirming this is a Mail Exchanger record.
- 5 is the priority value. This is the primary mail server because 5 is the lowest priority number in the set.
- gmail-smtp-in.l.google.com. is the hostname of the mail server that accepts delivery.
Reading the full set, you can see the fallback chain clearly. Priority 5 is the primary. If it is down, the sender tries priority 10, then 20, then 30, then 40. Each alternative server has a different hostname, which means they likely resolve to different IP addresses in different data centers. This five-deep fallback chain is why Gmail almost never loses inbound email even during partial infrastructure outages.
One thing that the output does not show you directly is the IP address of each mail server. The MX record only contains the hostname. The sending mail server performs a second DNS lookup (an A or AAAA query) on each MX hostname to get the actual IP it needs to connect to. This two-step resolution is by design: it lets mail infrastructure change IP addresses without touching the MX records themselves.
Common MX Configurations
Once you have looked at enough MX records, patterns emerge. Most domains fall into one of a handful of configurations that immediately tell you which email provider they use and how their mail infrastructure is architected.
Google Workspace
Google Workspace (formerly G Suite, formerly Google Apps) uses five MX servers with a distinctive priority spread. The primary server sits at priority 1, two alternates share priority 5, and two more sit at 5 or 10 depending on when the domain was configured. The canonical setup looks like this:
example.com. 3600 IN MX 1 ASPMX.L.GOOGLE.COM.
example.com. 3600 IN MX 5 ALT1.ASPMX.L.GOOGLE.COM.
example.com. 3600 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
example.com. 3600 IN MX 10 ALT3.ASPMX.L.GOOGLE.COM.
example.com. 3600 IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.The `ASPMX.L.GOOGLE.COM` pattern is unmistakable. If you see these hostnames in an MX lookup, the domain uses Google for email. This is one of the most common configurations on the internet: millions of domains point their MX records to Google's servers. You can use DomScan's Reverse MX API to find all domains sharing a specific MX server, which is useful for mapping an organization's domain portfolio.
Microsoft 365
Microsoft 365 (formerly Office 365) uses a single MX record per domain, following a tenant-specific naming pattern:
example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com.The hostname encodes the domain name with hyphens replacing dots, followed by `.mail.protection.outlook.com`. The priority is typically 0, making it the sole and highest-priority mail destination. Unlike Google's five-server setup, Microsoft handles redundancy behind the scenes: the single hostname resolves to multiple IP addresses via DNS round-robin, and Microsoft's Exchange Online Protection layer routes mail internally. The tenant-specific hostname means every Microsoft 365 customer gets a unique MX target, which is useful for identifying specific organizations.
Self-Hosted Email
Organizations running their own mail servers typically use a primary and backup configuration:
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backup-mail.example.com.The primary at priority 10 handles normal traffic. The backup at priority 20 accepts and queues mail when the primary is down, forwarding it once the primary recovers. Self-hosted setups are increasingly rare for business email but remain common for ISPs, universities, government agencies, and organizations with strict data sovereignty requirements. The hostnames under the same domain (rather than a third-party provider) are the giveaway.
Email Forwarding Services
Lightweight email forwarding services like Cloudflare Email Routing, ForwardEmail, and ImprovMX accept mail on behalf of a domain and forward it to another address without hosting a full mailbox. Their MX records point to the service's shared infrastructure:
example.com. 3600 IN MX 86 route1.mx.cloudflare.net.
example.com. 3600 IN MX 24 route2.mx.cloudflare.net.
example.com. 3600 IN MX 84 route3.mx.cloudflare.net.Forwarding services are popular for personal domains and small businesses that want a custom email address without the overhead of a full email hosting account. The unusual priority values (like 24, 84, 86) are a fingerprint unique to Cloudflare's configuration. Each forwarding provider has its own distinctive pattern.
Null MX: Explicitly Opting Out of Email
RFC 7505 defines the null MX record, a way for a domain to explicitly declare that it does not accept email. The configuration is a single MX record with priority 0 pointing to the root domain (a single dot):
example.com. 3600 IN MX 0 .When a sending server encounters a null MX, it should immediately reject the email with a permanent failure rather than attempting delivery. This is different from having no MX records at all. A domain with no MX records triggers a fallback to the A record (the sender tries to deliver directly to the domain's IP address), which usually fails but wastes time and resources. A null MX gives a clean, immediate signal: do not send mail here. This is important for defensive domain management, which we will cover in the security section.
MX Records and Email Security
MX records sit at the intersection of email routing and email security, but their role is often misunderstood. MX records control where a domain receives email. They do not control who can send email on behalf of a domain. That distinction matters enormously for understanding email authentication.
SPF (Sender Policy Framework) records list the IP addresses and hostnames authorized to send email for a domain. There is no technical link between a domain's MX records and its SPF record. A domain might receive email through Google Workspace (MX pointing to Google) but send outbound email through a transactional service like SendGrid or Amazon SES. The MX and SPF configurations are independent. However, in practice, most organizations include their MX hosts in their SPF record because the same servers often handle both inbound and outbound mail. You can audit a domain's full email authentication posture with DomScan's Email Security Check, which evaluates SPF, DKIM, and DMARC together.
From an attacker's perspective, MX records reveal which domains can receive email. If a domain has MX records, it has an active mail infrastructure, which means users at that domain can be targeted with phishing, spear phishing, and business email compromise attacks. MX records also reveal the email provider. Knowing that a target uses Microsoft 365 versus Google Workspace lets an attacker craft more convincing phishing pages that mimic the correct login portal. This is one reason MX records are among the first DNS records checked during OSINT reconnaissance.
Defensively, MX records matter for domains you own but do not use for email. Many organizations register dozens or hundreds of domains for brand protection, typosquatting defense, or future projects. These domains typically have no mail infrastructure, but without explicit configuration, they can still receive email via the A record fallback. Worse, without SPF and DMARC records, attackers can spoof email as coming from these domains. The defensive playbook is to publish a null MX record (to reject inbound email), an SPF record with `v=spf1 -all` (to declare that no servers are authorized to send), and a DMARC record with `p=reject` (to instruct receivers to reject spoofed messages). This trio shuts down email abuse on parked domains.
MX Troubleshooting
Email delivery failures caused by MX misconfiguration are particularly frustrating because they are often silent. The sender gets a bounce hours later, or the email vanishes into a queue and eventually times out. Here are the most common MX issues and how to identify them.
MX Points to an IP Address Instead of a Hostname
RFC 5321 requires MX records to contain a hostname, not an IP address. Some DNS providers let you enter an IP in the MX value field without warning. The result is an MX record like `10 192.168.1.5`, which is technically invalid. Some mail servers tolerate this and attempt delivery anyway. Others reject the record entirely and treat the domain as having no MX, triggering the A record fallback or a permanent failure. The fix is straightforward: create an A record for a hostname like `mail.example.com`, point it to the IP address, and update the MX record to reference the hostname.
MX Points to a CNAME
RFC 2181 and RFC 5321 both state that MX records must not point to a CNAME alias. If `mail.example.com` is a CNAME for `mailhost.provider.com`, and your MX record points to `mail.example.com`, you have a chain that some resolvers handle gracefully and others reject. The failure is intermittent and depends on the sending server's DNS resolver implementation, making it extremely difficult to diagnose. The fix is to point the MX record directly to the canonical hostname (the final A record target) rather than an intermediate CNAME.
Missing MX Records
When a domain has no MX records at all, RFC 5321 specifies a fallback: the sending server should attempt delivery to the domain's A record (or AAAA record) directly. In practice, this fallback is unreliable. Many mail servers skip the A record fallback entirely or treat it as a low-confidence signal. Even when the fallback works, the A record typically points to a web server that is not running an SMTP daemon on port 25. The result is a connection refused error, and the email bounces. If a domain should receive email, it needs explicit MX records. If it should not, it needs a null MX record. Relying on the A record fallback is never the right answer.
Wrong Priority Ordering
A common mistake is configuring a backup server with a lower priority number (higher priority) than the primary server. If your primary is `mail.example.com` at priority 20 and your backup is `backup.example.com` at priority 10, every sending server will try the backup first. The backup server becomes the de facto primary, and it may not have the capacity, filtering rules, or storage to handle full production traffic. Worse, if the backup is configured to relay mail to the primary (a common backup pattern), you get a relay loop or double-processing of every message. Always verify that your primary server has the lowest priority number.
MX Host Does Not Accept Connections
The MX record might be correctly configured, but the host it points to refuses connections. Common causes include a firewall blocking port 25, the mail server process being stopped, the hostname resolving to a server that does not run mail software, or the server rejecting connections because its TLS certificate has expired. The sending server will try other MX hosts in priority order, but if all MX hosts are unreachable, the email enters the sender's retry queue. Most mail servers retry for 24 to 72 hours before generating a final bounce. During this window, the email is in limbo and neither the sender nor recipient knows it has not been delivered.
MX Lookup for Domain Investigation
Beyond troubleshooting your own email, MX lookups are a powerful tool for investigating other domains. The MX records for a domain reveal its email provider, its infrastructure choices, and sometimes its organizational relationships.
Identifying Email Providers
MX hostnames are a reliable fingerprint for email providers. Seeing `ASPMX.L.GOOGLE.COM` means Google Workspace. Seeing `.mail.protection.outlook.com` means Microsoft 365. Seeing `mx1.zoho.com` means Zoho Mail. Seeing `.pphosted.com` means Proofpoint. Seeing `inbound-smtp.*.amazonaws.com` means Amazon SES or WorkMail. This identification works because email providers require customers to point MX records to provider-controlled hostnames, and those hostnames are stable and publicly documented. An MX lookup on a target domain immediately tells you what email stack they run.
Reverse MX Lookup
A reverse MX lookup answers the question: which domains use this mail server? If you know a company uses `mail.company.com` as their MX host, a reverse MX lookup returns every domain in the DNS ecosystem that points its MX records to that same hostname. This reveals subsidiary domains, partner domains, acquired brands, and shadow IT domains that share the same mail infrastructure. DomScan's Reverse MX API performs this lookup across a large dataset of active domains, making it practical for brand protection and domain portfolio discovery.
Detecting Infrastructure Changes
Monitoring MX records over time reveals when a domain changes email providers. A shift from Google Workspace MX servers to Microsoft 365 MX servers indicates a migration event. A new MX record appearing alongside existing ones might indicate a transition period. MX records disappearing entirely could mean the domain is being decommissioned or its DNS was misconfigured during a provider change. For competitive intelligence and vendor tracking, historical MX data is a concrete signal of organizational decisions that are otherwise invisible from the outside.
Running Your Own MX Lookups
If you want to check the MX records for a domain right now, you have several options depending on your operating system and preferences.
On macOS or Linux, `dig` gives you the most detailed output. Query MX records for any domain with a single command:
$ dig MX example.com +short
10 mail.example.com.
20 backup.example.com.The `+short` flag strips the output to just the priority and hostname, which is useful for scripting or quick checks. Drop it to see the full response with TTL, query time, and the responding server.
On Windows, `nslookup` with the type set to MX works similarly:
$ nslookup -type=mx example.com
Server: dns.example-isp.net
Address: 10.0.0.1
example.com MX preference = 10, mail exchanger = mail.example.com
example.com MX preference = 20, mail exchanger = backup.example.comFor a browser-based approach that does not require a terminal, DomScan's DNS Lookup Tool queries MX records along with all other DNS record types in a single view. The DNS Lookup API provides the same data programmatically for integration into monitoring scripts or security tools.
From Lookup to Intelligence
An MX lookup is a ten-second operation that tells you which servers handle email for a domain. But the value compounds when you combine it with other signals. Cross-reference MX records with SPF records to verify that a domain's sending and receiving infrastructure are consistent. Compare MX hostnames against known provider patterns to map an organization's email vendor. Use reverse MX lookups to discover related domains you did not know existed. Monitor MX changes over time to detect provider migrations, infrastructure failures, or domain takeover attempts.
MX records are one of the few DNS record types that directly reveal business decisions. A company's choice of email provider, its investment in redundancy, its defensive posture on parked domains, and its approach to email security are all visible in the MX configuration. Learning to read MX records fluently turns a simple DNS query into a meaningful investigation tool.
Independent references: Review RFC 5321 for the SMTP specification that defines MX handling, and RFC 7505 for the null MX mechanism.