MX Records Explained: Why Replies to Your Emails Never Arrive
You sent 300 reminders. Nobody replied. Or did they?
A client answers your payment reminder: “Paid on Friday, confirmation attached.” Another asks for a copy of the invoice. A third says the amount is wrong because they changed their plan. You never see any of these messages. The campaign went out, the stats look fine, and your inbox stays suspiciously quiet — until someone calls, annoyed that nobody answered.
When outgoing email works but incoming email silently disappears, the culprit is very often one small DNS entry: the MX record. This guide explains what MX records do, how they differ from SPF and DKIM, what a correct setup looks like, the mistakes that break it, and how to check yours in under a minute.
What an MX record actually does
MX stands for Mail Exchange. An MX record tells the rest of the internet where to deliver email addressed to your domain. When someone hits Reply on your message from billing@yourfirm.com, their mail server looks up the MX records for yourfirm.com, picks the server with the best priority and hands the message over. No MX record, no delivery.
You can have flawless SPF, DKIM and DMARC, land in the inbox every time, and still lose every reply because your MX records are missing or wrong. The reverse is also true: working MX records do nothing for your outgoing authentication. If your problem is on the sending side, start with our guide on how to fix SPF record errors.
What correct MX records look like
Each MX record has two parts: a priority (a number; the lowest is tried first) and the hostname of a mail server. Below are typical setups for the two most common business mailbox providers. Treat them as illustrations and always copy the exact values from your provider's admin console.
Google Workspace
Newer Google Workspace setups use a single record:
yourfirm.com. 3600 IN MX 1 smtp.google.com.
Older accounts often still use the classic five-record set, which keeps working:
MX 1 aspmx.l.google.com.MX 5 alt1.aspmx.l.google.com.MX 5 alt2.aspmx.l.google.com.MX 10 alt3.aspmx.l.google.com.MX 10 alt4.aspmx.l.google.com.
Microsoft 365
Microsoft 365 uses one record with a hostname derived from your domain name:
yourfirm.com. 3600 IN MX 0 yourfirm-com.mail.protection.outlook.com.
A single record is fine with large providers like these, because one hostname is backed by their own redundant infrastructure. If you run your own mail server, a second MX with a higher number (for example 20 backup.yourfirm.com.) gives senders somewhere to go when the primary is down. Records with the same priority share the load between them.
Six MX problems that silently swallow replies
1. No MX records after a domain or hosting migration
The classic. You move the website to a new host or transfer the domain to a new registrar, and the new DNS zone is created from a template that only contains website records. The MX records from the old zone never make it across. Sending still works, because your email platform doesn't need your MX, but nothing can reach you. Some servers fall back to your domain's A record and try your web server, which usually refuses — and whoever replied gets a bounce days later, if at all.
2. MX pointing to an IP address or a CNAME
An MX record must point to a hostname, and that hostname needs its own A (or AAAA) record. MX 10 203.0.113.25 is simply invalid. Pointing MX at a name that is itself a CNAME alias is forbidden by RFC 2181: many servers tolerate it, some don't, and you'll never know which ones are quietly failing.
3. Wrong or flipped priorities
Remember: lower number = higher priority. If your backup server is 10 and your main one is 20, most mail goes to the backup first. If that backup isn't set up to pass messages on to your real mailbox, mail piles up there or bounces.
4. Leftover records from your old provider
When switching mailbox providers, people often add the new MX records and forget to delete the old ones. Depending on priorities, some replies land in the new mailbox and some in the old account you no longer check — which may be shut down any day.
5. TTL and propagation
Every DNS record has a TTL (time to live) that tells resolvers how long to cache it. With a TTL of 86400 (24 hours), servers around the world may keep using your old MX for up to a day after you change it. Before a planned migration, lower the TTL to something like 300 a day or two in advance, make the switch, and raise it again once everything works.
6. Typos and the trailing dot
In DNS zone files, a hostname without a final dot is treated as relative to your own domain. So mail.provider.com (no dot) in the zone for yourfirm.com becomes mail.provider.com.yourfirm.com — a server that doesn't exist. Some registrar panels add the dot for you, some don't. After saving, always look the record up and check the hostname it returns. Watch for plain typos too, like aspmx.l.gogle.com: DNS will happily publish nonsense.
Why this matters even more when you email many clients
If you mostly send scheduled emails, it's tempting to think receiving mail is someone else's problem. It isn't:
- Replies are part of the job. For payment reminders, statements and fee notices, replies are often the most valuable outcome: “paid yesterday”, “please resend the invoice”, “can I pay in two instalments?”. Lose them and you lose the conversation that gets you paid.
- Some receivers check that your domain can receive mail. Many mail servers reject messages from sender domains with no MX (or at least A) record: a domain that can't accept mail can't accept bounces or complaints either, a pattern typical of spam. Gmail, Yahoo and Microsoft focus their rules on SPF, DKIM, DMARC, unsubscribes and spam rates (see bulk sender requirements for Gmail, Yahoo and Microsoft), but a domain that looks unable to receive mail does your reputation no favours.
- Reply-To pointing to a mailbox that doesn't exist. Your MX can be perfect and replies still vanish if the From or Reply-To address is a mailbox nobody created — say
accounts@when the real mailbox isaccounting@. Send yourself a test, hit Reply and make sure the answer lands where someone actually reads it.
How to check your MX records in a minute
- Enter your bare domain (no
www, nohttps://) in the MX checker. - Compare the hostnames with what your mailbox provider tells you to use, and make sure nothing is left over from a previous provider.
- Check the priorities: your main server should have the lowest number.
- Read the warnings. The checker flags a domain with no MX records, MX hosts that don't resolve to an IP address (which is how typos and trailing-dot mistakes usually show up) and single-record setups without a backup. With Google Workspace or Microsoft 365, a single record is expected, so that last warning is informational.
- Run a full Domain Health Check to see MX next to SPF, DKIM, DMARC and blacklist status in one report.
- Finish with a real test: reply to one of your own emails from an outside account and confirm it arrives.
How MailerBit helps
MailerBit is built for recurring emails where every recipient gets their own data — payment reminders, client statements, fee notices. Those are exactly the emails people reply to.
- Free DNS tools, no account required. The MX checker and the domain health check are public. In the overall health score, MX counts for 15%, alongside SPF, DKIM, DMARC and blacklist checks.
- Your own domain in the From field. You verify your domain before sending a campaign. MailerBit generates the DKIM and Return-Path records to paste into your DNS and checks the setup for you. Recipients see your name and domain, so replies go to your domain — which is exactly why your MX records have to work.
- Bounces handled separately from your inbox. A custom Return-Path routes bounces through a subdomain of your own domain, not through your mailbox. If your bounce rate goes above 5% or your complaint rate above 0.1%, sending is paused automatically to protect the reputation of your own domain.
Check your MX records today. When your domain is ready to send and receive, start your free MailerBit trial and set up your first recurring reminder with every client's own amount and due date.













