Client-Side vs Server-Side Email Signatures: How Each Works and Which to Choose (2026)

TL;DR: Client-side signatures are inserted inside the email app, so people see them while writing and mail never leaves Microsoft 365 or Google Workspace, but coverage depends on each app (Gmail for Android and Apple Mail, for example, can't be managed this way). Server-side signatures are added in transit by a mail flow rule or relay, so they cover every device and any tool that sends through the mailbox, but the sender doesn't see them and mail takes an extra hop. Most companies run client-side by default and server-side as a fallback for the gaps.

Last reviewed: October 2026.

"Client-side or server-side?" is the first architecture question in any email signature rollout, and the one security, IT and marketing most often disagree on. This guide explains how each approach works in Microsoft 365 and Google Workspace, compares them on the points that matter in practice (compose view, mobile, CRM email, replies, data path, deliverability, failure modes), and ends with a decision table by company type. Step-by-step setup is in the Microsoft 365 guide and the Google Workspace guide.

What is a client-side email signature?

A client-side signature is written into the email client, or into the mailbox settings the client reads, before the message is sent. The signature is part of the message from the moment the user starts writing. There are three ways vendors do it:

• Outlook add-ins (Microsoft 365). A web add-in deployed by the admin uses Outlook's event-based activation. When a user starts a new message, reply or forward, Outlook fires OnNewMessageCompose and the add-in inserts the signature. Microsoft supports that event in Outlook on the web, the new and classic Outlook for Windows, the new Outlook for Mac, and Outlook for iOS and Android (Activate add-ins with events, Microsoft Learn).
• Mailbox settings via API (Google Workspace). Gmail keeps a signature on each send-as address, and the Gmail API can set it (Google for Developers). A signature app updates every user's settings centrally; Gmail then shows it in the compose window.
• Desktop agents. For clients that support neither, such as Apple Mail or Outlook for users without a Microsoft 365 cloud license, a small app on the computer writes the signature locally. Scribe documents a desktop app for these cases, deployable silently through RMM tools on Windows (Scribe: Outlook Windows RMM).

The native equivalent is simply each user's own signature in Outlook or Gmail settings. It's client-side too, but without central control.

What is a server-side email signature?

A server-side signature is added after the message leaves the sender's device, while it's in transit through the mail system. Nothing is installed on devices. In Scribe's description, server-side installation "changes your mail routing, not your teammates' mailboxes" (Scribe: Microsoft 365 server side). The flow:

1. A user sends from any client or device; the mail platform accepts it.
2. A routing rule sends matching outbound mail to the signature service over TLS. In Microsoft 365 that's a mail flow rule plus an outbound connector to a smart host; in Google Workspace it's a content compliance rule plus a mail route (host).
3. The service inserts the right signature for the sender and context, re-signs the message, and stamps a header (Scribe uses X-Scribe-Processed).
4. The message returns through an inbound connector (Microsoft) or the SMTP relay service (Google) that only accepts the service's IP addresses.
5. The header matches the rule's exception, so the message isn't routed again, and the platform delivers it normally.

The native equivalents are Exchange Online's "Apply disclaimers" mail flow rule (Microsoft Learn) and Google Workspace's Append footer (Google). Both run in transit, but they add the same block for everyone in scope, with limited personalization and no design tooling.

How do client-side and server-side compare?

Question	Client-side	Server-side
Does the sender see the signature while writing?	Yes	No
Is it in the Sent folder copy?	Yes	No; Sent Items keeps the pre-processing version
Outlook web, desktop, iOS, Android	Yes, via add-in (supported builds)	Yes
Gmail web and iOS	Yes	Yes
Gmail for Android	No	Yes
Apple Mail (Mac, iPhone)	Only with a per-device desktop app or manual install	Yes
CRM and sequencer email sent through the user's mailbox	Only where the tool has its own integration	Yes, if the From address belongs to a managed user
Marketing platforms sending from their own servers	No	No
Reply and internal variants	Outlook: yes. Gmail: one signature in settings, no variants	Yes, chosen per message
Does mail leave your email provider?	No	Yes, one TLS hop to the vendor and back
DNS and authentication changes	None	DKIM record for the relay; vendor re-signs
Who can set it up	Global Admin or super admin, minutes	Exchange or Gmail admin, connectors and rules
Can users override it?	Managed tools re-apply the approved version	No
If the vendor has an outage	Existing signatures stay in clients; updates pause	Depends on routing design; ask the vendor
Rollback	Remove the add-in or app	Disable one rule

The coverage rows for Scribe specifically come from its mobile matrix: client-side works in the Gmail iOS app and the Outlook apps for iOS and Android but not in the Gmail Android app or Apple Mail, while server-side covers web, desktop (including Apple Mail), iOS and Android (Scribe: do signatures work on mobile?). The variant behavior is from Scribe's variants page, and the CRM behavior from its HubSpot server-side page: one-to-one, sequence and reply emails sent from HubSpot through a connected Gmail or Outlook inbox get the signature; marketing and automated workflow emails don't.

What are the pros and cons of each?

Client-side

• Pro: what you see is what they get. Users can check their details and the active banner before sending, which also reduces "my signature is wrong" tickets.
• Pro: no change to mail flow. Mail stays inside Microsoft 365 or Google Workspace. That simplifies security review, archiving and journaling, and there's no added hop.
• Pro: faster to deploy. A marketplace install and consent, no DNS.
• Con: coverage gaps. Apps that don't allow signature injection, older Outlook builds and unmanaged devices are missed.
• Con: Gmail has no per-context variants when the signature lives in settings.
• Con: propagation delay. Microsoft notes that admin-deployed add-ins can take 24 to 72 hours to appear (Microsoft Learn).

Server-side

• Pro: every device and client, including personal phones using company accounts, and tools that send through the mailbox.
• Pro: enforcement. Users can't remove it. That's why regulated firms use it for required disclosures (see the disclaimers guide).
• Pro: context-aware. Reply and internal variants are chosen per message.
• Con: invisible to the sender, and absent from Sent Items and CRM-logged copies.
• Con: mail transits a third party. Your security, privacy and, in healthcare, BAA review has to cover the vendor.
• Con: more moving parts. Connectors, rules, DKIM per domain, and rule ordering with other transport rules and archiving.

Can you run both, and how does the tool pick?

Yes, and it's the most common setup for companies over 100 people. The risk is a double signature, so the tool needs a rule for which path wins. Scribe's documented behavior: when both integrations are connected, it defaults to client-side so users see their signature while composing, and server-side acts as a fallback for apps and devices where client-side isn't supported (Scribe integrations overview). As a second guard, the server checks whether the body already carries the signature before inserting one, so a message that reaches it twice still goes out with a single signature (Scribe docs).

When you combine them, test the edge cases explicitly: a reply from Gmail on Android to a thread started on the web; a sequence email from your CRM; an email from a shared mailbox; and a message from a user whose signature isn't installed (it should go out without a signature, not with someone else's).

What does this look like for a real company?

Take a 400-person company on Microsoft 365. Most staff use Outlook on Windows and the Outlook mobile app. Thirty sales reps send sequences from a CRM connected to their Exchange Online mailbox. Fifteen designers use Apple Mail on Macs. Legal requires the UK company details on every external email.

Group	Client-side only	Server-side only	Both
Outlook desktop and mobile users (355)	Signature in compose, variants in replies	Signature added after send; not visible to the sender	Client-side used; server-side idle for them
Sales reps, CRM sequences (30)	Outlook mail covered; sequence emails missing a signature	All covered	Outlook mail client-side, sequences server-side
Designers on Apple Mail (15)	Missing unless a desktop app is installed on each Mac	Covered	Covered by server-side
Legal footer on every external email	At risk wherever client-side can't reach	Enforced	Enforced

Client-side alone leaves 45 people with gaps on some or all of their mail, including the sales team's highest-volume sending, plus a compliance gap. Server-side alone covers everything but takes away the compose preview for 355 people who had it. Running both gives every group the best result, at the cost of one security review for the relay and a DKIM record per sending domain.

Now change one thing: the company's security policy forbids routing mail through third parties. The answer becomes client-side for everyone, a desktop app pushed to the 15 Macs through the company's device management tool, and a signature configured directly in the CRM for sequences. The legal footer can then be enforced with a native Exchange Online mail flow rule, which runs in transit inside Microsoft 365, accepting that it looks different from the designed signature.

The same logic applies on Google Workspace, except that Gmail for Android joins Apple Mail on the "not covered client-side" list, and reply or internal variants are only available server-side.

What security questions should you ask about server-side signatures?

These are the questions a security team will raise, with the answers Scribe publishes for its own relay. Ask any vendor for the same level of detail.

Question	What to look for	Scribe's documented answer
Which mail is routed?	Only outbound from your users; never inbound	Microsoft 365: senders located InOrganization. Google: outbound and internal-sending, excluding Google system mail. Inbound external mail is never routed.
Is transport encrypted?	Enforced TLS both ways, certificate validation	Outbound connector requires TLS with a CA-issued certificate matching smtp.server.scribe-mail.com; returns accepted only from two fixed IPs (Google: TLS required on the relay)
What does the vendor change?	Signature only; no body, recipient or attachment changes	Inserts the signature and adds its own headers; recipients, subject, attachments and body text pass through unchanged
What about DKIM?	Re-signing for your domain after modification	New DKIM-Signature with a key published at scribe._domainkey, plus an ARC chain (RFC 8617)
SPF and DMARC?	Final delivery still from your provider	SPF unaffected because Microsoft or Google makes the final delivery; DMARC alignment relies on the re-signed DKIM
Can the vendor read mail?	Processing limited to signature insertion; audited controls	Scribe states it "cannot read or edit your emails" and that processing is limited to adding the signature; controls are covered by its SOC 2 Type II process
Loop prevention	Header-based exception	X-Scribe-Processed exception in the rule, plus a body check
Rollback	Single switch	Disable the mail flow rule (Microsoft) or the content compliance rule (Google)

Sources: Microsoft 365 server side, Google Workspace server side, mobile, security. Questions Scribe's public docs don't answer yet, and that you should raise with any vendor: added latency per message, behavior and queuing if the relay is unavailable, message retention on the relay, data residency of the relay, and interaction with journaling and archiving tools.

For client-side deployments, the review is about permissions instead. Scribe's Gmail app uses only the Gmail settings scopes (gmail.settings.basic, gmail.settings.sharing), which can't read mail (Scribe docs), and its Microsoft directory sync uses read-only Graph permissions (Scribe docs).

Which should your company choose?

Your situation	Recommended	Why
Microsoft 365, most users on Outlook desktop and mobile	Client-side add-in; add server-side only if Apple Mail or third-party apps matter	The add-in already covers Outlook on all platforms
Google Workspace with many Android users	Client-side plus server-side	Gmail for Android can't be managed client-side
Regulated disclosures (finance, legal, healthcare)	Server-side enforcement, client-side for visibility	Disclosures must be on every email, from any device
Sales teams sending sequences from a CRM through their inbox	Server-side (or the CRM's own integration)	Mail sent through the mailbox gets the signature in transit
Security policy forbids third-party mail routing	Client-side only	Mail never leaves your provider
Healthcare organization emailing PHI	Client-side by default; server-side only after BAA review	Routing PHI through a vendor makes it a business associate question
Mixed estate: Exchange on-premises or unlicensed Outlook	Desktop agent via RMM for those users, add-in for cloud users	Cloud add-ins and Exchange Online rules don't reach on-premises mailboxes
Marketing wants per-message banners and reply variants in Gmail	Server-side	Gmail settings hold one signature with no variants

A quick checklist before you decide:

1. List every client and device that sends company email, with rough user counts.
2. List every system that sends as your users (CRM, sequencer, help desk, scheduling tools) and whether it sends through the mailbox or its own servers.
3. Identify which content is legally required versus brand or marketing.
4. Ask security whether third-party mail routing is allowed, and under which conditions.
5. Check archiving, journaling and DLP rules that might interact with a routing rule.
6. Decide who owns rollback, and test it.

What does Scribe offer for each approach?

Deployment	Platforms	Notes
Client-side, automated	Microsoft 365 (Outlook web, desktop, iOS, Android), Google Workspace (Gmail web, iOS), Zoho Mail, Front, Outreach, Salesforce, Salesloft	Admin installs once; no user action
Server-side, automated	Microsoft 365, Google Workspace	All clients and devices; IT setup required
Manual or RMM	Apple Mail, Outlook for Mac, Outlook for Windows, signature HTML	Per user, or silent deployment through RMM tools

Source: Scribe integrations overview. Scribe recommends client-side for most teams and supports running both. Installation state per email address is visible in the dashboard and through the API, and the MCP server lets an admin ask an assistant such as Claude or ChatGPT which integrations are failing. Integration pages: Microsoft 365, Microsoft 365 server side, Google Workspace, Google Workspace server side, Apple Mail.

Frequently asked questions

What is the difference between client-side and server-side email signatures?

Client-side signatures are inserted in the email app before sending, so the sender sees them and mail stays in Microsoft 365 or Google Workspace. Server-side signatures are added in transit by a mail flow rule or relay, so they cover every device and client but are invisible to the sender.

Which is better for mobile?

Server-side. It adds the signature after the message is sent, so it works from any app. Client-side coverage depends on the app: Scribe's client-side install works in Outlook for iOS and Android and the Gmail iOS app, but not in Gmail for Android or Apple Mail. Scribe supports Gmail for Android only with server-side installation, on the Business and Enterprise plans.

Do server-side signatures appear in Sent Items?

No. The signature is added after the message leaves the mailbox, so the Sent Items copy, and any copy logged in a CRM, is the version from before processing. Recipients always receive the signature.

Does a server-side signature break DKIM or DMARC?

Inserting a signature changes the body and invalidates the original DKIM signature, so the relay must re-sign. Scribe re-signs with a key published at scribe._domainkey and adds an ARC chain; SPF is unaffected because Microsoft or Google still makes the final delivery.

Can I use client-side and server-side together?

Yes. Scribe defaults to client-side when both are connected so users see their signature while composing, uses server-side as a fallback for unsupported apps, and checks for an existing signature to avoid duplicates.

Do server-side signatures work with CRM emails?

For email a CRM sends through the user's Gmail or Outlook mailbox, yes, as long as the From address is a managed user. Scribe documents this for HubSpot one-to-one, sequence and reply emails. Marketing emails a platform sends from its own servers never pass through your mail system and get no signature.

Is server-side signature routing safe?

Evaluate it like any mail relay: enforced TLS, fixed return IPs, header-based loop prevention, DKIM re-signing, no changes to content, audited controls and a one-step rollback. Scribe documents each of these and states it is SOC 2 Type II compliant. Ask about latency, outage behavior, retention and data residency.

Related Handbook guides

• Microsoft 365 and Exchange Online company-wide signatures
• Google Workspace company-wide signatures
• Email disclaimers by country and industry
• Office 365 email signature management