Every way to deploy a signature, one place to choose
WeLink meets your mail platform where it is. From the per-user Outlook add-in to organisation-wide server-side push and the Gmail API — here is exactly how each method works, and how to pick the right one.
Choose a method
Template: Signature 2026
Five deployment methods across two platforms
Microsoft 365 offers four routes; Google Workspace deploys through one centralised push. Same editor, same tracking — the method is what changes.
Outlook add-in
Per user · in the compose window
A panel built into Outlook lets each person pick their signature while composing. Multi-signature, per-template language, remembered default — including shared mailboxes. Reaches New Outlook for Windows and Mac, classic Outlook and the web.
Exchange transport rules
Org-wide · appended on send
The signature is appended server-side to every outgoing email. Nothing to install, and it applies to every client — Outlook, web and mobile. The signature is added on send rather than shown in the compose window.
Mailbox configuration
Server-side · OWA & New Outlook
The signature is written to the mailbox store that Outlook on the web and the New Outlook read (in tenants that don't enforce roaming signatures), and added automatically on new mail and replies. Server-side, nothing to install.
EWS (Exchange Web Services)
Legacy compatibility
Low-level writes through Exchange Web Services for older environments. Available for backward compatibility where the newer methods don't fit.
Gmail API push
Org-wide · Google Workspace
On Google Workspace, WeLink writes the signature to Gmail through the Gmail API for every targeted user — on each person's primary address. No install on workstations, no per-user add-in. Applies to Gmail on web and mobile.
Which method, when
Every method side by side on the axes that decide it — scope, what you install, where the signature shows, and the clients it reaches.
| Method | Platform | Scope | Install on devices | Where it shows | Clients covered | Best for |
|---|---|---|---|---|---|---|
| Outlook add-inRecommended | Microsoft 365 | Per user | None — deployed centrally | In the compose window | Outlook Win / Mac / New, web | Per-user choice & multi-signature |
| Exchange transport rules | Microsoft 365 | Organisation | None | Appended on send | All — Outlook, web, mobile | One signature for everyone, every client |
| Mailbox configuration | Microsoft 365 | Per mailbox | None | In the compose window | OWA & New Outlook | Server-side default for OWA & New Outlook |
| EWS (Exchange Web Services) | Microsoft 365 | Per mailbox | None | In the compose window | Outlook (legacy) | Older or legacy environments |
| Gmail API push | Google Workspace | Per user (primary address) | None | In the compose window | Gmail (web & mobile) | Organisation-wide Gmail deployment |
Pick the method that fits the outcome you want
Most organisations combine a couple of these. Start from what you need, and WeLink supports the rest.
You want each person to choose
Pick the Outlook add-in. Everyone selects the right signature in the compose window — multi-signature, per-template language, and a remembered default per mailbox.
You want one signature, everywhere
Use Exchange transport rules. The signature is appended server-side to every outgoing email, on every client including web and mobile — nothing to install.
You want a server-side default on OWA & New Outlook
Mailbox configuration writes the signature to the store Outlook on the web and the New Outlook read (when roaming signatures aren't enforced), auto-added on new mail and replies. Server-side, no install.
You're on Google Workspace
The Gmail API push writes the signature to Gmail for every mapped user, on their primary address. Centralised, organisation-wide, with no per-user add-in.
See deployment in detail for your platform
Each platform has its own page with the full method walkthrough, the add-in experience and the security model.
Microsoft 365 & Outlook
The four Outlook deployment methods, the add-in experience and the four-step rollout.
Microsoft 365 deploymentGoogle Workspace & Gmail
The centralised Gmail API push, directory mapping and multilingual signatures.
Google Workspace deploymentThe Outlook add-in
Per-user signature choice in the compose window — New Outlook, classic and web.
Explore the add-inDeployment questions, answered
Which method should I choose?
For per-user signature choice and multi-signature, the Outlook add-in is recommended. For one organisation-wide signature on every client, use Exchange transport rules. On Google Workspace, deployment goes through the centralised Gmail API push. Many organisations combine more than one.
Do I need to install anything on each workstation?
No. Transport rules, mailbox configuration and the Gmail API push apply server-side with nothing to install. The Outlook add-in is deployed centrally from the admin side, so there's still no per-workstation setup.
What's the difference between the add-in and transport rules?
The add-in works in the compose window: each person picks their signature before sending, and can keep several. Transport rules append a single signature server-side as the email is sent — the sender doesn't see it while composing, but it reaches every client.
Do signatures work on Outlook web and mobile?
With transport rules, yes — the signature is appended server-side, so it reaches every client including web and mobile. The Outlook add-in covers New Outlook for Windows and Mac, classic Outlook and the web.
How does Google Workspace deployment differ from Microsoft 365?
Gmail has no per-user signature add-in like Outlook. WeLink deploys to Google Workspace through the Gmail API, writing each person's signature to their primary Gmail address centrally — one organisation-wide push rather than a choice of methods.
Ready to deploy signatures your way?
Connect Microsoft 365 or Google Workspace and push your first signature campaign in minutes.
No credit card — free plan available.