An ImprovMX to MailerZ move is an MX cutover, not a mailbox migration. Gmail or Outlook stays the store. You recreate named aliases, publish one inbound owner, and delete leftover ImprovMX hosts. Regex rules, webhooks, and multi-destination fan-out may not map one-to-one. Quote ImprovMX’s live docs for what you actually run. Dual-publishing both products is leftover MX with extra branding, not a safe overlap.
Quick answer for improvmx migration mailerz
Start on paper. Export every alias, destination, catch-all, rule, null route, webhook, and SMTP identity you actually use. A screenshot of “25 aliases” is not an export. If a critical route is regex or webhook-only, decide whether a named MailerZ alias is maintainable. If it is not, do not force the move.
Create the MailerZ domain and matching local-parts while ImprovMX still owns MX. Verification TXT does not steal inbound. You can build the map without an outage. Unknowns on MailerZ Free are held. Paid catch-all FORWARD is optional. Do not assume ImprovMX catch-all becomes Free HOLD and call that equivalent.
When the map exists, publish exclusive MailerZ MX and delete ImprovMX MX in the same change window. Lower TTL beforehand if you can. Wait remaining TTL if resolvers disagree. Do not leave ImprovMX at a worse priority “as backup.” Split delivery is the outage you will debug at 11 p.m.
Prove from another mailbox. Self-send can lie. Open MailerZ history. Empty history means leftovers or a name that never arrived. A 250 then destination 5xx is Gmail or Outlook. Copy the SMTP line before you roll back.
Paid send-as is a separate project. Free cannot send. Recreate SMTP identities only for addresses that must send. Quote ImprovMX’s current SMTP allowances if volume is why you stayed; MailerZ monthly outgoing is 50/100/200/400/800 by plan and hourly caps are 5/10/15/25. Those are not campaign relays.
Transport is still IETF RFC 5321 — Simple Mail Transfer Protocol. ImprovMX migration. Migration planner. Troubleshooting.
Inventory routes before you touch MX. A local-part list is not enough if ImprovMX rules or webhooks exist.
Open the ImprovMX migration pageThe real decision
People treat this as “change MX and hope.” The real decision is whether your ImprovMX graph is a list of named aliases or a small program of rules. MailerZ is named aliases, destinations, and explicit unknown HOLD or paid FORWARD. It is not a regex engine.
The second decision is volume. If you chose ImprovMX for high daily forwards or large SMTP quotas, read both live cards. MailerZ is human-scale operational sending. Do not migrate a newsletter onto MailerZ SMTP.
The third decision is recovery. MailerZ stores delivery history and failed hops (14 days Free, 90 paid). Judge ImprovMX logs on their current plan page. Do not invent matching retention.
Cancel last. Keeping ImprovMX billed for a week after exclusive MX is cheaper than restoring MX from memory when one alias was missing.
When this path is enough
- You can export every route, including rules you might drop.
- Named aliases cover the addresses customers actually use.
- You will publish one MX set and delete leftovers.
- You will keep ImprovMX readable until probes pass.
When this is the wrong ticket
- A webhook or regex is the business. Stay or rebuild that logic elsewhere first.
- You need IMAP or Calendar. Neither product is Workspace.
- You want both MX sets live “during overlap.” That is leftover MX.
- You need bulk SMTP. Use a compliant bulk sender.
Technical mail flow
Before cutover, senders look up ImprovMX MX and talk to ImprovMX. After cutover, they look up MailerZ MX. There is no shared inbound. Messages already accepted by ImprovMX finish on ImprovMX. Messages accepted by MailerZ finish on MailerZ. In-flight is TTL, not a merge.
MailerZ rewrites envelope MAIL FROM with SRS. Header From stays the original sender. If you were used to a From rewrite, stop. Changing Header From is how DKIM and DMARC die on the second hop.
Destinations stay Gmail or Outlook. You are not exporting PST files. You are pointing a domain at a new hop.
Outbound SMTP, if any, uses MailerZ credentials on a paid plan and dashboard SPF, DKIM, and DMARC. Do not keep ImprovMX SMTP in Gmail Send mail as after inbound moved. Wrong host is a 550 or a timeout.
Leftover Google or Microsoft MX from an older life can sit beside both products. Delete those too. Exclusive means exclusive.
Step-by-step decision path
- Export the live ImprovMX map Aliases, destinations, catch-all, rules, webhooks, SMTP. Quote their current UI.
- Mark untranslatable routes Regex and webhooks either become named aliases or stay behind.
- Create MailerZ domain and aliases Verify destinations. Set unknown behavior. Free holds unknowns.
- Write rollback MX Copy ImprovMX hosts and priorities into the ticket before you delete them.
- Lower TTL if you can wait a day Then publish exclusive MailerZ MX and delete ImprovMX MX together.
- Probe every critical alias Other mailbox, unique subjects, hop history copied.
- Attach paid send-as only if needed Free has none. Test outward to a second external inbox.
- Cancel ImprovMX after proof Not the same afternoon you published MX unless history is green.
Worked examples
A studio had hello, billing, and jobs. They recreated three aliases, cut MX, and proved from Proton. They cancelled ImprovMX six days later. No rules, no drama.
A shop used a regex that swallowed plus tags into one mailbox. MailerZ does not claim plus-tag stripping on custom domains. They created the five local-parts they actually printed. The regex stayed on ImprovMX until those five were live, then they cut.
An agency left ImprovMX MX at priority 20. Some senders still hit it. MailerZ history looked “flaky.” They deleted the leftover. It was not flaky.
SMTP in Gmail still pointed at ImprovMX after inbound moved. Outbound failed. They swapped the host from the MailerZ dashboard on Solo.
Someone enabled paid FORWARD to “match catch-all” on day one and then could not tell HOLD misses from real misses. They turned FORWARD off until named aliases were proven.
Sketch the cutover order before you delete the old MX.
Open the migration plannerFailure modes and proof
| Symptom | Likely cause | Proof |
|---|---|---|
| Empty MailerZ history | Leftover ImprovMX or Google MX | Two-resolver MX; delete leftovers |
| Some aliases work | Those names were recreated; others were not | Diff the export |
| Catch-all vanished | Free HOLD or FORWARD not enabled | Create names or pay for FORWARD |
| Outbound 550 | Free or old ImprovMX SMTP host | Paid identity; dashboard host |
| Webhook silence | MailerZ has no webhook copy of that rule | Do not cut until replaced |
| Rollback panic | Old MX never written down | Keep the rollback card |
MailerZ workflow and product boundary
Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not IMAP. Not an open relay.
What MailerZ does
- Accept MX for verified domains.
- Rewrite envelope MAIL FROM with SRS on the forward.
- Leave Header From and MIME intact.
- Hold unknowns on Free. Optional paid FORWARD.
- Paid SMTP from approved identities. Dashboard SPF, DKIM, and DMARC instructions.
- 550 for unauthorized From. Not an open relay.
What MailerZ does not do
- Guarantee Gmail Primary or any inbox placement rate.
- Host IMAP, webmail, or Calendar.
- Send-as on Free.
- SOC 2, ISO 27001, HIPAA, review counts, or an uptime SLA. Controls: Security and Trust Center.
Plans: pricing. Free $0, 1 domain, 3 aliases, 1 seat, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/year, 3 domains, 15 aliases, 90-day, 1,000 outgoing, 5/hour. Starter $8 or $80, 5/50/5, 2,000, 10/hour. Business $19 or $190, 25/200/25, 4,000, 15/hour. Agency $39 or $390, 100/500/50, 8,000, 25/hour. Unlimited is $99/month or $990/year. Annual Starter, Business, and Agency include two months free versus monthly. Solo is yearly only.
Cost, alternatives, and trade-offs
| Approach | You get | You give up |
|---|---|---|
| Named-alias cutover | One hop, stored history | Rules and webhooks you drop |
| Stay on ImprovMX | Keep current routing depth | You do not get MailerZ HOLD/history model |
| Dual MX “overlap” | Illusion of safety | Split delivery |
| Workspace instead | IMAP and Calendar | Seats; leftover MX if you keep a forwarder |
Field notes
Read /alternative/improvmx for the live comparison table. This page is the cutover, not the shopping list.
ImprovMX pricing and SMTP numbers change. Quote https://improvmx.com/pricing/ the day you decide. Do not paste last year’s blog.
MailerZ Agency is 100 domains, 500 aliases, 50 seats — still not an inbox SLA.
Keep the export in the ticket, not in Slack screenshots that expire.
If two clients share one ImprovMX account, migrate one domain at a time.
Do not rewrite Header From “to look local.” MailerZ will not.
Self-send after cutover still lies. Keep the Proton mailbox.
Retention: export hop rows you care about before Free’s 14 days roll off.
Treat improvmx migration mailerz as a ticket with artifacts, not a vibe. Ask for public MX from two resolvers, a received copy, and MailerZ history before anyone edits TXT.
Write a one-paragraph policy for ImprovMX to MailerZ Migration Guide: inbound versus outbound, what you will not do (dual MX, From rewrite, second SPF), and who owns DNS.
Self-send is invalid for improvmx migration mailerz. Gmail can short-circuit. Use another mailbox and a unique subject.
Leftover MX masquerades as improvmx migration mailerz. Empty history means the hop never ran. Delete aspmx, Microsoft, and registrar MX. Wait TTL.
Free HOLD and missing aliases look like outages. History shows the hold. Create the named local-part. Catch-all FORWARD is paid and optional — not a debugger.
Paid send-as is a different hop. Free cannot send. Unauthorized From is 550 / 550 5.7.1. DNS will not authorize a From the product has not approved.
ImprovMX to MailerZ Migration Guide does not include an inbox placement SLA, review counts, or Primary. Say that early.
Proof packet for improvmx migration mailerz: two-resolver MX, inbound copy with Header From, Authentication-Results, outbound copy if they send, plan name, SMTP line if anything refused.
Retention is 14 days on Free and 90 on paid. Export headers while they live. The destination inbox is the archive.
Agencies should not blend clients in one improvmx migration mailerz thread. Agency limits are 100 domains, 500 aliases, 50 seats, 8,000 outgoing, 25/hour — still not an SLA.
No SMTP passwords in the improvmx migration mailerz ticket. No invented SOC 2. Controls live on the Security and Trust Center.
If two products share MX, stop adding records. Exclusive MX is a hard stop. improvmx migration mailerz cannot be correct on a split path.
If Header From is rewritten, stop tuning SPF for improvmx migration mailerz. Change the hop. MailerZ will not offer a From-replace control.
If the customer wants Calendar, sell a suite. If they want a hop, sell a hop. ImprovMX to MailerZ Migration Guide is not Exchange.
Hourly and monthly send-as ceilings (disabled/1,000/2,000/4,000/8,000 outgoing; 5/10/15/25 per hour) produce refuses that look like improvmx migration mailerz. Read counters.
Null MX plus a real MX is a lie. Remove the lone-dot refuse if you intend to receive.
After any change for improvmx migration mailerz, wait TTL, probe from another mailbox, and store the new received source next to the MX screenshot.
Write improvmx migration mailerz in the subject and the layer in the first sentence: leftover MX, HOLD, destination 550, or TTL. Honest first sentences shrink tickets.
Monthly for improvmx migration mailerz: leftover MX lookup, one external inbound probe, send-as counters if paid. Five minutes. The outage you avoid is a Friday dual-MX restore.
When two vendors disagree about improvmx migration mailerz, believe two resolvers, one received copy, and one history row. Registrar dots lie. Composer UIs lie.
Teach the next hire the MailerZ split before they touch improvmx migration mailerz: envelope may change, Header From must not, Free cannot send, unknowns HOLD, leftover MX is a hard stop.
If improvmx migration mailerz appears in an RFP, answer with published caps and hop evidence. Decline inbox-rate clauses and fake certifications.
Do not bundle unrelated edits with improvmx migration mailerz. Rotating SMTP while republishing MX while enabling FORWARD is how you lose the ability to name the failure.
Field story 1 for improvmx migration mailerz: A studio had hello, billing, and jobs. They recreated three aliases, cut MX, and proved from Proton. They cancelled ImprovMX six days later. No rules, no drama. Keep it in the runbook.
Field story 2 for improvmx migration mailerz: A shop used a regex that swallowed plus tags into one mailbox. MailerZ does not claim plus-tag stripping on custom domains. They created the five local-parts they actually printed. The regex stayed on ImprovMX until those five were live, then they cut. Keep it in the runbook.
Field story 3 for improvmx migration mailerz: An agency left ImprovMX MX at priority 20. Some senders still hit it. MailerZ history looked “flaky.” They deleted the leftover. It was not flaky. Keep it in the runbook.
Field story 4 for improvmx migration mailerz: SMTP in Gmail still pointed at ImprovMX after inbound moved. Outbound failed. They swapped the host from the MailerZ dashboard on Solo. Keep it in the runbook.
Field story 5 for improvmx migration mailerz: Someone enabled paid FORWARD to “match catch-all” on day one and then could not tell HOLD misses from real misses. They turned FORWARD off until named aliases were proven. Keep it in the runbook.
For improvmx migration mailerz, “Empty MailerZ history” usually means Leftover ImprovMX or Google MX. Isolate with Two-resolver MX; delete leftovers. One change at a time.
For improvmx migration mailerz, “Some aliases work” usually means Those names were recreated; others were not. Isolate with Diff the export. One change at a time.
For improvmx migration mailerz, “Catch-all vanished” usually means Free HOLD or FORWARD not enabled. Isolate with Create names or pay for FORWARD. One change at a time.
For improvmx migration mailerz, “Outbound 550” usually means Free or old ImprovMX SMTP host. Isolate with Paid identity; dashboard host. One change at a time.
For improvmx migration mailerz, “Webhook silence” usually means MailerZ has no webhook copy of that rule. Isolate with Do not cut until replaced. One change at a time.
For improvmx migration mailerz, “Rollback panic” usually means Old MX never written down. Isolate with Keep the rollback card. One change at a time.
Setup step “Export the live ImprovMX map” for improvmx migration mailerz: Aliases, destinations, catch-all, rules, webhooks, SMTP. Quote their current UI. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Mark untranslatable routes” for improvmx migration mailerz: Regex and webhooks either become named aliases or stay behind. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Create MailerZ domain and aliases” for improvmx migration mailerz: Verify destinations. Set unknown behavior. Free holds unknowns. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Write rollback MX” for improvmx migration mailerz: Copy ImprovMX hosts and priorities into the ticket before you delete them. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Lower TTL if you can wait a day” for improvmx migration mailerz: Then publish exclusive MailerZ MX and delete ImprovMX MX together. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Probe every critical alias” for improvmx migration mailerz: Other mailbox, unique subjects, hop history copied. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Attach paid send-as only if needed” for improvmx migration mailerz: Free has none. Test outward to a second external inbox. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Setup step “Cancel ImprovMX after proof” for improvmx migration mailerz: Not the same afternoon you published MX unless history is green. Skip it and ImprovMX to MailerZ Migration Guide becomes next week’s ticket.
Trade-off on improvmx migration mailerz: Named-alias cutover gets One hop, stored history and gives up Rules and webhooks you drop. Write that on the quote.
Trade-off on improvmx migration mailerz: Stay on ImprovMX gets Keep current routing depth and gives up You do not get MailerZ HOLD/history model. Write that on the quote.
Trade-off on improvmx migration mailerz: Dual MX “overlap” gets Illusion of safety and gives up Split delivery. Write that on the quote.
Trade-off on improvmx migration mailerz: Workspace instead gets IMAP and Calendar and gives up Seats; leftover MX if you keep a forwarder. Write that on the quote.
Cutover week, written as a runbook
Treat the ImprovMX week as five named days, even if you compress them. Day minus two is export and untranslatable-route decisions. Day minus one is MailerZ aliases, destinations, and a rollback card. Day zero is exclusive MX and leftover delete. Day plus one is the probe list. Day plus two is SMTP, if you even need it. Compressing all five into one hour is how webhook silence and leftover MX share a ticket.
Write the untranslatable list in the same document as the alias list. A regex that folded plus tags, a webhook that billed a shop, a null route that swallowed a typo — those are product decisions, not DNS. If you hide them in Slack, the person who publishes MX will assume named aliases cover them. They will not.
Quote ImprovMX’s current hosts when you write the delete list. Memory of “mx1 and mx2” is how a third host survives at priority 20. Two public resolvers after the publish should show only MailerZ. If they still show an ImprovMX name, you are not in TTL. You are in leftover MX.
Keep Gmail filters and Outlook rules out of the cutover hour. A filter that filed hello@ into a label does not prove the hop. It proves a destination habit. Move filters after hop history is green. Mixing them makes “it arrived” mean “I found it in a label I forgot I had.”
Agencies should cut one client domain per window. A shared ImprovMX account with twelve domains is twelve cutovers. Blending them produces a probe list nobody can own. Agency plan caps (100 domains, 500 aliases, 50 seats) do not make a blended window safe.
If volume is the reason you hesitate, write the monthly outbound number you actually send as humans, not the campaign number marketing wants. MailerZ 100 outgoing on Solo and 200 on Starter are operational replies. A 6,000 SMTP month on someone else’s card is a different job. Stay or buy a bulk sender. Do not smuggle a newsletter onto MailerZ after MX moves.
Header From must stay the original sender after the hop. If a stakeholder wants “it should look like it came from us” on inbound, they are asking for a rewrite. MailerZ will not. Explain DKIM once. If they still want a rewrite, they want a different product class — say that before day zero.
Cancel is a finance action with a technical gate. The gate is: probe list green, leftover MX gone, SMTP host swapped if you send, rollback card filed. Same-afternoon cancel is how you lose the only log that showed jobs@ still lived on ImprovMX. A week of bill is cheaper than a letterhead address you cannot prove.
FAQ
What is the safest way to handle improvmx migration mailerz?
Export every route. Recreate named aliases on MailerZ while ImprovMX still owns MX. Publish exclusive MailerZ MX, delete leftovers, prove from another mailbox, then cancel. Do not dual-publish. Drop regex or webhooks you cannot represent.
Does this require a new mailbox?
No. The destination inbox stays. MailerZ is not IMAP. You are changing the receiving hop.
Will it work with Gmail or Outlook?
Yes as destinations. Gmail Send mail as uses MailerZ SMTP on a paid plan. Outlook uses a manual SMTP identity. Free has no send-as.
What DNS records are involved?
MailerZ verification TXT, exclusive MailerZ MX, leftover ImprovMX and Google MX removed. SPF, DKIM, and DMARC if you send. Quote ImprovMX’s current hosts so you know what to delete.
What should I test before production?
Every critical alias from an unrelated mailbox, hop history, Header From intact, rollback MX written down. Outbound only after inbound is green.
Key takeaways
- This is an MX cutover, not a mailbox move.
- Export rules, not just local-parts.
- Recreate names before you publish MX.
- Exclusive MX. Leftovers are a hard stop.
- Prove from another mailbox.
- Cancel ImprovMX last.
- Free cannot send-as.
- Quote ImprovMX live docs for volume and rules.
Conclusion and next action
Write the inventory like you will need it at midnight. Then cut once. The teams that fail this move are the teams that treat MX as a toggle and aliases as a vibe.
If named aliases are enough, the hop change is boring — which is the goal. If they are not enough, stay or rebuild the logic first.
Keep both dashboards open until history matches the probe list. Then cancel. Not before.
One MX owner
Cut MX once, after routes exist
When the inventory is real and leftovers are gone, create a Free MailerZ domain and prove inbound. Cancel ImprovMX only after hop history matches.
Review quarterly, or sooner if DNS hosts or dashboard instructions change. Author: MailerZ editorial, Secuno LLC.