MX records tell the rest of the internet where to deliver email for your domain. When someone sends a message to an address at your domain, their mail server looks up your MX records, picks the server with the lowest priority number and hands the message over. The lookup above shows your mail servers in the order senders try them, names the email provider behind each one and checks that every server actually works.

What an MX Record Is

MX stands for mail exchanger. Each MX record has two parts: a priority number and the host name of a mail server. A domain usually has one to five of them, all pointing at servers run by its email provider, such as Google Workspace, Microsoft 365 or Zoho Mail.

MX records only control incoming mail. They have nothing to do with which servers may send mail as your domain. That job belongs to SPF, DKIM and DMARC, which the lookup also checks and links to.

How to Read Your Result

The headline names the provider handling the domain’s mail, or tells you something is wrong. The Mail Servers table lists each record in the order senders try them:

• Priority: lower numbers are tried first, and records with the same number share the load
• Mail server: the host name the record points to, with the email provider it belongs to when we recognize it
• Addresses: the IP addresses the server name resolves to, which prove it exists and can receive mail

A green dot means the server resolves correctly. A red dot means mail sent to that server will fail, and What to Fix explains why and what to change.

Email and Website Hosting Are Separate

Your MX records are independent of where your website is hosted. A domain can run its website on one company’s servers and its email at a completely different provider, and this is the usual setup for most businesses. Moving your website to a new host doesn’t change your email, as long as the MX records stay the same. The reverse is true too: switching email providers only means changing the MX records, and your website keeps running exactly as before.

How Priority Works

When a sender has a message for your domain, it starts with the record that has the lowest priority number. If that server doesn’t answer, it moves to the next one. If every server is down, the sender holds the message and keeps retrying, usually for several days, before giving up and sending a bounce.

The numbers themselves don’t matter, only their order. A record with priority 1 and a record with priority 10 behave exactly the same as priorities 10 and 20. Records with equal priority are used in turn, which spreads mail across several servers.

Records for Popular Providers

Each email provider gives you the exact records to add during setup, and they look quite different from one another. Microsoft 365 uses a single record that points to a server named after your domain at mail.protection.outlook.com, with priority 0. Google Workspace has long used five records ending in aspmx.l.google.com, and newer setups use a single record, smtp.google.com. Zoho Mail, Fastmail and Proton Mail each use two or three records on their own domains.

The lookup recognizes more than 60 providers and security services by their server names, so you can confirm at a glance that your domain points where you expect.

Common MX Problems

Most email delivery failures that come down to DNS trace back to one of these mistakes:

• A server name that doesn’t exist, usually from a typo or a provider you no longer use, so mail sent to it fails
• An MX record that points to an IP address instead of a host name, which the email standards don’t allow and many senders reject
• An MX record that points to an alias (a CNAME), which the standards also discourage and some senders handle badly
• Records for two different providers left in place after switching, which splits incoming mail and loses some of it
• No MX records at all, so mail either fails or goes to the website server, which usually isn’t set up for email

Security services such as Proofpoint, Mimecast and Barracuda are an exception to the two-provider warning. They filter mail before passing it on, so their records often sit in front of your real provider on purpose.

Switching Email Providers

Moving to a new email provider is mostly a matter of replacing your MX records, but the order of steps matters. Set up your mailboxes at the new provider first. Then, a day before the switch, lower the TTL on your MX records to a few minutes so the change spreads quickly.

When you’re ready, delete every old MX record and add the new ones in a single change. Leaving old records in place, even at a lower priority, means some mail keeps going to the old provider. Afterward, update your SPF record with the new provider’s include and set up DKIM for it, then check all three with our tools.

Domains That Don’t Receive Email

If a domain never receives email, the cleanest setup is a null MX record: priority 0 and a server name of a single dot. Defined in RFC 7505, it tells senders right away that the domain doesn’t accept mail, so they bounce messages immediately instead of retrying for days.

Pair it with an SPF record of v=spf1 -all and a DMARC record with p=reject. Together they say the domain neither sends nor receives email, which stops scammers from using a parked or unused domain to send fake messages.

What Happens Without MX Records

When a domain has no MX records, the email standards tell senders to try the domain’s own address instead, the same address its website uses. This fallback rarely works in practice, because web servers usually aren’t set up to accept mail. If you use a domain for email, always publish MX records, even if mail is handled on the same server as your website.

The lookup reads records through public DNS, so it sees what other mail servers see. If you just changed your MX records and the result looks old, wait a few minutes and check again. Changes can take up to the record’s TTL to appear everywhere.