Not Receiving Emails on Your Domain? An MX-Record Checklist That Finds the Cause

Assumed audience: someone who owns a domain and pays for email through Google Workspace, Microsoft 365, Zoho, or a web host, and who can log into both their DNS manager and their mail provider's admin console. Not mail-server administrators, and not people running their own mail server, though a few notes point that way.

If inbound email to your own domain has stopped arriving, the cause is almost always one of four things:

• there is no MX record, or it points to a hostname that no longer works;
• you are editing DNS at a provider that is not authoritative for the domain, so your changes do nothing;
• an old MX record from a previous mail host is still catching part of your post;
• your web hosting control panel is set to deliver the domain's mail to a local mailbox instead of handing it to your real provider.

The quickest way to work out which one you are facing is to stop looking at your registrar's dashboard. Check what the rest of the internet sees: look up your domain's NS records to find out who actually answers DNS for it, then look up your MX records through a public resolver. After that, read the bounce message, because it names the failure precisely and it is the step most people skip.

This checklist is ordered by how common each cause is and how fast it is to rule out, so working straight down it is a reasonable strategy.

Start by finding out who actually controls your DNS

The single biggest time-waster in email troubleshooting is editing the wrong zone. A domain registered with one company can have its nameservers delegated to another: Cloudflare, Amazon Route 53, a hosting provider, a dedicated DNS service. Whichever service the NS records name is the only place where editing an MX record has any effect. Every other control panel will happily show you records and let you change them while quietly doing nothing.

Check it:

dig NS yourdomain.com +short

If that returns Cloudflare nameservers and you have spent the morning editing records at your registrar, you have found the problem. Make your changes wherever the NS records point.

The follow-up question is usually: should the records live at my registrar or my host? Wherever the NS records currently point. If you want to move them, change the nameservers, but treat that as a separate and slower job.

Check what the rest of the internet sees, not your control panel

Your DNS provider's dashboard shows you the record you intended. It does not show you caching, a conflicting record added by a setup wizard, or a DNSSEC failure. Use an outside view:

dig MX yourdomain.com @8.8.8.8 +short

Run it again against @1.1.1.1. If the two resolvers disagree, a change is still working through resolver caches. Web tools do the same job:

• MXToolbox MX Lookup (mxtoolbox.com), which also runs an SMTP connection test against your MX.
• Google Admin Toolbox Check MX (toolbox.googleapps.com/apps/checkmx/), the most useful of the three because it flags conflicting records, missing records, DNSSEC problems and common typos in one report, whether or not you use Google.

A healthy result is one or more MX lines, each pointing to a hostname (never an IP address), each of which resolves to an A record, with priorities matching what your mail provider specifies. Note the TTL value the lookup reports: that number, in seconds, is the worst case for how long a change takes to be seen everywhere.

Strictly, DNS records do not "propagate". Nothing is pushed anywhere. Resolvers cache the old answer until its TTL expires and then ask again. That distinction matters because it tells you the delay is bounded by a number you can look up, not the mythical 48 hours.

Read the bounce message before you touch anything

If senders are getting a non-delivery report, it contains the actual error. This is the highest-value thirty seconds in the whole process and it is routinely ignored.

If there is no bounce at all and nothing in the inbox, the mail is either being accepted and hidden (spam, quarantine, a filter) or it is being silently routed somewhere else, which points at the control-panel problem below.

The checklist, in the order worth working through

Items 1, 5 and 6 account for most real cases. The rest are quicker to check than to explain, which is why they sit in the table rather than the text.

MX syntax rules that quietly break delivery

An MX record has two parts: a priority number and a target hostname. The target is where the rules bite.

• The target must be a hostname with its own A or AAAA record, not an IP address. The SMTP specification (RFC 5321) defines MX resolution in terms of a domain name, and many sending systems reject an MX that contains an IP literal outright.
• The target must not be a CNAME or other alias. RFC 2181, section 10.3, states that an MX record must point to a host with an address record. Some senders follow the alias anyway; stricter ones fail, which is exactly the "some mail gets through" pattern.
• Priority is "lower wins". The lowest number is tried first; equal numbers share the load. A stray mail.yourdomain.com at priority 1, left over from an old setup and now pointing at a decommissioned server, will beat your real provider at priority 10 every time.
• Watch for an auto-appended domain. Some DNS editors add the zone name to anything that does not end in a full stop, turning smtp.google.com into smtp.google.com.yourdomain.com. Check the record as it renders after saving, not as you typed it.
• On Cloudflare, the MX target cannot be proxied. MX records themselves are always "DNS only". If your MX points at your root domain and the root record is proxied (the orange cloud), senders connect to Cloudflare's web servers on port 25 and get nowhere. Point MX at a subdomain such as mail.yourdomain.com with a grey-cloud A record, or use your provider's own hostname.
• A single MX of . is a Null MX (RFC 7505). It is a deliberate statement that the domain neither sends nor receives mail. If a setup wizard added it, inbound mail is being refused on purpose.

The follow-up question here is usually "which of these is mine?" The Google Check MX report names all of them except the Cloudflare proxy issue, which shows in the Cloudflare dashboard as a coloured cloud icon next to the record.

When some emails arrive and others disappear

Intermittent delivery, where some senders get through and others vanish with no pattern you can see, almost always means mail is being split between two destinations.

Conflicting MX records. You added your new provider's MX but the previous host's records are still there. Senders choose by priority, and round-robin between equal priorities, so a share of your mail is delivered to a mailbox on a server you no longer check. The fix is blunt: delete every MX record that is not your current provider's. There is no reason to keep the old ones "just in case", and a lingering backup MX causes far more trouble than it ever prevents.

cPanel or WHM set to local delivery. This is the one that costs an afternoon. cPanel has an Email Routing setting per domain, with options including "Local Mail Exchanger" and "Remote Mail Exchanger". If it is set to Local while your MX points to Google or Microsoft, the hosting server treats itself as responsible for the domain: it accepts messages for your addresses into local mailboxes and never forwards them to your real provider. The signature of this problem is that mail from Gmail and Outlook arrives normally, while mail from anyone whose address is hosted on that same server disappears completely, because for those senders the message never leaves the box. Set Email Routing to "Remote Mail Exchanger". It costs an afternoon because your own test messages, sent from an unrelated account, succeed the whole time you are looking for the fault.

A secondary MX that no longer relays. A backup MX at a higher priority number is only useful if it queues mail and forwards it to your primary. An old secondary that has been switched off will still accept connections and then drop whatever it receives.

Correct MX values for the common providers

Confirm these against your provider's own admin console before relying on them. Values change, and several providers have region-specific hostnames.

The commonest mistake with a table like this is a partial copy: three of the five legacy Google records, or the Microsoft host with somebody else's domain key still in it. If you are on the current single-record Google setup, there should be exactly one MX and nothing else alongside it.

DNSSEC: the misconfiguration that takes the whole domain down

If DNS was recently moved to a new provider and the old DS record is still published at the registrar, validating resolvers see a broken signature chain and return SERVFAIL for every query, MX included. Mail bounces with a DNS error, and the website often turns unreliable on some networks at the same time.

Check by running the Google Check MX report, or by querying a validating resolver directly and watching for SERVFAIL:

dig MX yourdomain.com +dnssec @8.8.8.8

The fix is either to remove the DS record at the registrar, which switches DNSSEC off, or to publish the correct DS record for the new DNS provider. Do not leave it half configured, because a partial chain fails closed.

When it isn't the MX record at all

If an external lookup shows the right MX and an SMTP test connects, DNS is not your problem. Look at:

• 550 user unknown in the bounce: the address, alias or catch-all does not exist at the provider, or the domain is verified but not fully set up.
• No bounce, empty inbox: check the junk folder, then the provider-level quarantine (Microsoft Defender and the Google Admin console both hold mail there, out of sight of the user), then any filters or rules that auto-archive or forward, then whether the mailbox is over quota.
• One address fails, the rest work: that user is suspended or unlicensed, or the alias is not mapped to a real mailbox.
• Greylisting: a first message from an unfamiliar sender gets a temporary rejection by design; compliant servers retry and get through within minutes.

One clarification that saves a lot of confusion: SPF, DKIM and DMARC have nothing to do with receiving mail. They authenticate outbound mail and are checked by the receiver. A broken SPF record damages your ability to send, which can look like a receiving fault when it is really your replies bouncing back into the thread.

How long to wait after a change

If you know a change is coming, drop the record's TTL to 300 a day beforehand and raise it again once the new value has settled. The old "wait 24 to 48 hours" advice is a holdover from an era of slower secondary-server updates and rarely applies to a single record edit today.

Confirming the fix

1. dig MX yourdomain.com against both 8.8.8.8 and 1.1.1.1 returns the same records, matching your provider's specification.
2. Google Check MX or MXToolbox reports no conflicting records and no DNSSEC error.
3. An SMTP diagnostic connects to your MX on port 25 and the greeting banner names the right provider.
4. A test message from an address on a completely unrelated system, not the same host and not the same Microsoft or Google tenant, reaches the inbox.
5. If cPanel routing was the cause, a message from another account on that same server also arrives, because that was the path that was broken.
6. The test messages are sitting in the inbox, not the spam folder or the quarantine.

If all six hold, the domain is receiving mail correctly. If step 4 works but step 5 does not, the control-panel routing is still set to local.

Related Guides

Business Email Not Sending or Receiving? Common Causes and Fixes - this checklist deals with inbound mail. If outgoing mail is failing too, or only sending is affected, start here.

Why Are Business Emails Going to Spam? SPF, DKIM and DMARC Explained - once mail reaches your domain again, the next complaint is usually that your replies land in other people's junk folders. This covers the three records that decide that, which the section above deliberately kept out of scope.

SPF Record 10-Lookup Limit Explained and How to Fix It - the common reason an SPF record silently stops working after you add another sending service such as a newsletter platform or CRM.

Domain Suspended, Pending ICANN Verification: How to Fix It - a suspended domain stops resolving altogether, which takes MX lookups down with it. If a bounce says SERVFAIL or the domain "cannot be found", rule this out first.

How to Move Your Website to a New Host Without Losing Traffic - host migrations are where conflicting MX records, stale DNSSEC keys and local mail routing usually get introduced. Worth reading before you move, not after.

My Website Is Down: What to Do First - the same nameserver and DNS checks in a wider context, for when the website has gone as well as the email.