MX record propagation is cache expiry, not a global switch. Senders use whatever MX their resolver still holds. If the old TTL was an hour, plan an hour. If it was a day, plan a day. Two public resolvers that disagree are still in the window. Two resolvers that still show Google next to MailerZ are leftover MX, not propagation. Do not toggle records while you wait.
Quick answer for mx record propagation
There is no universal “24 to 48 hours” that you owe the internet. IETF RFC 1035 — Domain names lets each record carry a TTL. Resolvers may cache the old MX until that timer ends. Some caches honor it. Some refresh earlier. None of them care that your registrar painted a green check. Read the TTL that existed before you published the new set. That number is the honest wait.
IETF RFC 5321 — Simple Mail Transfer Protocol then delivers to whatever MX the sending host’s lookup returns. During the window, one customer’s provider can still hit the old exchanger while another hits MailerZ. That split is expected until caches agree. It is not expected after both public views still list ASPMX or a registrar host. That is leftover MX. Delete it. See leftover MX.
Lower TTL a day before the cut if the old zone lets you. If you cannot, you inherit the old timer. Do not invent a second MX “until propagation finishes.” Dual MX extends the split forever. The no-loss order lives on change MX without losing email. This page is only the clock.
MailerZ Free is one domain, three aliases, 14-day store, one seat, send-as disabled, SMTP and API disabled. Paid adds domains, 90-day store, optional catch-all forward, and send-as. Solo is $40 per year. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm pricing. None of those cards expire DNS caches.
Query tools: MX lookup and leftover MX. Compare two public resolvers. Your laptop cache is not one of them.
The user problem and the decision criteria
Founders refresh the registrar, see “updated,” send themselves a test from Gmail, and declare the cut failed when the message is slow or missing. They publish the old MX again. Now two caches and two operators exist. The next day “sometimes works” becomes the product. The real question was never “is MailerZ down.” It was “what does this resolver still believe.”
Support hears both stories in one hour because two resolvers are still in different minutes of the TTL. The decision is wait versus fix leftovers versus fix aliases. Mixing those three into one toggle is how MX record propagation becomes a week-long outage.
| What you see | Likely cause | Action |
|---|---|---|
| Two public resolvers disagree on MX hostnames | Cache window | Wait. Do not toggle. |
| Both still show Google or the registrar plus MailerZ | Leftover MX | Delete the old names. Not a wait. |
| Both show exclusive MailerZ, one alias missing | No named route | Create the alias. Free holds unknown. |
| Public NS does not match the panel you edited | Wrong DNS host | Edit the authoritative zone. Clock has not started. |
| Self-send works, customers fail | Gmail short-circuit or leftover Google | Probe from a third mailbox. |
| You changed MX five times today | Oscillating caches | Stop. Publish once. Wait one old TTL. |
Agencies put the old TTL in the cut ticket. “It should be instant” is not a ticket field. “Old TTL 3600, published 14:02 UTC, check resolvers at 15:10” is. Customers can wait an hour if you told them the window. They cannot wait a week of toggles.
Phone networks and hotel resolvers can be stickier than Google Public DNS. That is annoying. It is still not a reason to republish Workspace MX. Tell the one stuck person to wait or to send from another network. Do not change production for one laptop.
Technical mail flow during the cache window
Authoritative nameservers answer the current MX set. Recursive resolvers cache that answer for up to the TTL. A sending MTA asks its resolver, not your dashboard. If the resolver has the old set, the message goes to the old host. If it has the new set, the message goes to MailerZ. Both can be true at once. That is mx record propagation as it actually works.
MailerZ then accepts a named alias, stores required content, returns 250, and forwards to Gmail or Outlook. Envelope SRS only. Header From stays the original sender. See email forwarding. None of that runs if the sender still connected to Google. There will be no MailerZ hop row for that message. Looking for recovery in MailerZ during leftover or cache-to-old-host delivery is empty by design.
Negative caches exist too. If you published nothing useful, a resolver may remember NXDOMAIN or a failed lookup for a short time. Rapid delete-and-recreate is how you earn that. Publish the dashboard set once. Leave it.
TTL on the new record does not rewind the old cache. Lowering TTL after you already published the new hosts helps the next change, not this one. The wait is the TTL that was attached to the set you replaced.
MX preference is not a propagation control. A leftover host with preference 20 still receives mail when the preference 10 host is unreachable, and some senders still try it. Delete leftovers. Do not “priority them away” and call it a cache trick. See MX priority explained.
Inbound MX caches have nothing to do with outbound SMTP. Send-as does not start when TTL ends. Free still has no send-as after a perfect wait. Attach paid SMTP later. Do not debug 535 AUTH during an MX window.
What to measure so the wait has an end
Write four numbers in the runbook before anyone asks “is it done.”
Old TTL in seconds
From a public lookup before the edit. If you forgot, assume the worse common value you remember seeing on that zone, then still query instead of guessing forever.
Publish timestamp in UTC
When the authoritative panel showed the new exclusive set, leftovers deleted. Not when you opened the tab.
Two resolver answers
Hostnames and preferences from 8.8.8.8 and 1.1.1.1. Screenshot both. Repeat on a timer. Do not use only the DNS host’s preview.
First third-mailbox probe after they agree
Unique subject. Named alias. Confirm Header From and a hop. That closes the clock. Self-send does not.
If you lowered TTL a day earlier, the old TTL you care about is that lowered value, but only if it actually published and caches had a day to learn it. Lowering TTL an hour before the cut does almost nothing. The previous high TTL is still in the wild.
Corporate resolvers can ignore TTL or pin records. A single office that “never updates” is not the internet. Prove public views first. Then tell that office their resolver is sticky. Do not republish Google MX for one firewall.
Step-by-step: wait for MX record propagation without making it worse
Before cut day, read TTL and NS
Confirm you will edit the authoritative host. Screenshot exclusive old MX and TTL. Create named aliases. Verification TXT already matches. See DNS cutover runbook.
On cut day, publish exclusive MailerZ MX and delete leftovers
Copy dashboard hosts. Remove Google, Microsoft, registrar, host, and null MX in the same hour. Demoting preference is not deletion.
Start the clock from the old TTL
Write UTC now plus TTL. Query two public resolvers on that schedule. If they disagree, wait. If they both show leftovers, you are not waiting. You are deleting.
Do not toggle
No “put Google back for an hour.” No alternating hosts. Oscillation creates two truths and a longer outage than the original TTL.
When public views agree, probe inbound
Third mailbox. Unique subject. Each named alias. If that fails, you have a route or destination problem. The wait is over. See MX troubleshooting.
Announce after the probe, not after the banner
Customers can send once you proved a hop. Announcing at minute zero guarantees tickets from slow resolvers.
If both resolvers show exclusive MailerZ and the probe still fails, stop talking about propagation. Check the alias, the destination, hold versus forward, and whether the message never left the sender. Troubleshooting is the next surface.
Weekend waits are still waits. A 86400 TTL on Friday afternoon means Monday morning may still be the honest “done” if you did not lower TTL earlier. Say that in the customer email before the cut.
Failure modes people call propagation
Leftover MX forever. Proof: both resolvers still list a second company. Fix: delete. Time will not remove a record you still publish.
Wrong panel. Proof: public NS is Cloudflare, you edited GoDaddy. Fix: open the real zone. Your clock never started. See authoritative nameservers versus registrar DNS.
Missing alias. Proof: exclusive MX, hello@ works, billing@ held or bounced. Fix: create the name. Do not wait another day.
Self-send. Proof: Gmail to Gmail looks fine or fails in a way customers do not see. Fix: another provider. See self-send tests.
Toggle storm. Proof: MX history in the panel shows five edits. Fix: one exclusive set. Sit on your hands for one old TTL.
Registrar upsell. Proof: a phone agent republished “free email” MX during the wait. Fix: delete again. Lock who can edit.
Sticky office resolver. Proof: public views are exclusive MailerZ, one LAN is not. Fix: that network’s DNS, not your zone. Do not dual-publish for them.
Null MX leftover. Proof: a null exchanger still published. Fix: delete it when you publish MailerZ. Waiting will not override a published refusal.
Confusing SPF with MX. Proof: someone is waiting for SPF “to propagate” so inbound starts. SPF does not route inbound. MX does. Publish sending records when you send. Do not block the inbound clock on them.
Expecting MailerZ recovery for mail the old host accepted. Proof: no hop row, customer has a sent item. Fix: that copy lives on the old host if it still exists. Exclusive MX prevents the next one. The store is 14 days on Free and 90 on paid for hops MailerZ actually took.
MailerZ workflow and the product boundary
MailerZ shows the MX you should publish. It does not flush Google Public DNS. It does not promise an inboxing minute. It is not Workspace, not IMAP, not webmail, not an open relay, not SOC 2. Controls: security. Docs: docs.
After the wait, inbound is named aliases into Gmail or Outlook. Unknown is held on Free. Paid may forward unknown after you choose that path. Seats operate the dashboard. They do not speed caches.
Failed hops you can recover are hops MailerZ accepted. Cache-to-old-host mail never arrives to recover. That is why leftover deletion and a single publish matter more than a longer store.
Compare routing-only products if you are leaving them. Cloudflare Email Routing is inbound without MailerZ leftover stop or paid send-as: compare Cloudflare Email Routing. ImprovMX is the closest competitor class: ImprovMX migration. Their TTLs are still their old zone’s TTLs, not a brand promise.
Header From stays the original sender on forwards. Envelope SRS only. Propagation does not rewrite From. A competitor that rewrites From creates a DMARC problem that looks like “slow DNS.” It is not. Keep those tickets apart.
Cost of waiting versus the cost of toggling
The wait is free. The toggle is expensive. An hour of quiet is cheaper than a week of dual MX. MailerZ Free can receive during and after the window if aliases exist. Solo at $40 per year adds aliases, 90-day store, and send-as when you need them. Starter, Business, and Agency scale domains and send ceilings. Annual paid cards except Solo include two months free versus monthly. Confirm pricing.
Do not buy Agency to “propagate faster.” Domain count is not a resolver. Do not buy Workspace to skip TTL unless you actually want a suite. Google Workspace — product overview is Calendar, Drive, and hosted mailboxes. It still has DNS if you move MX there later.
Staff time is the line item. One person owns the clock. Slack “is it done” every ten minutes is how toggles start. Put the UTC check time in the channel and mute the rest.
If a customer cannot wait the old TTL, say so before the cut. Lower TTL a day earlier next time. Do not dual-publish as a courtesy. Courtesy leftovers lose mail for everyone else.
Tools on tools are enough to compare resolvers. You do not need a paid DNS monitor for one domain cut. You need two lookups and a note.
A founder who pays for “premium DNS” still waits on TTL. Faster nameservers answer faster. They do not erase caches that already hold the old MX. Buying Anycast is not a substitute for reading the old timer. If a vendor sold you 60-second TTL after the cut, that helps the next edit. This edit still inherits whatever the world cached yesterday.
Laptop ipconfig /flushdns or macOS cache flush only clears that laptop. Customers do not flush for you. Google Public DNS and Cloudflare 1.1.1.1 are the views you publish in the ticket. Flushing your own machine and calling the internet done is how leftover Google survives until the first invoice.
IPv6-only resolvers and IPv4-only senders can theoretically see different glue if someone broke nameserver records during the same window. That is rare and it is still not a reason to dual-publish MX. Fix NS if NS is broken. Keep MX exclusive. Do not merge a nameserver outage into an MX propagation story without a lookup that shows the NS problem.
MailerZ hop history is timestamped. If a probe after agreement has a hop and a probe during disagreement does not, you have a clean picture. If neither probe has a hop and leftovers are gone, the sender never reached you. Ask for the customer’s bounce or a screenshot from a different network. Waiting another TTL will not create a hop that was never attempted.
Related reading: DNS looks correct but email still fails and check MX before switching. Those pages assume you already know whether you are in a cache window. This page is how you know the window ended.
Write the customer sentence before the cut: “Inbound may split for up to N minutes while DNS caches expire. We will not run two mail hosts. After public lookups agree, we will send you a unique test.” That sentence prevents the leftover-MX courtesy request. Courtesy leftovers are how mx record propagation never ends.
Hourly send-as limits and Paid outgoing ceilings are outbound numbers. They do not describe inbound cache. A founder who “waits for the quota to reset” during an MX cut is in the wrong queue. Inbound has no MailerZ monthly cap that you wait out. You wait TTL or you delete leftovers. Mixing billing with DNS is how the ticket lasts until the card renews.
Solo at $40 per year does not buy a shorter TTL. Starter at $8 or $80 does not either. The dashboard MX hostnames are the same class of object on every paid card. What changes is alias count, store length, catch-all forward, and send-as. Treat the wait as operational, not commercial.
If you run many client domains, do not cut three zones in the same hour unless three humans can watch three resolver pairs. Agency at $39 or $390 is a domain ceiling, not a batch-propagation engine. One exclusive publish per zone, one clock per zone, one probe per named alias. Parallel cuts without notes become a toggle storm with extra brands.
Catch-all hold on Free does not wait for TTL. Unknown local-parts are held as soon as MailerZ is the hop that accepted them. If customers still reach the old host, those unknowns never enter hold. People call that “propagation delayed catch-all.” It is leftover MX. Delete the old names, then look at hold.
Send-as after the window still needs Solo or higher, the dashboard pair, and a named From. A 535 during the TTL wait usually means someone attached SMTP too early on Free, or pasted the Gmail password. That ticket is SMTP authentication failed, not mx record propagation.
FAQ
How long do MX record changes take to propagate?
As long as the old TTL, plus whatever caches still hold it. Many zones sit at 3600 seconds. Some sit at 86400. Registrar “instant” banners are not proof. Query two public resolvers. When they agree on exclusive new MX, wait is over. Leftover old hosts are not propagation.
Does this require a new mailbox?
No. Propagation is DNS cache. Destinations stay Gmail or Outlook. MailerZ is not IMAP. Buying a seat does not expire a resolver cache.
Will it work with Gmail or Outlook?
Yes as destinations after public MX is exclusive MailerZ. Gmail as a sender may still use a cached MX. That is why you probe from a mailbox you do not own and why self-send can lie during the window.
What DNS records are involved?
MX and its TTL. You also need the authoritative NS so you edited the real panel. Verification TXT should already match. SPF does not control inbound MX caches.
What should I test before production?
Read the old TTL before you publish. After publish, compare 8.8.8.8 and 1.1.1.1. When they match and leftovers are gone, send a unique inbound probe. Do not toggle MX every ten minutes.
Key takeaways
- MX record propagation is old TTL cache, not a 48-hour law.
- Read TTL before you publish the new set.
- Registrar banners are not proof.
- Two public resolvers must agree on exclusive MX.
- Leftover hosts are not a wait. Delete them.
- Do not toggle MX during the window.
- Dual MX extends the split forever.
- Probe from a third mailbox after views agree.
- Self-send can lie while caches differ.
- Wrong NS means the clock never started.
- Missing aliases are not propagation.
- Free still has no send-as after the wait.
- MailerZ does not flush public DNS caches.
- Flushing your laptop DNS does not flush customer resolvers.
- Paid plans do not buy a shorter TTL. The old record’s timer still rules.
Conclusion and next action
MX record propagation ends when public resolvers agree on one exclusive set and a third mailbox proves inbound. It does not end when a panel says updated. Leftovers and missing aliases are not the clock.
Next action: screenshot old TTL, publish exclusive MailerZ MX, delete leftovers, write UTC plus TTL, compare 8.8.8.8 and 1.1.1.1, then probe. If they disagree, wait. If they show two companies, delete. If they agree and one local-part fails, create the alias. Do not put the old MX back.
Keep the TTL and the two screenshots in the same note as the alias list. The next cut will be boring. That is the goal. If the note is missing, you will guess, toggle, and call the wait a product outage. Write the note before anyone asks.
Ready to publish one MX set
Start free, create aliases, then wait one TTL.
Free receives one domain. Sign in if it is already there.
Review quarterly, or sooner if dashboard MX hostnames change. Author: MailerZ editorial, Secuno LLC.