MX – the address where your mail is delivered

MX records tell the world where mail for your domain is delivered. Here is what they contain, what a null MX does for a website-only domain, and what each inbox finding means.

An MX record is the postal address of your domain. When someone sends you a message, their server asks DNS a single question: where does mail for this domain go? The answer is a list of host names with numbers in front of them, and the sending server works through it from the lowest number up until one accepts the message.

If that answer is missing, mail does not arrive. Not delayed, not in spam – rejected, with an error the sender will see. And there is a second case that surprises people: a domain that is only used for a website, with no mailboxes at all, still needs a clear statement. Without one, senders fall back on the address of the web server and spend days trying to deliver to a machine that has never handled mail.

What the records look like

MX records live on the domain itself and always come in a list, even when the list has one entry.

example.com.  MX  10 mx01.mail.protection.outlook.com.
example.com.  MX  20 mx-backup.example.net.

A domain that deliberately receives no mail says so with a null MX:

example.com.  MX  0 .

That single dot is the whole statement: no mail server, do not try anything else. Senders then reject a message immediately with a clear error instead of retrying for days, and your customers find out at once that they used the wrong address.

The domain that only has a website

Most companies own more domains than they use. Old brand names, misspellings bought defensively, the domain from a campaign three years ago. None of them have mailboxes, and almost none of them are protected – which makes them convenient for anyone who wants to write in your name. A recipient has no reason to doubt an address at a domain that genuinely belongs to you.

A domain without mailboxes needs three records, and all three are cheap:

Ten minutes per domain, and the door is closed. This check reports the missing pieces separately, which is why three of the findings below are about domains with no mailboxes.

How to set it up

MX records are published where your DNS is hosted, and their values come from whoever runs your mailboxes.

Step by step at GoDaddy

1. Sign in, open My Products, then DNS next to the domain.
2. Delete the existing MX records – a leftover from an old provider will collect mail you never see.
3. Add New Record, type MX, name @, value the target name from your provider, priority as given.
4. Repeat for each further target.
5. Save and wait up to an hour, then send a test message from an outside address.
6. Run this check again to confirm the names resolve.

The findings in detail

No mail server configured

Your domain has no MX record at all, and no null MX either. Mail to this domain cannot be delivered: senders fall back to the domain's own web address and, if nothing there accepts mail, give up after days of retries.

What to do: if the domain should receive mail, publish your provider's MX records. If it should not, publish a null MX – 0 . – and add the strict SPF and DMARC records described above.

Only one mail server

There is a single MX record. If that server is unavailable, mail is not lost: sending servers queue it and retry, usually for several days. But you have no second route, and a long outage becomes visible to your customers.

What to do: nothing urgent. If your provider offers a second MX target, add it with a higher preference number. Most hosted providers already hide redundancy behind one name, and then a single record is perfectly correct.

MX points to an IP address

An MX record names an address rather than a host name. The standard does not allow this, so strict senders reject it outright while lenient ones still deliver – the result is mail that arrives from some places and not others.

What to do: create an A record such as mail.example.com pointing at the address, and set the MX record to that name.

MX points to an alias

An MX record points at a name that is itself a CNAME. MX records must reference a name with an address of its own, and some sending servers refuse delivery rather than follow the alias.

What to do: look up where the alias leads and enter that target name directly in the MX record. If the target changes often, keep an A record under your own domain and point the MX at that.

Mail server does not resolve

One of your MX names has neither an IPv4 nor an IPv6 address. Nobody can deliver to it, because there is nothing to connect to. Usually a typo, or a leftover pointing at a provider you left.

What to do: check the spelling against your provider's instructions. If the name belongs to a former provider, delete the record.

Mail server without reverse DNS

The address of one of your mail servers has no PTR record – no reverse entry from address back to name. For receiving mail this does not matter at all. For sending from the same address it matters a great deal: many recipients refuse connections from an address with no reverse entry.

What to do: if you run the server yourself, ask whoever provides the address – usually your hosting company – to set the PTR to the server's own name. If the mailboxes are hosted, the finding is informational and belongs to your provider.

Domain without mailboxes can still be forged

This domain states with a null MX that it receives no mail, but its SPF record does not close the other direction. Not receiving and not sending are separate statements, and only the first has been made. Anyone can still put this domain in a From line.

What to do: set the SPF record to exactly v=spf1 -all. Nothing sends from here, so nothing is authorised. It is a single record and cannot break anything.

Domain without mailboxes does not reject

The domain receives no mail, but its DMARC policy is not reject. On a domain with no legitimate senders there is no rollout to be careful about: everything claiming to be this domain is a forgery.

What to do: publish v=DMARC1; p=reject; rua=mailto:… at _dmarc. Add a reporting address as well – on a parked domain the reports show you very clearly whether anyone is trying.

No mail servers, and no clear statement either

The domain has no MX records and no null MX, and its DMARC policy is not reject. That leaves it in the worst of both worlds: senders fall back on the web server's address and retry for days, and the domain remains usable as a forged sender.

What to do: decide what this domain is for. If it receives mail, publish proper MX records. If it does not, publish a null MX, v=spf1 -all, and DMARC on p=reject.

Frequently asked questions

Does a null MX stop mail being sent from the domain?

No. It is a statement about receiving only. Sending is governed by SPF and DMARC, which is why a parked domain needs all three records rather than one.

Do I need a backup MX server?

Usually not. Sending servers already retry for days if yours is unreachable, and a badly maintained backup server is a well-known way to collect spam. Only add one if your provider offers it as part of the service.

Why does the check say transport encryption is "not measurable"?

Because measuring it means opening an SMTP connection to your server, and outgoing SMTP is blocked on the checking server. Rather than assume everything is fine, the report says so. What is measurable from DNS is on the transport encryption page.

The MX records are right and mail still does not arrive – what now?

Check whether the names resolve, whether the addresses appear on a blocklist, and whether an old MX record from a previous provider is still in the list with a lower number. The lowest number wins, and a forgotten entry quietly collects everything.