DEV Community

Cover image for How to Set Up Google Workspace Email for Multiple Domains Using Cloudflare
Kamil Buksakowski
Kamil Buksakowski

Posted on

How to Set Up Google Workspace Email for Multiple Domains Using Cloudflare

#googleworkspace #saas #dns

I was setting up yet another project and ran into a deceptively simple question: how do I handle email so it looks professional, lets me write as a brand, stays manageable, and does not require paying for a separate Google Workspace user for every address?

Sounds simple, but I ended up learning it the hard way because I had never properly set this up before. One detail is especially easy to miss: if you previously enabled Cloudflare Email Routing on the domain, it can conflict with Google Workspace MX records. Email will not work correctly until you disable it. I cover that in the relevant step.

This tutorial shows the exact setup: one Google Workspace account, multiple domains, multiple brand addresses, and one inbox to manage everything. I'll also show the DNS records, Gmail settings, and the small places where this setup can easily go wrong.

The idea: one inbox, many brands

Before you click anything, it's worth separating the roles of your addresses. This is the whole philosophy of the setup:

  • private Gmail (johndoe@gmail.com) → owner account, recovery, old logins. You don't use it on the website or in contact with clients.
  • main business inbox (john@johndoe.dev) → command center, Google Workspace.
  • public project email (contact@taskly.pl) → the address you give to clients.

The key: you don't create a separate Gmail for every project. Everything lands in one Workspace inbox, and you reply "as a brand". You'll wire up the next product with the same pattern (contact@newproduct.pl → the same inbox).

Step 1 — Google Workspace on the main domain

Go to workspace.google.com and start registration. When choosing a plan, you probably don't need the pricier Standard plan at the beginning — Business Starter is plenty for an MVP. You get Gmail on your own domain, Drive, Calendar, Meet, and an admin panel. The 2 TB and advanced Gemini from the higher plan are overkill for an MVP.

While creating the account, pick the "I already have a domain" option, enter johndoe.dev, and create the user john. Result: john@johndoe.dev.

On the contact details screen, your private Gmail will only serve as contact/recovery — it won't be the target business mail.

Step 2 — verifying the domain in Cloudflare

Google needs to confirm the domain is yours. It will show a TXT record to add. Choose manual verification (Switch to manual verification) — it's clearer and does not require connecting Google directly to your Cloudflare account.

In Cloudflare (for the johndoe.dev domain) → DNS → Records → Add record:

Type: TXT
Name: @
Content: google-site-verification=...   // paste the exact value from Google
TTL: Auto
Comment: Google Workspace verification
Enter fullscreen mode Exit fullscreen mode

Save, go back to Google, and click Verify. If it doesn't pass right away — wait 1–3 minutes. DNS sometimes needs a moment.

Important: Cloudflare Email Routing vs Google MX records

If you previously had Cloudflare Email Routing enabled on the domain (e.g. to forward mail to another address), pay attention here — otherwise you can skip this step.

Email Routing keeps its own MX records:

route1.mx.cloudflare.net
route2.mx.cloudflare.net
route3.mx.cloudflare.net
Enter fullscreen mode Exit fullscreen mode

These records block adding Google's MX and create a confusing setup — you end up with two mail systems at once. As a result, mail doesn't work the way it should, and the Google wizard can keep showing an error for a long time even though the DNS "looks" correct.

Important: disabling just the routing rules is not enough. You have to disable the entire Email Routing service. Check it like this:

Cloudflare → Email → Email Routing → Settings
Enter fullscreen mode Exit fullscreen mode

The status has to be Disabled, not just "rules disabled". If you see Status: Enabled or DNS records: Locked — Google still sees a conflict. Click Disable until you reach:

Status: Disabled
DNS records: Not configured (or Unlocked)
Enter fullscreen mode Exit fullscreen mode

Google's MX records only have a chance to work properly after Email Routing is actually disabled and the old routeX.mx.cloudflare.net records are removed.

Step 3 — Google MX record

In Cloudflare for johndoe.dev → DNS → Records → Add record:

Type: MX
Name: @
Mail server: smtp.google.com
Priority: 1
TTL: Auto
Comment: Google Workspace MX
Enter fullscreen mode Exit fullscreen mode

For new Google Workspace setups, Google usually shows a single MX record: smtp.google.com with priority 1 — no longer the old sets of five ASPMX records. Use exactly what the Google wizard shows you, and don't guess.

A small note from experience: if Google still complains, some panels normalize the MX value and may expect smtp.google.com. with a trailing dot. Cloudflare usually handles that for you — don't force the dot.

Step 4 — SPF

To improve deliverability and help receiving servers trust your mail, add an SPF record. In Cloudflare:

Type: TXT
Name: @
Content: v=spf1 include:_spf.google.com ~all
TTL: Auto
Comment: Google Workspace SPF
Enter fullscreen mode Exit fullscreen mode

This doesn't block the MX itself, but it's worth adding right away. We'll handle DKIM and DMARC at the end, after Gmail is active.

After saving, go back to Google and click Retry. Also do a quick test: send a mail from your private Gmail to john@johndoe.dev and reply the other way. If both directions work — the mail is fine, even if the Google wizard is still complaining.

Step 5 — adding support@ as an email alias

You want support@johndoe.dev, but not as a separate, paid user (every extra user is another paid Workspace seat). You do it as an alias to the existing account.

In Google Admin:

admin.google.com → Directory → Users → [your user]
→ User information → Alternate email addresses / Email aliases
Enter fullscreen mode Exit fullscreen mode

In the alias field, enter only support (Google appends the domain itself). Final result:

support@johndoe.dev → lands in → john@johndoe.dev
Enter fullscreen mode Exit fullscreen mode

Watch out: don't click "Add user" or "Set up mail routing" — that creates a new paid account / is for migration, not for an alias.

After adding, test it: send from your private Gmail to support@johndoe.dev — it should land in john@johndoe.dev.

Step 6 — adding the project domain as a Secondary domain

Now you attach the project domain taskly.pl to the same Workspace. There's an important choice here:

Google Admin → Account → Domains → Manage domains → Add a domain
Enter fullscreen mode Exit fullscreen mode

Google will ask about the domain type. For this setup, I prefer Secondary domain, not Domain alias. A domain alias can also work in simpler cases (it maps aliased addresses onto existing users), but a secondary domain gives you more explicit control over project-specific addresses and lets you create normal, separate ones:

contact@taskly.pl
billing@taskly.pl
support@taskly.pl
Enter fullscreen mode Exit fullscreen mode

Next, Google will ask for DNS verification — this time you add the TXT record in Cloudflare in the taskly.pl domain, not in johndoe.dev:

Type: TXT
Name: @
Content: google-site-verification=...
TTL: Auto
Enter fullscreen mode Exit fullscreen mode

And after verification — the MX record (same as before, smtp.google.com, priority 1).

Finally, add the project alias (just like support@ in step 5):

contact@taskly.pl → lands in → john@johndoe.dev
Enter fullscreen mode Exit fullscreen mode

Step 7 — "Send as" in Gmail (the client sees the brand, you have one inbox)

The alias alone makes mail arrive in your inbox. But when you reply, by default it goes out from john@johndoe.dev — and we want the client to see the brand. So we wire up sending.

In Gmail (on the Workspace account):

Settings → See all settings → Accounts → Send mail as → Add another email address
Enter fullscreen mode Exit fullscreen mode

Enter:

Name: Taskly
Email address: contact@taskly.pl
Enter fullscreen mode Exit fullscreen mode

Leave the "Treat as an alias" checkbox checked — these addresses belong to you / your projects and should behave as identities of the same inbox. Gmail will send a verification email to contact@taskly.pl — which will land in your inbox anyway. You confirm the code and you're done.

Now the most important setting, so replies go out as the brand and not as your main address:

Settings → Accounts → When replying to a message:
→ check: "Reply from the same address the message was sent to"
Enter fullscreen mode Exit fullscreen mode

Result: someone writes to contact@taskly.pl → your reply goes out as Taskly. The client doesn't see johndoe.dev. You handle everything from a single inbox.

Step 8 — DKIM and DMARC (deliverability)

The last technical step: DKIM signatures and a DMARC policy. Without them, your mail is more likely to land in spam.

DKIM — generating in Google Admin 

Google Admin → Apps → Google Workspace → Gmail → Authenticate email (DKIM)
Enter fullscreen mode Exit fullscreen mode

Pick the domain (e.g. johndoe.dev), click Generate new record, leave the key length at 2048 bit, prefix google. Google will show a TXT record:

Name: google._domainkey
Value: v=DKIM1; k=rsa; p=...   // very long key, copy it ALL, all the way to the end
Enter fullscreen mode Exit fullscreen mode

You paste this record in Cloudflare for the given domain:

Type: TXT
Name: google._domainkey
Content: v=DKIM1; k=rsa; p=MIIBIJANBgkq...   // the entire value from Google
TTL: Auto
Comment: Google Workspace DKIM
Enter fullscreen mode Exit fullscreen mode

After saving, go back to Google Admin and click Start authentication. The "up to 48 hours" propagation message is normal — it usually clears faster. Once DKIM kicks in, the button changes to Stop authentication — that means it's working, and you don't click it. Repeat the whole process for taskly.pl.

DMARC — in Cloudflare

For each domain, add in Cloudflare:

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:john@johndoe.dev
TTL: Auto
Comment: Google Workspace DMARC
Enter fullscreen mode Exit fullscreen mode

p=none is good to start with — it only monitors, doesn't aggressively block anything. After a few weeks, once everything works, you can tighten it to quarantine or reject. For a serious setup, you may later want to send DMARC reports to a dedicated mailbox or a DMARC monitoring tool instead of your main inbox — the aggregate XML reports can pile up fast.

Final setup

After these steps you have a solid, production-friendly mail foundation for a small business or MVP:

On your landing page you put contact@taskly.pl and handle clients from Gmail, without exposing your private address. Next product? Same pattern: a new domain as a "secondary domain" → a contact@… alias → "send as". One inbox, many brands.

If you ever had Cloudflare Email Routing enabled, it's worth checking first whether it's set to Disabled — that's the most common reason mail on a fresh Workspace doesn't start working.

Quick checklist if email still does not work

  • Cloudflare Email Routing is fully disabled, not only the routing rules.
  • There are no leftover Cloudflare MX records like route1.mx.cloudflare.net.
  • There is only one MX setup for the domain.
  • Google MX points to smtp.google.com with priority 1.
  • SPF exists as a TXT record on @.
  • DKIM was generated for the correct domain.
  • DMARC exists on _dmarc.
  • The Gmail alias was added both in Google Admin and in Gmail "Send mail as".
  • Gmail is set to reply from the same address the message was sent to.

Happy shipping! 🚀

Top comments (0)