By David,
Here's the lifecycle every IT team knows: the new signature ships on Monday, looks perfect through Friday, and by month's end the exceptions have begun - a bolder font here, a deleted legal footer there, an inspirational quote in italics. Within a quarter the tenant is back to the zoo the project was supposed to end, except now the zoo is IT's fault.
The instinct is to blame users, and the instinct is wrong. Drift is simply what happens to any configuration that's editable but not enforced - signatures just happen to be the one piece of company-visible branding every employee can edit. You don't fix that with reminder emails. You fix it the way you fix every other config-drift problem: reconciliation.
Why people break signatures (a field taxonomy)
Worth naming, because each type needs a different response:
- The improver thinks the standard is ugly and can do better. Font changes, spacing "fixes," a headshot.
- The trimmer deletes the legal footer or the second contact line "to keep emails clean." Often your most senior senders.
- The rebuilder lost the signature after a client reinstall and reconstructed it from memory - old logo, old title, wrong phone.
- The personalizer adds pronouns, quotes, causes, or seasonal flourishes - some of which you may want to allow, which is a policy question, not an enforcement one.
- The ghost is a new joiner who never got the signature at all and invented one. Not drift technically - rollout failure - but indistinguishable to recipients.
Notice what's absent: malice. Every type is someone reasonably exercising an editability nobody told them they didn't have. Which is exactly why announcements don't work - the policy exists only in email archives, while the edit box sits right there in Outlook.
The enforcement model that works
Reconcile on a schedule, silently. Atlas Ink re-applies each managed user's assigned signature daily: if someone edited or cleared it, the correct version is quietly restored within a day. No confrontation, no ticket, no all-staff reminder - the system just holds its shape, the way group policy holds a desktop setting. One rollout plus reconciliation beats a hundred perfect rollouts without it.
Make exceptions deliberate, not accidental. Some people should keep custom signatures - the founder, the exec whose assistant manages correspondence, the board liaison. The wrong way to handle them is enforcement that quietly loses to whoever complains loudest. The right way is a per-user unmanaged switch: flipping it is an explicit, auditable decision, the exception list is visible instead of folklore, and everyone else stays enforced. Exceptions you chose are policy; exceptions that accumulated are drift with paperwork.
Verify state, don't assume it. Per-user rollout status - applied, pending, failed - turns "we deployed the signature" from an announcement into a checkable claim, and catches the ghosts: mailboxes where the push failed for boring, diagnosable reasons (litigation hold, unlicensed account) before recipients notice a three-year-old logo.
Keep rollback one action away. Enforcement cuts both ways: when the rebrand template ships with a typo in the phone number, the daily reconcile will faithfully enforce the typo. Template revision history with rollback means the fix is re-push yesterday's known-good version - not a second emergency project.
Why not just stamp over everyone?
There is a blunter enforcement mechanism: transport-rule or server-side stamping, which rewrites mail in transit so whatever users do, the stamped signature wins. It's genuinely unbeatable for unremovable legal disclaimers - and it earns its keep there. As a drift solution for human signatures it creates the problems we've documented in the full comparison: senders compose blind (so they add their own signature anyway, and now there are two), reply chains stack blocks, and a service now processes your outbound mail - a compliance surface purchased to fix fonts. Mailbox-level reconciliation enforces at the same layer users edit, so what they see is what's enforced, and the mail path stays empty.
The policy conversation to have once
Enforcement machinery makes the policy question unavoidable, which is healthy. Decide once, write it down: what's locked (legal footer, brand block, token-driven facts), what's flexible (pronouns? a booking link?), and who's unmanaged (the named exception list). Flexible elements belong in the template as sanctioned variants - a group-scoped version with the booking link, say - rather than as tolerated free-editing, scoped through the same precedence system as everything else.
The end state worth aiming for: signatures that stay correct structurally - directory-fed, scope-assigned, reconciled daily, exceptions on a named list - rather than correct for now because the reminder email is recent. That's the difference between managing signatures and chasing them, and it's the product.