MX Records Explained: Why Replies to Your Emails Never Arrive

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.

The one rule to remember: MX records are about mail coming to your domain (receiving). SPF, DKIM and DMARC are about mail going out from your domain (sending and authentication). They are separate systems and one does not fix the other.

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 is accounting@. 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

Free tool: Paste your domain into the MX Record Checker to see every MX record with its priority, a score out of 100 and warnings — no signup needed.
  1. Enter your bare domain (no www, no https://) in the MX checker.
  2. Compare the hostnames with what your mailbox provider tells you to use, and make sure nothing is left over from a previous provider.
  3. Check the priorities: your main server should have the lowest number.
  4. 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.
  5. Run a full Domain Health Check to see MX next to SPF, DKIM, DMARC and blacklist status in one report.
  6. 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.

Related articles

Client Contact Hygiene: Keep Payment Reminders Out of Spam

Client Contact Hygiene: Keep Payment Reminders Out of Spam

Outdated addresses and typos quietly push your payment reminders toward spam and leave clients uninformed. How to keep your client contact data clean, step by step, every month.

Email Deliverability in 2026: Keep Client Emails Out of Spam

Email Deliverability in 2026: Keep Client Emails Out of Spam

A payment reminder in the spam folder is a payment that arrives late. A practical guide to authentication, warm-up and clean client data, so your notices reach the inbox.

New in MailerBit: Clients and Payment Tracking

New in MailerBit: Clients and Payment Tracking

Sending the invoice is the easy part. Client cards with a full history, payments tied to the emails you send, a clear list of who owes what and optional automatic reminders that stop once a client pays.

All articles →