MX Lookup Email
An MX lookup returns the mail servers that accept email for a domain. Enter a domain to see its MX records in the order senders try them, the IP addresses behind each host, and which email provider or security gateway runs them.
How to read MX lookup results
Each row is one MX record. The priority (also called preference) sets the delivery order: a sender connects to the host with the lowest number and only moves to a higher number when that host is unreachable. Two hosts with the same priority are picked at random, which is how providers spread load across several servers.
The mail server column is the hostname the record points to, and the IP addresses column shows the A and AAAA records for that hostname. An MX host with no address cannot receive mail, so the tool flags it. The operator column names the service behind the hostname when it matches a known pattern, for example Google Workspace, Microsoft 365, Proofpoint or Mimecast.
What the MX records tell you about a domain
Because MX records have to be public for email to work, they are a reliable way to see how an organization handles mail:
- Mailbox provider. Hosts ending in
google.comoroutlook.commean the mail goes straight to Google Workspace or Microsoft 365. - Security gateway. If the MX points at a filtering service, inbound mail is scanned there before it reaches the mailbox provider. The mailbox provider is then usually visible in the SPF record rather than the MX.
- Self-hosted mail. A host inside the organization's own domain, such as
mail.example.com, usually means it runs its own server. - No inbound mail. A null MX (
0 .) is an explicit statement that the domain does not accept email, which is common on parked and send-only domains.
Common MX record problems
- MX points to a CNAME. The target of an MX record must be a hostname with its own address records. An alias works with some senders and fails with others.
- MX points to an IP address. The value has to be a hostname. A bare IP is invalid and most servers will not deliver to it.
- Old records left behind after a migration. A leftover low-priority record for the previous provider keeps receiving a share of the mail, and it is also a route spammers use to bypass a new filtering gateway.
- Backup MX that accepts everything. A secondary server that does not know which recipients exist will accept spam and then generate bounce messages for it.
- Missing reverse DNS. This matters for sending rather than receiving, but servers that both send and receive should have a matching PTR record. Check it with the reverse DNS lookup.
After you change MX records
Resolvers cache the old records until the TTL runs out, so mail can arrive at both the old and new servers for a while. Keep the old service running for at least one full TTL, and use the DNS propagation checker to see which public resolvers already return the new records. For the record format and worked examples, see the MX record guide.
Frequently asked questions
What is an MX record?
An MX (mail exchange) record is a DNS record that names a mail server responsible for receiving email for a domain, together with a priority number. A domain can publish several MX records for redundancy.
Which MX record is used first?
The record with the lowest priority number. A sender only tries a higher number when every host at the lower number is unreachable. Records with equal priority are chosen at random, which spreads the load between them.
What happens if a domain has no MX record?
Senders fall back to the domain's A or AAAA record and try to deliver there. In practice that host rarely runs a mail server, so the message is deferred and eventually bounces. A domain that should never receive mail can state that explicitly with a null MX record, 0 .
Can I find a company's email provider from its MX records?
Usually, yes. The MX hostname shows where inbound mail is delivered first, which is either the mailbox provider or a security gateway placed in front of it. When a gateway is in use, the SPF record normally reveals the mailbox provider behind it.
How long do MX record changes take to propagate?
As long as the TTL on the old records. A resolver that cached the old answer keeps using it until that timer expires, so lowering the TTL a day before a migration shortens the changeover.
Last updated: