How to Set Up Google Workspace for Multiple Organizations with Separate Domains (And Manage Email Authentication Per Domain)

 

Google Workspace makes it look like multi-domain setup is one admin-console task. It is not. Each domain still has its own DNS, its own SPF record, its own DKIM key, and its own DMARC policy. If you add six domains, you now have six separate email authentication setups to keep clean. That is where most problems come from. Reading the raw XML was not a good use of time. We used DMARCflow for that part, because the reports are easier to work with once you can filter them by domain, sender, and failure type.

How Workspace Multi-Domain Architecture Actually Works

Google Workspace lets you add multiple domains to a single admin account. Each domain gets its own set of users, groups, and email settings. You can assign users to one domain at a time, and aliases let them have addresses across domains too.

The key thing to understand: adding a domain to Workspace doesn't merge it with your primary domain. Each domain keeps its own DNS zone and its own email authentication settings. What happens in one domain stays in that domain.

Step 1: Add Each Domain and Verify Ownership

Start with your primary domain, the one you used when you first set up Workspace. Then add each additional domain:

1. In the Google Admin console, go to Menu → Domains → Add domains. Enter the domain name.
2. Choose Add without verifying if the domain is already verified elsewhere, or follow the domain verification steps. For subdomains, you typically use a TXT record on the parent domain.
3. After verification, set the domain up as either a primary domain or a secondary domain. For your use case, secondary is right.

DNS propagation can take a few hours, and Workspace won't let you proceed with DKIM setup until the domain is verified.

Step 2: Generate and Publish DKIM Keys Per Domain

This is where most multi-domain setups go wrong. You generate DKIM keys in Workspace, but you publish them to the wrong domain's DNS, or you forget to enable DKIM signing for one of the domains.

For each domain:

1. In Admin console → Apps → Google Workspace → Gmail → Authenticate email.
2. Select the domain you want to configure.
3. Click Generate new record. You'll get a DKIM TXT record  and a value string.
4. Add that TXT record to your DNS provider under the correct domain - not your primary domain.
5. After propagation (allow 24–48 hours), come back and click Start authentication.

Do this for every domain. DKIM keys are domain-specific. If you only generate keys for your primary domain, the others won't have signed email and receiving servers will treat their mail as unauthenticated.

Step 3: Configure SPF Per Domain

SPF for multi-domain Workspace setups is straightforward but easy to get wrong when you have third-party mailers involved.

Each  domain needs its own SPF record. If A uses Office 365 for some sending and Workspace for others, the SPF record must include both. If B uses a third-party email blast platform, that include goes in b's SPF record, not a's.

A typical Workspace SPF record looks like:

v=spf1 include:_spf.google.com ~all

Add this to each DNS zone. If you have third-party senders, append them:

v=spf1 include:_spf.google.com include:someservice.com ~all

Keep the records separate per domain. Don't copy your primary domain's SPF record to the others they may have different sending sources.

Step 4: Set Per-Domain DMARC Policies (And Monitor Them)

This is the part that most multi-domain guides skip entirely. Your DMARC policy applies per domain,  you need a DMARC record for each domain  not just your primary.

Each  should have its own DMARC record in its own DNS zone

Start with p=none while you collect data. After two to four weeks of aggregate reports, check for failures. If everything looks clean, move to p=quarantine. Only move to p=reject when you're confident.

The rua destination (aggregate report email) should go to an address you actually check.  That's fine the aggregate report includes the responsible domain in each record, so you can tell which generated which report.

Here's where it gets practical: managing DMARC across six domains means six sets of aggregate reports. Reading them manually works at first, but it's slow and error-prone, you'll miss patterns if you're skimming instead of analyzing. A tool that collects aggregate reports across all your domains in one place, flags authentication failures per domain, and shows you which has a DKIM or SPF problem is genuinely useful when you have six domains instead of one.

Step 5: Organize Users with OU Structure

Give each its own organizational unit (OU) in Google Admin. This lets you apply different policies to different domains without cross-contamination.

Each OU can have its own email routing rules, its own spam settings, and its own user management. When B needs a new user or a changed sending policy, you open that OU and change only what needs to change.

Step 6: Email Blast Systems and Separate MX Records

If each one uses a third-party email blast service (for newsletters, emergency alerts, bulk communications), that service will have its own MX record requirements and its own sending infrastructure.

For each blast service:

1. Add the service's sending IPs to the SPF record.
2. Ask the service for their DKIM key and add it to the same domain's DNS (some services require a CNAME or TXT record under a specific selector hostname).
3. Make sure the blast service knows the From domain so they can align their DKIM and SPF correctly.

 

Common Failures in Multi-Domain Workspace Setups

A few things go wrong more often than others when you're running multiple domains from one Workspace account.

DKIM signing not enabled for one domain. You generated the key but never clicked Start authentication. The result: unsigned email from that domain, flagged as suspicious by receiving servers. This one catches people because the key is published but the signing is still off.

SPF records pointing to the wrong domain. You copied the include from your primary domain and applied it to a Domain that uses different sending infrastructure. SPF fails, emails bounce or go to spam.

 

Forwarding breaks authentication silently. If one forwards mail through a third-party relay, that relay re-sends the mail and breaks DKIM alignment. The forwarded mail fails DMARC even though the original authentication was correct. You won't catch this unless you're reading aggregate reports.

How to Verify Everything Is Working

After DNS has propagated  give it 48 hours after the last record change:

1. Send a test email from each domain to a Gmail address and check the authentication headers. Look for dkim=pass and spf=pass.
2. Check your DMARC aggregate reports. After a few days, you should see data for all six domains in your rua inbox.
3. Use a DMARC lookup tool to confirm each domain's record is published correctly.

If you see failures in the aggregate reports, the report will show whether the failure is in SPF, DKIM, or alignment and which domain is generating the failure. This is why collecting DMARC reports matters, especially when you're managing six domains instead of one.

The Short Version

Set up multiple organizations in Workspace by adding each domain separately, generating DKIM keys per domain, writing separate SPF records per domain's actual sending sources, and configuring per-domain DMARC policies starting at p=none. Use OUs to keep settings clean. Keep blast service infrastructure separate from transactional email. And actually read the aggregate reports in the first month, that's where you catch the mistakes before they become email delivery problems.

When you have six domains, a DMARC monitoring tool that aggregates all your reports in one place is less of a luxury and more of a practical necessity. 

We ended up using DMARCflow simply because manually reviewing DMARC aggregate XML reports across multiple domains becomes tedious pretty quickly. Mostly it was useful for spotting SPF or DKIM failures without having to parse raw reports by hand.