Reassign a role email alias by keeping the public string and moving the store. sales@, billing@, and hello@ should outlive the person. Remap the destination to the human who now owns the role. Rotate every send-as secret they could use the same hour. Do not keep the leaver’s Gmail “for a month.” Exclusive MX still matters: leftover Google can hide whether the remap worked. Probe from another mailbox with a new unique subject. MailerZ is not IMAP and not an HR system.
Quick answer
Keep the role string. Change the destination. Rotate send-as. Probe with a new subject. Remove the leaver dest on the last day. That is how you reassign a role address. Do not create a new public name unless the old one is abused. Do not share the leaver’s mailbox password as the handoff. Two dests during overlap should be dated.
MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as Off, SMTP Off, API Off, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99 monthly or $990 yearly. Confirm live numbers on MailerZ pricing. Those ceilings are capacity, not an inbox-placement promise.
Gmail Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a suite is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol. None of those pages ask you to invent sales2@.
The real decision
Last day is an hour, not a feeling. HR names the date. Ops remaps dests and rotates secrets in the same hour. “We’ll do SMTP next week” is how the leaver still sends as sales@ from a laptop copy. “We’ll leave her Gmail on the alias in case something important arrives” is how she keeps customer mail.
The public string should not change. Customers already have it. A new sales2@ is a failure of nerve. Criteria: dest changed, secret rotated, new probe landed, leaver dest gone, exclusive MX still exclusive.
| Item | Keep | Change |
|---|---|---|
| Public string | Yes | Only if abused |
| Destination | No | New human store |
| Send-as secret | No | Rotate same hour |
| MX | Exclusive still | Do not add leftover |
| Leaver dest | Dated overlap only | Remove on last morning |
Remap dest and rotate secrets the same hour. Probe with a new subject.
Start free — one domainTechnical mail flow
After remap, the second SMTP hop uses the new dest. The old dest should get nothing new. A leftover dest is a second copy you forgot to delete. Fan-out during a dated shadow week is two hops you can explain. Fan-out forever is two people who both think they own the reply.
Send-as with the old pair still leaves as the domain until you rotate. Inbound remap does not revoke a CMS password. Unauthorized 550 after rotate is success, not a new outage.
Self-send from the new dest is not proof customers reach the new human. Gmail can short-circuit to itself. Use an unrelated provider and a unique subject. Search the new dest including spam. Confirm the old dest is quiet.
MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP or POP, not an open relay. Leftover MX is a hard stop. If Google still answers, your remap is theater. Public mail never hits the new dest.
The 14-day Free store, 90-day Solo through Agency store, and 180-day Unlimited store show hops this layer saw. They will not recover mail the leaver deleted in Gmail. Takeout or a dest-side export is the store’s story. MailerZ cannot pull a mailbox archive into the new hire.
Step-by-step handoff
Write last day, new dest, and every From they could send. Then click. HR owns the date. Ops owns the hour.
List role aliases they received or sent
Include hello@, billing@, security@, CMS, forms, Zapier, and the invoice tool. One click on sales@ does not cover the sheet.
Map each to the new human
Date any overlap. Two dests for a week of shadowing can be right. Write the morning you will remove the leaver.
Rotate send-as the same hour
Revoke laptop copies, WordPress, plugins, and chat pastes. Copy the new dashboard pair as one unit. Free had no send-as — still remap inbound.
Remove the leaver dest on last day
Not next month. Not “when we remember.” The dated overlap ends that morning.
Check exclusive MX
Leftovers are not a handoff tool. Dual MX as a “transition” is split brain. DNS help lives on troubleshooting.
Probe each remapped name
Another mailbox. New unique subject. Old probes do not prove the new dest. Confirm spam on the new store. Confirm the old store is quiet.
Re-attach dest send-as if they reply as the role
Gmail Send mail as or Outlook SMTP identity on the new human’s store. Labels in Google Gmail Help — Send mail from a different address. Do not paste the secret into a personal account “just this once.”
Related: aliases and catch-all, send and reply, use cases. Offboarding a whole client domain is the agency version. This page is one human leaving one zone.
Failure modes and proof
| Symptom | Likely cause | What to check |
|---|---|---|
| Leaver still gets customer mail | Safety dest left forever. | Remove dest. Probe. Confirm old inbox quiet. |
| Customers write sales2@ | New public string. | Keep sales@. Remap dest only. |
| Domain From still leaves from a laptop | Secret in Slack or CMS. | Rotate. Expect 550 on the old pair. |
| New hire sees nothing | Self-send only, or leftover MX. | Foreign probe. Public MX from two views. |
| Some senders still hit Google | Dual MX “transition.” | Exclusive MailerZ MX. Then remap. |
| Catch-all hid a missing list | Skipped the sheet. | Hold unknowns. Name every role. |
If the new dest is quiet, print public MX before you blame the remap.
Open leftover MX troubleshootingMailerZ workflow and product boundary
MailerZ remaps aliases and rotates SMTP. It does not cancel a Workspace seat, run takeout, or file a legal hold. Do not call dest remap a hold. Do not invent SOC 2. Do not promise the new hire will see Primary.
Agencies: per-zone sheets. A clean zone A does not offboard zone B. Separate SMTP credentials. Do not keep a client harvest forwarding into the agency inbox after the contractor leaves.
Contractors and interns should have been dests with end dates from day one. If they were not, treat last day like an employee leave. If they had send-as, rotate even if “they only sent twice.” If they used a personal Gmail dest, remove it. Do not wait until they post a customer thread from that account.
security@ on-call changes use the same remap. Founder coverage is a dated second dest, not a forever fan-out. The two-founders article is overlap by design. This page is overlap with an end date.
Cost and seats
Reassignment is not a new MailerZ seat. It is a dest change. A MailerZ seat is a dashboard operator, not a hosted inbox. A suite seat you cancel is a different line — export first if that store held mail you still need. Confirm hop pricing only if you also add names or finally need send-as.
If they had a Workspace seat that was actually a role, cancel the seat after export. The alias is the public string. The seat was the wrong store. If they had a real human seat you are replacing, that is a suite hire. Keep the alias mapped to the new human’s store — Gmail, Outlook, or the new seat. One dest you intend.
Free still remaps inbound. Solo at $40 per year is the smallest plan if the new hire must send as the role. Do not buy Unlimited because a departure felt large. Limits are not an inbox SLA.
Worked examples
They printed sales2@ because they were nervous
Customers kept writing sales@. The new hire watched an empty inbox. They put sales@ back, remapped dest, rotated SMTP, and emailed nothing about a “new address.” The homepage never changed. Nerve was the bug.
The leaver dest left “for safety”
Three months later she still had invoices. They removed the dest, probed, and confirmed her Gmail was quiet. Safety without an end date is not a handoff. It is a second employee.
SMTP next week
The laptop still sent as billing@ from a local copy. They rotated Friday night, revoked WordPress, and confirmed 550 on the old pair. Inbound had been fine since Monday. Two hops, two clocks, one hour next time.
Leftover MX hid the remap
They remapped hello@ and swore MailerZ failed. Public MX still included Google. Half the senders never hit the new dest. They deleted the leftover, waited for two views, probed again. The remap had been correct. The split was not kindness.
Write the last day on a sticky note with the dest email and whether SMTP existed. If the sticky note says “leave her Gmail on,” rewrite it with a date. If it says “new public string,” rewrite it to remap. If it says “MX transition,” rewrite it to exclusive then probe.
Print the remaining role list after the hour. If you cannot print it, you will leave a dest on a name nobody remembered. Three named aliases on Free are enough for a small site. Grow the list when a role is real, not when a harvest guessed admin@.
Do not catch-all during the gap because the sheet is incomplete. Hold unknowns. Review the store. Promote a leftover only when a real person used it. Catch-all during a leave week is how you invent roles you then cannot offboard.
Words that do not belong in the exit ticket: legal hold, guaranteed Primary, “the old address still works for a quarter,” and the new SMTP password. Send vendors nothing unless the public string actually changed. Internally, say which names still work and which dest to search.
Quarterly leftover MX review still applies after the incident. Panic is not a reason to reintroduce registrar forwarding. The next contractor will ask for the mailbox password. The answer is still the dest store, the MailerZ operator seat, and the SMTP secret as three objects.
A one-hour leave-day clock
Minute zero: HR confirms last day and the new dest email. Minute ten: print the role list they actually received. Minute twenty: remap each alias. Minute thirty: rotate SMTP and revoke CMS copies. Minute forty: public MX check so you did not add a leftover “for transition.” Minute fifty: probe every remapped name from another mailbox. Minute sixty: confirm the old dest is quiet and the new dest including spam. If you cannot finish rotate because the secret sits on a contractor laptop, remap inbound anyway. A dest that still receives is worse than a From that 550s.
The new hire still has dest-side work. If they reply as the role from Gmail, they attach Send mail as with the new pair. If they use Outlook, they attach SMTP without adding IMAP. MailerZ will not invent that identity because you remapped inbound. Two hops remain two hops after the person changes.
Shared mailboxes and on-call
A Microsoft shared mailbox that was the dest is still a dest. Remap to the new shared mailbox or to a human store. Do not leave the leaver as a member of the shared mailbox and call the alias done. Alias remap and suite membership are different lists. security@ on-call is the same pattern: the public string stays, the humans on the dest list change, the end date is written.
If two remaining people must both see the role, you are now in the two-founders design: named reply owner, two dests, one send-as identity. That is overlap by design. This page still requires an end date for the person who left. Do not keep three dests because you were tired.
What counsel can and cannot ask this hop to do
Counsel can ask you to keep the public string, to preserve a dest archive, or to stop the leaver from sending as the domain. The first is this remap. The second is the dest product’s export or hold. The third is SMTP rotate. MailerZ store windows are hop evidence, not eDiscovery. Do not promise a 14-day Free row will satisfy a records request for mail the leaver deleted in Gmail last year.
If the role was legal@ or careers@, counsel or HR owns the public sentence if the string itself must change. You still own the row the hour they leave. Disable or remap first. Draft the website sentence second. Printing second is how PDFs stay honest.
Agencies billing a client for “email access” should say what that means: dest inbox they already pay for, MailerZ alias they can take at offboard, SMTP they will rotate when the contractor leaves. A vague “we’ll keep you on the alias” without a dest name is how last day becomes a guess.
If the new hire’s dest is Outlook and the leaver’s was Gmail, that is still one remap. The public string does not care which vendor stores the copy. Prove inbound to the new dest from another mailbox. Then attach send-as on whichever composer they will use. Do not leave both dests “until Outlook feels right.” Feeling is not a date.
Self-send from the new hire to the role that lands in their own inbox is the same lie as always. Use another provider. If leftover MX still answers, your quiet old dest is not proof the leaver is off the path — some senders never hit this layer. Print MX. Then probe. Then stop mailing the role “to see.”
Filters travel with the dest, not with the alias. The leaver’s Gmail filter that filed sales@ to a label does not move to the new hire. Tell them to search the unique subject in all folders the first week. Do not call a missing filter a MailerZ outage. Vacation responders on the old dest should be turned off the same hour you remove the dest, or customers get a goodbye from someone who already left. Confirm pricing only if the new hire must send as the role and you are still on Free. Solo at $40 per year is the usual door for that From. Do not buy a bigger card because a departure felt large.
Dest-side objects the hop cannot move
Remapping sales@ stops new hops to the leaver. It does not move the objects that used that string as a login, a recovery mailbox, or a vendor contact. Print that dest-side list the same hour you remap. Password-manager recoveries, two-factor backup mail, the registrar login, Stripe and GitHub org recoveries, calendar subscriptions, and invoice-portal accounts all keep writing to whoever still controls those logins. MailerZ never sees them.
Assign each object to the new human before last day, or write who will own it after. A remap with an orphan registrar login is how the leaver resets the domain next quarter. A remap with Stripe still recovering to their Gmail is how refunds stay on their phone. The hop is done when dest and secret change. The company is done when those logins change too.
Held MailerZ rows from before the remap stay in the store window. They do not jump into the new hire’s Gmail. If you need a message from last week, open the store, not the dest. After the 14-day Free window or the 90-day paid window, that hop is gone. Do not treat store search as takeout. Confirm live ceilings on MailerZ pricing if you expected a longer window than the card you actually bought.
FAQ
- How do I reassign a role address when someone leaves?
- Keep the public role string. Remap the destination to the new human. Rotate send-as the same hour. Probe from another mailbox with a new subject. Remove the leaver destination on their last day. Do not invent a new public address unless the old one is abused.
- Does this require a new mailbox?
- No. MailerZ is Mail Box portal webmail (Inbox, Sent, New email). It is not IMAP or POP. Gmail or Outlook remains the store. The handoff is a dest change, not a mailbox product. If they had a suite seat that held mail you still need, export that store first — that is a suite job.
- Should I leave the leaver’s Gmail on the alias for a month?
- No, unless you wrote a dated overlap and will remove them on that morning. An open-ended “just in case” dest is how they keep customer mail. Two dests during shadowing can be right. Forever is not.
- Do I need to rotate SMTP?
- Yes if they could send as the role. Rotate the same hour you remap. Revoke WordPress, plugins, and chat pastes. Dashboard rotation is not enough if a laptop still has the old pair. Free has no send-as — still remap inbound.
- What should I test on the last day?
- Send a uniquely titled message from an unrelated provider into each remapped alias. Confirm Header From and history on the new dest, including spam. Confirm the old dest is quiet. Self-send from the new hire’s Gmail is not the public path.
- When should I change the public string?
- Only if the old address is abused or legally retired. Customers already have sales@. A new sales2@ is usually a failure of nerve, not a security improvement.
Key takeaways
- Keep the public role string. Remap dest. Do not invent sales2@.
- Rotate send-as the same hour. Revoke CMS copies.
- Dated overlap is fine. Forever leaver dest is not.
- Probe with a new subject from another mailbox.
- Exclusive MX. Dual MX is not a kind transition.
- MailerZ is not IMAP. Export a suite store separately if you need it.
- Free remaps inbound. Solo $40/year if the new hire must send as the role.
- HR owns the last day. Ops owns the remap hour.
Conclusion and next action
A role address should outlive the person. Keep the string. Move the dest. Rotate the secret. Probe again. Remove the leaver that morning. Do not share a mailbox password as the handoff. Do not change the homepage because you were nervous.
Same string, new human
Start free, map roles, remap dest on the last day.
Rotate SMTP the same hour. Probe with a new subject.
Review after every departure, and leftover MX quarterly. Author: MailerZ editorial, Secuno LLC.