MX Record Checker

MX records point to the host names of the servers that receive email for your domain, never to IP addresses directly. Each record carries a preference number. A sending server looks up your MX records and tries the lowest preference number first; if that host is unavailable, it tries the next one.

Multiple records give a domain somewhere else to deliver when the primary host is unreachable. Senders work through the list in preference order, so a second host reduces the risk that a temporary outage turns into bounced or delayed mail.

Open the DNS management interface at whatever provider hosts your domain's DNS, add one MX record per receiving host, and give each a preference number. The host names you point at must themselves resolve through A or AAAA records.

A single MX record with preference 0 and a host of "." (the root label) is a null MX, defined in RFC 7505. It is a deliberate statement that the domain accepts no email at all, which is the correct configuration for a domain used only for a website or only for sending. Senders reject mail to it immediately instead of falling back to the address record and retrying for days.

Mail does not simply stop. Under RFC 5321 a domain with no MX record is treated as having an implicit one at preference 0 pointing to the domain itself, so senders fall back to its A or AAAA record. That is usually a web server with no mail service, so delivery fails after days of retries rather than immediately. If the domain is not meant to receive mail, publish a null MX and senders get a clear answer on the first attempt.

Changes propagate as cached copies expire, which is governed by the TTL on the records. Until every resolver's cached copy expires, some senders still use the old value, so keep the previous host accepting mail until the change has fully rolled out.

Technically yes, but separating them is usually better for both performance and security, and it means a web outage does not also stop mail delivery.

Not directly. MX governs inbound routing, while SPF, DKIM, and DMARC govern how your outbound mail is authenticated. They matter together: the hosts you receive on are frequently the same platform you send through, and that platform is what has to be authorized in SPF and signing with DKIM.

Pointing an MX record at an IP address instead of a host name, pointing it at a host that has no A or AAAA record, leaving a retired provider's host in the list after a migration, and removing MX entirely on a domain that should publish a null MX.

Yes. Point your MX records at the host names that provider gives you, remove the previous provider's records once the migration is complete, and update SPF and DKIM at the same time so your outbound mail stays authenticated.