When someone loses access to a work mailbox, uncertainty can make the situation worse: colleagues may not know who can help, where to begin, or how to distinguish the account holder from someone impersonating them. A short written plan gives authorised administrators a consistent path without collecting staff passwords or promising that access can always be restored. Keep the plan specific to your organisation, review it when responsibilities change, and make sure staff know how to reach the authorised team through a separate, trusted channel.
The useful bits
- Name the administrators allowed to handle recovery and define how their authority is confirmed.
- Direct account recovery to the official sign-in service; do not use links supplied by an unexpected message.
- Verify requests through an internal process without asking for passwords or one-time codes.
Set a clear boundary around who can act
List the roles permitted to coordinate mailbox recovery, such as the organisation’s designated mail or workspace administrators. Identify a primary contact and a backup by role, not just by name, so the plan remains useful when staff change. Keep the list in a location that the appropriate people can access even if one administrator’s mailbox is unavailable.
State what these administrators may do: receive a recovery request, confirm the requester’s identity under your internal procedure, and direct the account holder to the official recovery starting point. Do not imply that every administrator can change every account setting. Available controls depend on role, plan and provisioning state, and permissions are enforced server-side.
- Record each authorised role and a separate way to contact its holder.
- Name a backup and describe how authority is checked when the primary contact is unavailable.
- Tell staff that coworkers, managers or support intermediaries cannot bypass the designated process.
Point to the official starting place
BITTU Mail is powered by BITTU ICLOUD. Sign-in, registration, account recovery and account actions go through https://mail.bittuicloud.com. Put that address in your internal plan as the starting point, and explain that the account holder should enter it directly or use a bookmark they created themselves.
A message that claims to provide a recovery shortcut should not replace this route. If a staff member is unsure whether a message is genuine, they should contact an authorised administrator using a known internal channel rather than replying with account details or following an unexpected link. The plan should not promise that a particular recovery option will appear or that an account can always be recovered; availability and outcomes depend on the account and the service.
Verify identity without collecting secrets
Choose an internal identity check before an administrator guides someone through recovery. For example, the administrator can contact the requester using a previously established workplace channel or speak with them through a known organisational contact. Where appropriate, confirm the request with a second authorised person. Define what evidence is sufficient for your organisation and what to do if the usual contact method is unavailable.
Never ask a staff member to send or read out their mailbox password or a one-time verification code. Do not store passwords, codes, recovery answers or copies of sensitive identity material in the plan or a shared recovery log. A password manager or other credential system, if your organisation uses one, is separate from this procedure; this plan should not become a place for credentials.
Make the steps usable during an incident
Write the procedure in the order an administrator will follow: receive the request, record the minimum details needed, verify the requester, direct them to the official starting point, and check back through the agreed channel. Ask for only practical details, such as the affected work address and a way to contact the person. Do not record unnecessary personal information.
If the requester cannot complete recovery, the administrator should record that the issue remains unresolved and use the organisation’s approved escalation route. Avoid improvising changes to another person’s account or claiming that an administrator can guarantee restoration. Account controls may differ by role and provisioning state.
Mailbox recovery request Account: [employee@example.com] Requester contact through known internal channel: [method] Authorised administrator handling the request: [role or name] Identity check completed under: [internal procedure] Next step: Requester starts at https://mail.bittuicloud.com Status: [awaiting requester / escalated / resolved] Do not enter passwords or one-time codes.
Test the plan, then keep it current
Walk through a fictional case with the authorised administrators: a staff member cannot access employee@example.com and reports the problem through the normal internal channel. Confirm that the team can identify who is allowed to act, verify the requester without using mailbox access, and direct the person to the official starting point. This is a check of your internal procedure, not a test or guarantee of the provider’s recovery outcome.
The plan is workable if each person knows the next step, no one needs to disclose a password or code, and the backup administrator can locate the instructions. Revise it when administrator responsibilities or internal contact methods change. Keep a review date and remove outdated contacts, while retaining no credentials in the document.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction