Email Signatures for Multiple Companies in Microsoft 365
Drafted with AI assistance and reviewed before publishing. How we write and source articles →
TL;DR: When one Microsoft 365 tenant holds several companies or brands, each email needs the signature and legal text of the company it is sent as. That is not always the company the person works for. People send from shared mailboxes, from aliases on another brand’s domain, and on behalf of colleagues. So base your signature rules on the address in the From line, usually by matching the sender’s domain. Do not rely only on who the person is. Then test three cases before you go live: a shared mailbox, an alias and a reply.
This guide is for you if your organisation runs two or more companies or brands from one Microsoft 365 tenant. You might have bought another business and moved its staff into your tenant. You might run a group with several limited companies, or one company that trades under several brands. In every case, people now send email under more than one name.
How to Set Email Disclaimers by Department, Office or Country covers the basic method. You build one Exchange mail flow rule for each disclaimer variant, and scope it to a group or a directory field. Read it first if you have not built a scoped rule before. Its warning about overlapping rules adding two disclaimers applies here too. This guide covers what changes when the variants are separate companies or brands, not just separate teams.
Start with a list of legal entities, not brands
Before you build anything, write down every legal entity that sends email from your tenant. For each one, record:
- its registered name and company number
- the email domains it sends from
- the logo and brand it uses
- the legal text its emails must carry
A brand and a legal entity are not the same thing. One limited company can trade under three brands. Two companies can share one brand. The signature design follows the brand, but the legal details follow the company.
For a UK company, the legal details are its registered name, registered number, place of registration and registered office address. A trading name or logo alone does not meet the rule. UK Email Footer Legal Requirements sets out exactly what each company’s footer must say. If you have companies in other countries, Email Signature and Disclaimer Laws by Country covers the US, Canada, Australia and New Zealand. Ask your legal team to confirm which company is the sender for each domain before you write any rules.
Match on the sender’s domain when brands share people
The disclaimers guide recommends matching on group membership rather than free-text directory fields. That is still true when each person only ever sends as one company. It stops being true when people send as more than one.
A mail flow rule can check the sender’s domain. In the Exchange admin centre, the condition is “The sender > domain is”. In PowerShell, it is SenderDomainIs. By default, a rule reads the sender from the message header, which means the From line. So a domain rule follows the address the email actually went out under, not the person who wrote it.
Compare the two approaches for someone in a “Brand A” group who also has an alias on the Brand B domain:
| Condition | Email sent from their Brand A address | Email sent from their Brand B alias |
|---|---|---|
| Sender is a member of the Brand A group | Brand A footer | Brand A footer (wrong) |
| Sender’s domain is branda.com | Brand A footer | No match |
| Sender’s domain is brandb.com | No match | Brand B footer |
Two details to know before you rely on domain matching:
- It also matches subdomains. Microsoft says a rule for
contoso.comalso matchessubdomain.contoso.com. If a subdomain belongs to a different company, add an exception for it. - It only covers your own domains. Every domain has to be added to the tenant before people can send from it. Your list of entities should account for each one.
You can still use groups and directory fields as extra conditions, for example to pick a department variant within one company. Use the domain to pick the company, then narrow down from there.
Shared mailboxes send as the mailbox, not the person
A shared mailbox, such as accounts@ or hello@, has no owner of its own. People are given permission to send from it. Microsoft offers two kinds:
- Send As: the email appears to come from the shared mailbox alone.
- Send on Behalf: the email shows “Jo Smith on behalf of Accounts”.
In both cases, the shared mailbox’s address is in the From line. A rule that reads the From line checks the shared mailbox’s own domain, directory details and group memberships. It does not check the person’s.
That has two effects. A rule aimed at the person’s group may not add their company’s footer to email from the shared mailbox. And a rule based on the sender’s domain gives the shared mailbox the footer for its domain, which is usually what you want. Check that the shared mailbox’s domain belongs to the company that is actually trading. A shared invoices@ address used by two companies is a common trap. Give each company its own shared mailbox instead.
Also decide what a shared mailbox signature should show. A personal name, job title and direct phone number rarely make sense on email from a team address. Many organisations give shared mailboxes a team signature with the legal footer and no personal details.
Aliases can switch brand in the middle of a thread
An alias is a second email address on the same mailbox. After an acquisition, people often keep their old address as an alias so that customers can still reach them.
Microsoft documents two behaviours that matter for signatures:
- Replies may use a different address in different apps. When someone replies to an email that reached their alias, Outlook on the web replies from the alias. Outlook on the desktop replies from the primary address. So the same reply can go out under a different brand depending on which app the person uses.
- Sending from an alias in Outlook on the web needs an admin to turn it on. The setting is
Set-OrganizationConfig -SendFromAliasEnabled $true. Once it is on, each person chooses which aliases appear in their From list.
A domain-based rule handles both cases, because it reads whichever address ended up in the From line. A rule based on the person’s group does not. Before you turn on sending from aliases, decide whether people should be sending as the old brand at all. If the old company has stopped trading, its address may be better as a receive-only alias.
If you use an Outlook add-in, check how it handles a change of sender
So far this guide has covered mail flow rules, which add text on the server after the email is sent. A signature add-in works differently. It inserts the signature into the message while the person is writing it, so they can see it. For the trade-offs between the two, see Server-Side vs Add-In.
The multi-brand risk for an add-in is the moment someone changes the From address. They start a new email under their own name, then switch to a shared mailbox or an alias. The signature already in the message belongs to the first address.
Outlook gives add-ins a way to deal with this. Microsoft’s OnMessageFromChanged event runs when the account in the From field changes, so an add-in can replace the signature. Microsoft’s documentation, checked in October 2026, says:
- In Outlook on the web, new and classic Outlook for Windows, and Outlook for Mac, the event supports shared mailboxes, delegates and aliases.
- In Outlook on iOS and Android, it supports switching between accounts, but not shared mailboxes, delegates or aliases.
An add-in only reacts to a change of sender if it was built to. If you are choosing a tool, ask the vendor to show you three things in your own tenant:
- a new email from a shared mailbox
- a switch from a personal address to an alias on another domain
- the same switch on a phone
Test the cases that break
Build your rules or templates, then send test emails that cover each case below. Send them to an external mailbox you can read, such as a personal account, because many disclaimer rules only apply to external recipients.
- A new email from each company’s domain.
- A reply from each company’s domain, in Outlook on the web and in desktop Outlook.
- A reply to an email that arrived at an alias on another company’s domain.
- An email sent as each shared mailbox, using Send As and, if you use it, Send on Behalf.
- An email from someone who belongs to more than one company’s groups.
- An email from a subdomain, if any company uses one.
For each test, check that the email has one footer, that it names the right company, and that the logo matches. Mail flow rules can take 30 minutes or more to apply after you create or change them, so wait before you judge a result.
When one tenant becomes several
Everything above assumes one tenant. Some groups keep each company in its own Microsoft 365 tenant instead. Mail flow rules belong to a single tenant. So each tenant needs its own set of rules, and you keep each set up to date separately.
Frequently asked questions
Can one person have a different signature for each company they work for?
Yes, if each company has its own email address for them. Give the person an alias or a separate mailbox on each company’s domain. A domain-based rule then adds the right footer to whichever address they send from. A rule based only on the person’s group cannot tell the two companies apart.
Should the old company’s footer stay on after an acquisition?
Only while the old company still trades and sends email in its own name. Once the business has been absorbed and the old company no longer trades, its footer should come off. If people keep the old address as an alias, check that replies are not still going out under the old company’s name. Your legal team should confirm the date the old company stops being the sender.
Do I need a separate signature design for each brand?
Not always. The legal text must match the company, but the design can be shared if the brands share a look. Many groups use one layout with a different logo, colours and footer for each brand. Fewer layouts mean fewer rules to keep in step.
SigHQ is building an add-in-first email signature management tool for Microsoft 365 organisations of 50–250 employees. Join the waitlist to follow progress.