By David,
Walk through any 400-mailbox tenant and count the signature variants. There's the current brand template, the one from the rebrand before that, the one someone rebuilt from memory with the old logo, three with personal quotes, and at least one in Comic Sans. Nobody chose this. It's what happens by default when the signature is the only piece of company-visible branding that every employee is allowed to edit.
The fix isn't a better-looking template. It's treating the signature like any other piece of managed configuration: one source of truth, deployed centrally, checked for drift. Here's the playbook, applicable whatever tooling you use - including none.
1. Make the directory the single source of truth
Every piece of per-person data in a signature - name, job title, department, phone, office - already has a home: Microsoft Entra ID. The moment someone types their title into a signature by hand, you have two copies of that fact, and they will disagree within a year.
The practice: fix the data in Entra first. Audit jobTitle, department, telephoneNumber, and physicalDeliveryOfficeLocation for the accounts that send external mail, and make HR changes flow into the directory as part of the joiner-mover-leaver process. Every downstream signature approach - transport rules, scripts, or a provisioning product - gets better when the directory is right, and none of them can save you when it's wrong.
2. Use tokens, never typed text
A template should contain placeholders, not people. {{displayName}}, {{jobTitle}}, {{department}} - hydrated per user from the directory at deployment time. That's what makes practice #1 pay off: when someone is promoted, the next push picks up the new title, and nobody retypes anything.
This is the single biggest difference between "we emailed everyone the approved signature" and actually managing signatures. A pasted signature is stale the day the org chart changes. A token-driven one is stale never - it re-resolves every time it's applied. Atlas Ink does exactly this - tokens hydrate from each user's Entra ID profile at push time - but the principle holds for any mechanism you build or buy.
3. Scope assignment: tenant default, group variants, user exceptions
One template never fits everyone. Sales wants a booking link, legal needs a disclaimer, executives want minimal. The wrong answer is separate hand-maintained templates per team; the right answer is scoped assignment with precedence: a tenant-wide default, group-level variants where a department genuinely differs, and individual exceptions where you must - with the most specific scope winning.
Precedence matters because membership overlaps. If a user is in both "Sales" and "UK Employees," something deterministic has to decide which signature they get. Define the hierarchy once (user beats group, group beats tenant) and document it, or you'll re-litigate it per escalation.
4. Enforce drift - don't chase it
Roll out a signature with no enforcement and entropy starts immediately: users "improve" fonts, delete legal footers, add quotes. Within a quarter you're back to the zoo you started with, except now IT owns it.
Decide the policy explicitly. Managed users get their assigned signature re-applied on a schedule - a daily reconcile that quietly reverts edits is far kinder than a quarterly email asking 400 people to fix themselves. And make the unmanaged state deliberate: some users (founders, execs with assistants) may legitimately keep a custom signature - switch them to unmanaged on purpose rather than letting exceptions accrete silently.
5. Keep the HTML boring
Email HTML is where modern CSS goes to die. Signatures render in Outlook desktop (Word engine), Outlook on the web, mobile clients, and whatever your recipients use. The signatures that survive all of them are built from tables, inline styles, web-safe fonts with fallbacks, and restraint:
- No image-only signatures. They're invisible until images load, unreadable to screen readers, useless to reply-chain text, and they bloat every message.
- One small logo, absolutely referenced and with alt text - not a 2 MB PNG resized in markup.
- Skip the automatic-inspiration widgets - per-send dynamic quotes and banners push you toward in-transit stamping architectures, with all the mail-path consequences those carry.
- Test in the ugly clients first. If it renders in Outlook desktop's Word engine, it renders anywhere.
6. Know where your enforcement mechanism sits
There are only three places a signature can be applied, and each is an architecture choice, not a feature checkbox:
| Where | How it works | The trade |
|---|---|---|
| In the client | User pastes it, or an add-in inserts it | Zero infrastructure; zero governance |
| In transit | A transport rule or vendor service stamps mail after sending | Covers every device - but senders never see it, reply chains stack it, and something now processes your outbound mail |
| In the mailbox | The compose signature is written centrally into each mailbox | What users see is what recipients get; no mail path involvement; covers what composes with the mailbox signature |
Exchange transport rules are the built-in version of "in transit," and they carry real limitations - we've written a full comparison of mail-flow rules vs mailbox provisioning if that's the decision you're weighing. If a third-party service does the stamping, your compliance review now includes a vendor in the outbound mail path - a consequence worth naming explicitly before you buy, and the reason Atlas Ink pushes the mailbox signature instead.
7. Treat rollout as something you verify, not announce
"We deployed the new signature" should be a claim you can check per user. Whatever the mechanism, you want a status view: applied, pending, failed - and for the failures, why. Mailboxes in litigation hold, unlicensed accounts, and service principals all fail in boring, diagnosable ways; without per-user status you find out from a customer-facing email with a three-year-old logo.
The same goes for change history. Templates should have revisions and a rollback path, because the rebrand will have a typo in the phone number, and re-pushing yesterday's known-good template beats hotfixing at 5 pm.
8. Write down who owns the signature
Finally, the organizational practice that makes the technical ones stick: name an owner. Marketing owns the template's content and brand; IT owns deployment, scoping, and enforcement; legal signs off on the footer. The failure mode isn't a missing owner - it's three partial owners who each assume someone else approves changes.
The checklist
- Directory attributes audited and maintained as part of joiner-mover-leaver
- Templates use tokens; no per-person typed text anywhere
- Tenant default + group variants + deliberate user exceptions, with documented precedence
- Drift enforcement on a schedule; unmanaged users are opt-out, not accident
- Table-based, inline-styled HTML tested in Outlook desktop first
- Applied-in-the-mailbox unless you have a hard requirement for in-transit stamping
- Per-user rollout status and template rollback
- A named owner for content, deployment, and legal
If you'd rather not build the machinery yourself, this checklist is more or less a description of Atlas Ink: author a token-driven template, assign it tenant/group/user with precedence, push it into every Microsoft 365 mailbox from your own Azure subscription, and let the daily reconcile hold the line - at $1 per active user, per month, always, billed as prepaid units via Stripe.