Employee Email Offboarding: Disable the Mailbox and Rotate the API Key

Do this on departure day: retarget the domain catch-all if the leaving person owned it, disable the mailbox (do not delete it), keep customer-facing addresses alive with verified forwarding or a living role mailbox, rotate every sending API key they could have used, and revoke mailbox Settings → AI assistants plus device sessions. Delete only after your retention window. A live key that still sends as their From address is an incomplete offboard.

The failure that offboarding checklists miss

Jane’s last day is Friday. HR collects the laptop. Someone resets her Workspace password—or nobody does. On Monday, two things are still true:

• Mail to [email protected] still lands in a mailbox she can open from a phone that was never wiped.
• A sending API key she committed to a repo, or left in CI, still authenticates as the company and can send as [email protected].

That is not an HR leftover. It is a mail-and-credentials problem. Customer threads bounce or go unanswered, and outbound identity stays live on a domain Gmail and Yahoo already score tightly in 2026. Offboarding that stops at “collect the laptop” leaves both doors open.

ArawaMail keeps people mailboxes and the HTTP send API in one workspace, so the same administrator can disable the inbox and rotate the key. Split stacks (Google Workspace or Microsoft 365 for humans + SES or Resend for app mail) require two tickets and two logs. The second ticket is the one teams forget.

The departure-day order of operations

Industry security guides in 2026 still put identity disable and session revoke in the first hour. Mail routing is a parallel operations step, not a substitute for disable. Use this sequence on ArawaMail:

1. Check whether the departing mailbox is the domain catch-all. If it is, select another active mailbox first.
2. Disable the mailbox. Do not delete it.
3. Keep customer-facing addresses alive: verified forward, a living role mailbox such as support@, or an alias onto a living mailbox.
4. Rotate and delete sending API keys the person could have used. Hunt by last_used_at, repo search, and CI variables.
5. Revoke AI-assistant (MCP) connectors at mailbox Settings → AI assistants, and remove the connector in the assistant itself.
6. Leave administrators able to open retained mail. Schedule permanent delete only after your retention policy says so.

There is no ArawaMail “offboarding wizard.” The controls live on email accounts, receiving / catch-all, API keys, and AI assistants.

Disable versus delete: keep the data, stop the person

Disable mailbox immediately blocks webmail, SMTP, mobile, and connected AI-assistant access without removing stored data. Existing mailbox sessions are revoked. Queued mailbox sends are cancelled. A disabled mailbox cannot send and cannot act as a catch-all destination.

Administrators may still open retained mailbox data. They cannot send as the disabled address. Mail sent to that exact address goes to the domain catch-all when one is configured; otherwise it is discarded.

Re-enabling permits a new sign-in. Previously issued sessions and revoked integrations are never restored. A password change (administrator-set, at least 12 characters) also revokes mailbox sessions, but it is not a substitute for disable if the person still has a device profile or an MCP grant.

Permanent delete is a later step. A mailbox must be disabled first. Deletion requires typing the complete address and has no recovery window. It removes mail, attachments, imports, forwarding rules, personal contacts, signatures, spam rules, calendar data, devices, and mailbox integrations immediately. Organization contacts created by the mailbox remain. Activity logs remain according to the service audit-log retention policy. Do not delete on the last day unless counsel and your own retention policy already require it.

Retarget catch-all before you disable

Inbound resolution on ArawaMail is exact active mailbox → active catch-all → discard. Mail to a disabled exact address follows the same fallback. One active mailbox per domain may be the catch-all.

The product fact operators miss: disabling the mailbox currently selected as catch-all automatically disables the domain catch-all until another active mailbox is selected. If that catch-all also had verified forwarding, those copies stop with it.

If Jane was the catch-all, pick support@ or her manager’s living mailbox first, then disable Jane. Leaving her selected turns off catch-all for the whole domain on her last day. For when catch-all is even appropriate, see Should you use a catch-all inbox?.

Keep jane@ reachable without leaving Jane in control

Clients already have [email protected]. That address should not bounce on day one. Three supported paths:

• Verified forwarding from the (still-existing) mailbox to a living destination, while keeping a local copy for admin review. Destinations must approve the verification link within 24 hours. Messages are resent from the local mailbox with Reply-To set to the original sender. Forwarded recipients count toward the monthly transactional-email allowance. Destination limits: Free 1, Pro 5, Business 10. Forwarding applies only to new inbound mail. A forwarding failure never removes the local copy.
• Role mailbox such as support@ or sales@ that people already know. Point customers there in an out-of-office or a last-day reply.
• Alias or shared-inbox pattern onto a living mailbox. Mechanics live in aliases, shared inboxes, and plus addressing. ArawaMail docs do not describe an automated alias-transfer or “convert this mailbox to a shared inbox” control—do not assume one exists; verify the live UI if you need that shape.

Disable still blocks Jane. Forwarding and catch-all decide what happens to mail after she is locked out. If you disable with no catch-all and no forward, inbound to that exact address is discarded.

Rotate the sending key, not only the mailbox password

A sending API key is as powerful as the mailbox password for outbound mail. Current ArawaMail keys authenticate the public send API after sending is active. They support the sending scope and cannot sign in to the dashboard. A key may be unrestricted across company domains or restricted to one domain. Keys are shown once; ArawaMail stores a prefix and a SHA-256 hash. Each successful authenticated request updates last_used_at.

HTTP API sends are written to the Sent folder, so an administrator can see outbound activity after a departure. Use that folder plus last_used_at, git history, and CI variables to find leftovers.

Practical rule: if Jane could have copied a company sending key—or if the key was unrestricted across domains—issue a new key, put it in CI, then delete the old one. Rotating only her mailbox password leaves the send API intact. A leaked From address plus a live key can burn domain reputation; that risk is covered in Don’t let an AI agent burn your domain.

Agents that send on your domain still need a mailbox someone owns after Jane leaves. See Give agents a mailbox, not just an API key.

Revoke MCP connectors and device sessions

OAuth and MCP grants survive a password change unless they are explicitly revoked. ArawaMail’s remote MCP at https://app.arawamail.com/mcp/email uses OAuth against the approved mailbox. The assistant never receives the mailbox password. Documented limits: it cannot access another mailbox, manage drafts or spam, download attachments, permanently delete email, or administer domains.

Disable blocks connected AI-assistant access. Also revoke at mailbox Settings → AI assistants and remove the connector in ChatGPT, Claude, or Grok. There is no separate “MCP token rotation” screen—treat revoke as the control.

Connect-device (IMAP/SMTP/mobile) sessions are likewise blocked by disable. Do not rely on a password change alone if a phone profile may still be present.

Why the split stack fails this runbook

On a Workspace + SES (or Microsoft 365 + Resend) stack, the people admin disables the human mailbox while the app-mail key in CI still sends as the same From domain. Two vendors, two logs, easy to miss one. SPF, DKIM, and DMARC then still authorize the leftover key. That architecture problem is documented in Two vendors, one From address and Keep inboxes and product email on one domain.

One workspace does not remove the need for a checklist. It removes the second ticket. The same person who disables jane@ can see Sent-folder API traffic, last_used_at on keys, and MCP grants without crossing products.

Teams moving people mail off Workspace can follow How to move business email off Google Workspace. Customer-facing From addresses should stay human-owned—stop using noreply@ is the related habit, not a last-day control.

How we analyzed this

This runbook is assembled from ArawaMail product behavior on email accounts (disable, delete, forwarding, sessions), receiving (catch-all resolution and the auto-disable side effect), API keys (sending scope, prefix + hash storage, last_used_at), mailbox Sent-folder API writes, and MCP OAuth limits. Legal hold, country-specific retention, and employment law are out of scope: use your counsel. Alias-transfer and shared-inbox conversion UIs are not documented on the email-accounts page, so this article does not invent them.

What good and bad look like

• Good: last-day disable of jane@; catch-all moved to support@ before disable if she owned it; verified forward onto a living mailbox; new sending key in CI and the old key deleted; MCP connector revoked; admin reviews retained mail for 30–90 days; permanent delete only if policy allows.
• Bad: deleting the mailbox immediately and bouncing every vendor thread.
• Bad: disabling Workspace but leaving a Resend or SES key that still sends as [email protected].
• Bad: leaving Jane selected as the domain catch-all so disable turns off catch-all for everyone.

For the company-email hub see business email. List quality after a messy departure—stale personal addresses on marketing streams—is a separate job covered in email list hygiene.

FAQ

Should we delete the mailbox on the last day?
No. Disable first, keep data for admin review, and delete only after your retention window. Permanent delete has no recovery window.

How do customers keep reaching [email protected]?
Verified forward while keeping a local copy, route through a living role mailbox, or use an alias onto a living mailbox. Do not bounce the address on day one.

What happens if we disable and have no catch-all?
Mail to that exact address is discarded.

What happens if Jane was the domain catch-all?
Disabling her mailbox automatically disables the domain catch-all until another active mailbox is selected. Retarget first.

Do we rotate the company sending API key or only Jane’s password?
Rotate any sending key she could have used. A password change does not invalidate API keys.

How do we find keys Jane might have used?
Check last_used_at on keys, the Sent folder for API sends, repo history, and CI variables.

Does disable revoke MCP and mobile access?
Yes. Disable blocks connected AI-assistant access, SMTP, and mobile sessions. Also revoke at Settings → AI assistants and remove the connector in the assistant.

Why is this harder on Workspace plus SES than on one platform?
Two admins, two logs, and a sending key that outlives the human mailbox. The leftover key still speaks for the same From domain.