Parallel email provider migration is safe when you prepare the new hop while the old MX stays exclusive, then cut to one owner. It is unsafe when you publish both exchangers and call that a bake-off. Senders pick a host. Two hosts means two companies. MailerZ history cannot show the half that never arrived. Screenshot the old set. Map aliases. Swap one owner. Drain the old store without its MX.
Quick answer for parallel email provider migration
Name the mode. Config parallel: MailerZ aliases exist, old MX still only. Cut: publish only MailerZ, delete the old names. Drain parallel: old webmail open for cache, MX already gone. Product path: migration planner and troubleshooting. MX selection is in IETF RFC 5321 — Simple Mail Transfer Protocol. Names are in IETF RFC 1035 — Domain names.
Google’s sitemap docs are about pages; see sitemaps and helpful content. A migration page that recommends “keep both MX for a week” is leftover MX with a calendar.
Confirm MailerZ pricing. Free receives on one domain. Solo is $40 per year for send-as. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. No plan merges two MX owners. No inbox SLA.
The user problem and the decision criteria
Founders want zero missed mail. The instinct is two MX sets. The physics is a coin flip per sender. The real safety is a complete map before the window, a dated screenshot for rollback, and a drain of the old store after the old MX is gone.
| Question | If yes | If no |
|---|---|---|
| Are both MX products published? | Unsafe. Delete one owner. | You can be in config or drain. |
| Are new aliases live while old MX is exclusive? | Safe prep. Cut when ready. | Do not cut yet if the map is empty. |
| Is the old mailbox open after its MX is gone? | Safe drain for TTL cache. | If MX remains, you are split. |
| Self-send worked? | Prove nothing about the other owner. | Good. Still use a foreign probe after cut. |
| Equal priority “for load”? | Not load balancing. Two products. | Still delete leftovers at any priority. |
Technical mail flow
The sending server resolves MX, sorts by preference, and offers the envelope to the first willing host. If that host is the old provider, MailerZ never runs alias policy, HOLD, or SRS. IETF RFC 5321 — Simple Mail Transfer Protocol does not require trying every MX after a 250.
Destination parallel is different. You can tell MailerZ to send a copy to two Gmail addresses after the hop exists. That is two stores, one MX owner. It is not two exchangers. Do not confuse it with leftover Google MX.
TTL means some senders keep the old set after you delete it. That is why drain exists. It is not a reason to leave the old row published. Published rows attract new lookups, not only stale caches.
Self-send from Gmail to Gmail can skip public MX and invent a local win on whichever product Google already knows. Foreign probes after exclusive cut are the gate.
Step-by-step setup and decision path
Screenshot the old exclusive MX
Date it. That file is rollback. Do not keep those names as priority 100.
Build the new map while old MX stays
Aliases, destinations, HOLD default. MailerZ receives nothing yet. That is fine.
Cut exclusively
Publish MailerZ hosts only. Delete old names the same hour. One owner.
Query two public resolvers
If extras remain, you edited theater or TTL has not passed.
Foreign probe
Unique subject. History 250. Header From intact. Then search the destination.
Drain the old store
Read cached arrivals. Do not republish its MX. Close it after TTL plus a day.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| Some customers on the old host | Dual MX or stale TTL | Second resolver lists extras, or old TTL not done |
| History empty after cut | Wrong zone or missing alias | NS plus envelope name |
| 250 empty inbox | Filter or HOLD | Recovery |
| Old host republished after save | Registrar email or parking | MX changed after website DNS |
| Rollback with both sets | You recreated the split | Restore one exclusive screenshot |
| Self-send only | Invalid gate | Foreign probe missing |
Proof is mode name, two listings, and a history row after cut. Agencies run this per zone. Client A can be exclusive while Client B still has outlook.com at priority 20.
MailerZ workflow and product boundary
MailerZ is inbound MX plus authenticated SMTP. Envelope SRS only. Header From never rewritten. During config parallel it does not receive. During exclusive cut it does. It is not IMAP, not Workspace, not an open relay. Unhosted SMTP is 550 / 550 5.7.1.
HOLD stores unknown local-parts on Free. Free is one domain, three aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo is $40 per year: 3 domains, 15 aliases, 90-day store, 1,000 outgoing, five outgoing per hour, unknowns forwarded. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm pricing. Limits are not an inbox SLA. No SOC 2 claim lives here.
Features describe routing. They do not turn two MX products into one inbox. Paid plans do not buy a bake-off.
Cost, alternatives, and trade-offs
| Choice | What you get | What you give up |
|---|---|---|
| Config parallel then exclusive cut | One owner and a rollback file | The comfort of two live hops |
| Dual MX for a week | A quiet second inbox | A complete archive in Gmail |
| Two destinations on one MX | Two stores, one hop | Nothing if you meant copies |
| Buy a suite to “run both” | A store. Quote live | The Gmail you already use |
Time is a line item. A dated screenshot costs less than a week of split invoices. Leftover MX costs more than Solo. A Free-plan send-as argument still costs more than the upgrade.
Three things people call parallel
Config parallel is cheap and safe. You pay nothing in missed mail because the old owner still takes everything. You spend time copying aliases. That time is the migration.
Destination parallel is a product choice after MailerZ owns MX: two Gmails, or Gmail plus a helpdesk. One hop. Two stores. Write who reads which copy.
MX parallel is leftover MX. Call it that in the ticket. Do not call it blue-green. Blue-green for mail would require the sender to try both and merge, which SMTP does not do after a 250.
Some hosts offer “dual delivery” inside one product. That is still one MX owner with an internal fan-out. Google plus MailerZ MX is not that feature. It is two vendors.
Why dual MX is not a safety net
Preference 10 versus 100 still delivers to the old host when the new host is down—or when a sender ignores preference. You wanted delayed mail you can recover. You got accepted mail in a mailbox nobody opens.
Equal priority is worse. Tuesday’s probe hits MailerZ. Wednesday’s bank hits Microsoft. You conclude it works. The bank concludes you are unreachable.
Rollback with both sets recreates the incident. Restore one screenshot. Delete the other names the same hour. Wait TTL. Probe that owner.
Cloudflare routing leftover, registrar included email, and parking MX are dual MX with extra branding. Same delete. Same two resolvers.
Drain versus publish
After exclusive cut, keep the old webmail password for the old TTL plus a day. Move stragglers. Then disable that mailbox. Leaving MX published “until we are sure” is how leftovers survive a quarter.
If counsel needs the old store’s archive, export it. Do not keep MX to keep the archive. Archives do not require live exchangers.
If a second operator needs the same order without a call, send this page plus leftover MX and the Cloudflare migration guide when that is the old hop. Config first. Exclusive cut. Drain without MX. That order prevents a bake-off.
Paid plans do not change the physics. Solo, Starter, Business, and Agency still need one inbound owner. The upgrade changes send-as and limits. It does not make two MX products share an inbox.
Legal hold is not the 14-day Free store. Two-factor on the destination Gmail is still required after the cut. Agencies: one mode name per zone on the ticket. “We are running parallel” without the mode is how Client B stays split.
Night operators add the new MX beside the old “to test.” Morning half the mail is missing. Test with aliases live and old MX exclusive. Cut in a window. Do not test with two owners.
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 passwords to support. The artifacts that close a parallel email provider migration are a mode name, two resolver listings with one owner after cut, and a foreign-probe history 250.
IPv6 versus IPv4 on the new MX hostname is reachability after the names are exclusive. Do not republish the old set because AAAA failed. Fix the host.
Registrar saves can republish included email MX after you cut. Re-query the next day. Drain does not help if the old row came back.
Send-as is a second job after exclusive inbound. Free has no send-as. Do not mix a 550 5.7.1 into a dual-MX inbound ticket.
TTL clocks versus published leftovers
Time-to-live is a clock on a cached answer. It is not permission to leave the old exchanger published. A published leftover MX keeps attracting new lookups after the clock on the old answer has already expired. Those new lookups are not “stragglers.” They are current policy you chose not to delete.
Parallel email provider migration fails most often when someone treats TTL as a reason to keep both names live “until caches clear.” Caches clear because you deleted the old name. They do not clear because you hoped senders would prefer the new priority. IETF RFC 1035 — Domain names describes names and TTLs. It does not describe a merge of two mail products.
Measure the old MX TTL before the window. If it is 3600 seconds, drain for an hour plus a day of human delay. If it is 86400, plan a longer drain. Write the number on the ticket. Do not invent “a week for safety” as a substitute for reading the record. A week of dual publish is a week of split invoices, not a week of safer cache.
Some registrars hide TTL or reset it on save. Screenshot the value you actually published. After exclusive cut, query two public resolvers an hour apart. If the old hostname still appears, you either failed to delete it, edited a theater zone, or the authoritative nameservers have not served the new set yet. Theater is the usual miss: you edited Cloudflare while NS still points at the registrar, or the reverse.
Negative cache also matters. If a sender looked up MX while you had a typo, they may remember the failure for the negative TTL. That is not a reason to republish the old host. Fix the typo. Wait. Probe again from a foreign mailbox. Republishing Google MX “so mail works while we debug” recreates leftover MX and hides whether MailerZ is actually reachable.
IPv4 and IPv6 answers can cache independently. A sender that reaches MailerZ over A but fails AAAA is a host problem after exclusive names exist. Do not add the old MX as a “backup path.” Fix the new host. History will show whether the hop accepted the envelope. An empty history plus leftover MX means the envelope went elsewhere.
What belongs on the migration ticket
A useful ticket names the mode in the first line: config parallel, exclusive cut, or drain. If the first line says “running both for a week,” rewrite it before anyone touches DNS. The next lines should list the printed domain, the authoritative NS, the dated screenshot path, the alias sheet, the HOLD default, the cut window, and the drain close date.
Attach the old exclusive MX screenshot with a date in the filename. Rollback is that file, not a second live row. Attach the MailerZ dashboard MX you will publish. If those two lists share a hostname, you have not actually changed owners. If they share a priority number but different names, you still have two owners once both are published.
List every public local-part you printed: hello, support, billing, careers, founder names. Map each to a destination that will be staffed on cut day. Unknowns stay HOLD unless you have a written reason to FORWARD. Catch-all FORWARD during a parallel email provider migration is how guessed addresses train the new destination while you are still debugging MX.
Write the proof gate: two resolvers, foreign probe subject, history 250, Header From intact, destination search. Self-send is explicitly not the gate. Write who owns the old webmail password during drain and when that password will be rotated or the mailbox disabled. If legal needs the old archive, the ticket says export, not “keep MX.”
Send-as is a separate ticket after inbound is exclusive. Free has no send-as. Mixing 550 5.7.1 into an inbound leftover-MX thread is how both jobs stay open for a month. Link send and reply only after the inbound owner is one name.
Agencies paste this ticket per zone. Client A can be in drain while Client B is still in config parallel. A Slack channel titled “all clients parallel” without per-zone modes is how leftover outlook.com survives on the one domain nobody opened.
Agencies and per-zone parallel
An agency running ten client domains does not get one parallel story. Each zone has its own NS, its own leftover products, and its own TTL. Client A can be exclusive MailerZ while Client B still has parking MX from a registrar upsell. Treating the fleet as one bake-off is leftover MX at scale.
Build the alias map in MailerZ while the old MX stays exclusive. That work is cheap and reversible. The cut is a window per zone, not a Friday when three clients happen to be “ready.” If a client’s registrar email product republishes MX on website save, put a re-query on the next-day checklist. Drain does not help if the old row came back overnight.
Do not share one SMTP credential across clients after paid send-as starts. That is a later article. For inbound parallel, the agency risk is copying the wrong MX set into the wrong zone because two tickets used the same screenshot. Filename the screenshot with the zone and the date.
Quote Agency at $39 or $390 when the fleet needs more domains and aliases. Confirm pricing. The plan does not buy dual MX. It buys capacity for maps you still have to cut exclusively. Product path: features and the migration planner.
Offboard is the inverse of parallel. When a client leaves, delete their MX from MailerZ only after they have an exclusive new owner—or after they accept that mail will bounce. Leaving MailerZ MX published while they also publish Google is their leftover MX with your hostname in it. Close the ticket with a resolver listing that no longer names you, or with a written accept of bounce.
What you tell customers during the cut
Customers do not need a lecture on MX preference. They need a window and a way to resend if something looks missing. Tell them the public address does not change. Tell them not to email a personal Gmail “just in case.” That second address is how you lose the archive you were trying to protect.
Internal staff should know the old webmail still exists for drain and is not the place to file new work. If accounting keeps opening the old host because it still receives a fraction of invoices, you have dual MX or stale cache. Fix the owner. Do not staff two inboxes as a process.
If you must announce a delay, announce a delay. Do not announce “we are running both providers so nothing can be lost.” That sentence trains the company to treat leftover MX as competence. The honest sentence is: we prepared the new map, we cut one owner, we will read the old store for cached mail, then we close it.
Support macros should not say “try sending to the old domain host.” There is no old host after exclusive cut except as a drain mailbox you control. Asking a customer to discover which MX their ISP cached is how you spend a week on one invoice.
Founders who self-send from Gmail to hello@ and celebrate will still miss the bank. Put the foreign-probe rule in the same announcement as the window. Link troubleshooting for leftover MX language the team can reuse.
Leftover products that look like safety
Registrar included email, parking MX, website-builder mail, Cloudflare Email Routing hosts, and old Google or Microsoft rows all present as “we should keep this until we are sure.” They are leftover MX. The brand on the hostname does not change the coin flip. Delete them in the same hour you publish MailerZ.
Some panels add an MX when you click email in the domain dashboard, even if you already set DNS elsewhere. Re-query after every website or email save for a week. Parallel email provider migration is not finished because you cut once. It is finished when the leftover product stops republishing.
Dual delivery inside one vendor is still one MX owner. Google Workspace dual delivery is not “Google MX plus MailerZ MX.” If a sales engineer offers both products as a safety net, ask which hostname senders will resolve. If the answer is two hostnames, you have leftover MX with a slide deck.
Destination copies on MailerZ—two Gmails after one hop—are the legitimate way to give two founders the same public string. That is not parallel providers. It is one owner and two stores. Write who reads which copy. Do not publish a second MX to achieve the same feeling.
Rollback is exclusive too. If the new hop is wrong, restore the dated old screenshot and delete MailerZ names the same hour. Wait TTL. Probe the old owner. Adding both sets “until we decide” is the incident you already had, with a new label.
Legal hold, e-discovery, and tax archives live in exports and destination Gmail, not in a live leftover exchanger. Keeping old MX for counsel is a category error. Export, then delete the name. If counsel needs the old store online, they need a mailbox login, not a public MX.
Two-factor on the destination remains required after cut. HOLD review is still a weekly job if you allowed unknown local-parts to store. Open a held body for break-glass and expect an audit row. That is a control. It is not SOC 2. Do not send zone passwords to support.
The artifacts that close parallel email provider migration are a mode name, two resolver listings with one owner after cut, a foreign-probe history 250, and a drain close date. Everything else is comfort language. Comfort language is how leftover MX survives a quarter.
FAQ
What is the safest way to handle parallel email provider migration?
Prepare the new map while the old MX stays exclusive. Cut to one new owner in a window. Keep the old mailbox readable to drain cache, with its MX already gone. Publishing both MX sets is leftover MX, not a safety net.
Does this require a new mailbox?
No. Parallel prep does not demand a new store. Gmail can stay the destination on both sides of the cut. 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 the exclusive MX you published. Dual MX means some customers still land at the old host. Self-send can hide the split. Free has no send-as.
What DNS records are involved?
One exclusive MX set on the printed name. NS that names the live panel. Verification TXT on the new hop. SPF, DKIM, and DMARC when you send. A leftover old MX at any priority is still a second owner. See RFC 5321.
What should I test before production?
During prep, confirm aliases exist and the old MX is still the only public set. After cut, two resolvers, a foreign probe, history 250, then drain the old store. Do not call dual MX a test.
Key takeaways
- Parallel email provider migration: prep the map, cut one MX owner, drain without the old MX.
- Dual MX is leftover MX. It is not blue-green and not load balancing.
- Config parallel is safe. MX parallel is a coin flip.
- Two destinations on one hop is not two exchangers.
- Rollback is one dated exclusive set, not both names.
- Foreign probe after cut. Self-send is not the gate.
- Free receives. Solo $40/yr starts send-as. Confirm /pricing.
- Envelope SRS only. Not IMAP, not an inbox SLA, not SOC 2.
Conclusion and next action
If you want old and new in parallel, name the mode. Build the new map while the old MX stays exclusive. Cut one owner. Drain the old store without republishing it. MailerZ can show hops it accepted. It cannot merge a leftover host. Start free on one domain and run config parallel before the window.
Ready to prep without a split
Start free with one domain and aliases before the cut.
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 republish MX after a website save. Author: MailerZ editorial, Secuno LLC.