MX Record Lookup Tool

Look up mail exchange (MX) records for any domain to see which servers handle its email

This check runs from our infrastructure and may log the queried information to improve accuracy and availability. Logs are retained for a short period and are not used for marketing

Domain Name

Try:

About MX Records

What are MX Records?

MX (Mail Exchange) records specify which mail servers are responsible for accepting email messages on behalf of a domain. Each MX record points to a mail server hostname.

Priority Values

Lower priority values indicate preferred servers. If the primary server (lowest priority) is unavailable, email will be delivered to servers with higher priority values.

What Are MX Records?

MX (Mail Exchange) records are DNS records that tell the internet which mail servers are responsible for accepting email on behalf of a domain. Every domain that receives email needs at least one MX record. Without MX records, email sent to your domain has nowhere to go and will bounce back to the sender.

Each MX record contains two pieces of information: a priority value and a mail server hostname. The priority value is a number — lower numbers indicate higher priority. When a sending server looks up your MX records, it tries the server with the lowest priority number first. If that server is unavailable, it moves to the next one. This is how email achieves redundancy — you can have a primary mail server and one or more backup servers that accept email when the primary is down.

For example, netoz.au has an MX record with priority 10 pointing to smtp.netoz.au (138.252.126.33). Under normal conditions, all email goes to this primary server. If a domain has multiple MX records, the sending server tries the lowest priority first, then falls back to higher-priority servers if the primary is unreachable.

How Email Routing Works

When you send an email to hello@netoz.au, your mail server needs to figure out where to deliver it. Here's what happens step by step:

DNS lookup. Your mail server queries DNS for the MX records of netoz.au. This returns the mail server smtp.netoz.au (138.252.126.33) and its priority.
Priority sorting. The sending server sorts the MX records by priority value (lowest first) and attempts delivery to the highest-priority server.
SMTP connection. Your server opens an SMTP connection to the target mail server on port 25 (or 587 for submission). It introduces itself with an EHLO command and begins the handshake.
TLS negotiation. If the receiving server supports STARTTLS, the connection is upgraded to an encrypted channel. Most modern mail servers require or prefer encrypted connections.
Authentication checks. The receiving server checks the sender's IP address against the domain's SPF record to verify the sender is authorised. It also checks DKIM signatures and DMARC policies. You can verify your SPF configuration with our SPF Validator.
Delivery or rejection. If all checks pass, the email is accepted and delivered to the recipient's mailbox. If the server is unavailable, the sending server queues the message and retries for up to 5 days (typically) before sending a bounce notification.

This entire process usually happens in under a second. But when MX records are misconfigured, email can be delayed for hours, delivered to the wrong server, or lost entirely. That's why checking your MX records regularly is important — especially after changing email providers or DNS hosting.

How to Fix MX Record Issues

MX record problems are one of the most common causes of email delivery failures. Here are the issues we see most often and how to resolve them.

Missing MX Records

If your domain has no MX records at all, email cannot be delivered to it. This often happens when migrating to a new DNS provider and forgetting to recreate MX records, or when a domain is newly registered. Use this tool to check — if no records appear, log in to your DNS provider and add MX records pointing to your mail server. Your email provider will have the exact records you need in their setup documentation.

MX Records Pointing to Old Servers

After switching email providers (e.g. moving from self-hosted to Google Workspace or Microsoft 365), the old MX records must be replaced with the new provider's records. If you leave the old records in place, email will be delivered to servers that no longer accept it, causing bounces. Remove all old MX records and add the new ones provided by your email provider.

Incorrect Priority Values

If your primary and backup mail servers have the same priority, sending servers will randomly choose between them. This might not be what you want if one server is your primary and the other is a backup. Ensure your primary server has the lowest priority number (e.g. 10) and backups have higher numbers (e.g. 20, 30). Most email providers specify the exact priority values to use.

MX Records Pointing to a CNAME

The DNS specification (RFC 2181) states that MX records must point to a hostname with an A or AAAA record, not to a CNAME. While some mail servers tolerate this, others will reject the connection. If your MX record points to a CNAME, change it to point directly to the mail server's A record hostname. You can use our DNS Lookup tool to check what your MX hostname resolves to.

TTL and Propagation Delays

After changing MX records, the old records may be cached by DNS resolvers around the world. The TTL (Time to Live) on your previous MX records determines how long this takes — typically a few hours to 48 hours. During this window, some email may still be delivered to the old server. To minimise disruption, lower the TTL on your MX records to 300 seconds (5 minutes) at least 24 hours before making the switch.

Common Email Deliverability Problems

Even with correct MX records, email can end up in spam or be rejected entirely. Deliverability depends on several factors beyond MX configuration.

Missing or Invalid SPF Records

SPF (Sender Policy Framework) is a TXT record that lists which IP addresses and servers are allowed to send email on behalf of your domain. Without SPF, receiving servers have no way to verify that an email claiming to be from your domain actually came from your server. This makes your emails more likely to be flagged as spam. Use our SPF Record Builder to create a correct SPF record for your domain.

Missing DKIM Signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails, allowing receiving servers to verify that the message hasn't been tampered with in transit. Without DKIM, your emails lack a key authentication signal that major providers like Gmail and Outlook use for spam filtering. Your email provider should provide DKIM keys to publish as DNS TXT records.

No DMARC Policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication — accept it, quarantine it, or reject it. Without DMARC, you have no control over how failed authentication is handled, and you get no reporting on who is sending email using your domain. Start with a p=none policy to monitor, then move to p=quarantine or p=reject once you're confident.

IP Reputation and Blacklists

If your mail server's IP address is on a real-time blacklist (RBL), many receiving servers will reject your email outright. This can happen if your server was previously used for spam, or if another user on the same IP range is sending spam. Check your server's IP against major blacklists with our RBL Checker. If you're listed, most blacklist operators provide a delisting process.

Missing Reverse DNS (PTR Record)

Many mail servers check that the sending IP address has a valid PTR (reverse DNS) record that matches the server's hostname. If your mail server's IP doesn't have a PTR record — or it points to a generic ISP hostname — your emails are more likely to be flagged as spam. Contact your hosting provider to set up a PTR record that matches your mail server's EHLO hostname. If you host with NetOz, we set this up as part of your email hosting configuration.