When an organization rolls out centralized email signatures, one technical choice — often invisible in the sales demo — decides where every sent message actually travels. That choice pits two architectures against each other: the signature applied server-side, which routes the email through the vendor's servers, and the signature applied client-side, inserted directly in Outlook. The difference matters enormously for confidentiality and compliance.
Two ways to apply a signature
Every signature-management solution ends in the same visible result — a consistent block at the bottom of the email — but they get there by two very different paths.
- Server-side (relay): the vendor inserts itself into the mail flow. Every outgoing email is redirected to its servers, which add the signature, then the message continues to its recipient. On Microsoft 365 this usually runs through an Exchange connector or a mail flow rule.
- Client-side (add-in): an Outlook add-in runs on the user's device or in their web session. It inserts the signature into the message body while the person is drafting. The email then follows its normal path through Microsoft 365, with no detour.
The key word is routing. Server-side adds a step to the email's path. Client-side adds none: the signature is already there before the message leaves.
The email's journey server-side
In a server-side architecture, the email is not signed on the user's device. It travels first, then receives its signature along the way. The journey looks like this:
- The employee writes and sends an email from Outlook.
- Microsoft 365 hands the message to an outbound connector that redirects it to the signature vendor's infrastructure.
- The vendor receives and processes the full message — headers and body — to identify the sender, pick the right template and inject the signature.
- The signed email returns to Microsoft 365, then goes out to the recipient.
This approach has real strengths: it applies to any mail application (including unmanaged devices), guarantees identical rendering, and enables advanced server-side features such as centrally driven marketing banners or click analytics. It is the model used by mature players in the market. The trade-off is that the content of every email passes through a third party, and the location of those servers becomes a data-residency question.
The email's journey client-side
In a client-side architecture, the signature is added before the message leaves the user's environment. The journey is shorter:
- The employee opens a new compose window in Outlook.
- An event-based add-in fires and inserts the organization's signature directly into the message body.
- The employee sends; Microsoft 365 routes the email normally, with no detour through an external server.
The add-in retrieves only what it needs to build the signature — the person's contact details and the organization's template, obtained via Microsoft Graph — not the email content. This is how ATOM Signatures works: an event-based Outlook add-in covering Windows, Mac, the web and mobile, with configuration data hosted in Canada. The email body is never transmitted to ATOM. The trade-off: insertion depends on the Outlook add-in (it does not apply to a third-party mail client that does not support it).
Comparison of the two approaches
The table below summarizes the structural differences, from the point of view of a Quebec organization concerned with how its data moves.
| Criterion | Server-side (relay) | Client-side (add-in) |
|---|---|---|
| Where the email travels | Redirected to the vendor's servers | Never leaves Microsoft 365 |
| Message content seen by the third party | Yes, to apply the signature | No — only contact details feed the template |
| Adds a routing step | Yes (connector / mail flow rule) | No |
| Data transfer outside Canada | Possible if servers are abroad | Avoided when hosting is Canadian |
| Law 25 exposure | Higher (routing + residency) | Reduced |
| Outlook platform coverage | Any app that passes through the gateway | Windows, Mac, web, mobile via the add-in |
| Advanced features (banners, click analytics) | Rich, server-driven | More targeted, no message interception |
Why client-side better protects data
The confidentiality advantage of client-side comes down to one sentence: the email is never handed to a third party to be signed. In the server-side model, the vendor's infrastructure receives the full message — including a body that may contain personal information, client data or sensitive content. The signature itself is harmless; it is the passage of the message through an external system that creates the exposure.
For an organization subject to Law 25, this matters twice over. First because the movement of personal information must be controlled. Second because, if the relay servers are abroad, each send may constitute a communication of personal information outside Quebec — which triggers a privacy impact assessment. A client-side architecture, paired with Canadian data residency, removes that transfer by design.
Architecture is not the only compliance factor, and this guide does not constitute legal advice. A server-side vendor can absolutely host its relays in Canada. The question to ask stays the same: where are the servers that see my emails pass through?
When each approach makes sense
Neither architecture is universally superior; they serve different priorities.
Server-side suits you when…
- you want dynamic marketing banners and fine-grained click analytics driven centrally;
- you must sign emails sent by systems that cannot run an add-in (line-of-business apps, unmanaged devices);
- data residency and third-party routing are not strong constraints in your context.
Client-side suits you when…
- confidentiality and data sovereignty are the priority — the message must not leave Microsoft 365;
- you are a Quebec or Canadian organization subject to Law 25 and want to limit transfers outside Quebec;
- you want a simple model, with no gateway to maintain, and all-inclusive pricing (ATOM: CAD $1 per user per month).
To compare a well-known server-side solution with ATOM's approach, see ATOM vs Exclaimer.
Frequently asked questions
What is the difference between a client-side and a server-side signature?
Server-side, every outgoing email is routed through the vendor's servers, which add the signature before delivery. Client-side, the signature is inserted directly in Outlook at compose time: the email never leaves Microsoft 365 and is never relayed by a third party.
Does the server-side approach see the content of my emails?
Yes. To insert the signature, the vendor's infrastructure receives and processes every outgoing message, body included. If those servers are outside Canada, the content — often carrying personal information — leaves the country. The client-side approach avoids this, because the email body is never transmitted to the vendor.
Does client-side work on every Outlook platform?
ATOM's event-based add-in covers Outlook on Windows, Mac, the web and mobile (iOS, Android). Insertion happens at compose time. Server-side, by contrast, applies to any email that passes through the gateway, regardless of the app, but at the cost of routing the entire message.
Does the architecture change anything for Law 25?
Yes. A server-side signature can result in personal information being communicated outside Quebec if the servers are abroad, which triggers an assessment. Routing-free client-side, hosted in Canada, avoids that transfer and lightens compliance.
A routing-free signature, hosted in Canada. ATOM Signatures inserts your organization's signature directly in Outlook, client-side: your email never leaves Microsoft 365.
Go further: email signatures and Law 25 and Canadian data residency.