Table of contents
The Workspace sign-up took five minutes. Then it asked you to “verify your domain”, and you have now spent two evenings in the DNS panel of Squarespace, GoDaddy or Wix, half the company’s mail goes to the old host, and Google says the domain is “already in use” by an account nobody remembers. This is one of the most common ways a Google Workspace setup gets stuck, and the reason is structural: the registrar, the DNS provider, the website host and Google can be four different companies, and each help centre describes only its own piece.
Below is the whole picture: which records exist, where they actually live, what each of the classic error messages means, and how to move mail without losing any. Checked against Google’s documentation on 9 September 2026.
First: find out who runs your DNS
The records described below live in the authoritative DNS zone for your domain. That is often the registrar, but not always: a domain bought at GoDaddy may have its DNS at Cloudflare or at the website host. Look up the domain’s NS records with any public DNS lookup tool; whoever those nameservers belong to is where you edit records. Everything else in this article assumes you have found that panel.
The five DNS records that matter
| Record | What it does | Value for Google Workspace |
|---|---|---|
| TXT (verification) | Proves to Google that you control the domain | google-site-verification=... from the Admin console. Can be removed after verification, but leaving it does no harm. |
| MX | Tells the world where your mail is delivered | One record: smtp.google.com, priority 1. The older set of five aspmx.l.google.com records still works; do not mix the two with your old host’s records. |
| TXT (SPF) | Lists who may send mail as your domain | v=spf1 include:_spf.google.com ~all, plus any other sender you use, in one record. |
| TXT (DKIM) | Cryptographic signature for mail from Gmail | Generated in Admin console, Apps, Gmail, Authenticate email. 2048-bit key at google._domainkey. |
| TXT (DMARC) | Tells receivers what to do with mail that fails the above | v=DMARC1; p=none; rua=mailto:... at _dmarc to start, then tighten. See our SPF, DKIM and DMARC guide. |
Everything else in the zone, including the A and CNAME records that point to your website host, is not touched by a Workspace setup. Setting up Gmail normally does not require changing nameservers; if you do decide to move DNS to another provider for other reasons, copy the whole zone first and check every record afterwards.
Where the records live: Squarespace, GoDaddy, Wix
Squarespace
Squarespace acquired Google Domains in 2023 and migrated most of those domains in 2024, so if you bought the domain through Google Domains, it is probably at Squarespace now (a smaller number went to other providers; check where yours is). DNS is under Settings, Domains, your domain, DNS settings. Squarespace offers an automatic “connect to Google Workspace” step that adds the MX records for you; check afterwards that the old host’s MX records were removed, because it does not always do that. If your Workspace subscription itself was bought through Google Domains, its billing moved with the domain, which matters for the “already in use” problem below.
GoDaddy
DNS is under My Products, Domains, DNS. When Google’s Admin console offers “sign in to GoDaddy to verify automatically”, that works and is the fastest path. The pitfall is an existing GoDaddy email product or Microsoft 365 subscription that still holds the MX records; the wizard adds Google’s records next to them and mail splits between two systems. Remove the old MX records only once you have confirmed nothing else depends on them.
Wix
If the domain is registered at Wix or connected to Wix through nameservers, DNS is under Domains, your domain, Manage DNS records. If the domain is only “pointed” to Wix from elsewhere, DNS is wherever the nameservers say it is, and Wix cannot edit it for you. Wix also sells Google Workspace mailboxes: the Google organisation is yours, but billing is managed by Wix. Moving that subscription to Google direct or to a partner is a billing transfer that goes through Wix support; your users and data stay where they are.
“This domain is already in use” and other error messages
Domain is already associated with another Google account
Somebody, at some point, created a Workspace trial or a Cloud Identity account using your domain. It could be a former employee, a web agency, or a mailbox bought years ago through GoDaddy, Wix or Google Domains. These are two different situations with two different fixes:
- The account exists and you want it back. Find out who set it up: ask former staff and agencies; check old invoices for “Google Workspace” or “G Suite” lines from a reseller. If a reseller bills it, the fix is a billing transfer to you or to your partner, not a new sign-up. If nobody has admin access any more, use Google’s admin account recovery form; proving domain control with a DNS record is part of that process, but Google decides case by case and it can take days. Do not create a second organisation in the meantime, because you will then have two.
- The account is a dead trial and you want the domain free. If you can get into it, delete the organisation from inside it (export anything useful first). If you cannot, Google’s “domain in use” flow lets you request that the unmanaged or abandoned account is released; expect a waiting period and a verification step. Google does not promise an outcome, and we have seen this take a few days and a few weeks.
Verification failed
The usual suspects, in the order we check them: the record was added at a DNS provider that is not the authoritative one (see the first section); the host field contains the domain name instead of @, so the record ends up at yourdomain.com.yourdomain.com; the value was pasted with a missing character; or you simply need to wait. Google says DNS changes can take up to 72 hours to be recognised, though most are visible within an hour. Check with an external DNS lookup tool before changing anything else.
Mail arrives at the old host, or only some mail arrives
Two sets of MX records are active and sending servers pick either. If you are moving to Google as your only mail server, remove the old host’s MX records. If you deliberately route mail through a security gateway or another system first, do not touch the MX records at all; that setup has its own rules and Google’s records belong in the gateway’s configuration, not in your DNS. Then check that the old host has no “email forwarding” still switched on for the domain.
Mail from Workspace lands in spam
Start with authentication: SPF, DKIM or DMARC is missing, or there are two SPF records (a common leftover from the previous host), which receivers treat as a failure. Merge them into one. If authentication passes and mail still lands in spam, the cause is elsewhere: sender reputation, content, a new domain, or the receiver’s own policy. Authentication is necessary, not sufficient.
The cut-over sequence that avoids lost mail
- Inventory the current mail flow: who sends as your domain (Gmail, CRM, invoicing, newsletter tool), whether a gateway sits in front, and what the DNS TTLs are. Lower the MX TTL a day before the switch.
- Create all users in Workspace first, with the same addresses as today. Set up aliases and groups.
- Verify the domain (TXT). Do not change MX yet. Prepare the SPF record with all legitimate senders, generate the DKIM key in the Admin console and publish it, and publish a DMARC record at
p=none, so authentication is ready before the first message leaves Gmail. - Migrate existing mail with Google’s data migration tools or the old host’s IMAP, while the old host still receives new mail.
- On a quiet evening, switch MX to Google and remove the old records (unless a gateway is meant to stay in front). Legitimate sending servers retry temporary failures for hours, which covers the propagation window; mail that was wrongly rejected or delivered to the old host is not recovered automatically, which is why the old mailbox stays alive for the next step.
- Send and receive test messages from external accounts, check the headers for SPF, DKIM and DMARC passes, and confirm the old host receives nothing new.
- Keep the old host alive until the acceptance checks pass and the team has confirmed nothing is missing, typically one to two weeks, then run a final migration of anything that arrived there late and close it.
Frequently asked questions
Do I have to move my domain to Google to use Google Workspace?
No. The domain stays at Squarespace, GoDaddy, Wix or any registrar. Workspace only needs a few DNS records added there.
Which MX record does Google Workspace use now?
A single record, smtp.google.com with priority 1. The five legacy aspmx.l.google.com records still work if you already have them; do not combine either set with another provider’s MX records.
How long does DNS take to update?
Usually minutes to an hour; Google’s documentation allows up to 72 hours. Check with an external lookup tool rather than by sending yourself test mail.
Related articles
- Why important emails never arrive: SPF, DKIM and DMARC in order
- Migrating from Microsoft 365 to Google Workspace: what to actually expect
- Google Workspace setup service
If the domain is stuck, the fastest fix is usually somebody who has seen the exact error before. We handle the verification, the billing transfer from a reseller and the cut-over as part of Google Workspace setup.
Not sure who controls your domain, DNS and Google billing? We map registrar, DNS host and Workspace organisation, then plan and test the changes. Book a free 30-minute audit or call +371 22 30 50 90.
