Checking MX records before switching email providers is how you avoid a week of mail that “sometimes works.” MX names the host that answers for the domain. Two providers in that set is not a backup. It is a coin flip. You look up the set in public, save the old values, publish one new set, delete leftovers, look up again, then prove inbound from a mailbox you do not own.
Quick answer for check mx records
IETF RFC 5321 — Simple Mail Transfer Protocol says sending servers look up mail exchangers for the domain and deliver there, following preference numbers. Lower preference is tried first. That is not load-balancing for a small business that left Google MX next to a new forwarder. Some networks will still hit the old host. The new dashboard will look fine. The customer will say they sent mail. Both can be true.
Check means a lookup from a resolver that is not your office Wi-Fi cache. Write every host and preference. Compare that list to what you intend to publish. After the switch, the list must match the new provider only. Registrar “email forwarding” hosts count as leftovers. So do aspmx.l.google.com style names and Microsoft exchangers you forgot to delete.
You do not change Gmail’s MX. You change the brand domain. Destinations stay inboxes you already use. MailerZ is not IMAP. See troubleshooting, tools, and migration planner for the surrounding cut, and docs for record shapes the dashboard shows.
TTL matters. A four-hour TTL means some resolvers will keep the old answer after you delete it. Do not print a new support@ in the same hour you cut if you have not watched public lookups converge. Checking MX is a loop, not a single screenshot.
User problem and decision criteria
Teams switch providers in the registrar UI, see “records saved,” and go to lunch. Their laptop still has the old MX. They send a test from Gmail to Gmail. It works because it never left Google. Monday, a vendor on another network still delivers to the leftover Microsoft host. The ticket says “your email is down.” The dashboard says connected. Nobody checked MX from the outside.
Decision criteria: can you name every current exchanger from a public lookup; can you screenshot them; do you have the registrar or DNS panel that is actually authoritative; will you delete leftovers the same day; will you look up twice from two resolvers; will you prove inbound from a third mailbox; is someone else allowed to republish Google MX “just in case.”
Criteria that do not belong: keeping old MX as a rollback without a written plan, trusting the new vendor’s “domain connected” badge as a public lookup, or changing personal Gmail MX. Rollback is republishing the screenshot you saved, not running two providers in parallel.
Agencies inherit domains where Cloudflare, Google, and a registrar each have an MX story. The authoritative nameserver set decides which panel wins. If you edit the registrar while NS points at Cloudflare, you did not change what the internet sees. Checking MX in public is how you discover that before the cut.
Subdomains are separate. app.example.com has its own MX if it receives mail. Checking the apex does not prove the subdomain. If the switch is only for the apex, say so. If support lives on a subdomain, look that name up too.
Priority values that look like “10 and 20 for the same provider” are normal. Priority values that name two companies are the problem. Write the company next to each host so a junior person can see the leftover.
Technical mail flow
The sending server queries DNS for MX. It sorts by preference and connects to the first host that answers. If that host accepts the message, the new provider never sees it. If the old host still has a mailbox or a catch-all, mail disappears into a store you no longer open. If the old host rejects, the sender may try the next MX—or bounce—depending on the response. That is why leftover hosts feel random.
After exclusive MX at MailerZ, the host matches local-parts to named aliases and holds unknown on Free. Envelope SRS on the forward hop. Headers intact. None of that runs if MX never delivered there.
Sending DNS (SPF, DKIM, DMARC) does not move inbound. People republish SPF because “email is broken” when the actual bug is leftover MX. Check MX first. Then sending records if you also send. Copy SMTP from the dashboard on paid plans. Free has no send-as.
Propagation is resolver caches honoring TTL, not a mystical 48-hour law. A 300-second TTL converges faster than a 86400-second TTL. Lower TTL a day before a planned cut if you can. Then check MX after the cut until two public views match.
Step-by-step setup / decision path
- Confirm which nameservers are authoritative. If NS is not the panel you are editing, stop.
- Look up MX on a public resolver. Screenshot hosts and preferences. Label each host’s company.
- Look up again on a second public resolver. If they disagree, wait and recheck. Do not cut on a split view.
- Create named aliases and verify TXT on the new provider before you publish MX. A cut with no aliases is a hole.
- Publish only the new MX set. Delete leftover hosts in the same change window. Do not leave Google MX at preference 10 “for safety.”
- Wait at least one old TTL if you can. Look up from both public resolvers. The leftover names must be gone.
- Send a unique message from a third mailbox to a named alias. Confirm hop history. Self-send is not this test.
- Save the old screenshot for rollback. Rollback is republish old exclusive set, not dual MX.
- Tell the team not to add Google MX back from a mobile registrar app.
If a contractor “helped” during the cut, check MX again the next morning. Leftovers return through kindness.
Parked domains you forgot still have MX. If they forward to the same Gmail, check those names too or you will debug the wrong domain.
Failure modes and proof
Laptop-only lookup: you see the new set, the world sees the old. Proof: two public resolvers.
Dual MX: random delivery. Proof: two company names in the set.
Wrong panel: you edited registrar DNS while NS is at Cloudflare. Proof: public MX unchanged.
Self-send: Gmail never asked MX. Proof: third mailbox.
Vendor “connected” badge: UI, not DNS. Proof: public lookup.
TTL surprise: some regions hours behind. Proof: repeated lookups, not one.
Subdomain ignored: app mail still on old host. Proof: MX on that name.
Rollback dual publish: you made split MX on purpose. Proof: the screenshot you were supposed to restore exclusively.
Changing Gmail MX: you cannot and should not. Proof: you edited the wrong domain.
Catch-all on new host plus leftover old host: two cannons. Proof: made-up local-part tests to both eras if both still answer.
MailerZ workflow and product boundary
MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. It is not Workspace, not IMAP, and not an open relay.
The dashboard shows the MX set to publish. Your job is exclusive publication and a public check. Envelope SRS inbound. Headers intact. Free holds unknown. Copy SMTP only on paid send-as. Do not invent ports.
Free: one domain, three aliases, fourteen-day store, fifty outgoing, no send-as. Solo: forty dollars a year, fifteen aliases, ninety-day store, one hundred outgoing, five send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote pricing live.
This page does not invent SOC 2, ISO, HIPAA, SLAs, or inboxing rates. Public DNS tools vary. The requirement is two independent views, not a brand of lookup site.
Cost, alternatives, and trade-offs
An hour of MX checks is cheaper than a week of “sometimes down.” Workspace seats do not fix leftover MX. A migration consultant who does not show public lookups is selling hope.
Lowering TTL a day early has no product cost. Dual MX as a safety net has a silent mail-loss cost. Choose the screenshot rollback.
Doing nothing leaves registrar MX you will forget. The next switch inherits it. Check now even if you are not switching this week.
Tools on this site help you see records. They do not replace the authoritative panel. Edit where NS points.
If two people own DNS, the cost is coordination. Put the lookup screenshot in the same ticket as the cut. Unowned DNS is how leftovers return.
Agencies should bill a “public MX proof” line so clients do not skip it. The proof is the product they actually need.
Mobile registrar apps love “restore Google email” buttons. After a successful cut, those buttons are an outage. Disable the app on the owner’s phone or write a one-line rule: no MX edits from a phone. Checking MX the next morning catches that class of help.
IPv6-only or unusual resolvers can still see old glue longer than your two favorite websites. If a single customer network is stuck, ask them what their resolver is, and compare. You are debugging DNS cache, not MailerZ policy, until public MX is exclusive and their cache expires.
CNAME at the apex is not an MX substitute. If someone “pointed the domain at the new host” with a CNAME, you have not moved mail. Check MX specifically. Website routing and mail routing are different records. Mixing them is how a successful site launch coincides with a silent inbound outage.
Two resolvers, one owner, then switch
Checking MX before you switch providers is a packet, not a vibe. Query two public resolvers that are not your laptop. Paste every hostname and priority. Circle leftovers: aspmx, Microsoft, registrar, old forwarder, null MX. Circle the intended owner. If two owners exist, you are not ready to switch. You are ready to delete. Switching while leftovers remain is leftover MX with a new logo.
NS must match the zone you will edit. If registrar preview shows MailerZ MX but public resolvers show Google, you are editing a diary. Fix delegation first. RFC 1035 before RFC 5321.
Screenshot the current exclusive set if it is already clean. That screenshot is rollback after a bad switch. If the current set is leftovers, write that down too. Rollback to leftovers is sometimes what you had, not what you want. Be honest on the card.
Recreate aliases on the new hop before you publish its MX. MailerZ Free: three names, HOLD unknowns. Empty history after a switch is often a name you never created, not a failed lookup. Create first. Cut second. Probe third.
The switch itself is exclusive new MX, leftovers deleted, two resolvers, stranger probe. Self-send is invalid. Gmail-to-Gmail can hide both old and new MX.
Priority is try-order inside one owner. Old vendor at 20 is not a check that passed. It is a leftover you failed to delete. Demoting is not deleting.
After public views agree, send a unique subject to each critical alias from another mailbox. Hop history empty: leftovers or no arrival. HOLD: unknown on Free. 250 then 5xx: destination. Copy SMTP. Do not switch back because Gmail filed a test in spam.
Send-as is a later check. Free cannot send. Do not require outbound 250 to pass the MX check. Unauthorized From is 550. Wrong object.
Registrar “email forwarding” MX that you forgot is the usual miss. Two resolvers catch it. The pretty UI badge does not.
Agencies: one domain’s MX packet per ticket. A spreadsheet of “all green” without pastes is how one client keeps aspmx.
What “MX looks fine” hides
Fine to the laptop, leftover to the world: office DNS or a hosts file. Use public resolvers.
Fine in Route 53, leftover in public: NS still at Cloudflare. You checked the wrong zone.
Fine priorities, two vendors: leftover. Delete the foreign host.
Fine plus null MX: contradictory. Remove the refuse if you receive.
Fine CNAME at apex: some providers drop MX. Check whether MX still exists after the CNAME fashion.
Fine IPv6-only view versus IPv4: still the same RRset if the zone is one. Disagreement is split view or a lie, not a vibe.
Keep the packet in the ticket through the keep window of the old vendor login. MX already exclusive. Login remains. Cancel after probes.
No inbox SLA because MX is exclusive. Placement is Gmail’s mood. We do not sell Primary. No SOC 2.
Start free — one domain — after the MX packet is exclusive and three aliases exist. The check is the precondition, not the product.
Monthly: two-resolver leftover lookup. The switch you did in January dies in March when someone restores Google. The check is a habit.
What two public resolvers must agree on before you switch
Checking MX before a switch is not a single dig on your laptop. Your laptop may use a resolver that still has the old set, or a corporate DNS that lies, or a browser extension that never queried MX at all. The check is two public resolvers, the same name, the same minute, pasted into the ticket. If they disagree, you do not switch yet. You wait remaining TTL or you find split horizon. Switching during disagreement is how you get a clean laptop and a dirty world.
Read every answer, not the first priority. Priority 10 MailerZ plus priority 20 aspmx is leftover MX. People screenshot the first line and call it exclusive. The second line is the failure. Null MX, a lone dot, is exclusive “we do not receive.” If you intend to receive, null MX is a fail. If you intend to refuse inbound, say that out loud before someone adds MailerZ MX beside the null and calls it a hybrid.
Hostnames matter more than priority folklore. Google’s aspmx family, Microsoft’s outlook family, a registrar’s mail.brand.com, ImprovMX, and MailerZ each have names you can learn. A CNAME at the apex is not MX. A URL in a registrar field is not MX. If the panel shows a website builder “connected,” query MX anyway. Panels lie. Resolvers, when they agree, are closer to what senders see.
NS is the parent of the MX check. If you edit the wrong nameservers, public resolvers will keep serving the old MX no matter how pretty your panel looks. Check NS at the registrar and at the same two resolvers. A migrated domain that still has the old DNS host as authority is why “I already changed MX” lasts a week. Fix NS first. Then MX. Then aliases. That order is in the cutover runbook for a reason.
TTL is a clock, not a vibe. If TTL is 86400, a sender who cached leftovers yesterday can still be wrong tomorrow after you publish exclusive MX. Lower TTL days before the switch if you can wait out the old value. Lowering TTL at the start of the window does not rewind the previous 86400. Write the old TTL in the ticket so nobody says “DNS is instant” at hour two.
After you publish, check again from the same two resolvers. Then probe. A green MX check with empty hop history is leftover at a third resolver, a name that never arrived, or a sender still cached. The MX check is necessary. It is not sufficient. Self-send is still not the probe. A stranger mailbox is the probe.
IPv6 and additional section noise confuse people who copy the whole dig output into Slack. Teach the team to read the ANSWER for MX and the hostnames. Glue A/AAAA is useful when you debug the hop. It is not a second MX owner. Do not delete MailerZ MX because you saw an A record for an old mail host. That A record might still serve a webmail you no longer use. MX is the switch. A is leftover furniture.
Registrar email upsells republish MX after a clean check. The day after you switch, query again. If aspmx is back, the phone app ran. The check is not only before. It is before, during, and the next morning. Put “next morning MX” on the card. Unowned morning checks are how leftovers live for a quarter.
Switching providers without a screenshot of the old exclusive set makes rollback a memory test. Save the two-resolver paste. If you must roll back, republish that set and delete the new MX. Do not run both. Dual MX during rollback is leftover MX with a sadder subject line.
MailerZ MX values come from the dashboard after the domain is added. Do not invent hostnames from a blog. Do not copy a neighbor’s zone. Verify TXT first so you are editing the domain you think you are editing. Free still needs exclusive MX to receive. Three aliases. HOLD for unknowns. The MX check does not create aliases. Empty HOLD after a probe to a missing name is a map problem, not an MX problem.
Facts stay thin: no inbox SLA, no SOC 2, envelope SRS after mail arrives, Header From intact. Start free, then publish the MX the dashboard shows. Sign in if the domain is already on the hop. The check is agreement plus exclusivity plus a stranger probe. Anything less is a vibe.
Commands and what “good” looks like in the paste
Use two public resolvers you do not own. Paste the MX answer set, not a screenshot of a panel. Good looks like one hostname family, the MailerZ hosts from the dashboard, no aspmx, no outlook, no registrar mail, no leftover forwarder. Bad looks like two families at any priority. Also bad: no MX when you intend to receive, or a null MX you did not choose. Write “good” or “bad” on the paste. Do not write “looks fine.”
Repeat the paste after publish and the next morning. The morning paste catches the phone-app republish. If morning is bad, the switch is not done. Delete leftovers again. Probe again. Do not add aliases as a consolation prize. Aliases do not fix a second owner. Start free, add the domain, then publish only the MX the dashboard shows. Sign in if that work already happened.
Teach one non-engineer to read the paste. Circle hostnames, not TTL trivia. If they can spot aspmx, you have a second checker when you are on a plane. That is the operational win. The command is a means. Agreement plus exclusivity is the result. Self-send remains off the card.
FAQ
- What is the safest way to handle check mx records?
- Look up MX from two public resolvers, not only your laptop cache. Screenshot the old set. Publish one new set and delete leftover Google, Microsoft, or registrar hosts the same day. Look up again. Prove inbound from a third mailbox. Do not dual-publish two providers as a safety net.
- Does this require a new mailbox?
- No. MX names the receiving host for the domain. Destinations can stay Gmail or Outlook. MailerZ is not IMAP. A new seat does not fix leftover MX.
- Will it work with Gmail or Outlook?
- Yes as destinations after the custom domain’s MX points at the alias service. You do not change Gmail or Outlook MX. You change the brand domain’s mail exchanger. Personal provider MX is a different name.
- What DNS records are involved?
- MX is the record you check before a switch. Also confirm verification TXT exists and leftover host MX is gone. SPF, DKIM, and DMARC matter if you send. They do not replace an MX lookup.
- What should I test before production?
- After the public lookup shows one set, send a uniquely titled message from an unrelated provider to a named alias. Confirm Header From and a hop row. Repeat the MX lookup from a second resolver. Self-send from Gmail to Gmail can hide a leftover host.
Key takeaways
- Check MX records from two public resolvers before and after a provider switch.
- One MX set. Leftover Google, Microsoft, or registrar hosts split mail.
- Save the old set for exclusive rollback. Do not dual-publish as safety.
- Edit the panel that matches authoritative NS.
- Do not change Gmail or Outlook MX. Change the brand domain.
- Prove inbound from a third mailbox. Self-send hides leftover hosts.
- TTL means you loop the lookup until public views agree.
- MailerZ receives only where MX actually points.
Conclusion
Look up, screenshot, publish one set, delete leftovers, look up again, prove inbound. That is the whole switch discipline. The new logo in a dashboard is not a lookup.
Verify the domain on MailerZ, publish the MX the dashboard shows, then check it in public before you tell customers the address moved.