DNS Helper

MX

An MX record says which server handles incoming mail for a domain, a routing record like A, AAAA, CNAME and NS, not an authentication one. Getting mail delivered anywhere at all starts here; SPF, DKIM and DMARC, covered under Mail authentication, only matter once mail is already arriving somewhere in the first place.

Most domains that use a hosted mail provider, Google Workspace or Microsoft 365 among the common ones, get their MX values straight from that provider's own setup instructions rather than picking a server themselves. The Interface page's note about Google's own values arriving in capitals applies here directly, this is the record it was talking about.

If you're running your own mail server

If mail for this domain is actually handled by a server you run yourself, rather than a hosted provider, that server needs a name of its own with an A or AAAA record, exactly the kind covered on the A / AAAA page, and the MX record then points at that name. mail.example.com is the common modern choice: one name, one A/AAAA record, and the MX record is the only other thing that ever needs to reference it.

Older setups sometimes use several names instead of one: pop.example.com, imap.example.com and smtp.example.com, occasionally even a fourth, pop3.example.com, for good measure. All of them are free to be separate A/AAAA records aiming at the same address as mail.example.com, or simply CNAMEs pointing at mail.example.com instead. None of them ever did anything technically different from one another, it was a naming convention from a time when spelling out the protocol in the name felt clearer, not a requirement DNS or mail software actually enforces.

Priority: lower number goes first

A domain can have more than one MX record, each with its own priority number. Sending mail servers try the lowest number first, and only fall back to a higher one if the first doesn't answer. In the example above, mail is tried at mail.example.com. first, and only goes to mail2.example.com. if that one is unreachable. Lower number, higher priority, the opposite of how it might read at a glance.

Worth knowing before setting one up: a second MX record only adds real resilience if it actually points at independent infrastructure. mail.example.com and mail2.example.com are only meaningfully redundant if they're genuinely separate servers, in a cluster or otherwise able to fail independently of each other. Creating two A records that both quietly point at the same single server, then listing both as MX targets, doesn't add anything: if that one server goes down, both "different" names go down with it. For a small setup with a single mail server, one MX record is perfectly fine, there's no need to invent a second target just to have one.

Two mistakes worth avoiding

An MX value has to be a hostname, never an IP address directly, even though the mail server obviously has one. Point it at a name, and let that name's own A or AAAA record supply the address.

That name also shouldn't be a CNAME. An MX record pointing at an alias rather than directly at a name with its own A or AAAA record is invalid by the DNS standards themselves, and mail servers are entitled to simply refuse to deliver to it. If a hosted mail provider hands you a CNAME-shaped value for this field, double check it, that's usually meant for a different record entirely.

Not accepting mail at all: the null MX

A domain that never sends or receives email, a brand-protection registration, for instance, or one used only for a website, is still a valid target for someone to try mailing anyway, deliberately or by mistake. Leaving MX empty doesn't communicate that the domain wants no part of it, it just leaves the question unanswered. The deliberate way to say "this domain doesn't accept mail, don't bother" is a null MX record: priority 0, value a single dot, nothing else. It tells a sending server plainly that there's nowhere to deliver to, rather than leaving it to find that out the slow way.