MX record troubleshooting is a list, not a vibe. If inbound fails, you do not start in Gmail filters. You read nameservers, list public mail exchangers from two resolvers, delete leftovers and null MX, then prove the hop with a message that is not a self-send. Pretty panels lie. Resolvers do not. MailerZ can show history only for mail that actually arrived.
Quick answer for mx record troubleshooting
Work the order. Query NS. Edit that zone only. Copy the MX hosts from the MailerZ dashboard. Delete Google, Microsoft, registrar, old cPanel, and leftover Cloudflare routing MX. Delete a null MX if one exists. Query 1.1.1.1 and 8.8.8.8. If extras remain, you edited theater or TTL has not passed. Product path: troubleshooting and the tools hub. Do not debug aliases while ASPMX is still published.
MX selection is in IETF RFC 5321 — Simple Mail Transfer Protocol. Domain names themselves are in IETF RFC 1035 — Domain names. Cloudflare’s own exchangers are documented in Cloudflare Email Routing. Dual-publishing those next to MailerZ is leftover MX with extra branding. One inbound owner.
If public MX is already exclusive and history is empty, leave this checklist and open DNS looks correct but email still fails. The remaining causes are alias, HOLD, destination filter, or a sender that never offered the envelope. If leftovers remain, stay here. Paying does not merge two MX owners.
MailerZ Free can prove inbound on one domain once MX is exclusive. Solo is $40 per year when you also need send-as. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm MailerZ pricing. No plan heals a split set or a null MX you forgot to delete.
The user problem and the decision criteria
The ticket says “MX looks fine.” The evidence is a registrar screenshot. A customer invoice never arrived. A Gmail Send mail as confirmation vanished. Your self-send worked. That pattern is MX until proven otherwise. The checklist exists so two operators run the same order and stop arguing about spam folders while a second host is still live.
| Question | If yes | If no |
|---|---|---|
| Does any public resolver list a non-MailerZ MX? | Delete it. Hard stop. | MX may be exclusive. Probe next. |
| Is MX a lone dot (null MX)? | Senders must refuse mail. Remove it. | Continue the host list. |
| Are you editing a panel that NS does not name? | Theater. Open the live zone. | The panel matches NS. Continue. |
| Did you keep old MX as backup? | That is leftover MX. Remove it. | Good. Still verify from two resolvers. |
| Self-send worked? | Prove nothing. Use another mailbox. | Good. Still read public MX. |
Registrar included email is the quiet failure. A parking MX or mail.domain.com row survives after you added MailerZ. Saving the website DNS later can republish it. The checklist includes a re-query after every registrar save, not just after the first MX edit.
Google Workspace leftovers are the loud failure. ASPMX.L.GOOGLE.COM and friends stay published because someone feared cutover. Those hosts still accept mail if the Workspace account exists, or bounce if it does not. Either way MailerZ never saw the envelope. Microsoft leftovers look like mail.protection.outlook.com. Same physics.
Technical mail flow
The sending server resolves MX for the recipient name, sorts by preference, connects, and offers the envelope recipient. If the first willing host is not MailerZ, alias policy never runs. Envelope SRS and Header From preservation do not apply to a hop you did not receive. IETF RFC 5321 — Simple Mail Transfer Protocol does not require the sender to try every MX when the first accepted the message.
Preference numbers look like a backup plan. They are not. A leftover host at priority 100 still receives mail when the preferred host is down, when a sender ignores preference, or when equal priorities let the sender pick either. Delete the name. Do not demote it.
TTL delays what resolvers cache. After you delete a row, some senders still use the old set until their cache expires. That is not a reason to keep the old row. It is a reason to wait out the previous TTL, then re-query two resolvers, then probe again. Corporate resolvers can cache longer than the published TTL. Split tests by network.
A and AAAA on the MX hostname are a different failure from leftover names. If the public set is only MailerZ but one hostname does not resolve, senders fail to connect. List names first. Then resolve each name. Do not mix “extra host” and “dead host” in one sentence on the ticket.
Null MX is MX 0 pointing at “.”. It is a published refusal. Empty history is expected. The checklist treats it as a hard stop before you invent alias bugs. See the dedicated null MX article if that is the only row you have.
SPF, DKIM, and DMARC do not file MX. IETF RFC 7208 — Sender Policy Framework (SPF) and IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) evaluate authorization after a hop exists. A perfect DMARC policy on a split MX still loses the half that never arrived. Authentication is step eight. Host list is step one.
Gmail Send mail as sends a confirmation to the alias. If leftover Google MX answers that confirmation, Gmail may accept a path that never proved MailerZ inbound, or the confirmation dies on the old host. Delete leftovers before you paste SMTP. Free still cannot send-as after you clean MX.
Self-send from Gmail to the same Gmail account can skip public MX. Thunderbird Send Later does not change physics. Budget an external mailbox every time MX is in question. The docs assume that probe. So does this checklist.
Step-by-step MX checklist
Read NS, then open that zone
If NS is Cloudflare, Route 53, or the registrar, edit there. Do not publish MX in a panel that does not answer. After a transfer, the pretty old host is usually dead.
Copy the MailerZ MX set exactly
Hosts and preferences from the dashboard. Do not invent a backup row. Do not keep ASPMX at 20. Do not CNAME the receiving name to a website.
Delete leftovers and null MX
Google, Microsoft, registrar, old cPanel, old Cloudflare routing MX, and a lone-dot null MX. One owner. No published refusal.
Resolve each remaining MX hostname
A or AAAA must exist. A name that does not resolve is a dead exchanger, not a leftover. Fix the host or the dashboard copy-paste.
Query two public resolvers
List every MX. If extras remain, you edited the wrong zone or TTL has not passed. Wait, re-query. Do not add leftovers back.
Probe from another mailbox
Unique subject. Header From intact. Delivery history present. If history is empty and MX is exclusive, leave this list for alias and HOLD.
Re-query after the next registrar save
Website DNS, parking pages, and “email included” toggles republish MX. The checklist is not done until a later save still shows one owner.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| Some senders hit the old host | Leftover MX or stale TTL | Two resolvers still list extras, or one does |
| All senders bounce immediately | Null MX or no MX plus a refusing host | MX is “.” or the set is empty |
| Panel is clean, public is dirty | Wrong zone or NS mismatch | NS names a different product than the tab |
| History empty, MX exclusive | Alias, HOLD, or sender never offered | Leave MX. Open the next article |
| MX names do not resolve | Typo or missing A/AAAA | Host lookup fails on both resolvers |
| Site deploy republished mail | Registrar email or parking MX | MX changed after a website save |
Proof is a resolver listing plus a history row, not a feeling. If you cannot paste the MX names from two public resolvers, you have not finished the checklist. If you can paste them and they still include ASPMX, you have not deleted leftovers. If they are exclusive and history is empty, stop blaming MX.
Agencies run this per zone. Client A can be exclusive while Client B still has outlook.com. Dashboard green on the wrong domain is how “we already checked MX” spreads across a book of business.
MailerZ workflow and product boundary
MailerZ is inbound MX plus authenticated SMTP. It is not a mailbox, not IMAP, not Workspace, not an open relay. History shows hops MailerZ accepted or refused. It cannot show mail that a leftover host accepted. HOLD stores unknown local-parts on Free. It does not store mail that never arrived.
Envelope SRS rewrites MAIL FROM on the forward. Header From stays the original sender. That split matters after the hop exists. It does not rescue a message that went to Google MX. Do not ask support to invent a log for an envelope they never received.
Free is one domain, ten aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo is $40 per year: 5 domains, 25 aliases, 90-day store, 2,500 outgoing, 20 send-as per hour, unknowns forwarded. Confirm pricing before you quote a client. Limits are not an inbox-placement SLA.
The checklist does not change at Agency. One hundred domains still need exclusive MX each. A shared screenshot of one clean zone does not certify the other ninety-nine. Features describe routing. They do not merge leftover hosts.
Unhosted or unauthorized SMTP is 550 / 550 5.7.1. That is outbound. Do not mix it into an inbound MX ticket. If send-as fails after MX is exclusive, you are on a different checklist: paid plan, verified sender, matching identity.
Cost, alternatives, and trade-offs
| Choice | What you get | What you give up |
|---|---|---|
| Two-resolver MX plus history | A real split between leftover, dead host, and filter | The comfort of a pretty panel |
| Keep old MX as backup | A quiet second inbox | A complete Gmail archive |
| Buy a suite mailbox to “fix MX” | A new store. Quote live | The Gmail archive you already have |
| Self-send only | A fast green checkbox | Truth about public MX |
Time is a line item. One external probe costs less than another day of MX looks fine. Leftover MX costs more than Solo. A Free-plan send-as argument costs more than the upgrade. Registrar included email looks free until it republishes leftover MX on save.
If every teammate needs a hosted mailbox, a suite is the honest product. A forwarder will look incomplete because it is incomplete for stored humans. Pretty MailerZ DNS will not become IMAP. Quote vendors the day you debug. Gmail spam UI changes. The MX order does not.
Open a held body for break-glass recovery and expect an audit row. That is a control, not a SOC 2 badge. Do not send zone or SMTP passwords to support. The artifacts that close an mx record troubleshooting ticket are two resolver listings, a history row, and either an inbox hit, a HOLD body, or a far-side SMTP error.
Apex, subdomain, and CNAME collisions
The name that receives mail is the name you must troubleshoot. Cleaning example.com does not clean shop.example.com. If invoices print billing@pay.example.com, that name needs its own exclusive MX. Operators waste hours on the apex while the printed name still points at the old host.
A CNAME at the receiving name usually cannot sit next to MX. People point the domain at a website with a CNAME and delete MX by accident, or they leave old MX on a name that no longer exists. After a CDN cutover, re-read MX. Leftover MX is not only old email hosts. It is collateral damage from a site deploy.
WWW versus apex is a web problem that leaks into mail when someone copies the wrong hostname into a form. The checklist asks: which name did the sender actually use? Query that name. Do not query the name on your business card if the form posts to a subdomain.
IPv6-only or odd resolver paths still read the same MX set. It works on my phone is one resolver. Query two public resolvers, not two tabs on the same office DNS. Split horizon can show you a clean internal MX while the world still sees ASPMX.
Multiple domains on one MailerZ account each have their own leftover story. Cleaning example.com does not clean example.net. Agencies: one checklist row per zone, with the NS product named on the ticket.
Null MX, empty sets, and republish traps
Null MX is an explicit “do not send mail here.” It is useful for domains that must not receive. It is fatal for a domain you just moved to MailerZ. If you see MX 0 “.”, delete it before you create aliases. Empty history is the correct outcome of a published refusal.
An empty MX set is different. Some senders fall back to the A record and try the website host as if it were a mail server. That host is not MailerZ. History stays empty. Publish the dashboard MX set. Do not rely on A-record fallback. It is legacy behavior, not a product.
Registrar email toggles and parking products republish MX when you save A records for the website. The last step of the checklist is a second public query after the next unrelated DNS edit. If leftovers return, turn the registrar email product off, not just the row.
Cloudflare routing MX leftover is common when you leave their routing product half-disabled. Their docs describe their exchangers. Quote them live. If those names remain beside MailerZ, you have two inbound products. Pick one. Dual publish is not a migration. It is a coin flip.
After exclusive MX, if mail still fails, you are no longer on this checklist. Alias missing, HOLD on an unknown local-part, destination filter after 250, or a sender that never offered the envelope live in the next article. Do not keep deleting and re-adding MailerZ MX hoping Gmail will change its mind.
Helpdesks that ingest the alias are destinations. If the helpdesk rejects the hop, history will show it. That is not leftover MX. Remap or fix the helpdesk inbound address. Two-factor on the destination Gmail is still required. A clean MX ticket that ends in a compromised destination is a different incident.
Priority is not failover insurance
Operators keep the old host at a higher preference number because a runbook from 2014 said that was how you built redundancy. That runbook assumed both hosts were the same product with the same mailbox. MailerZ and Google Workspace are not the same product. Mail that lands at the backup never appears in MailerZ history and never reaches the Gmail destination you mapped. The backup is a second company.
Equal priority is worse. Senders may pick either host. Your Tuesday probe hits MailerZ. A bank’s mailer hits leftover Microsoft. You conclude the setup works. The bank concludes you are unreachable. The checklist treats any non-MailerZ name at any preference as a fail. There is no “only if MailerZ is down” row that is safe for a forwarder cutover.
If MailerZ is actually unreachable, senders should queue and retry that host, not silently succeed at an old Workspace account you no longer read. Retry is a feature of SMTP. Dual owners are not. Design for the failure you want: delayed mail you can recover, not accepted mail in a mailbox nobody opens.
Some enterprise outbound gateways cache MX longer than your TTL and will keep hitting the old host after you delete it. That is drain, not a reason to keep the row. Keep the old mailbox readable for one TTL window plus a day if you must, with the MX row already gone. Then close it. Leaving MX published “until we are sure” is how leftover MX survives a quarter.
Mobile carriers add another cache. A VIP on a phone network can fail after your office resolvers are clean. Ask that sender which MX their logs show. If they still list the old host, their resolver or their smart host is the remaining cache. You cannot flush a sender you do not operate. Exclusive MX plus time is the lever you own.
IPv4 versus IPv6 on the MX hostname is still not leftover MX. If both resolvers list only MailerZ names and one address family fails to connect, that is a host reachability problem. File it as such. Do not delete and republish the whole set unless the names themselves are wrong.
What to paste on the ticket
A useful MX ticket is short. Paste NS from a public resolver. Paste MX from two public resolvers. Name the panel you edited. Name the UTC time of the last change and the previous TTL if you know it. Paste the probe message-id and the history row, or write “history empty.” Do not paste zone passwords. Do not paste a full customer invoice.
If those five facts are missing, the ticket will bounce back as a request for the same screenshots. “MX looks fine” is not a fact. The listing is the fact. If you cannot produce two listings, you have not run the checklist. If the listings disagree, you have a TTL or split-horizon problem, not a Gmail problem.
Include the exact recipient name the sender used. Apex versus subdomain mistakes waste a day. Include whether the probe was a self-send. If it was, say so and run a real probe before you escalate. Support cannot disprove a self-send that never left Google.
After exclusive MX, do not keep reopening the MX ticket. The next owner is alias state, HOLD, destination policy, or the sender. Send the operator the DNS-looks-correct article and close the MX row. Mixing both jobs in one thread is how leftover MX gets republished “just to try something.”
Paid plans do not change the paste list. Solo, Starter, Business, and Agency still need exclusive MX and a named alias. The upgrade changes send-as and limits. It does not make a leftover outlook.com host disappear. Do not buy a plan to fix an MX listing.
Legal hold is not the 14-day Free store. If counsel needs years, Gmail Vault or Microsoft retention is the archive. Do not treat HOLD as compliance because inbound failed last Tuesday. Two-factor on the destination Gmail is still required after the MX set is clean.
If you want a second operator to repeat the same order without a call, send this page plus the leftover-MX article. This page is the list. That page is the story of why two owners steal mail. Together they cover the two most common inbound DNS failures before anyone opens a spam folder.
Google’s people-first guidance is about pages, not SMTP; see creating helpful, reliable, people-first content. An MX checklist that only says wait for TTL without listing hosts is how the old provider keeps a quiet copy of invoices. Name the hosts. Then wait. Then name them again.
FAQ
What is the safest way to handle mx record troubleshooting?
Read NS, open that zone, copy the MailerZ MX set, delete leftovers and null MX, then query two public resolvers. Only after the set is exclusive do you probe from another mailbox and read history. A registrar screenshot is not a resolver.
Does this require a new mailbox?
No. MX troubleshooting is DNS and hop proof. Gmail or Outlook can stay the store. MailerZ is not IMAP. Buy hosting only if you need folders on the domain instead of Gmail.
Will it work with Gmail or Outlook?
Inbound reaches those destinations only for senders who hit exclusive MailerZ MX and a mapped alias. Leftover Google or Microsoft MX still steals a subset. Self-send from Gmail to the same Gmail account can hide a split. Free has no send-as.
What DNS records are involved?
NS tells you which panel is live. MX must be exclusive on the name that actually receives. A and AAAA on the MX hostnames must resolve. Verification TXT is for ownership, not delivery. SPF, DKIM, and DMARC matter when you send, not when MX never answers.
What should I test before production?
Two-resolver MX listing with only MailerZ hosts, no null MX, no CNAME at the receiving name, a uniquely titled probe from another provider, Header From intact, and history present. Then drain the old host. Do not keep it as backup MX.
Key takeaways
- MX record troubleshooting: NS, exclusive set, two resolvers, then an external probe.
- Leftovers and null MX are hard stops. Demoting old hosts is not deletion.
- A registrar screenshot is not a resolver. Query 1.1.1.1 and 8.8.8.8.
- Dead MX hostnames (no A/AAAA) are a different failure from extra hostnames.
- Self-send lies. Probe from another provider. Match history.
- After exclusive MX, stop this list. Check alias, HOLD, and destination.
- Free receives. Solo $40/yr starts send-as. Confirm /pricing.
- Envelope SRS only. Header From untouched. Not an inbox SLA. Not IMAP.
Conclusion and next action
If MX is the suspect, run the list. Read NS. Publish only the dashboard set. Delete leftovers and null MX. Query two resolvers. Probe from somewhere else. Re-query after the next registrar save. MailerZ can show the hop. It cannot invent an exchanger you left live or a log for mail that went to Google. Start free on one domain and run the order.
Ready to prove the hop
Start free with one domain and an exclusive MX set.
Inbound on Free. Solo when send-as is the job. Sign in if the domain is already there.
Review quarterly, or sooner if registrar email products or MailerZ MX hostnames change. Author: MailerZ editorial, Secuno LLC.