yodai Academy Domain and email

Academy › Publishing › Domain and email

The day someone leaves, all you change is the key

If the email address belongs to the role, someone leaving gets handled that same day: change the password, close their sessions, and check the forwarding rules, no migration and no need to notify customers.

By Yodai · Published September 6, 2026 · Updated October 12, 2026

7 min read

The person who handled the business's WhatsApp is leaving. Or the one who answered the reservation emails. And the first question that hits you isn't who replaces them, it's what you do with their email. This happens more often than you'd think: someone changes jobs, someone doesn't come back after summer, someone's season ends.

Do you need to tell customers to write to a different address? Do you need to save their old emails so nothing gets lost? Do you need to explain why they suddenly disappeared? If the email they worked from was reservations@yourbusiness.com and not maria@yourbusiness.com, the answer is much shorter than you'd fear: you change the password that same day, and that's it. No one migrates anything. No one writes to anyone.

The key and the lock aren't the same thing

In the previous lesson, you already decided that the email address should be named for the role, not the person. That decision is what saves you the headache now.

The role, reservations@, hello@, frontdesk@, is the lock: it belongs to the business and it's always there. The person who has the password today is the key: it can change without the lock ever knowing. Over five years, three or four different people might pass through reservations@, and the address never changes; the only thing that changes is who holds the key at any given time. It doesn't matter if that person stayed three months or five years: the lock doesn't age with them.

When someone leaves, they don't take the lock with them. They just lose the key. You change the password and give a new one to whoever comes in. The email history, the customers who wrote last week, the open thread with the flower supplier for Saturday's order: it all stays in the same inbox, ready for whoever uses it next.

Email with a name or email with a role, on the day someone leaves
Email with a name (maria@)
  • The history lives in Maria's head, not in an inbox someone else can simply inherit
  • Customers have her direct address saved and will keep writing to her, not to the business
  • You have to rescue the important emails before they're lost along with the account
  • You have to tell customers to write somewhere else, which forces you to explain why
Email with a role (reservations@)
  • The history already lives in a business inbox, not in anyone's head
  • Customers were writing to reservations, not to a person: they never noticed the change
  • There's nothing to rescue: the inbox is the same before and after
  • There's nothing to announce: from the outside, the business keeps replying from the same address

Which one applies to you: If your email is already set up by role, the day someone leaves, you don't migrate anything or send out notices: you just change the password and move on. If you still have an email with a person's name handling customers, that's your sign to fix it now, while that person's still on staff, not the day after they're gone.

What you do need to do that same day

Changing the password isn't just typing a new one and calling it done. If you do it halfway, the person who's leaving can keep reading emails weeks later without you knowing.

The day someone leaves
  1. 1Change the password on the role's email
    Do it that same day, not whenever you get a free week. As long as the password stays the same, the person who's leaving can still log in from their phone even after they've stopped working with you. And if the account's recovery phone or email still belongs to that person, swap them for the business's own: according to Google's help on recovery options, those are used to get back into the account if the password is forgotten, and Google can keep sending codes to the old ones for seven days.
  2. 2Sign out of every device
    Changing the password doesn't always lock everyone out. On a Google account, according to its help page on changing your password, it signs you out everywhere except on the devices you use to verify it's you and on some third-party apps you'd given account access to. If the departing employee's phone was one of those, they're still logged in. Open the list of devices with access to the account, in the same Security and sign-in section where you changed the password, and sign out of any that aren't the business's own. With other providers, look for the equivalent option in their security settings.
  3. 3Check the forwarding rules
    Go into the email settings and make sure no one set up automatic forwarding to a personal account. In Gmail it's under the Forwarding and POP/IMAP tab, and it can also be tucked inside a filter, according to its help page on forwarding. In Outlook.com it's on the Forwarding and IMAP page of the settings, and Microsoft notes that it can also be set up through rules. It's a quiet way to keep reading someone else's email.
  4. 4Remove them from the dashboard and every access list
    Cut off their access to the dashboard where you manage your website, to the shared appointment calendar, and to any sheet or list where the role email's password was written down. INCIBE, Spain's cybersecurity institute, calls for this in its access control policy for small businesses: once you end a relationship with an employee, you need to revoke their permissions and delete their accounts across services and apps. A forgotten login in the dashboard is a door you never locked.
  5. 5Give the new password to whoever's coming in
    The inbox stays the same, with all its history intact. The new person starts replying from minute one, and the customer never notices the change.
The forwarding rule no one remembers setting up
The expensive mistake isn't forgetting to change the password: it's forgetting that someone could have set up, months earlier, for a copy of every email to reservations@ to also land in their personal account, so they could check it from their phone without logging into the business one. It's the same as someone keeping a copy of the key without you ever seeing it. You change the password, you feel safe, and that person keeps getting every new booking in their Gmail for months. Gmail's own help treats changing the password and turning off a forwarding rule you never set up as two separate steps, and the notice that your email is being forwarded only shows up the first week. It's worth checking that rule now and then with your current team too, not just when someone leaves, the same way INCIBE, in that same policy, recommends periodically reviewing that everyone's permissions are still appropriate: it's easy to set up forwarding to work comfortably from your phone and then forget it's there forever.

What you don't need to do

You don't need to email customers explaining that someone has left. You don't need an apology note or an explanation of the staff change. The customer never wrote to a person: they wrote to reservations or to hello, and reservations keeps answering them. Over-explaining, in this case, costs more than staying quiet: it turns a normal internal change into an announcement nobody asked for. That silence on the outside is exactly the result you were after when you decided the email should belong to the role, not the name.

What's still left, and it's not today's topic, is what you do when the departure isn't a calm one: when someone leaves angry or might try to use that address to impersonate the business. That calls for a different, more urgent set of steps, which is what the next lesson covers.

What you'll walk away with
  • You know a role-based email doesn't need migrating or announcing when someone leaves: you change the password and move on
  • You have the list of what to check that very day: password and recovery details, open sessions, forwarding rules, dashboard access
  • You know how to tell a role-based email from a name-based one, and why the second forces you to migrate and notify

Test yourself

Answer before opening each one. If one gives you trouble, go back to the section that explains it.

1. Vanessa has been answering from reservations@yourclinic.com for two years, and today is her last day. You don't plan to fill the role this week, so you're thinking of leaving it until you hire someone.

Change the password anyway, even if no one's logging in tomorrow. The role being vacant doesn't change the fact that you need to change the key: leaving it with the old password is an open door for a day, a week, or a month, whether or not there's a reason to close it.

2. Two months after the person who handled your email left, a customer writes to say it seemed odd getting a reply that sounded different, like someone else had answered without signing their name.

You check the forwarding rules and open sessions, not the password: if you already changed it back then, that's not where the problem is. An automatic forward to a personal account, set up months earlier, keeps delivering emails even with a new password.

3. You realize your customer service email is still carla@yourbusiness.com, named after the person who runs it. Carla still works with you, with no plans to leave.

You fix the name now, while Carla's still there, having her migrate her own inbox to the role-based email before you actually need to. Doing it the day she leaves means scrambling to recover emails and notify customers; doing it now costs nothing because she can help make the switch herself.

That works when the change is clean and on time. When it isn't, when suspicion arrives before the notice does, the rule changes.

Sources

  1. Change your password. Google Account Help, accessed October 2026.
  2. See devices with access to your account. Google Account Help, accessed October 2026.
  3. Automatically forward Gmail messages to another account. Gmail Help, accessed October 2026.
  4. Turn automatic forwarding on or off in Outlook. Microsoft Support, accessed October 2026.
  5. Security policies for small businesses: access control. INCIBE (Spain's National Cybersecurity Institute), accessed October 2026.
  6. Set up recovery options. Google Account Help, accessed October 2026.

In Yodai you connect the domain you already have to your site, and it stays registered where it is, in your name. See how your own domain for your website works.

NextCut first, ask questions later