MX Record Lookup

Find the Mail Exchange (MX) servers responsible for accepting email on behalf of a domain.

About MX Records & Priorities

Mail Exchange (MX) records direct email to a mail server. They indicate how email messages should be routed in accordance with the SMTP protocol.

Priority: The priority number indicates the preference given to an MX record. The lowest number gets the highest priority (e.g., priority 0 or 10 is chosen before priority 20 or 50). If the primary server is down, senders will try the server with the next lowest priority number.

Our MX Record Lookup queries the DNS mail exchanger records for any domain, showing every mail server, its priority value, and the resolved IP address. Use it to confirm where your email is delivered and to diagnose mail routing failures in seconds.

What is an MX Record?

An MX (Mail Exchanger) record is a DNS record that tells the internet which mail servers accept email for a domain. When someone sends a message to you@example.com, the sending server queries DNS for the MX records of example.com and delivers the message to the host those records name.

Each MX record has two parts: a priority number and a hostname. The priority (also called preference) controls the order in which servers are tried — lower numbers are tried first. A domain typically publishes several MX records so that mail still flows if the primary server is unreachable.

MX records must point to a hostname, never to an IP address. That hostname must itself resolve to an A or AAAA record.

Tells sending servers where to deliver mail for your domain
Defined in RFC 5321 as part of the SMTP specification
Lower priority numbers are tried first
Must point to a hostname, never directly to an IP address
Multiple records provide redundancy if a mail server goes down

Why MX Records Matter

A missing or misconfigured MX record is the single most common cause of total email loss for a domain. If no MX record exists, sending servers fall back to the A record of the domain — and if nothing is listening on port 25 there, every message bounces.

MX records are also a security surface. Attackers check them to identify your mail provider and craft targeted phishing. A stale MX record pointing at a decommissioned host can allow an attacker to claim that hostname and intercept your inbound mail.

No MX record means inbound email silently bounces or is lost
Wrong priority order can send mail to a backup server permanently
Stale records pointing at dead hosts are an interception risk
MX hostnames reveal your mail provider to attackers planning phishing
Correct MX setup is a prerequisite for SPF, DKIM and DMARC to work properly

How This MX Record Lookup Works

The tool performs a live DNS query of type MX and then resolves each returned hostname to its address.

Validates the domain input against format and SSRF safety checks
Queries authoritative DNS for records of type MX
Sorts every result by priority, lowest number first
Resolves each mail server hostname to its A or AAAA address
Flags common faults such as missing records or IP addresses used as targets

How to Use the MX Record Lookup

Enter your domain name such as example.com in the input field
Run the lookup to query live DNS
Review every mail server returned and its priority value
Confirm the lowest-priority host is your intended primary mail server
Check that each hostname resolves to a valid IP address

Understanding Your MX Record Results

Each MX record returns a priority, a target hostname and a TTL. Here is what each field means:

Field / Value	Meaning
`Priority`	Also called preference. Sending servers try the lowest number first. Equal values are load-balanced randomly. Typical values are 10 for primary and 20 or higher for backups.
`Mail server`	The fully qualified hostname that accepts mail. It must have its own A or AAAA record. Common values point at Google Workspace, Microsoft 365, or your own mail host.
`Resolved IP`	The address the mail server hostname currently resolves to. If this is blank, the MX target is broken and mail will not be delivered.
`TTL`	How long resolvers cache this record, in seconds. 3600 is a common value. Lower it to 300 before migrating mail providers.
`Null MX (.)`	A single record with priority 0 and a target of "." declares that the domain accepts no email at all, as defined in RFC 7505. This is correct for domains that only host a website.

Common Problems & How to Fix Them

Your domain cannot receive email. Sending servers will fall back to the A record and, finding nothing listening on port 25, bounce the message.

Add an MX record at your DNS provider:
Type: MX
Name: @
Priority: 10
Value: the hostname your mail provider gave you, such as aspmx.l.google.com

If the domain is intentionally not used for email, publish a null MX record instead: priority 0 with a target of a single dot.

MX records must contain a hostname, never a raw IP address. Many sending servers reject the record outright and mail bounces.

Create an A record such as mail.yourdomain.com pointing at the IP, then set the MX target to mail.yourdomain.com.

The MX hostname has no A or AAAA record, so sending servers have nowhere to connect.

Verify the hostname is spelled correctly and that its own DNS record exists. This commonly happens after a mail migration when the old host is removed but the MX record still points to it.

Lower numbers are tried first, so a backup with priority 5 and a primary with priority 10 means all mail goes to the backup.

Reverse the numbers: the primary should have the lowest value. Remember that priority is an order of preference, not a ranking of importance.

Records left over from a previous mail provider cause mail to be split between systems, with messages landing in an inbox nobody monitors.

Remove every MX record that does not belong to your current provider. Only the records from one mail system should remain.

Best Practices

Publish at least two MX records so mail still flows if one server is unreachable
Give the primary server the lowest priority number, typically 10
Always point MX records at a hostname that has its own A or AAAA record
Remove old provider records immediately after a mail migration
Lower the TTL to 300 seconds a day before migrating, then restore it afterwards
Publish a null MX record for domains that never receive email
Keep SPF records aligned with the servers your MX records name

Security Recommendations

Audit MX records for hostnames pointing at decommissioned or third-party infrastructure you no longer control
Pair MX records with SPF, DKIM and DMARC — MX alone provides no authentication
Publish MTA-STS and DANE where supported so inbound mail is encrypted in transit
Check that your mail servers are not open relays, which gets your IP blacklisted rapidly
Monitor for unauthorised MX record changes, which are a hallmark of domain hijacking and mail interception
Avoid exposing internal hostname patterns in MX targets that reveal your infrastructure layout

Frequently Asked Questions

An MX record is a DNS record that tells sending mail servers which host accepts email for your domain. It contains a priority number and a hostname. Servers try the lowest priority number first.

Priority, also called preference, controls the order in which mail servers are tried. The lowest number is attempted first. If two records share the same number, sending servers pick between them at random, which distributes load.

At least two is recommended so mail is still accepted if one server is down. Most hosted providers such as Google Workspace and Microsoft 365 supply several records with different priorities — publish all of them exactly as given.

No. The SMTP specification requires MX records to name a hostname, which must then have its own A or AAAA record. An MX record containing a raw IP address is invalid and many sending servers will reject it.

The most common causes are an MX target that no longer resolves, leftover records from a previous mail provider splitting delivery, a firewall blocking port 25, or the receiving server rejecting mail because your IP is blacklisted. Check each in turn.

A null MX record, defined in RFC 7505, is a single record with priority 0 and a target of one dot. It explicitly declares that the domain accepts no email, so sending servers reject messages immediately rather than retrying for days.

Changes propagate according to the previous record TTL, usually between 5 minutes and an hour, though worldwide propagation can take up to 48 hours. Lower the TTL to 300 seconds before a planned mail migration.

MX records control inbound mail, not outbound. They do not directly affect whether your sent mail reaches the inbox — that depends on SPF, DKIM, DMARC and your sending reputation. However, a broken MX record prevents you from receiving bounce notifications and DMARC reports, which indirectly harms deliverability management.