How to Check MX Records and Fix Email Delivery Problems

Common MX Record Problems

1. Missing MX records

Check whether your email provider requires explicit MX records and whether you queried the correct recipient domain. SMTP has an implicit fallback to the domain’s address records when no MX records exist, but that only helps if the destination actually accepts mail. It is not a reliable substitute for your provider’s documented configuration. A null MX record, written as priority 0 with target “.”, explicitly declares that the domain does not accept email; do not confuse it with an absent record.

2. Incorrect mail server hostnames

Compare each target character by character with the email provider’s instructions. An MX value must be a hostname, not an address such as https://mail.example.com or a literal IP address. Its target must resolve to usable A or AAAA records and should not be a CNAME alias. Check that your DNS panel has not appended the domain to a value that was already fully qualified.

3. Wrong or unintended MX priorities

A lower number is preferred, so reversing values can send traffic toward the wrong service. Use your provider’s required priorities instead of assuming that 10 is always correct. Multiple MX entries can be intentional redundancy; confirm their purpose before deleting a backup server or changing equal-priority entries.

4. Records left from a previous provider

After an email migration, stale MX records can still direct senders toward the old service, especially if those records have a preferred or equal priority. Follow the migration plan before removing them. Confirm that the new mailboxes, aliases, and routing rules are ready, and keep any intended coexistence arrangement until the provider says it can be retired.

5. DNS propagation and stale caches

Resolvers and sending mail systems may retain older MX answers until their cache lifetimes expire. A TTL controls caching, not a guaranteed delivery deadline. Lowering a TTL now does not remove an answer that was already cached with the previous TTL. Negative answers can also be cached. There is no universal 24- or 48-hour propagation promise; compare authoritative and recursive answers, then allow the relevant caches to expire.

6. Incorrect or inactive authoritative nameservers

Confirm which nameservers the registrar delegates to, then edit the DNS zone served by that active provider. Records saved in an old hosting account or inactive DNS zone will not affect public lookups. In a control panel, @ or a blank host field often means the domain itself, but follow that panel’s instructions. Changing nameservers can affect the website and other services too, so preserve the full required zone configuration.

7. Delivery problems despite correct MX records

Check that the recipient mailbox and aliases exist, have available capacity, and are enabled. Read the bounce message and provider logs where available. Recipient rejection, spam filtering, forwarding rules, provider outages, SMTP connectivity, and sender reputation can all prevent delivery even with correct MX records. Authentication problems can also influence acceptance; MX alone cannot diagnose them.

If a message is merely delayed, the sending server may still be retrying after a temporary failure. Ask the sender for the delivery status rather than repeatedly sending test messages or assuming that a DNS change can recover every previously rejected message.