By David,
Every Microsoft 365 tenant already owns a signature mechanism. Exchange Online's mail flow rules (transport rules) can append a block of HTML to every outbound message, with conditions and exceptions, for free, today. Plenty of organizations run exactly this - and every admin who has knows both halves of the experience: the fifteen minutes it takes to set up, and the years of quietly living with what it can't do.
This comparison takes the built-in option seriously, because it has a narrow job it does well. But "free" describes the license, not the cost - and the costs of transport-rule signatures land on users, recipients, and the IT queue instead of a budget line.
The short version: a mail flow rule stamps the signature onto messages in transit - after the sender hits Send. That mechanism guarantees a disclaimer on every message, and it also guarantees the sender never sees it, replies stack it, and rendering is at the mercy of what the transport service can append. Atlas Ink writes each user's own Outlook compose signature, hydrated from Entra ID, from a service in your own Azure subscription - so the signature is present while typing, native in the client, and centrally governed. Rules are right for bare legal disclaimers; provisioning is right for signatures humans are meant to see.
How each mechanism actually works
Mail flow rules operate inside Exchange Online's transport pipeline. A rule matching your conditions ("sender is inside the organization," "recipient is external") appends or prepends an HTML disclaimer to the message as it passes through. The user's client is not involved; the signature exists only on the delivered copy. This is Microsoft's own recommended mechanism for organization-wide legal disclaimers - language that must appear on every message and that no user may remove.
Atlas Ink, by default, never touches the transport pipeline. It resolves which template applies to each user (tenant, group, or user scope - most specific wins), fills the tokens from that user's Entra ID profile, and writes the result into the mailbox as the user's Outlook signature via the Exchange admin API. Outlook then composes with it, the way a hand-crafted signature would appear - except it's centrally authored, current, and re-applied daily if anyone edits it. (Outlook's roaming signatures solved per-user sync; they didn't add central governance - that's the gap provisioning fills.)
Same tenant, same Exchange - two different layers. Which is why their failure modes don't overlap at all.
One honest footnote: Atlas Ink also offers an opt-in server-side stamping mode for the clients a mailbox signature can't reach - classic desktop Outlook, Apple Mail, and other non-Outlook apps. It's built on exactly the mechanism above: one mail-flow rule, created in your own Exchange Online for the users you enroll in it. So for those users the signature is applied after Send, and a stamped signature appends at the bottom of the thread on replies. An admin has to turn it on explicitly, it isn't available in GCC or GCC High, and mail still never routes through Atlas.
The four problems every transport-rule admin knows
1. The sender composes blind. The signature is applied after Send, so the person writing the email sees no signature at all - and neither does their Sent Items copy, depending on configuration. Users conclude they have no signature and add their own by hand. Now every external message carries the homemade signature and the stamped one, which is exactly the inconsistency the rule was meant to end.
2. Reply chains stack. The rule can't reliably know it already stamped an earlier message in the thread, so long conversations accumulate a disclaimer per hop. Exchange's "stop processing" and one-time-append options mitigate but don't eliminate it, particularly across mixed internal/external threads. Every recipient has scrolled through a five-disclaimer chain; that's transport stamping at work.
3. Rendering is the weak layer. Transport-appended HTML is inserted where the pipeline decides - typically the very bottom of the message body, below the quoted thread rather than under the new reply. Embedded images are the classic casualty: the mechanics available to a transport rule tend to produce broken-image icons or attachment clutter, which is why so many rule-based signatures are text-only by surrender.
4. Personalization is shallow. Rules can substitute Active Directory attributes into the disclaimer, so "%%displayName%%" works. But it's one template per rule - per-department variants mean a growing pile of rules with mutually exclusive conditions, evaluated on every message, maintained by hand, with no per-user status, no revision history, and no rollback beyond "edit the rule back."
The side-by-side
| Atlas Ink | Exchange mail flow rules | |
|---|---|---|
| Where the signature is applied | Written into the mailbox; Outlook composes with it | Stamped in transit, after Send |
| Sender sees it while composing | Yes - it's their signature | No |
| Reply-chain behavior | One signature, where the client puts it | Disclaimer stacking risk per hop |
| Images and layout | Native client rendering | Transport-append limitations; images unreliable |
| User can remove it | Enforced by daily reconcile; per-user unmanaged opt-out | Cannot remove - stamped regardless |
| Per-user variants | Tenant → group → user scopes with precedence | One rule per variant; conditions maintained by hand |
| Directory data | Entra tokens hydrated per user at push | AD attribute substitution in the disclaimer |
| Rollout visibility | Per-user applied / pending / failed | Message trace, if you go looking |
| Change management | Template revisions and rollback | Edit the rule; hope |
| License cost | $1/user/mo, metered | Included in Microsoft 365 |
Run both layers
Mail flow rules and Atlas Ink work side by side. Keep a rule for the job it was designed for - a plain-text legal disclaimer on mail from scanners, CRM sends, and other systems - and let Atlas Ink handle the signatures people actually see. No mail routes through Atlas, ever, so the two never touch each other.
What provisioning gives you
Flip it around: buy provisioning when the signature is meant to be seen - brand, contact details, current titles - because that's precisely what stamping does worst. What you're paying for, concretely: the signature present while composing, tokens that update when the org chart does, scoped variants without a rules pile, drift enforcement with a per-user opt-out, per-user rollout status, and template rollback when the rebrand ships a typo.
And notice what the two mechanisms have in common when you pick this split: the disclaimer rule keeps running untouched for the mail that needs it, while humans compose with real signatures. The architectures don't conflict - they're solving different layers of the same tenant.
The verdict: keep a transport rule for any legal footer your policy requires, and give your people real signatures on top. If your requirement is what "email signature management" usually means - every mailbox on brand, visible to the people sending, current with the directory - the built-in mechanism was never designed for that, and the full architecture comparison shows how the mailbox-push model answers it. Start with what a pushed signature looks like end to end, and if you're formalizing your rollout either way, our Microsoft 365 signature best-practices guide applies to both architectures.