Updated: July 2026
Quick Answer. Multi-domain email signature management means one tool that handles signatures across multiple domains under one workspace (for example @brand1.com, @brand2.com, and @acquired-co.com). SyncSignature supports unlimited domains per workspace with separate templates per domain. Google Workspace treats domains as primary plus secondary, and aliases inherit the parent's signature. Microsoft 365 uses accepted domains in Entra ID. The setup that breaks most often is treating an alias as if it were a separate domain.
Multi-domain email signature management is the standard requirement for any organization that operates more than one brand from a single email platform. Most parent companies, agencies, holding structures, and post-acquisition integrations end up here. The platform consolidates onto Google Workspace or Microsoft 365 but the brands stay separate. Each brand needs its own signature, its own banner, and often its own disclaimer, applied to whichever domain that brand operates on.
The configuration is straightforward once the distinction between primary, secondary, and alias domains is understood. Most setup mistakes come from getting that distinction wrong. For the broader multi-brand picture, see the multi-brand email signature platform. For the closely related parent and subsidiary architecture decision, see email signatures for parent company and subsidiaries.
The multi-domain problem
Three patterns produce multi-domain organizations.
Acquired domains. Company A acquires Company B. Company A consolidates onto its email platform but keeps Company B's domain active for at least a year to preserve customer recognition. Result: one workspace, two domains, two brands.
White-label or DBA brands. A holding company operates multiple consumer-facing brands from one back-office. Each brand has its own domain. Employees may serve multiple brands or be assigned to specific ones.
Regional or product-line domains. A company operates a primary .com brand and a series of regional or product-specific domains (acme.uk, acme.de, acmehealth.com). Each is its own brand expression in the local market.
In all three patterns, the signature must match the domain. Sending an email from @acquired-co.com with the parent company's signature breaks customer recognition for the acquired brand. Sending from @acme.uk with the .com signature creates confusion about which entity the customer is actually doing business with.
The default behavior of most email clients (and most signature tools) is one signature per user. That does not handle multi-domain users who send from different addresses. Multi-domain signature management requires the signature to be selected based on the sending domain, not the user identity.
How Google Workspace handles multi-domain
Google Workspace supports a primary domain and one or more secondary domains in the same tenant. Each user can have addresses on the primary plus any secondary domain. Aliases are different and behave differently.
Primary domain. The domain Google Workspace was provisioned under. One per tenant. Cannot be changed without significant operational disruption.
Secondary domain. Additional domains added to the same tenant. Users on secondary domains are first-class users with their own mailboxes. Each secondary domain has its own MX records pointing at Google.
Alias domain. A domain that forwards to addresses on another domain in the tenant. An alias user does not have their own mailbox. Mail sent to @alias.com is delivered to their @primary.com mailbox.
Email alias. A second address on the same user ([email protected] plus [email protected]). Both deliver to the same mailbox.
For signature management:
Users on the primary or secondary domain can have their own signatures rendered per their domain. SyncSignature reads the user's primary email address from the directory and applies the template assigned to that domain.
Users with alias domains inherit the signature of their canonical user. The alias is not a separate user from the platform's perspective.
Users with multiple aliases (sending from different addresses on the same mailbox) need a sendAs configuration per alias. Gmail supports send-as alias selection, and SyncSignature can apply a different signature per sendAs identity if configured.
The setup that breaks most often is assuming an alias domain has independent signature behavior. It does not. If you need a fully independent signature for an acquired brand, the acquired domain needs to be added as a secondary domain (not an alias).
How Microsoft 365 handles multi-domain
Microsoft 365 uses the concept of accepted domains in Entra ID (formerly Azure Active Directory). Each accepted domain is registered with Microsoft 365 and can serve as a primary SMTP address or as a secondary address for users.
Authoritative domain. A domain where Microsoft 365 manages all mailboxes. Equivalent to Google's secondary domain concept.
Internal relay domain. A domain where Microsoft 365 forwards mail to on-premise mailboxes. Used in hybrid Exchange deployments.
External relay domain. A domain where mail is forwarded externally. Rare in pure-cloud Microsoft 365 setups.
Each user has a primary SMTP address (the one displayed as the From address by default) and can have multiple proxy addresses (additional addresses that deliver to the same mailbox). The primary SMTP determines the default sending domain.
For signature management:
SyncSignature reads each user's primary SMTP address from Microsoft Graph API and applies the template assigned to that domain.
If a user sends from a proxy address instead of the primary, the Outlook add-in detects the sending address and applies the corresponding template.
Shared mailboxes inherit the signature of the shared mailbox configuration, not the user who sent the email from the shared mailbox. This is usually the desired behavior for customer-facing shared mailboxes ([email protected], [email protected]).
Setting up multi-domain signature management in SyncSignature
The configuration is three steps.
Step 1: Connect the workspace. One OAuth consent for Google Workspace (Admin SDK plus Gmail sendAs) or for Microsoft 365 (Microsoft Graph plus Outlook add-in deployment). The consent reads all domains accepted by the workspace.
Step 2: Build a template per domain. In the SyncSignature admin dashboard, create a template for each brand. Set the logo, color palette, font, contact field layout, and any per-domain disclaimer or banner. Assign each template to its domain.
Step 3: Map users to templates by domain. The mapping rule is "users whose primary email is on domain X get template X." SyncSignature handles this automatically based on the directory data. Override rules can apply where needed (a specific user gets a custom template regardless of their domain).
For employees who send from multiple addresses across domains, configure the alternate sendAs identity in their email client and SyncSignature renders the matching template based on which identity they send from.
Common multi-domain mistakes
Treating an alias as a separate brand. An alias domain inherits the canonical user's signature. If you need an independent signature for the alias, it has to be a secondary or authoritative domain, not an alias.
Forgetting to update the directory after a domain change. Adding a new domain to Google Workspace or Microsoft 365 does not automatically update the SyncSignature workspace mapping. After adding the domain to the email platform, re-run the SyncSignature workspace sync to pick up the new domain, then assign templates to it.
Conflicting signature on shared mailboxes. A shared mailbox at [email protected] that is accessed by users who normally send from @brand2.com needs explicit signature assignment to the shared mailbox identity. Without it, the user's personal signature can render, breaking the shared mailbox brand.
Sending behavior on hybrid Exchange. Organizations running hybrid Exchange with some mailboxes on-premise and others on Microsoft 365 cannot use SyncSignature's Outlook add-in for the on-premise mailboxes. Those mailboxes need transport-rule-based signature stamping or migration to the cloud first.
Banner targeting across domains. A banner campaign targeted to "sales team" can inadvertently apply to sales team members on all brands. If you intend the banner for one brand only, target by the directory group that aligns with the brand, not just the role.
What this looks like at three scales
Two domains, 20 users total. One workspace, two templates, two groups (one per domain). Setup time 45 minutes. Ongoing admin time roughly zero once configured.
Five domains, 100 users. One workspace, five templates, five groups, possibly with sub-groups for departments inside each domain. Setup time 90 minutes. Ongoing admin time roughly 1 hour per month for template updates and banner rotations.
12 domains, 500 users, distinct compliance regimes per brand. This is where Architecture A (workspace per subsidiary) starts to make more sense than a single workspace. See parent company and subsidiaries architecture for the migration path.
Frequently asked questions
How many domains can SyncSignature handle per workspace?
No fixed limit. Practical limits depend on directory size and admin complexity. Most multi-domain setups stay under 15 domains in one workspace. Beyond that, the architecture decision usually shifts toward separate workspaces per entity.
Do I need separate Teams plans for each domain?
No. One Teams plan covers all users in the workspace regardless of how many domains they span. Pricing is per user, not per domain.
Can I have the same signature on two different domains?
Yes. Templates can be reused across domains. Assign the same template to multiple domains in the mapping rules.
What happens when a domain is removed from the workspace?
The domain disappears from the SyncSignature template mapping. Users on that domain (if any remain) revert to a default template or no signature until reassigned. Run the workspace sync after any domain change to keep the mapping current.
Can I migrate from one tool's multi-domain setup to SyncSignature?
Yes. Template import is supported for common signature manager formats. Each domain's template is imported separately and reassigned to the corresponding domain mapping in SyncSignature. Plan one hour of admin time per domain for the migration.
What is the best way to manage email signatures for multiple brands and domains?
One workspace with domain-based or group-based template assignment, unless the brands need separate compliance boundaries (then use separate workspaces per entity). Central assignment is what keeps signatures consistent when people move between brands. If the multiple domains came from a merger or acquisition, the phased approach in email signatures during mergers and acquisitions covers the transition sequencing.
Does multi-domain support work the same way on Google Workspace and Microsoft 365?
The capability is equivalent. The technical mechanisms differ. Google Workspace uses the Gmail sendAs API to write signatures to each user's account, including for secondary domain users and aliased sendAs identities. Microsoft 365 uses the Outlook add-in to stamp signatures client-side based on the sending domain. Both produce the same end result: the right signature renders for the right domain on every email.
Share this post