Blog · Deliverability
How to Change Your Google Workspace Primary Domain (And Fix Common Blockers)
Introduction
When a company rebrands or consolidates its email infrastructure, one of the first tasks is updating the Google Workspace primary domain. The Admin console makes it sound straightforward: go to Account > Domain > Manage Domains > Change Primary. In practice, many admins hit a wall. The console displays a generic error that does not say which blocker is actually active.
This guide walks through every common blocker Google checks before allowing a primary domain change, how to diagnose which one is active, and how to resolve it. Work through it as a checklist: start at the top, stop when the change goes through.
Before You Start
Two prerequisites must be in place before attempting the domain change:
Verify domain ownership. The new primary domain must already be added to the organization and verified in the Admin console. If DNS verification is not yet complete, Google blocks the change before checking anything else.
Confirm you have the right admin privileges. The Super Admin role is required. Domain management privileges alone are not sufficient.
With those confirmed, attempt the domain change and watch which blocker the console flags. If the error message does not specify, use the checklist below to test each item in order.
The Common Blockers and How to Diagnose Them
Google checks several conditions when you attempt to change the primary domain. The error message tells you a blocker exists but not which one. Work through these in order.
User accounts still on the old domain
What to check: Go to Users and look for any account with the old domain in the primary email address. This includes suspended accounts.
How to resolve: Migrate each affected user to the new domain. If a user account is no longer needed, delete it instead of migrating.
Shared drives owned by users on the old domain
What to check: In Google Drive, go to Shared drives. Look for any drive where the owner has an email address using the old domain.
How to resolve: Transfer ownership of each affected shared drive to a user on the new domain through Drive sharing settings.
Google Groups with old domain addresses
What to check: Go to Groups and look for any group whose email address uses the old domain, including group owners and managers.
How to resolve: Either delete the group or change its address to the new domain before attempting the primary domain change.
Calendar resources with old domain in the resource name
What to check: In the Admin console, go to Buildings and Resources. Look for any resource whose name or email address contains the old domain.
How to resolve: Update the resource name and email address to use the new domain. If the domain change has already started, you may need to re-create the resource.
Marketplace app assignments tied to old domain
What to check: Go to Apps > Google Workspace Marketplace apps. Look for any app configured for or assigned specifically to the old domain.
How to resolve: Update app assignments and domain-specific configurations to point to the new domain. Uninstall and reinstall the app if no domain-specific option is available.
Data migration jobs referencing old domain
What to check: In the Admin console, go to Data migration. Look for any active or recently completed migration job that uses the old domain as a source or destination.
How to resolve: Cancel or complete any pending migration jobs. If the job is finished, try deleting its record from the migration console.
SSO or SAML app references to old domain
What to check: Go to Apps > Web and mobile apps. Look for any app configured with an ACS URL, Entity ID, or SSO URL that references the old domain.
How to resolve: Update the IdP configuration to use the new domain. If the app does not support changing the domain, delete and recreate the app entry with updated settings.
Billing account tied to the old domain
What to check: Go to Billing > Manage billing. Google ties billing accounts to a domain at creation time. If your subscription is still registered to the old domain, the change will be blocked.
How to resolve: Contact Google Workspace support through Billing > Manage billing > Contact us. This is the one blocker that cannot be resolved through the Admin console alone.
Domain claimed as primary in another Google organization
What to check: If your organization was created through a reseller or has domain configurations in a separate Google Cloud organization, the domain may already be claimed as primary elsewhere.
How to resolve: Contact Google Workspace support. Untangling domain ownership across organizations requires direct intervention. In some cases, a new Workspace organization with the correct primary domain is the cleanest path.
Step-by-Step Resolution Order
Work through the blockers in this order to avoid repeating steps:
1. User accounts (most common, check first)
2. Shared drives
3. Google Groups
4. Calendar resources
5. Marketplace app assignments
6. Data migration jobs
7. SSO and SAML configurations
8. Billing account (may need Google support)
9. Cross-organization domain conflicts
After each blocker is resolved, return to Account > Domain > Manage Domains and attempt the change again. The console will either proceed or show the next blocker.
After the Change Goes Through
Once the primary domain change is accepted, several follow-up tasks need attention.
Notify users. Google account email addresses have changed. Users will need to update saved credentials in third-party apps and re-authenticate.
Update OAuth scopes. Any application using Google OAuth with the old domain as a scope parameter needs to be updated to reflect the new domain.
Update DNS records. This step is easy to overlook but matters for email delivery. If you are removing the old domain entirely, update your DNS: remove or repurpose the old domain's SPF, DKIM, and DMARC records. If the old domain is being retired from mail sending, set its DMARC policy to reject and stop its rua reporting. If you keep the old domain as a secondary, existing authentication records still apply.
During this DNS cleanup, DMARCFlow can help aggregate reports from both domains and flag any authentication failures that appear after the transition. It is a practical way to catch misconfigured records before they cause deliverability problems.
Review admin roles. Super Admin accounts tied to the old domain email address may need to be updated to avoid lockout.
Audit third-party integrations. Any SaaS tool configured to send mail through the old domain SMTP settings needs to be updated.
FAQ
How long does the primary domain change take?
The change itself processes immediately once all blockers are resolved. The follow-up work - notifying users, updating integrations, cleaning up DNS - takes the most time. Budget a few hours to a full day for the complete process.
Can I change the primary domain without migrating all users first?
No. Google requires all user accounts to be on the new domain before accepting the primary domain change. There is no partial state.
What happens to email sent to the old domain after the change?
If the old domain is removed from the organization, mail sent to addresses at that domain will bounce. If the old domain is kept as a secondary, mail continues to flow normally. Decide this before completing the change.
Do I need a new Google Workspace subscription when changing the primary domain?
No. Your existing subscription covers the organization, not a specific domain. You can change the primary domain without changing your subscription tier or billing cycle.
Who do I contact if the billing account is blocking the domain change?
Google Workspace billing support. Contact them through Billing > Manage billing > Contact us in the Admin console. This is the one blocker that requires direct support intervention.
Summary
Changing your Google Workspace primary domain requires clearing every reference to the old domain across users, drives, groups, apps, and configurations. The Admin console error does not tell you which blocker is active. Work through the checklist in order, resolving each item before re-attempting the change. After the change succeeds, update DNS records, notify users, and audit third-party integrations that reference the old domain. Pay particular attention to DMARC and SPF records if the old domain is being retired from mail sending.