By David, , updated
Server-side email signatures are added after the user clicks Send, by a mail flow rule or by a service the mail is routed through, so every message from every device gets one, but the sender can't see it while writing and on replies it usually lands at the bottom of the thread. Client-side signatures are added while the user writes, by the email client itself or by an add-in, so the sender sees exactly what goes out and it sits right under their reply, but only clients that support it apply it. Many organizations use both: client-side for everyday mail, server-side for the clients and devices the first can't reach.
The short version: If every message from every device must carry the signature, including phones' built-in mail apps and system-generated mail, you need a server-side layer. If you want senders to see their signature, replies to look right, and no service in your mail path, use a client-side approach. If you need both, combine them and scope each to the users who need it.
The three ways a signature gets onto an email
It helps to split client-side in two, because the two halves behave differently.
1. Server-side: added in the mail flow
After the message leaves the user's client, something in the mail flow adds the signature. There are two forms:
- A mail flow rule in your own Exchange Online, also called a transport rule or disclaimer rule. Exchange appends HTML or text, filling in sender details from the directory. Nothing leaves Microsoft 365.
- A vendor service. Exchange Online connectors route outbound mail to the vendor's cloud, which adds the signature and sends the message back to Exchange for delivery. Most server-side signature products work this way.
2. Client-side, by add-in
An Outlook add-in inserts the signature when the user starts a new message, reply or forward. Modern add-ins use Outlook's event-based activation, which Microsoft supports in Outlook on the web, new and classic Outlook for Windows, the new Outlook for Mac, and Outlook for iOS and Android.
3. Client-side, from the mailbox
Outlook adds a signature it already has. In Outlook on the web and new Outlook, that signature is stored in the mailbox, and an admin or a signature tool can write it there centrally with Exchange Online PowerShell once roaming signatures are turned off. Our guide to signatures in new Outlook covers how that works.
Side by side
| Server-side (mail flow rule) | Server-side (vendor service) | Client-side add-in | Client-side mailbox signature | |
|---|---|---|---|---|
| When it's added | After Send | After Send | While writing | While writing |
| Sender sees it while writing | No | No | Yes | Yes |
| In the sender's Sent Items | No | Depends on the product | Yes | Yes |
| Position on replies | Top or bottom of the whole message, not under the latest reply | Product-dependent; most can place it under the reply | Under the reply | Under the reply |
| Phones' built-in mail apps, other clients, system mail | Yes | Yes | Only where the add-in runs | Only Outlook clients that read the mailbox signature |
| Who handles your outbound mail | Microsoft only | The vendor's service, on every external message | Nobody new | Nobody new |
| Encrypted or signed mail | Falls back to wrap, ignore or reject | Product-dependent | Signature is part of the message before it's signed | Signature is part of the message before it's signed |
| Images | Linked, not embedded | Product-dependent | Supported | Supported |
| Works if the service is down | Yes, it's Exchange | Depends on the connector setup | Depends on the add-in | Yes, it's already in the mailbox |
What server-side does well, and what it costs
Coverage is the reason to choose it. A rule in the mail flow doesn't care whether the message came from Outlook, Apple Mail, a phone's built-in mail app, a scanner or a line-of-business system. If a policy says every external message must carry certain text, only a server-side layer can guarantee it.
The costs are real, though:
- The sender is writing blind. People who can't see their signature add their own, and recipients get two.
- Replies look wrong. Microsoft's documentation is direct about its own rules: you "can't insert the signature directly under the latest email reply or forward," and without an exception the text repeats on every message in a thread. Vendor services handle this better, but the signature still appears after the message is sent.
- Encrypted mail is a special case. When an Exchange rule can't change a message, for example because it's encrypted, it falls back to one of three actions: wrap the original as an attachment inside a new message that carries the disclaimer (the default), ignore and deliver it without one, or reject it.
- A vendor service adds a party to your mail path. Routing every external message through a third party is a design choice your security review has to accept and document, however well the vendor runs it. Check where the service runs, what it keeps and for how long.
What client-side does well, and what it costs
The sender sees what the recipient sees, including on replies, and the signature sits where people expect it. Nothing new handles your mail, so a mail-privacy review has nothing to add.
The costs:
- Coverage depends on the client. An add-in only works where it's deployed and running; a mailbox signature only appears in Outlook clients that read it. Classic Outlook for Windows, for example, keeps its own signatures, and phones' built-in mail apps don't read Outlook signatures at all.
- Users can change it. A client-side signature can be edited or deleted. A good tool notices and puts it back; a script usually doesn't.
- Add-ins have runtime limits. Microsoft caps how many event-based add-ins run at once and how long they can take, especially on mobile.
How to choose
- Write down what must carry the signature. If the answer includes mail from phones' built-in apps, shared devices or systems, you need a server-side layer for at least that mail.
- Write down who may handle your outbound mail. If the answer is "nobody but Microsoft", that rules out vendor relays but still leaves Exchange's own rules.
- Check your clients. If almost everyone uses Outlook on the web and new Outlook, a mailbox signature covers them with no add-in; test the Outlook mobile apps, which Microsoft's mailbox signature documentation doesn't cover. Lots of classic Outlook, Mac or mobile users point to an add-in, or to a server-side rule for those users.
- Combine where it helps. A common pattern is client-side signatures for people and a mail flow rule for a short legal footer, which keeps the footer guaranteed and the signature looking right. Our guide to signature legal requirements by country covers what that footer needs.
How Atlas Ink handles both
Atlas Ink, our signature product, is client-side by default and server-side by choice. It writes each user's signature into their mailbox from your own Azure subscription, so it appears while they write in Outlook on the web, new Outlook and Outlook for iOS and Android, on new mail and replies, and a daily reconcile puts it back if someone changes it. No mail is ever routed through Atlas.
For users on classic Outlook or non-Outlook apps, an admin can turn on optional server-side stamping. It's a mail flow rule, the first server-side form above, created in your own Exchange Online and scoped to just those users, so nobody gets two signatures. Atlas configures the rule but never sits in it. Stamped signatures behave like any mail flow rule signature: they're added after Send, they append at the bottom of the thread on replies, and S/MIME-signed or encrypted messages are delivered unstamped. It needs explicit admin consent and the Exchange Administrator role, and it isn't available in GCC or GCC High.
Comparing products rather than approaches? See Exclaimer alternatives, CodeTwo alternatives, and what "push, never intercept" means for email compliance.
FAQ
What is a server-side email signature?
A signature added after the user clicks Send, by a mail flow rule in Exchange or by a service the mail is routed through. It applies to every message whatever device sent it, but the sender doesn't see it while writing.
What is a client-side email signature?
A signature added while the user writes, either by the email client from a stored signature or by an add-in. The sender sees it, it's in Sent Items, and it sits under their reply, but only clients that support it add it.
Are server-side signatures more secure?
Not inherently. A mail flow rule in your own Exchange Online keeps everything inside Microsoft 365. A vendor's server-side service routes your outbound mail through a third party, which widens what your security review has to cover. Client-side approaches add no one to the mail path.
Why does my server-side signature appear at the bottom of the email thread?
Because it's added to the whole message after Send, not inserted where the user was typing. Microsoft notes its mail flow rules can't place a signature directly under the latest reply or forward.
What happens to server-side signatures on encrypted email?
An Exchange mail flow rule can't change an encrypted message, so it applies its fallback action: wrap the message as an attachment inside a new one, deliver it without the signature, or reject it. Client-side signatures don't have this problem, because the signature is part of the message before it's encrypted.
Can I use server-side and client-side signatures together?
Yes, and many organizations do. The usual rule is to scope them so no user gets both: client-side for Outlook users, server-side for the clients it can't reach, or a short server-side legal footer under a client-side signature.
Last updated 9 November 2026. Microsoft details are drawn from Microsoft Learn as of November 2026: disclaimers, signatures, footers or headers with mail flow rules, signatures and disclaimers in Microsoft 365, event-based activation for Outlook add-ins and on mobile, and Set-OrganizationConfig.