Use an existing recovery method or an appropriately privileged administrator first, then the existing reseller or official provider recovery route; a password reset does not itself recover MFA, administrative rights or mailbox data.

Recover the existing account before changing the email service. Start with a recovery method already attached to the account, another authorized administrator with the right privileges, or the existing reseller. If none works, use the provider’s official recovery process. A new subscription or a change to MX records does not unlock the old administrator account.
First establish what failed: the password, the second authentication factor, the organization’s sign-in system, or permission to administer it. These instructions are researched from current Google Workspace, Zoho and Microsoft documentation. We have not recovered an account or tested a support response for this article.
1. Identify the account and the failed step
Record the provider, full sign-in username, organization/domain and exact error with its time and timezone. A mailbox address can be an alias rather than the administrator’s sign-in name. Distinguish a business-managed account from a personal Gmail or Microsoft account. Use a trusted device and the provider’s genuine sign-in page; keep reset links, codes and private account evidence out of public forums.
| What you observe | First useful route | What that route does not prove |
|---|---|---|
| Password rejected or forgotten | Configured password recovery or an authorized administrator’s reset | That you can complete MFA or have administrator privileges |
| Password accepted, but the second factor is unavailable | A registered alternative, saved recovery code or role-appropriate MFA recovery | That changing the password removes the second-factor requirement |
| Redirect to the organization’s sign-in provider fails | The responsible identity-provider administrator and the documented product-specific route | That resetting the mailbox-provider password repairs SSO |
| Mailbox opens, but administration is denied | Check the account, organization and assigned role with an authorized administrator | That every mailbox user is entitled to administrative control |
| Former administrator is unreachable or ownership is disputed | Provider/reseller ownership recovery with the requested business evidence | That domain access alone authorizes access to all organization data |
If multiple users suddenly cannot sign in, ask the responsible administrator to check service health and recent identity-policy changes before resetting accounts individually. If unauthorized changes or account takeover are suspected, tell official support that this may be a security incident. Preserve relevant notices and audit evidence through an authorized person rather than treating it as a forgotten password.
2. Prepare a reachable contact and the right helper
Find another authorized administrator and identify their actual role, not just their job title. A billing contact, mailbox delegate or website developer may lack recovery privileges. Use an independent contact address you control if the locked mailbox cannot receive recovery correspondence. Check existing invoices and contracts to identify a reseller; an authorized colleague may still be able to inspect the account.
Prepare account and organization identifiers plus the evidence requested by the official process. Google’s support checklist includes account-creation and payment information. Do not fabricate missing answers, upload complete bank statements unnecessarily or give a helper your remaining recovery codes. Submit only what is requested through the verified support channel.
3. Google Workspace: separate Super Admin, password and 2SV recovery
For an administrator password problem, begin with Google’s administrator recovery instructions. Use the configured email/phone method if offered; otherwise follow the wizard’s available verification branch. Another Super Admin may reset the password. If automated recovery fails, the offered support-assisted route can require both domain and account-data ownership evidence.
A user who can sign in but cannot reach an administrator has a separate user-promotion process on that same official page. Google contacts existing administrators and evaluates the request; do not treat a DNS change as automatic promotion. If rights to the organization or its data are disputed, stop and resolve authorization through the provider’s process.
For a missing second factor, Google documents backup-code recovery. Only a Super Admin can generate codes for another administrator. The ordinary-user route requires the appropriate User management privilege and applicable account settings. If no Super Admin is available, return to administrator recovery. Use an already registered spare method or saved code where available; do not move the whole organization out of 2SV to repair one account.
SSO changes the diagnosis. Google’s Super Admin SSO documentation says direct sign-in at admin.google.com uses the full Google administrator address and Google password, rather than the external SSO credentials. Other sign-in paths and SSO profiles differ. This documented route still requires the applicable authentication controls; it is not a general bypass for ordinary users.
For a reseller-managed subscription, use the existing Google reseller. An authorized signed-in colleague can inspect Billing → Subscriptions; otherwise start with existing business records. Do not purchase a direct subscription to try to gain control of the reseller-managed organization.
4. Zoho Mail: a Super Admin needs a different route
Zoho separates user, administrator and Super Admin password recovery. An authorized administrator can reset an ordinary user’s password in Users → Security → Change Password. Another administrator can help an administrator account, but cannot reset the Super Admin password. The Super Admin must use the official Forgot Password options or the applicable recovery process.
Zoho’s verified-domain route is for organization administrators, not ordinary or personal users. Follow the generated verification instructions for a domain already associated with the organization. Crucially, an account with MFA enabled must still complete that factor before changing the password. Domain verification does not cure a missing MFA device.
Try a previously configured alternative or a saved Zoho backup verification code. Each code works once; a new set invalidates unused old codes. You need the permitted account access to generate replacements, so “create new codes” is not a solution for someone already fully locked out.
For an ordinary user who lost their factor, Zoho documents an authorized administrator’s Users → Security settings → TFA → Reset TFA action, with administrator reauthentication. Confirm the target and reenrollment plan first. Do not apply that user procedure to the Super Admin or disable organization-wide MFA.
With Zoho SAML sign-in, organization users authenticate through their identity provider. Involve its responsible administrator when that step fails. For an inaccessible former administrator, follow Zoho’s ownership-recovery process, which has role-specific notifications and evidence requirements. Competing ownership claims can become an internal dispute; neither a consultant nor this guide can promise a transfer.
5. Microsoft 365: check the role and identity source
Follow Microsoft’s work-account recovery route using the configured methods offered for that account. Work/school recovery differs from a personal Microsoft account. If another administrator is available, verify their authority for the affected account before requesting a reset.
Entra’s role reference gives Authentication Administrator a limited target scope. Privileged Authentication Administrator can manage authentication methods for any user, including a Global Administrator. Do not assume an ordinary helpdesk or user-administrator role can recover the highest-privilege account.
In Users → Authentication methods, Reset password, Require re-register MFA and Revoke sessions are separate actions. Reregistration affects existing factors and requires a viable reenrollment path; session revocation forces reauthentication. Choose the documented action needed for the identified failure, rather than applying all three without considering legitimate access.
For hybrid, federated or external accounts, check the password’s source of authority. A cloud reset cannot universally change an external identity or an on-premises federated password. The identity administrator must use the route supported by that configuration.
If no authorized recovery path remains, use Microsoft’s official business support instructions. If all subscriptions were bought through a partner, contact that existing partner. Obtain current regional contact details from Microsoft’s linked directory. Do not create a trial tenant, buy a new license or rely on an unofficial “MFA bypass” service as a way into the existing organization.
What to do when verification fails
If the official recovery flow requests a DNS challenge, have the authorized DNS operator add only the exact verification record supplied for that case. Check the hostname, value and authoritative DNS provider, then follow the flow’s verification guidance. The registrar and active DNS host can be different; repeated edits in the wrong dashboard will not help. Our domain-connection guide explains how to establish that responsibility.
Do not change MX, nameservers, SPF or the receiving mailbox service merely to prove control. Keep the current email delivery configuration intact. If you cannot access the required DNS account or the evidence is rejected, preserve the case reference and ask the official provider what legitimate route remains. Do not invent records, race through multiple ownership requests or assume a particular recovery deadline.
6. Verify recovery beyond the first successful login
Confirm that the correct account opens the correct organization and the intended administrative page. Then verify the recovered factor and current recovery contacts. A mailbox opening successfully does not demonstrate an administrative role; an administrator dashboard opening does not prove that old messages, sending or receiving are intact.
- Check the approved role and responsible business owner; avoid leaving temporary excessive privileges behind.
- Review recovery addresses, registered authentication methods and recent security changes. Remove unauthorized access through the product’s documented controls.
- If compromise is suspected, coordinate password replacement, session revocation and review of integrations or app-specific credentials. Check their scope; these are not interchangeable actions.
- Use controlled messages to verify sending, receiving and replies for the affected mailbox, then check important aliases and required clients. Do not change delivery DNS to solve an authentication-only problem.
- Record the observed checks and open issues before closing the support case. Keep the recovered service and billing active until any separate migration is deliberately planned.
Zoho’s domain-recovery page distinguishes browser/app sessions and API tokens during suspected compromise. Its TFA documentation also treats app-specific passwords separately. Do not assume a single browser logout revokes every integration.
Reduce the chance of the same lockout
After recovery, document who controls the subscription, domain and recovery contacts, using our business account-control checklist. Maintain role-appropriate backup administration, tested recovery methods and securely stored codes or spare authenticators. Review them when staff, agencies or devices change.
For Microsoft Entra, current emergency-access guidance recommends two or more cloud-only emergency accounts, protected with suitable phishing-resistant authentication that meets mandatory MFA, with restricted use, monitoring and regular checks. Have the responsible administrator follow the complete guidance. Simply excluding every administrator from MFA is not a recovery plan.
Keep a private recovery handover
Copy these deliberately unfilled fields into a private case note. This is a template, not an account recovery we performed. Reference secure evidence storage rather than pasting passwords, codes, reset links or customer messages.
- Provider, organization and affected sign-in identity: [account reference]
- Observed failure and time/timezone: [password, factor, SSO or role; exact error]
- Authorization and helper’s role: [responsible owner; verified permission]
- Recovery route and official case reference: [method; private case ID]
- Changed access and verification results: [actions; observed checks; remaining limits]
- Next action and owner: [open requirement; responsible person; review time]
Recover first; compare services for a separate decision
Use the existing provider and included support where they can meet the recovery need. Pay for qualified administration only when there is a clear skill or responsibility gap, and grant scoped, revocable access through a secure channel. Nobody’s fee can guarantee that the provider will accept an ownership claim.
If a later change of service is justified, compare Workspace and Zoho for your team’s actual requirements and the complete mailbox budget. Follow a planned mailbox migration after establishing authorized access to the data you need. Switching providers is a separate project, not a shortcut around account recovery.
Sources and verification
Editorial review 2026-10-10. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Google Workspace: Recovering administrator accessChecked Automated recovery precedes supported assistance; an unavailable administrator has a separate user-promotion route with verification and contact of existing administrators.
Limits: Recovery eligibility and ownership are provider decisions; no account, DNS record or support request was exercised. - Google Workspace: Account recovery information for supportChecked Support may request account-creation, payment and recovery information to establish ownership.
Limits: Only submit requested evidence through the verified official process; a payment record alone is not an access guarantee. - Google Workspace: Recover an account protected by 2-Step VerificationChecked Only Super Admins generate another administrator’s backup codes; ordinary-user recovery needs the documented user-management privilege and applicable settings.
Limits: Recovery-code availability depends on policy; do not generalize ordinary-user permissions to administrator accounts or relax organization-wide 2SV. - Google Workspace: Super administrator SSOChecked Direct Admin console sign-in for Super Admins uses the Google account credentials; SSO behavior differs by profile and route.
Limits: This is not permission to disable SSO or MFA; the organization’s actual identity configuration was not inspected. - Google Workspace: Contact your Google resellerChecked An existing reseller can assist with access, accounts, domain settings and billing; a signed-in authorized billing administrator can identify the reseller in Subscriptions.
Limits: The locked-out person may not be able to open Billing; existing invoices and contracts are alternative identification records, not authentication bypasses. - Zoho Mail: Password resetChecked Users, administrators and Super Admins have different password-reset routes; another administrator cannot reset the Super Admin password.
Limits: The English official search extract was inspected from an older cache; the direct default page redirected to a Dutch localization. A current direct English opening was not established. The English Zoho Accounts domain-recovery page separately corroborates domain verification and MFA. - Zoho Accounts: Reset a password using a verified domainChecked Organization-admin domain recovery adds the generated verification record and still requires the enabled MFA method; record values and active DNS provider matter.
Limits: This route is not for ordinary or personal users and does not bypass unavailable MFA or resolve an ownership dispute. - Zoho Accounts: Backup verification codesChecked Previously saved codes are one-use; generating a new set invalidates unused old codes and may be restricted by organization policy.
Limits: A locked-out user cannot assume that they can generate a new set without account access. - Zoho Mail: Two-factor authenticationChecked The documented individual-user Reset TFA action requires administrator reauthentication; app-specific passwords are separately revocable.
Limits: The page contains inconsistent enable/disable wording; this guide uses the explicit user-reset procedure only and does not generalize it to Super Admin recovery. - Zoho Accounts: Sign in using SAML-based SSOChecked SAML sign-in uses the configured identity provider and its credentials for organization users.
Limits: A Zoho password reset is not presented as repairing the external identity provider; actual SSO exceptions require the responsible administrator. - Zoho: Account recovery processChecked Ownership recovery has role-specific notification and evidence requirements and can become an internal access dispute.
Limits: Not an automatic transfer; the relevant service, existing agreement and requested evidence determine the procedure. - Microsoft: Forgotten Microsoft 365 sign-in passwordChecked Work/school and personal Microsoft accounts have different recovery routes; configured self-service recovery, another administrator and official support are separate options.
Limits: A password reset is not a guarantee of MFA recovery, account eligibility or administrative access. - Microsoft Entra: Built-in rolesChecked Authentication Administrator has a limited target scope; Privileged Authentication Administrator can manage authentication methods for all users, including Global Administrators.
Limits: The existence of a role does not establish that a particular helper holds it or is authorized to use it. - Microsoft Entra: Manage authentication methodsChecked Password reset, MFA reregistration and session revocation are distinct actions in Authentication methods with different consequences.
Limits: No commands or retired portal procedures are copied and no live methods or sessions were changed. - Microsoft Entra: Reset a user’s passwordChecked Password-reset authority depends on the home directory and identity source; synchronized and federated identities require their documented source-specific route.
Limits: Do not assume a cloud administrator can reset every external, federated or synchronized account. - Microsoft 365: Get support for businessChecked Business support has administrator/subscription requirements; partner-only subscriptions use the existing partner and current regional contact details come from Microsoft.
Limits: No support deadline, internal escalation or recovery outcome is promised; creating a new trial tenant is not a recovery step. - Microsoft Entra: Manage emergency access accountsChecked Microsoft recommends two or more cloud-only emergency accounts with phishing-resistant authentication satisfying mandatory MFA, restricted use, testing and monitoring.
Limits: Prevention after recovery, not an instruction to create inaccessible emergency accounts during lockout or disable organization-wide MFA.