Two people cover a client mailbox, but both sign in with the same password. When one is absent or leaves, nobody has a clear record of who should retain access. For a Gmail account that supports it under your organization’s settings, named delegation offers a more explicit arrangement: colleagues enter through their own accounts.
Delegation is mailbox-management access, not a read-only view. Decide who needs that responsibility before changing account settings. This guide describes a Gmail-specific route; it does not claim that every email platform uses the same controls.
Confirm the account and the permitted delegates
Identify the mailbox’s actual Google Account and the person responsible for it. An address alias is not a separate account to which you can add delegates. In work or school environments, delegation depends on organization settings and eligible colleagues within the organization.
Google’s delegation guide states that delegates can read, send, and delete email. Consider those rights against the actual job. If somebody only needs one document or a forwarded conversation, full mailbox delegation may be unnecessary.
Ask the administrator about enabled delegation and sender-display settings where applicable. Do not assume the display a recipient sees is identical in every organizational configuration. Keep your organization’s account and client-data policies in force.
Add a named colleague through Gmail settings
On a computer, the mailbox’s authorized user opens Gmail settings, chooses See all settings, and finds Accounts and Import or Accounts. In Grant access to your account, use Add another account and enter the permitted colleague’s address. Follow the invitation step in the current interface.
The colleague accepts the invitation and opens the delegated mailbox from the account switcher in their own Gmail account. Check the address at the top before working in it. Access may take time to become available; a sent invitation alone is not a completed handover. Use the current Google instructions if the controls differ.
Do not circulate the mailbox password as a fallback. If delegation is unavailable, use an administrator-approved alternative rather than turning a setup problem into shared credentials.
Agree who owns each reply
Delegation grants access; it does not decide which colleague answers a message. Use a short coverage rule alongside it.
Fictional example: Maya covers the mailbox in the morning and Jordan in the afternoon. The person taking an inquiry records their name and next action in the team’s existing tracker. Before the handover, they identify unresolved replies and deadlines. The other colleague checks that handover before sending a second response.
Use this minimum arrangement:
| Question | Agreed answer |
|---|---|
| Who covers the mailbox now? | Named person or coverage period |
| How do we claim a reply? | Existing agreed marker or tracker field |
| What needs handover? | Unresolved request, deadline, and next action |
| Who can remove access? | Authorized account user or administrator |
Avoid creating a second shadow tracker if the team already has a usable one. The objective is one visible responsibility record.
Verify with a controlled message
Confirm that the colleague can open the correct mailbox and perform the intended task. If a send check is needed, use an agreed internal test destination and examine the actual sender display. Do not send a test to a real client.
Check coverage separately from technical access: can the next colleague find the unresolved inquiry and understand what remains? A working account switch does not establish a working reply handover.
When a colleague no longer needs access, remove their delegation through the supported settings and verify the change. Keep that removal distinct from deleting the mailbox, changing retention, or altering client communications. You end up with named mailbox access and an understandable coverage routine, instead of a shared password whose custody is unclear.