If nobody can sign in to your Google Workspace Admin console, you are not locked out of an app, you are locked out of your company’s identity system. Every path back in ends at the same question: can you prove, to Google’s satisfaction, that you control the domain name. Some of these recoveries take an afternoon, some take weeks, and a small number never succeed at all.
A super administrator is the Google Workspace role that can reset any password, assign admin roles, and change any setting in the Admin console. Losing every super admin account means losing administrative control of your email, your files and your user accounts, even though the service itself keeps running normally for staff.
Work out which lockout you actually have before you touch anything
The recovery paths are different and the wrong one wastes days. Find yourself in this list first.
You forgot the password and your recovery email and phone still work. This is the easy case. Fix it in ten minutes with the standard recovery wizard.
You know the password but 2-Step Verification is blocking you. The phone is gone, the security key is lost, or nobody printed backup codes. Different path, and slower.
The super admin has left, been dismissed, gone quiet or died. The account may still exist and still be the only super admin. This is the most common serious case in small businesses.
Nobody knows who the super admin is. Often it turns out to be a generic address like info@ or admin@ that nobody has opened in years, or a personal Gmail address used during signup.
The account is suspended. Usually billing, occasionally a policy or abuse action. Recovery is a payment or a support case, not a DNS record.
A contractor, web developer or hosting company set the domain up. They own the Workspace signup, or the domain registration, or both. This is the case that most often fails, because two separate ownership problems have to be solved in the right order.
Being honest about which one you are in is the whole job. Everything below assumes you have picked correctly.
Try the self-service paths in Google’s order, because support will ask if you did
Google’s published position is that support-assisted recovery is only available after you have been through the automated flow. Do not skip it.
1. Ask another super admin. Any other super administrator can reset your password from the Admin console in under a minute. This is the reason Google’s own security guidance says every organisation should have more than one super admin account, each held by a different person. If you have a second one, stop reading and go use it.
2. Standard password recovery. Go to accounts.google.com/signin/recovery, enter the admin address, click Next and then Try another way. If a recovery email or phone number is attached to the account, Google sends a verification code and you reset the password. If you have forgotten the address itself, use Forgot email? and supply the recovery email or phone plus the full name on the account.
3. Check whether self-recovery is even switched on. This is the step almost every guide misses. Super admin account self-recovery is a setting an organisation can turn off, and if it is off, the Forgot password? link tells super admins to contact their administrator rather than offering a code. The control lives in the Admin console at Security, then Authentication, then Account recovery. Google documents the default as off for a list of editions including Business Plus, Frontline Standard, Enterprise Essentials Plus, Education Standard and Plus, G Suite Basic and Cloud Identity Premium, and on for the others. Google’s admin security best practices page states it differently again, that recovery is off by default for most current and all new customers, with existing customers under three super admins or 500 users defaulting to on. If you can still get in, check yours now rather than trusting either summary.
4. Backup codes and a spare security key. If 2-Step Verification is the blocker and the account has printed backup codes or a second enrolled security key, that is your way through. If it does not, note that Google is progressively enforcing 2SV on administrator accounts, so this failure mode is becoming more common, not less.
If none of that works, you are into domain proof.
Proving you own the domain is what actually decides most of these cases
Google’s fallback is not a phone call and not a photo of a driver’s licence. It is a DNS record you place at your domain host, because control of the domain is the only ownership signal Google can verify without a human judgement call.
There are two flows and they use different record types. Most guides conflate them.
The automated wizard asks for a CNAME record. Working through accounts.google.com/signin/recovery and clicking Try another way repeatedly eventually offers domain verification. Google gives you a CNAME record to add at your DNS host. Wait a few minutes, click Next, and if Google finds the record you get straight to a Create Password screen. If it does not find the record immediately, you supply a contact email address that is not the locked account, receive a verification code, and Google emails a password reset link once the record is confirmed. Google’s documented cut-off is that if the CNAME is not found within 48 hours, you get an email telling you the recovery failed and you start again.
The support-assisted flow accepts a CNAME or a TXT record. If the automated wizard cannot resolve it, it may offer Contact support, which sends you to the Apps Admin Toolbox at toolbox.googleapps.com/apps/recovery/form. You give a contact email address that is not the locked account, Google issues a support reference number, and you add either a CNAME built from that reference number or a TXT record at your domain host. Then you click Check Again, select Request for Password Reset, and submit. Google’s documentation says DNS changes can take up to 24 hours to propagate and gives you two toolbox.googleapps.com/apps/dig lookups to confirm the record is visible before you resubmit.
Use those lookups. A large share of failed recoveries are not identity failures, they are a record placed on the wrong zone: added at the registrar when DNS is actually hosted somewhere else, added to a redirect service, or added with the domain name accidentally doubled on the end of the hostname. Google’s own note is explicit that if your hosting provider is separate from your registrar, you must change the record with the provider that is actually answering for the zone.
Then Google asks the account history questions. Expect to be asked the date the Workspace account was created, the original secondary or recovery email address used at signup, the Google order number if there is one, how many user accounts were created, the billing address, and the card type and last four digits. Google states you do not have to answer every question correctly. You do have to answer enough of them, and the answers a departed admin took with them are usually the signup email address and the creation date. Search old email for a welcome message from [email protected] and pull the oldest Google charge off the company card statement before you start the form.
The only elapsed times Google commits to are the ones inside the DNS steps. On the automated flow you have 48 hours for the CNAME to be found, after which Google emails you to say the recovery was unsuccessful and you begin again. On the support-assisted flow Google allows up to 24 hours for the record to propagate before you click Check Again. Past the point where you press Submit Request, Google publishes no timeframe at all. Its documentation says only that the support team will contact you for next steps, and that in some cases you may need to provide additional verification so that access is granted to the rightful owner.
What governs how quickly a human picks the case up is your support tier rather than the recovery flow, and the tiers are set out further down. Plan against the documented floor, not against a promise, and get the DNS record right the first time, because a failed check restarts the whole sequence.
If you are a user and there is no reachable admin at all, you can be promoted
There is a separate path most people never find. A normal user account can be promoted to super administrator with proof of domain ownership, using the same Apps Admin Toolbox form.
You sign in to your own working Google account first, because only active accounts can be promoted. Then enter the domain at toolbox.googleapps.com/apps/recovery/form, click Lookup Recovery Options, choose I am a user and cannot contact my administrator, add the CNAME or TXT record, and submit Request User Promotion.
The important detail: Google then contacts the existing administrators. If they are inactive and unresponsive, Google promotes your account. If they respond, you are offered the option of having Google pass your contact details to them instead. So this path works when an admin has genuinely vanished, and does not work as a way around an admin who simply disagrees with you.
When the registrar login is gone too
This is where recoveries stall. You cannot add a DNS record if you cannot sign in to the registrar or the DNS host, and the person who could is the same person who has gone.
Work in this order.
Find out who actually answers for the domain, rather than who you think does. A public WHOIS lookup gives you the registrar of record. A nameserver lookup gives you the DNS host, which is frequently a different company: the domain sits at one registrar while the zone is served by a web host, a CDN or a previous IT provider.
Then run the registrar’s own account recovery against the registrant email address on the record. If that address is inside the locked Workspace tenancy, you have a circular dependency and you need to break it at the registrar, not at Google.
For a .com.au name, the auDA rules work in your favour more than most people expect. The .au Domain Administration Rules state that a licence confers no proprietary rights in a domain name: a registrant holds a licence to use the name for a period and does not legally own it. Eligibility for com.au requires both an Australian Presence and a Commercial Entity, and auDA’s definitions include a company registered under the Corporations Act 2001 and any entity issued with an ABN. The name itself must be a match or an acronym of the registrant’s company, business, statutory or personal name, or a match or synonym of goods or services that the registrant actually provides. If your business is the genuine registrant, that list is also the evidence pack: ABN, company extract, business name registration, invoice history.
Ask for the authorisation code by name. auDA requires a valid authorisation code from the registrant for a transfer between registrars, and requires the registrar to release it in writing only to the registrant contact recorded in the registry data, unless the registrant has authorised in writing that it go to a third party. That ordering matters. Getting the registrant contact corrected comes before asking for the code, not after.
If the registrar will not act, there is a defined complaints path rather than a dead end. auDA’s rules require the complaint to go to the registrar of record first, give that registrar 30 calendar days to resolve it, and require written reasons plus notice of your right of appeal to auDA for review. It is slow. It is also a real lever, and registrars behave differently once you cite it.
The other lever is the paying party. Whoever’s card is on the domain renewal has standing to ask the registrar to correct the account.
Google’s clock is not the Australian problem here. Google’s published hours of operation table lists Australia as 24/7 in English, the same as the United States and the United Kingdom. There is no overnight window in which nobody is available to take the case. The delays in Australian recoveries come from the registrar side, not from Google’s support hours.
When a third party registered the domain in their own name
If a web developer or agency registered the domain as themselves rather than as your business, you have a commercial problem wearing a technical hat. Google will accept a DNS record from whoever controls the zone, and right now that is not you.
The realistic options are to get the third party to add the record on your behalf, to get the domain transferred into your own registrar account, or to pursue it as a contractual matter. None of those are quick, and the technical recovery cannot start until one of them lands.
If the business is still trading and simply unresponsive, a written request naming the specific record to add, with a deadline, resolves it more often than people expect. If the business has wound up, the registrar becomes the only route.
auDA’s rules are clearer on this than most web development contracts are. A person may use an agent to make a licence application. That agent warrants to the registrar and to auDA that it has the authority to bind the person it is acting for, and the rules require the agent to ensure that the person on whose behalf they are applying is recorded as the registrant in the registry data. A developer who put their own company in that field did not follow the rules. Quote that when you write to them, because it changes the conversation from a favour you are asking for into an obligation they already had.
The correction path exists, and it closes fast. auDA allows a registrant to ask a registrar to correct registrant information, and the listed grounds include a licence incorrectly registered by the registrar in the name of the reseller or other agent who arranged the registration. The catch is in the next rule: the request must be made within 14 calendar days of the licence being recorded in the registry data. Three years after a website build, that route is shut and you are into a change of registrant instead.
A change of registrant is a transfer, not an edit. auDA requires the transfer request in writing from the current registrant to the registrar, requires the incoming party to satisfy the Australian Presence and the namespace eligibility criteria at the date of transfer, to enter a new licence agreement and pay a new licence fee, and requires the registrar to complete the transfer within two calendar days of the request. Read that list again and note where the friction actually sits. Everything except the first line is mechanical. The whole thing turns on the departed developer signing a written request.
Escalation: what Google support can and cannot do for you
Google Workspace support is real, staffed and reachable, and it is also narrower than most people assume.
You need an admin account to raise a case. Contacting support requires the Support administrator privilege and access to the Admin console. That is the trap: the people who most need support are the ones who cannot get in to ask for it. That is exactly why the Apps Admin Toolbox login issues form exists as an unauthenticated channel.
Support tiers change response speed, not eligibility. Google publishes three offerings. Standard Support is included with a Workspace licence, has 24/7 access, and carries a four hour service level objective for P1 cases. Enhanced Support accelerates that to one hour for P1 and adds commercially reasonable help with third-party applications. Premium Support carries a fifteen minute P1 objective, designated technical advisors and a Technical Account Manager. Cases are prioritised P1 to P4, where P1 is a critical service access issue affecting more than one user with no workaround, and Google’s stated commitment is an initial response within one business day or less.
Note what that does not say. A faster tier gets you a human sooner. It does not remove the domain ownership requirement, and it does not let an agent hand over a super admin account because you sound convincing.
If you bought Workspace through a reseller, Google will send you back to them. This is stated plainly in Google’s own troubleshooting documentation, along with links to reseller-specific reset instructions for Wix, Squarespace, Weebly, Automattic, Namecheap, Bluehost, Domain.com, HostGator and iPage. If your Workspace came bundled with a website build or a hosting plan, check this before anything else. Your reseller set the account up and can usually reset the password directly.
What a reseller or a support partner can actually do, according to Google’s own documentation. There are two distinct arrangements and Google documents both. If a reseller manages your subscription, Google states the reseller can access your Admin console, submit support cases and provide other services for you unless you remove that access, and Google’s stated recommendation is to leave the access on so they can troubleshoot for you. Separately, any Workspace customer can assign a Support Partner in the Google Cloud Support Portal, and Google’s wording is that while assigned, the partner can file cases on your behalf and access cases you filed yourself.
Two things follow. Both arrangements are switches inside your own account, under Account then Reseller management in the Admin console, or under Support Partners in the Support Portal. And both require a working admin sign-in to set up, which means neither is something you can arrange after you are already locked out. Turn on the one you want while you can still get in.
What that buys you is a second party who can open and chase the case while you are dealing with the registrar. It does not change the evidence Google requires. The domain proof is identical, the account history questions are identical, and nobody at Google or at a partner can release a super admin account without them.
TechAssist is listed in Google Cloud’s partner directory and we take that second-party role for clients, which means the case gets opened and chased by someone who has run the flow before rather than by an owner reading the form for the first time. It buys you competence and persistence on the process, not a shortcut through it.
Have this ready before you open the case. The domain name. The exact admin address you are trying to recover. Evidence of the signup: the original welcome email, the creation date, the secondary email address used. Billing evidence: the card type and last four digits, the billing address, the Google order number, and the date of the most recent payment. Registrar and DNS host details, with proof you can edit the zone. A contact email address that is outside the locked domain. Assembling this first is the difference between one exchange and five.
Two lockouts that look like this but are not
A suspended account is a billing or policy problem. If you can reach the Admin console but the service is suspended, or if sign-in reports the account is not using Google Workspace, no amount of DNS proof helps. Check the payment method and the billing contact first. Google’s documentation is blunt that if a Workspace or Cloud Identity account has been deleted rather than suspended, the data is not recoverable, and re-signing up the domain 24 hours later gives you a new empty tenancy.
A Context-Aware Access rule can lock every admin out at once. If an access level was applied to the Admin console itself and the conditions can no longer be met, for example a device or IP requirement that no longer exists, you have a total lockout that no password will fix. Google’s documented remedy is to contact support through the Customer Care Portal, and support will remove all Context-Aware Access policies applied to the Admin console. Policies on other apps are untouched. Google is equally clear that the policies must be reapplied immediately after access is restored.
Be honest about the odds
Some of these recoveries simply fail. The pattern is consistent: the further the domain is from your control, the worse the outcome. If you can edit DNS, you will almost certainly get back in eventually. If you cannot edit DNS and cannot recover the registrar account, there is no Google process that fixes that, because from Google’s side you are indistinguishable from an attacker.
The realistic worst case is not that you never recover the tenancy. It is that recovering it costs more elapsed time than the business can absorb, and someone makes the call to stand up a new tenancy on a new domain and accept the data loss. That decision is much easier to make on day three than on day twenty.
There is one structural failure point rather than a list of them, and Google’s documentation makes it obvious. The automated wizard, the support-assisted form and the user promotion path all terminate at the same requirement: a record placed in the zone that answers for your domain. Google offers no documented alternative to it. Whoever can edit the zone completes a recovery. Whoever cannot does not, however obviously they are the rightful owner. Everything worth doing in advance is really about making sure that person is you.
Making sure this never happens again
Every item here takes minutes while you have access and is impossible once you do not.
Run at least two super admin accounts, held by two different people. Google’s own guidance says so. One is a single point of failure attached to a human being who can resign, get sick or lose a phone.
Create a break-glass account. A dedicated super admin account that belongs to the business rather than to a person, not used for daily work, with a long unique password and its own 2-Step Verification enrolment. Store the credentials and the printed backup codes somewhere physical and controlled. Google’s guidance to enrol a spare security key and to generate backup codes in advance exists precisely for this account.
Keep recovery information current and remove it when people leave. Google explicitly recommends stripping a super admin’s recovery phone and email the moment they are terminated, so they cannot recover their way back in. That cuts both ways: the recovery details on your remaining admin accounts need to point at people who still work there.
Separate admin duties from daily accounts. Google’s best practice is that each super admin has two accounts, one for super admin tasks and one for everyday email, and that routine administration is delegated to limited roles rather than super admin. Shared generic admin accounts also destroy your audit trail, because you cannot tell which person made which change. Store the credentials in a business password manager rather than a spreadsheet, and put multi-factor authentication on the manager itself.
Document the registrar, the DNS host and who pays for them. Written down, in your IT documentation, with the account holder named. This one item removes the single most common cause of failed recovery.
Check that the registrant on the domain is your legal entity, and hold the authorisation code. For a .com.au name, confirm the registrant recorded in the registry data is your company and not a developer, an agency or a staff member’s personal name. Ask your registrar for the authorisation code and store it with the rest of the break-glass material. auDA requires that code for any transfer between registrars, and it will not be handed to you at speed during a crisis.
Decide now whether a reseller or support partner should have access. If someone else is going to open the case on your behalf, the switch has to be on before the lockout, not after.
Record the signup facts while someone still remembers them. Creation date, original secondary email address, order number, billing contact. Those are the questions Google will ask, and they are trivial to capture now.
Turn on admin alerts and review the admin log. You want to know when a super admin role is granted, when recovery information changes, and when a new admin appears. Most of that is covered in the Admin console settings that carry real risk, and the wider programme is in hardening Google Workspace properly.
Understand what you would actually lose. Losing admin access and losing data are different problems with different answers. If the tenancy is unrecoverable, or if someone with access deletes at speed, Google’s retention windows are shorter than most owners assume. That argument is set out in Google is not backing up your Workspace data.
If you have just taken over a Workspace tenancy from a previous provider or a departed staff member, do all of the above in the first week. The full checklist is in inheriting a Google Workspace tenancy nobody documented, and if you are also running Macs and Windows machines alongside it, running Windows, Mac and Google in one business covers how the pieces fit together. Being a partner on the Apple, Microsoft and Google sides at once is unusual for a Melbourne provider, and it is the reason we can tell you which platform genuinely suits the business rather than the one we happen to sell.
If you are locked out right now, call us on 1300 028 324 and have your domain name, your registrar details and any old Google billing records in front of you. We will tell you within one conversation which recovery path applies and whether it is realistically going to work. You can also start at techassist.au/contact.
