MX record wrong? how to fix inbound email on your custom domain
If your custom domain isn't receiving inbound email, a wrong or missing MX record is the most likely cause. Here's how to diagnose and fix it.
Your custom domain is configured, but emails to you@yourdomain.com aren't arriving. No bounce notification, no error on your side. The most common cause: a wrong or missing MX record.
An MX record tells the internet which server handles inbound email for your domain. When it points to the wrong hostname or doesn't exist, incoming messages bounce or vanish without any signal on the receiving end.
If your agent needs reliable email on a custom domain, and skip the DNS headaches. Your agent provisions an address and starts receiving mail in about 30 seconds. Otherwise, here's how to find and fix the problem.
How to fix a wrong MX record for your custom domain (step by step)#
- Open your terminal and run
dig MX yourdomain.com +shortto see current records. - Log in to your DNS provider dashboard and navigate to MX record settings.
- Compare your current MX values against your email provider's documentation.
- Delete any MX records belonging to old or unused email providers.
- Add the correct MX records with the priority values your provider specifies.
- Save changes and wait 15 to 60 minutes for DNS propagation.
- Send a test email from an external account to confirm delivery.
- Re-run
dig MX yourdomain.com +shortto verify external resolvers see the update.
If that resolved it, you're done. If emails still aren't arriving, the sections below cover the deeper causes.
Why a wrong MX record kills inbound email#
When someone sends a message to hello@yourdomain.com, their mail server queries DNS for your domain's MX records. DNS returns one or more hostnames (like aspmx.l.google.com) along with priority numbers. The sending server connects to the highest-priority hostname and delivers the message there.
If no MX record exists, behavior depends on the sending server. Some fall back to the domain's A record and attempt delivery directly. Others reject the message with a permanent 550 error. Microsoft's documentation notes that Azure Communication Services doesn't provide MX records at all because it only handles outbound mail. If you're using a send-only service without configuring a separate inbound provider, your domain has no mechanism to accept email.
Priority numbers control failover. Lower values mean higher priority. With one record at priority 10 and another at 20, senders try 10 first and fall back to 20 only if the primary is unreachable. The problem shows up when your priority-20 record still points to a mail server you decommissioned months ago. Microsoft's Exchange documentation describes this exact failure mode: Exchange resolves the secondary MX, the old server rejects the message, and the email is permanently lost. The sender may or may not receive a bounce.
Common causes of MX record failures#
The most frequent cause is leftover records from a previous email provider. You moved from Google Workspace to Microsoft 365 but left Google's MX records in place. Now inbound mail splits between two systems, one of which no longer has an active mailbox. Some emails arrive, some don't, and the inconsistency makes debugging feel impossible when the real fix is just cleaning up stale DNS entries.
Just as common: domains that never had an MX record at all. Registering a domain and setting up a website doesn't configure email. Web hosting and mail hosting are independent services. Without an explicit MX record, your domain serves web pages fine but silently drops every inbound email. Microsoft's Q&A forums are filled with threads from domain owners who discovered this weeks after launch, having assumed email would "just work."
Cloudflare users face a specific trap. If the hostname your MX record points to uses Cloudflare's orange-cloud proxy, mail servers can't connect. Cloudflare proxies HTTP and HTTPS, not SMTP on port 25. Switch the target hostname to DNS-only (grey cloud) and inbound delivery should resume immediately.
DNS propagation lag trips people up too. You updated the MX record in your dashboard, but dig still returns the old value from an external machine. This is normal. DNS changes propagate over minutes to hours, occasionally taking up to 48 hours for full global resolution. If your registrar's UI shows the correct record but external queries don't, you're in the propagation window. Wait, then re-test.
The last common culprit is a typo in the MX hostname. MX records point to hostnames, not IP addresses. Mistype aspmx.l.google.com as aspmx.l.gogle.com and the record resolves to nothing. DNS won't flag it. The record just sits there, silently broken, until someone notices deliveries have stopped.
Correct MX record values for major providers#
No single resource online consolidates these side by side. Here's a reference you can copy from:
| Provider | MX hostname | Priority |
|---|---|---|
| Google Workspace | aspmx.l.google.com | 1 |
| Google Workspace (backup) | alt1.aspmx.l.google.com | 5 |
| Microsoft 365 | yourdomain-com.mail.protection.outlook.com | 0 |
| Zoho Mail | mx.zoho.com | 10 |
| Zoho Mail (backup) | mx2.zoho.com | 20 |
| Proton Mail | mail.protonmail.ch | 10 |
| Proton Mail (backup) | mailsec.protonmail.ch | 20 |
For Microsoft 365, replace yourdomain-com with your actual domain name using hyphens instead of dots. For Google Workspace, Google recommends adding all five MX records listed in their admin setup guide, not just the primary.
Warning
Always delete old MX records before adding your new provider's records. Leaving both sets in place creates split delivery where roughly half your inbound email goes to a server that no longer has your mailbox.
Verifying your fix#
Run this from any terminal:
dig MX yourdomain.com +short
The output should show your provider's hostnames with their priority values. If you see nothing, or you see hostnames from a provider you no longer use, that's your answer.
Tip
If you don't have dig installed, MXToolbox provides a free browser-based MX lookup that shows the same information.
For a more thorough check, Microsoft's Remote Connectivity Analyzer tests MX resolution end-to-end and reports exactly where delivery would fail. It's free and works for any domain, not just Microsoft-hosted ones.
One thing to keep in mind: don't test by sending email from the same domain to itself. Internal routing can bypass MX lookups entirely, so a message from you@yourdomain.com to test@yourdomain.com proves nothing about external delivery. Use a separate Gmail or Outlook account.
Set up monitoring before you forget#
MX records can change without warning. A compromised DNS account, an accidental edit, a registrar migration, or a domain renewal that resets settings can silently alter your records. None of the top troubleshooting guides online mention ongoing monitoring, but it matters for any system that depends on inbound email.
A simple cron job running dig MX yourdomain.com +short and comparing the output against expected values takes five minutes to set up. It saves you from discovering a problem days after emails stopped arriving. We covered the full DNS setup (including SPF, DKIM alignment, and record validation) in our guide to custom domains for agent email.
Skipping MX management altogether#
Every MX troubleshooting thread follows the same arc: configure records once, change something months later, forget to clean up the old entries, then spend an afternoon figuring out why half your emails vanish.
If you're building an agent that needs reliable inbound email, or setting up email for an OpenClaw agent, LobsterMail provisions inboxes on @lobstermail.ai with zero DNS configuration. Your agent creates its own address and receives mail immediately. On the Builder plan ($9/mo), you can connect up to 3 custom domains with MX records pre-configured and validated before go-live. The misconfiguration problem becomes structurally impossible because your agent never touches DNS.
Frequently asked questions
What does an MX record do, and why does inbound email fail when it's wrong?
An MX record maps your domain to the mail server that should receive inbound email. If the record is missing, points to the wrong server, or contains a typo, sending servers either bounce the message or deliver it to a server that doesn't have your mailbox.
How can I check my domain's MX records right now?
Run dig MX yourdomain.com +short in a terminal, or use a free web tool like MXToolbox. Both show the hostnames and priority values currently published in DNS for your domain.
Why am I receiving some emails but not others on my custom domain?
You likely have conflicting MX records pointing to two different mail servers. When a sending server resolves the old record first, the message goes to a mailbox that no longer exists. Delete the outdated records so all mail routes to your current provider.
What priority values should I assign to my MX records?
Use the exact values your email provider specifies. Lower numbers mean higher priority. Google Workspace uses priorities 1, 5, 5, 10, 10 across its five records. Microsoft 365 uses 0. Don't invent your own values unless you understand the failover behavior.
Why does Microsoft Exchange sometimes resolve the secondary MX record instead of the primary?
If the primary MX server is temporarily unreachable or slow to respond, Exchange falls back to the secondary. If that secondary points to an old server you no longer use, the message gets rejected permanently. Remove any MX records that no longer handle your mail.
Do I need to remove old MX records before adding new ones?
Yes. Leaving old MX records in place causes split delivery where some messages go to your new provider and others go to the old one. Delete all existing MX records first, then add your new provider's values.
How long should I wait after changing MX records before testing delivery?
Most changes propagate within 15 to 60 minutes, though full global propagation can take up to 48 hours. Use dig from an external machine (not your local network) to confirm resolvers have picked up the new values before you test.
Why are emails still bouncing even though the MX record looks correct in my DNS dashboard?
DNS caching is the most common reason. The sender's mail server may still have the old record cached. Wait for the TTL (time-to-live) to expire and retry. Also verify that your mail server is actually accepting connections on port 25 and that no firewall is blocking SMTP traffic.
Can Cloudflare's proxy block all inbound email to my domain?
Yes. If the hostname your MX record points to is set to orange-cloud (proxied) in Cloudflare, SMTP connections will fail because Cloudflare only proxies HTTP and HTTPS. Set the target hostname to DNS-only (grey cloud) to allow mail delivery.
Do MX records affect outbound email sending?
Not directly, but some receiving servers check whether the sender's domain has a valid MX record as part of spam filtering. A domain with no MX record can trigger rejection or spam classification on outbound messages even if SPF and DKIM pass.
What happens if two MX records have the same priority and point to different servers?
Sending servers will randomly distribute mail between the two. If both servers host your mailbox, this works as basic load balancing. If only one does, roughly half your inbound email will go to the wrong place and be lost.
Is there a way to get alerted when my MX record changes or stops resolving?
You can set up a cron job that periodically runs dig MX yourdomain.com +short, compares the output against expected values, and sends a notification if they differ. DNS monitoring services like DNSCheck and Oh Dear also offer automated MX change alerts with email or Slack notifications.
