MX Lookup

MX (Mail Exchanger) records are DNS entries that tell the internet which mail servers are responsible for receiving email on behalf of your domain. When someone sends an email to you@yourdomain.com, the sending server looks up your domain's MX records to figure out where to deliver the message. Without MX records, email sent to your domain either falls back to the domain's A record (which usually isn't configured to handle mail) or gets rejected entirely.

Each MX record has two parts: a priority value and a mail server hostname. The priority determines the order in which servers are tried — lower numbers are tried first. If the primary server is unavailable, the sending server moves to the next one in priority order. This is how email achieves redundancy: multiple MX records with different priorities mean your mail can still be delivered even if one server goes down.

Running an MX lookup is one of the quickest ways to diagnose email delivery problems. If emails aren't arriving, the cause is often a missing, misconfigured, or stale MX record — especially after migrating to a new email provider. An MX lookup instantly tells you which servers are handling your mail and whether the configuration matches what you expect.

Beyond troubleshooting, MX lookups are useful when setting up DMARC monitoring. Your DMARC aggregate reports are sent via email to the address in your rua tag, which means the receiving domain's MX records need to be correctly configured to accept those reports. If you're using a service like Viewleaf to collect DMARC reports, verifying that MX records are routing mail correctly is an important step in making sure your reports actually arrive.

MX record priorities are numeric values that determine the order in which mail servers are contacted. The server with the lowest priority number is tried first. If it's unreachable or returns an error, the sending server tries the next-highest priority, and so on.

For example, if your domain has two MX records — one with priority 10 pointing to mail1.example.com and another with priority 20 pointing to mail2.example.com — all email will be directed to mail1 first. Only if mail1 is unavailable will mail2 receive the message. If two records share the same priority value, sending servers will distribute messages between them roughly equally, providing basic load balancing.

Most email providers set up priorities automatically when you configure your domain. Google Workspace, for instance, uses five MX records with priorities 1, 5, 5, 10, and 10 to provide redundancy and load distribution across their infrastructure.

MX records are one of the fastest ways to determine which email service a domain uses. The mail server hostnames in the records usually make the provider obvious. Some common patterns:

Google Workspace domains point to servers like aspmx.l.google.com and other googlemail.com hostnames. Microsoft 365 domains typically use *.mail.protection.outlook.com. Zoho Mail uses mx.zoho.com variants. ProtonMail uses mail.protonmail.ch and mailsec.protonmail.ch.

For domains using transactional or marketing email services alongside their primary provider, you may also see MX records for services like Amazon SES, SendGrid, or Postmark — though these services more commonly appear in SPF records rather than MX records.

Knowing which provider handles a domain's email is useful context when reviewing DMARC reports — it helps you quickly distinguish your own legitimate sending infrastructure from unauthorized sources.

If this lookup tool returns no MX records for your domain, it means there's no explicit instruction in your DNS telling sending servers where to deliver email. In this situation, per the email specification (RFC 5321), the sending server will fall back to your domain's A record and attempt to deliver mail directly to that IP address. In practice, this almost never works as intended — the server at that IP usually isn't configured to accept email, so messages bounce or get silently dropped.

The most common reasons for missing MX records are: you're setting up a new domain and haven't configured email yet, your DNS records were accidentally deleted during a migration or provider switch, or you're using a subdomain that doesn't have its own MX records and doesn't inherit them from the parent domain (MX records are not inherited).

The fix is to add the appropriate MX records for your email provider in your domain's DNS settings. Your email provider's documentation will list the exact records to add — the process usually takes under five minutes, though DNS propagation can take up to 48 hours.

MX records, SPF, DKIM, and DMARC all live in your domain's DNS, but they serve different roles in the email authentication chain.

MX records handle inbound routing — they tell the world where to deliver mail sent to your domain. SPF records handle outbound authorization — they list which servers are allowed to send mail on behalf of your domain. DKIM adds a cryptographic signature to outgoing messages so recipients can verify the message hasn't been tampered with. DMARC ties SPF and DKIM together with a policy, telling receivers what to do when authentication fails and where to send reports.

These systems are complementary, not redundant. A domain can have perfect MX records (inbound mail arrives fine) but completely lack SPF and DMARC (outbound mail has no authentication, making spoofing easy). Conversely, a domain can have strong DMARC enforcement but broken MX records (so inbound email, including DMARC aggregate reports, never arrives).

This is why checking all four — MX, SPF, DKIM, and DMARC — gives you a complete picture of your domain's email health. Viewleaf's DMARC monitoring brings SPF, DKIM, and DMARC alignment into a single dashboard, while this MX lookup tool helps you verify that the underlying mail routing is correct. For a step-by-step walkthrough of verifying and troubleshooting SPF, DKIM, and DMARC, see our email authentication verification guide.