MX Record Lookup — How to Check Mail Server Records

What Are MX Records?

MX records are DNS (Domain Name System) entries that specify which mail servers are responsible for receiving email on behalf of a domain. When someone sends an email to user@yourdomain.com, their mail server looks up the MX records for yourdomain.com to find out where to deliver the message. Without MX records, email cannot be delivered to your domain.

Every domain that receives email must have at least one MX record. Most domains have two or more for redundancy — if the primary mail server is unavailable, email is routed to a backup server. The MX system has been fundamental to email routing since the 1980s and remains the backbone of email delivery today.

MX records are also a critical component of email verification. When an email verification API checks an address, one of the first steps is looking up the domain's MX records to confirm the domain is configured to receive email. A domain without MX records (and without an A record fallback) cannot receive email, and any address at that domain is immediately classified as invalid.

How MX Records Work

MX records follow a specific format and use a priority system to determine which servers receive email first.

MX Record Format

Each MX record has two parts: a priority value (also called preference) and a mail server hostname. The format in DNS is:

// MX record format
yourdomain.com.    IN    MX    10    mail.yourdomain.com.
yourdomain.com.    IN    MX    20    backup.yourdomain.com.

// Breakdown:
// yourdomain.com.     — the domain this record applies to
// IN                  — Internet class (standard)
// MX                  — record type
// 10                  — priority (lower = higher priority)
// mail.yourdomain.com — the mail server hostname

Priority and Failover

The priority number determines the order in which mail servers are tried. Lower numbers have higher priority. When a sending server looks up your MX records, it connects to the server with the lowest priority number first. If that server is unavailable, it tries the next lowest priority, and so on.

// Example MX configuration with failover
yourdomain.com.    MX    10    primary-mail.yourdomain.com.
yourdomain.com.    MX    20    secondary-mail.yourdomain.com.
yourdomain.com.    MX    30    tertiary-mail.yourdomain.com.

// Delivery order:
// 1. Try primary-mail (priority 10) first
// 2. If primary is down, try secondary-mail (priority 20)
// 3. If secondary is down, try tertiary-mail (priority 30)
// 4. If all are down, queue and retry later

If multiple MX records have the same priority value, the sending server distributes email randomly among them. This is used for load balancing across multiple servers.

// Load balancing with equal priorities
yourdomain.com.    MX    10    mail1.yourdomain.com.
yourdomain.com.    MX    10    mail2.yourdomain.com.
yourdomain.com.    MX    10    mail3.yourdomain.com.

// Email is distributed randomly across all three servers

The A Record Fallback

If a domain has no MX records, the sending server falls back to the domain's A record and attempts to deliver email directly to that IP address. This fallback exists for backward compatibility but is not recommended for production use. Always configure explicit MX records for any domain that should receive email.

How to Look Up MX Records

There are several ways to query MX records, from command-line tools to web-based checkers.

Using dig (Linux/macOS)

The dig command is the standard DNS lookup tool on Linux and macOS:

// Basic MX lookup
dig MX example.com

// Short output (just the records)
dig +short MX example.com

// Example output:
// 1 aspmx.l.google.com.
// 5 alt1.aspmx.l.google.com.
// 5 alt2.aspmx.l.google.com.
// 10 alt3.aspmx.l.google.com.
// 10 alt4.aspmx.l.google.com.

// Query a specific DNS server
dig @8.8.8.8 MX example.com

// Get detailed output including TTL
dig +noall +answer MX example.com

Using nslookup (Windows/Cross-Platform)

The nslookup command is available on all major operating systems:

// Windows / macOS / Linux
nslookup -type=mx example.com

// Example output:
// example.com     mail exchanger = 1 aspmx.l.google.com.
// example.com     mail exchanger = 5 alt1.aspmx.l.google.com.

// Using a specific DNS server
nslookup -type=mx example.com 8.8.8.8

Using host (Linux/macOS)

// Simple MX lookup
host -t mx example.com

// Example output:
// example.com mail is handled by 1 aspmx.l.google.com.
// example.com mail is handled by 5 alt1.aspmx.l.google.com.

Programmatic MX Lookup — Node.js

// MX record lookup in Node.js
const dns = require('dns').promises;

async function lookupMX(domain) {
  try {
    const records = await dns.resolveMx(domain);

    // Sort by priority (lowest first)
    records.sort((a, b) => a.priority - b.priority);

    console.log(`MX records for ${domain}:`);
    records.forEach((record) => {
      console.log(`  Priority: ${record.priority}  Server: ${record.exchange}`);
    });

    return records;
  } catch (error) {
    if (error.code === 'ENODATA') {
      console.log(`No MX records found for ${domain}`);
    } else if (error.code === 'ENOTFOUND') {
      console.log(`Domain ${domain} does not exist`);
    } else {
      console.error(`Lookup failed: ${error.message}`);
    }
    return null;
  }
}

// Usage
await lookupMX('gmail.com');
await lookupMX('outlook.com');
await lookupMX('nonexistent-domain-xyz.com');

Programmatic MX Lookup — PHP

// MX record lookup in PHP
function lookupMX(string $domain): array {
    $mxHosts = [];
    $mxWeights = [];

    if (!getmxrr($domain, $mxHosts, $mxWeights)) {
        return ['found' => false, 'records' => []];
    }

    $records = [];
    for ($i = 0; $i < count($mxHosts); $i++) {
        $records[] = [
            'priority' => $mxWeights[$i],
            'server' => $mxHosts[$i],
        ];
    }

    // Sort by priority
    usort($records, fn($a, $b) => $a['priority'] - $b['priority']);

    return ['found' => true, 'records' => $records];
}

// Usage
$result = lookupMX('gmail.com');
if ($result['found']) {
    foreach ($result['records'] as $record) {
        echo "Priority: {$record['priority']}  Server: {$record['server']}\n";
    }
} else {
    echo "No MX records found\n";
}

Programmatic MX Lookup — Python

// MX record lookup in Python
import dns.resolver

def lookup_mx(domain: str) -> list:
    try:
        answers = dns.resolver.resolve(domain, 'MX')
        records = []
        for rdata in answers:
            records.append({
                'priority': rdata.preference,
                'server': str(rdata.exchange).rstrip('.'),
            })
        records.sort(key=lambda r: r['priority'])
        return records
    except dns.resolver.NoAnswer:
        print(f"No MX records for {domain}")
        return []
    except dns.resolver.NXDOMAIN:
        print(f"Domain {domain} does not exist")
        return []

# Usage
for record in lookup_mx('gmail.com'):
    print(f"  Priority: {record['priority']}  Server: {record['server']}")

Interpreting MX Record Results

MX records reveal a lot about a domain's email infrastructure. Here is how to read common configurations.

Google Workspace

// Google Workspace MX records
1   aspmx.l.google.com.
5   alt1.aspmx.l.google.com.
5   alt2.aspmx.l.google.com.
10  alt3.aspmx.l.google.com.
10  alt4.aspmx.l.google.com.

This is the standard Google Workspace configuration. Five servers with tiered priorities provide high availability. If you see these MX records, the domain uses Google for email hosting.

Microsoft 365

// Microsoft 365 MX records
0   yourdomain-com.mail.protection.outlook.com.

Microsoft 365 typically uses a single MX record pointing to their mail protection service. The subdomain is derived from the customer's domain name. Microsoft handles redundancy internally.

Custom Mail Servers

// Self-hosted mail server
10  mail.yourdomain.com.
20  backup-mail.yourdomain.com.

Custom configurations point to the domain's own servers. This is common for organizations running their own mail infrastructure (Postfix, Exchange on-premise, etc.).

Email Security Gateways

// Domain using Proofpoint email security
10  yourdomain-com.pphosted.com.
20  yourdomain-com.pphosted.com.

When MX records point to a security gateway (Proofpoint, Mimecast, Barracuda), email is filtered before reaching the actual mail server. The gateway performs spam filtering, virus scanning, and DLP inspection before forwarding clean email to the internal server.

Common MX Configurations by Provider

Here is a reference table of MX patterns for popular email providers. This helps you quickly identify what email service a domain uses:

// Provider identification by MX records
Provider              | MX Pattern
----------------------|------------------------------------------
Google Workspace      | aspmx.l.google.com (and alt servers)
Microsoft 365         | *.mail.protection.outlook.com
Amazon SES            | inbound-smtp.*.amazonaws.com
Zoho Mail             | mx.zoho.com, mx2.zoho.com
Yahoo (business)      | *.yahoodns.net
ProtonMail            | mail.protonmail.ch, mailsec.protonmail.ch
FastMail              | in1-smtp.messagingengine.com
Rackspace             | mx1.emailsrvr.com, mx2.emailsrvr.com
GoDaddy               | mailstore1.secureserver.net
Proofpoint            | *.pphosted.com
Mimecast              | *.mimecast.com
Barracuda             | *.barracudanetworks.com

Troubleshooting MX Record Issues

No MX Records Found

If a domain has no MX records, email delivery relies on the A record fallback. This usually indicates one of three situations: the domain is not configured for email (informational website only), the MX records were accidentally deleted, or the domain is newly registered and DNS has not been set up yet. If you manage the domain and it should receive email, add MX records pointing to your mail server.

MX Pointing to Invalid Hostname

If the MX record points to a hostname that does not resolve to an IP address, email cannot be delivered. This happens when the mail server hostname is misspelled, the mail server's A record is missing, or the mail server has been decommissioned without updating the MX record. Verify that each MX hostname resolves to a valid IP address.

MX Pointing to CNAME

RFC 2181 states that MX records must not point to CNAME records. Some DNS resolvers handle this gracefully, but others reject the configuration. Always point MX records directly to A records (hostnames that resolve to IP addresses), not to CNAMEs.

MX Pointing to IP Address

MX records must point to hostnames, not IP addresses. An MX record like 10 192.0.2.1 is invalid. Use 10 mail.yourdomain.com and ensure mail.yourdomain.com has an A record pointing to 192.0.2.1.

TTL Too High or Too Low

The TTL (Time To Live) controls how long DNS resolvers cache your MX records. A TTL of 3600 (1 hour) is standard. Very high TTLs (86400+) mean changes take a long time to propagate. Very low TTLs (60-300) increase DNS query load. When migrating email providers, temporarily lower the TTL before changing MX records, then restore it after migration.

MX Records in Email Verification

MX records play a critical role in the email verification process. Here is how verification services use them:

Domain Validation

The MX lookup confirms that the domain can receive email. If no MX records exist (and no A record fallback), every address at that domain is invalid. This single check eliminates a large percentage of invalid addresses from any list — typo domains, parked domains, and defunct domains all fail the MX check.

Provider Identification

MX records reveal the email provider, which affects verification behavior. Gmail, Outlook, and Yahoo respond to SMTP verification queries in predictable ways. Corporate servers behind security gateways may behave differently. Knowing the provider helps the verification service apply the right verification strategy.

Catch-All Detection

Some mail servers are configured to accept email for any address at the domain (catch-all), regardless of whether the specific mailbox exists. Verification services detect catch-all configuration by testing a known-random address against the server. If the server accepts it, the domain is classified as catch-all, and individual mailbox verification becomes unreliable.

Our email domain checker performs comprehensive MX analysis along with SPF, DKIM, and DMARC checks. For individual address verification including MX lookup, use our free email verifier.

How to Set Up MX Records

If you are configuring email for a domain, here is the process for setting up MX records.

Step 1: Determine Your Mail Server

Identify the mail server(s) that will receive email for your domain. If you use a hosted provider (Google Workspace, Microsoft 365, Zoho), they will give you the exact MX records to create. If you run your own server, use your server's hostname.

Step 2: Access Your DNS Management

Log into your domain registrar or DNS hosting provider. Navigate to DNS management for your domain. You will add MX records in the same interface where you manage A records, CNAME records, and TXT records.

Step 3: Create MX Records

Add your MX records with appropriate priorities. For Google Workspace, the records are:

// Google Workspace MX setup
Type   Name   Priority   Value                        TTL
MX     @      1          aspmx.l.google.com           3600
MX     @      5          alt1.aspmx.l.google.com      3600
MX     @      5          alt2.aspmx.l.google.com      3600
MX     @      10         alt3.aspmx.l.google.com      3600
MX     @      10         alt4.aspmx.l.google.com      3600

Step 4: Verify Configuration

After adding the records, wait for DNS propagation (typically 15 minutes to 48 hours depending on TTL) and verify using any of the lookup methods described above. Send a test email to an address at your domain and confirm delivery. Use our authentication checker to verify your complete email configuration.

MX Records and Email Security

MX records interact with several email security mechanisms:

MX and SPF

The mx mechanism in SPF records authorizes the IP addresses of your MX servers to send email. If your mail server both sends and receives email (common for smaller organizations), using mx in your SPF record is convenient. However, for organizations with separate sending and receiving infrastructure, you should explicitly list your sending IPs rather than using the mx mechanism. Learn more in our SPF, DKIM, and DMARC guide.

MX and MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard that tells sending servers to only deliver email to your domain over encrypted TLS connections to specific MX hostnames. It prevents downgrade attacks where an attacker intercepts email by stripping TLS. MTA-STS references your MX records to define which servers are legitimate recipients.

MX and DANE

DANE (DNS-based Authentication of Named Entities) uses DNSSEC-signed TLSA records to bind your MX server's TLS certificate to its DNS name. This prevents man-in-the-middle attacks by ensuring the sending server is connecting to the genuine mail server. DANE requires DNSSEC to be enabled for your domain.