If you’re still using [email protected] or [email protected] for business, or you’re setting up a new business and want [email protected] from the start, Google Workspace is the standard way to get there. The setup itself isn’t hard — but the order you do things in matters more than most guides make clear, and getting it wrong is how people end up with “domain verified but no email arriving,” or a working setup that quietly loses a week of messages during the switch.
This is the order I actually use with clients, including the one step most guides skip: what to do differently if you already have email somewhere else.
First — Are You Starting Fresh, or Moving Existing Email?
This changes the order of everything that follows, so it’s worth answering before you touch any DNS settings:
Starting fresh (no real email on this domain yet, or you’re fine losing what’s there) — go straight through the steps below in order.
Moving existing email (cPanel, Zoho, an old host, anything with real messages in it) — don’t touch MX records yet. Migrate the existing mail into Workspace first, confirm it’s all there, and only then switch MX. Doing it the other way around is how people lose email mid-switch.
If you’re not sure which situation you’re in, or your domain shows a “this domain is already in use” error before you even get this far, that’s a different, more careful process — see the domain already in use guide rather than proceeding below.
Verify Domain Ownership
Google needs proof you actually own the domain before it’ll activate email on it. You’ll be given a TXT verification record to add to your DNS — something like google-site-verification=xxxxxxxx.
Where this trips people up: your domain registrar (where you bought the domain — GoDaddy, Namecheap, BigRock) and your DNS provider (wherever your nameservers actually point — which might be your hosting company, or Cloudflare) aren’t always the same place. Add the record wherever your nameservers point, not automatically at the registrar. If you’re not sure which that is, check your domain’s nameserver settings first.
Verification usually takes 10–30 minutes to reflect, though DNS changes can occasionally take longer.
If You Have Existing Email, Migrate It Now
Skip this step if you’re starting fresh.
If you’re moving off cPanel, Zoho, an old host, or anywhere else, use Google’s built-in data migration tool (in the Admin Console) or an IMAP-based migration, and confirm everything’s actually arrived in the new Workspace inbox before doing anything else. Keep the old mail service active in parallel for a day or two after — it catches anything still in transit during the switch.
Point MX Records to Google
This is the step that actually routes incoming email to Google. Current setup:
| Field | Value |
| Type | MX |
| Host | @ (or blank — the root of your domain) |
| Priority | 1 |
| Value | smtp.google.com |
That’s the full configuration for a new setup — one record, not several. Remove any old MX records from a previous provider so there’s nothing conflicting.
(If you’re working on a domain that’s had Google Workspace since before 2023, you may see the older 5-record setup instead — ASPMX.L.GOOGLE.COM plus four ALT records. That’s still supported and doesn’t need to be changed if it’s already working; it’s just not what a brand-new setup should use.)
Propagation is usually a few hours, occasionally longer — check with a DNS lookup tool if you want to confirm it’s live before testing.
Set Up Email Authentication (SPF, DKIM, DMARC)
This is what keeps your email out of spam — worth doing properly at setup, not as an afterthought later:
- SPF confirms which servers are allowed to send mail for your domain. Add this as a TXT record on your domain: v=spf1 include:_spf.google.com ~all — this is Google’s standard SPF entry and doesn’t change per domain (unless you also send from other tools — see below).
- DKIM is generated and activated inside the Admin Console (Apps → Gmail → Authenticate Email), then added as a DNS record. This one’s genuinely per-domain — there’s no generic value to copy; it has to be generated for your specific domain.
- DMARC is optional at this stage but worth having in monitoring mode from the start, then tightened gradually once SPF and DKIM are confirmed working. A DMARC policy set too strictly too early can cause legitimate email to bounce — this is worth doing carefully rather than copying a record from a blog post.
If you plan to send from third-party tools alongside Workspace (a CRM, a marketing platform), this is also the point to account for those in your SPF record — trying to add them later is a common source of deliverability problems.
Create Users and Test Before Going Live
Add your team in the Admin Console (Directory → Users), and use aliases (like info@ or support@) instead of separate paid accounts where you just need mail routed to one inbox.
Before turning off anything old: send test emails both ways (to and from Gmail, and to and from an address outside Google — Outlook works well for this), and confirm they land in the inbox, not spam, and that authentication is actually passing — not just that mail arrived. A message can land in the inbox during testing and still have an SPF or DKIM problem that shows up later at scale. Only disable the old email service once that’s confirmed.
A Few Things Worth Knowing Before You Start
- Screenshot your existing DNS records before changing anything. If something needs to be reverted, you want to know exactly what was there.
- If you’re using Cloudflare, make sure the MX record isn’t proxied (the “orange cloud” needs to be off for mail records — it needs to resolve directly).
- DNS changes can take longer than expected. Give it a full day before assuming something’s wrong.
The Mistakes That Actually Cause Problems
In rough order of how often I see them:
- Editing DNS in the wrong place — registrar instead of wherever DNS is actually managed
- Switching MX before existing email is migrated — the single most common way people lose email during setup
- Mixing old and new MX configurations instead of fully replacing one with the other
- Leaving Cloudflare’s proxy (“orange cloud”) on for the MX record — mail records need to resolve directly
- Skipping SPF/DKIM entirely — the setup “works” (mail arrives) but new email quietly starts landing in spam within days
- Assuming DNS changes are instant — propagation can take anywhere from a few minutes to a couple of days depending on your provider; give it time before assuming something’s broken
FAQ
Do I need to migrate existing email, or can I just switch MX records?
If there’s real email in your current inbox that you want to keep, migrate it first — switching MX before migration means new mail starts arriving at Google while your old mail (and the tool to move it) is still sitting somewhere else. If you’re starting fresh, this step doesn’t apply to you.
How long does the whole process take?
For a straightforward setup with no existing email to migrate, often the same day. With migration involved, it depends on mailbox size — DNS propagation and mail transfer both take real time, not just clicks.
Will my website break if I change DNS for email?
Not if you’re only touching MX and the specific TXT/authentication records — those don’t affect your website’s A records or hosting. The risk is only if something gets changed in the wrong place, which is exactly why knowing where your nameservers actually point (Step 1) matters.
Do I need to switch from the old 5-record MX setup if it’s already working?
No. Both configurations are fully supported by Google. There’s no benefit to changing a working legacy setup — this only matters for new setups, where the single record is simpler and has fewer places to make a mistake.
I see a “domain already in use” message before I can even get this far — what now?
That’s a different situation from a standard setup, and needs to be handled carefully to avoid losing an existing account’s data. See the dedicated guide on that error rather than proceeding with the steps above.