Centralised Email Signatures in Microsoft 365: The Complete Guide (2026)
TL;DR: Microsoft 365 includes a built-in mechanism for appending signatures to outgoing emails, but it has fundamental limitations that make it unsuitable for organisations that need branded, personalised signatures. “Centralised” means different things depending on the deployment architecture — server-side, native transport rules, and add-in-based approaches each offer a different combination of control, coverage, and tradeoffs. This guide explains each in technical detail so you can make an informed decision before evaluating any vendor.
If you’ve been asked to “centralise” email signatures across your organisation and you’re running Microsoft 365, there are more options than most guides let on — and the differences between them matter more than most guides explain.
The word “centralised” gets used loosely in this space. It can mean anything from “we applied a transport rule in Exchange so a disclaimer appears on outgoing emails” to “a cloud platform manages the full signature lifecycle and syncs automatically with our employee directory.” These are not the same thing. The gap between them is significant, and which approach is right for your organisation depends on factors that are specific to your M365 configuration, your device landscape, and your compliance requirements.
This guide covers all of it, with a comparison table at the end.
What Does “Centralised” Actually Mean?
In the context of email signatures, centralised means that the IT team or a designated administrator controls what appears in employees’ signatures — employees cannot change or override them. The opposite of centralised is distributed: each employee sets their own signature, which is the default state in every email client including Outlook.
There are three meaningful dimensions of centralisation to consider:
Control: Can an administrator change the signature template and have that change take effect for all users without any employee action? The strictest form of centralised control means employees have no ability to edit their own signature at all.
Personalisation: Can the signature include the individual employee’s name, job title, phone number, and other attributes — pulled automatically from the directory, rather than manually entered? Centralised doesn’t have to mean generic.
Coverage: Does central management apply to emails sent from all surfaces — Outlook on Windows, Outlook on Mac, Outlook Web Access, Outlook Mobile, and potentially native device mail apps? Coverage varies significantly between deployment approaches.
A solution can be centralised in some of these dimensions but not others. Understanding that distinction helps you evaluate tools clearly.
Microsoft 365’s Native Approach: Exchange Mail Flow Rules
The starting point for most organisations is the question: “Can we do this without buying anything?”
The answer is yes — partially. Microsoft 365 includes a feature called mail flow rules (also known as transport rules in Exchange terminology) that can append text or HTML to outgoing messages. These are configured in the Exchange admin centre and apply at the mail server level, after emails leave the sender’s mailbox.
Here’s what they can do:
- Apply a standardised block of HTML or plain text to all outgoing emails
- Apply conditionally based on sender (e.g., only external emails, or only emails from a specific domain)
- Include a static legal disclaimer beneath the email body
- Be configured without any software installation on employee devices
And here’s what they cannot do, which matters considerably:
No per-user personalisation. The signature appended by a transport rule is the same for every email it matches. You cannot insert the sender’s name, job title, phone number, or any other individual attribute. To personalise by user, you would need to create a separate rule for each employee — which is unmanageable at any meaningful scale and breaks every time someone’s details change.
No compose-time preview. The signature is added after the email is sent, at the server level. The employee never sees it in the compose window. They’re writing what appears to be a signatureless email. This causes confusion, and frequently leads to employees manually adding their own signature as well — producing duplicates on outgoing mail.
No visual template editor. Transport rules are configured in the Exchange admin centre using raw HTML or a minimal text editor. There is no drag-and-drop template builder, no logo management interface, no preview of how the signature will render across email clients.
Append-only, with unpredictable placement. Transport rules append content to the email body — they cannot reliably place a signature in the conventional position (immediately below the sender’s text, above quoted text in a reply). In practice, the disclaimer often appears at the very bottom of an email thread, including below all quoted replies. This is technically correct from the rule’s perspective but looks wrong to the recipient.
No reply/forward control. Transport rules apply to all outgoing emails that match the conditions. There is no native way to apply a full branded signature to new emails while suppressing it on replies and forwards — which is standard behaviour in purpose-built signature tools. Microsoft’s own documentation acknowledges these limitations explicitly, noting that inserting signatures directly under replies, displaying them in Sent Items, and skipping lines for missing user variables all require a third-party tool.
No analytics or impression data. There is no mechanism to track how often a signature banner is clicked, or to measure any engagement with signature content.
For organisations that need nothing more than a consistent legal disclaimer on all external emails, native transport rules may be sufficient. For organisations that want a recognisable, branded, personalised signature that looks professional and is maintainable over time, they are not the right tool.
The Three Architectural Approaches to Centralised Signature Management
Beyond the native M365 option, there are two dominant architectural categories used by third-party email signature management tools. Understanding the architecture — not just the feature list — is the foundation of a good purchasing decision.
Approach 1: Server-Side Routing
In this architecture, outgoing email is routed through a third-party cloud platform before it reaches its destination. The platform intercepts the email, appends the correct signature for that sender, and forwards the email to the recipient.
In a Microsoft 365 environment, this is typically implemented using Exchange mail flow rules that redirect outbound email through the vendor’s SMTP relay service, or via a connector configured in the Exchange admin centre. The vendor’s servers sit between your Microsoft 365 tenant and the public internet.
How personalisation works: The vendor’s platform maintains a database of employee profiles, synced from your directory (Azure Active Directory / Entra ID). When an email passes through, the platform looks up the sender’s profile and injects their personalised signature — name, title, photo, phone number — before delivering the email.
Coverage: Because the signature is applied at the mail server level, it applies to emails sent from any client: Outlook on Windows, Mac, OWA, Outlook Mobile, and native device mail apps. The email client doesn’t matter — the email always passes through the vendor’s server.
The GDPR consideration: This is the most important thing to understand about server-side routing: every email your organisation sends — including the body content, attachments, and any personal data in the message — passes through the vendor’s servers for processing. Under GDPR, this makes the vendor a data processor of that content. You will need a Data Processing Agreement (DPA) with the vendor, and your legal or data protection team should review what data is retained, where it is processed, and under what conditions. Vendors operating under the UK GDPR or EU GDPR will provide a DPA — reputable ones make this straightforward. But it is a compliance relationship that needs to be actively managed.
In regulated industries — financial services, healthcare, legal, or any sector where email content is particularly sensitive — this is a question that procurement and your DPO will likely raise. It is not a blocker for most organisations, but it needs to be addressed.
Notable vendors using this architecture: Exclaimer, Letsignit, Rocketseed, and most of the established players in the enterprise segment.
Approach 2: Outlook Add-In (Compose-Time Injection)
In this architecture, a small software component — an Outlook add-in — is deployed to employees’ Outlook clients. When an employee opens a compose window, the add-in is activated. It identifies the sender, fetches the appropriate signature (typically from a cloud-hosted template), and injects it into the email body before the employee sends.
The email is never routed through any third-party infrastructure. It goes from the employee’s Outlook client, through Microsoft’s servers, to the recipient — exactly as it would without any signature tool in place.
How personalisation works: The add-in identifies the sender from Outlook’s current session context and fetches their personalised signature from the vendor’s CDN or API. The signature content is pre-rendered based on the employee’s directory attributes and the active template. The employee sees the correct signature in their compose window from the moment they open it.
Deployment in M365: Add-ins are deployed using Microsoft’s Centralised Deployment feature, available in the Microsoft 365 admin centre. An admin with Global Admin or Exchange Admin permissions publishes the add-in to all users (or specific groups), and it appears in Outlook automatically — no action required from employees. Deployment typically propagates within 24 hours.
Coverage: The add-in works in Outlook for Windows (new Outlook), Outlook for Mac, and Outlook on the web (OWA). Outlook Mobile also supports add-ins — employees using the Outlook app on iOS or Android will have the signature injected the same way. The limitation is native device mail apps: if an employee accesses their company email through the iPhone’s built-in Mail app rather than Outlook Mobile, the add-in does not apply.
The data architecture: Because signatures are pre-rendered and served from a CDN at compose time — not generated dynamically per email — the email body itself is never processed by the vendor. What the vendor handles is the signature template management and directory sync to know which signature to serve to which person. The email content remains entirely within Microsoft’s infrastructure.
Compose-time visibility: Employees see the signature as they write. This eliminates the confusion and duplicate-signature problem common with transport rule approaches. It also means employees can verify their signature looks correct without sending a test email.
Notable vendors using this architecture: CodeTwo (hybrid — both add-in and server-side options), Sigsync, Dynasend, and a small number of newer entrants.
How the Three Approaches Compare
| Native M365 Transport Rules | Server-Side Routing | Outlook Add-In | |
|---|---|---|---|
| Cost | Included with M365 | Per-user/month subscription | Per-user/month subscription |
| Per-user personalisation | ✗ Not possible | ✓ Yes, via directory sync | ✓ Yes, via directory sync |
| Compose-time preview | ✗ No | ✗ No — added after send | ✓ Yes — employee sees it |
| Mobile coverage | ✓ All clients (server-level) | ✓ All clients (server-level) | ✓ Outlook Mobile only |
| Native mail app coverage | ✓ Yes | ✓ Yes | ✗ No |
| Email content through third-party servers | ✗ No | ✓ Yes | ✗ No |
| GDPR / data processing relationship | None (Microsoft only) | DPA required with vendor | Minimal (template delivery only) |
| Template editor | ✗ None (raw HTML) | ✓ Visual editor | ✓ Visual editor |
| Reply/forward control | ✗ Limited | ✓ Yes | ✓ Yes |
| Analytics / click tracking | ✗ No | ✓ Typically included | ✓ Typically included |
| Deployment method | Exchange admin centre | Exchange connector / mail flow rule | M365 Centralised Deployment |
| IT effort to deploy | Low | Medium (connector setup) | Low (Centralised Deployment) |
| Best suited for | Basic disclaimer only | Broad device coverage required | M365-standard device environments |
Which Approach Is Right for Your Organisation?
There is no universally correct answer, but the decision usually comes down to two factors: device landscape and compliance posture.
If your organisation has a standardised device environment — company-managed Windows or Mac devices, with Outlook as the enforced email client — the add-in approach is operationally simpler and avoids the third-party data processing relationship. Your IT policies already ensure Outlook is in use, so the mobile native app limitation is a non-issue.
If employees use personal devices and a mix of mail apps — common in smaller organisations or those with a BYOD policy — server-side routing gives you consistent coverage regardless of which app employees use. The GDPR tradeoff is real but manageable with a proper DPA in place.
If you just need a legal disclaimer and personalisation, visual templating, and compose-time preview are not requirements, native transport rules are free and require no additional vendor relationship. This is a legitimate choice for organisations with very basic requirements.
If you’re in a regulated industry with heightened sensitivity to email content passing through third-party systems, the add-in architecture gives you a simpler compliance answer — the email itself never leaves Microsoft’s infrastructure.
Most organisations in the 50–250 employee range, running a standard M365 environment with company-managed or Outlook-enforced devices, will find the add-in approach gives them everything they need with the least compliance overhead.
Deploying an Add-In via Microsoft Centralised Deployment: What’s Involved
Since Centralised Deployment is the standard method for pushing an Outlook add-in to all users in an M365 organisation, it’s worth knowing what it involves before you commit to an add-in-based tool.
What you need: Global Admin or Exchange Admin access in the Microsoft 365 admin centre.
Where you do it: Microsoft 365 admin centre → Settings → Integrated apps (or the legacy path: Admin centres → Exchange → Add-ins).
What you provide: The add-in manifest — an XML file provided by the vendor that tells Outlook where to find the add-in and what permissions it needs. Some vendors offer direct deployment from Microsoft AppSource, which simplifies the process further.
Who it applies to: You can deploy to all users, specific security groups, or individual users. Most signature management deployments target all users, sometimes with a pilot group first.
How long it takes: Add-in deployment propagates across the tenant within a few hours to 24 hours. It does not require any action from employees — the add-in appears in Outlook automatically on the next launch after propagation.
What permissions the add-in requires: This varies by vendor but typically includes read access to the composed email (to know where to inject the signature), write access to the email body (to inject it), and access to the sender’s identity. Well-built add-ins request the minimum permissions necessary. Review the manifest permissions carefully and ask the vendor to explain any that seem broader than expected.
A Note on Legacy Outlook for Windows
There are currently two versions of Outlook for Windows in circulation: classic Outlook (sometimes called legacy Outlook) and new Outlook for Windows, which Microsoft has been rolling out as the replacement.
These are architecturally different applications. Classic Outlook uses a COM-based add-in model (VSTO); new Outlook uses the modern Office Add-ins framework (the same JavaScript/web-based model used by Outlook on Mac and OWA). Most modern email signature tools have moved to the web-based add-in model, which works in new Outlook, Outlook on Mac, and OWA, but may not support classic Outlook.
Microsoft’s current roadmap has classic Outlook for Windows being retired in phases — the opt-out phase began in early 2026, with full retirement of classic Outlook from Microsoft 365 subscriptions expected around 2028, and end-of-life support continuing until at least 2029. Many organisations still have employees running it in the interim. Before committing to any add-in-based tool, ask the vendor explicitly:
- Do you support classic Outlook for Windows?
- Do you support new Outlook for Windows?
- Is the add-in deployed via the same manifest for both, or are they separate deployments?
This is a real compatibility question, not a theoretical one. Getting a clear answer upfront saves painful discovery later.
Summary
Centralised email signatures in Microsoft 365 can be achieved through three architecturally distinct approaches, each with genuine tradeoffs:
Native transport rules are free and require no third-party relationship, but cannot personalise by user, cannot show signatures in compose, and cannot support visual template management. They’re suitable for basic disclaimers only.
Server-side routing gives you coverage across all mail clients regardless of device policy, with full personalisation and visual template management — but routes email content through the vendor’s servers, requiring a GDPR data processing agreement and introducing a third-party dependency in your mail flow.
Add-in-based deployment keeps email within Microsoft’s infrastructure, gives employees compose-time signature visibility, and deploys cleanly through M365 Centralised Deployment — but depends on Outlook being the email client in use.
For most M365 organisations with standard device management, the add-in approach delivers central control, personalisation, and a simpler compliance architecture. The right answer for your organisation depends on how much control you have over which email clients employees use.
If you’re earlier in your research and want a broader map of the problem space — deployment options, questions to ask before evaluating vendors, and what to look for in a solution — start with How to Manage Email Signatures Across a Company: What IT Admins Actually Need to Know.
Frequently Asked Questions
What is the difference between centralised and standardised email signatures?
Standardised means everyone uses the same format and design — but employees may set this themselves from a template. Centralised means the organisation controls the signature directly; employees cannot change it. Centralised management is required to maintain consistency over time, because distributed self-management always drifts.
Does Microsoft 365 have a built-in email signature manager?
Not in the sense most organisations need. M365 includes Exchange mail flow rules that can append a static block of text or HTML to outgoing emails. These cannot personalise by individual user, cannot show the signature at compose time, and have no visual editor. For managed, branded, personalised signatures, a third-party tool is required.
What is Microsoft Centralised Deployment for Outlook add-ins?
It’s a feature in the Microsoft 365 admin centre that allows IT admins to push Outlook add-ins to all users in the tenant without requiring any manual installation on employee devices. The add-in appears in Outlook automatically after deployment. It requires Global Admin or Exchange Admin permissions and is the standard deployment method for add-in-based email signature tools. Full requirements and a step-by-step guide are available on Microsoft Learn.
Is server-side email signature management compliant with GDPR?
It can be, with the right contractual arrangements. Because email content passes through the vendor’s servers for signature appending, the vendor is a data processor under GDPR. A Data Processing Agreement must be in place. Reputable vendors provide a DPA as standard. Your Data Protection Officer should review the vendor’s DPA, data retention policies, and the location of their processing infrastructure (particularly for UK GDPR purposes post-Brexit). The ICO’s guidance on controllers and processors explains what a data processing relationship requires. This is a manageable compliance requirement, not a prohibition.
Do email signature add-ins work on Outlook Mobile?
Yes — Outlook Mobile for iOS and Android supports Office Add-ins in the same way as desktop Outlook. Add-in-based signature tools work in Outlook Mobile when the add-in is deployed via Centralised Deployment. They do not work in native device mail apps (iOS Mail, Android Gmail app, etc.) — signatures on those clients remain under employee control unless a server-side approach is used.
Can I have different email signatures for different teams in Microsoft 365?
Yes, with a dedicated email signature management tool. Both server-side and add-in-based tools support rules-based signature assignment — you can define that the sales team uses one template, customer support uses another, and leadership uses a third. This is not possible with native M365 transport rules without creating a separate rule for each signature variant and maintaining complex conditions.
How does an email signature management tool sync with my employee directory?
Modern tools connect to Azure Active Directory (Entra ID) via the Microsoft Graph API. The sync pulls employee attributes — display name, job title, department, phone number, photo, and any custom attributes you’ve configured — and uses them to personalise each employee’s signature automatically. When an employee’s details change in the directory, the signature updates at the next sync (typically within hours). This eliminates manual maintenance of individual signature records.