Email Signature Tools and GDPR: Server-Side vs Add-In Architecture Explained
TL;DR: There are two fundamentally different ways email signature management tools work, and they have materially different data processing footprints under UK GDPR. Server-side tools process your outbound email — content, recipients, attachments — through their own cloud infrastructure. Add-in-based tools inject signatures at compose time, inside Outlook, without email leaving Microsoft’s environment. This article explains the technical reality of each model and what it means for your Article 28 obligations, your DPA, and your records of processing activities.
Why architecture is a GDPR question, not just a technical one
When your IT team evaluates email signature software, they’re typically thinking about features, pricing, and ease of deployment. When your DPO reviews the same decision, the first question should be different: what data does this tool actually process, and on what basis?
The answer is not the same for all tools in this category. It depends almost entirely on the architectural model the tool uses. Two tools can offer near-identical features — Azure AD sync, campaign banners, centralised management — while having entirely different data processing footprints. One routes your outbound email through its own cloud infrastructure. The other never touches your email at all.
Understanding the difference is not optional if you’re operating under UK GDPR. It determines what kind of processor relationship you have with the vendor, what your DPA needs to cover, and what personal data you’re responsible for as a controller.
Model 1: Server-side architecture
How it works technically
In the server-side model, the email signature vendor operates a cloud relay that sits between your Exchange Online tenant and the public internet. The flow looks like this:
- An employee composes and sends an email in Outlook
- The email leaves your Exchange Online tenant and is routed to the signature vendor’s cloud infrastructure
- The vendor’s servers process the email: they identify the sender, look up the appropriate signature template, render the signature HTML, and append it to the email body
- The modified email is forwarded on to the recipient
This is the dominant deployment model in the market. It works reliably across all devices and clients — because the signature is applied after sending, it doesn’t matter whether the employee used Outlook on Windows, Mac, mobile, or the web. The vendor’s server sees everything, so everything gets a signature.
What data is processed
This is where the GDPR implications become concrete. For the vendor’s server to append the correct signature, it must be able to read the email. In practice, the data the vendor’s infrastructure processes on every outbound email typically includes:
- The full email body — plain text and HTML content
- Recipient addresses — To, Cc, and Bcc fields, including full email addresses and display names
- The subject line
- Attachments — the email passes through the relay as a complete MIME message; attachments are present in the stream even if the vendor does not inspect them
- Sender identity — the sender’s email address and display name, used to look up the correct template
- Send timestamp and message metadata
For a professional services firm of 100 people sending an average of 40 emails per day, that is approximately 4,000 outbound emails per working day passing through the vendor’s servers — every one of which may contain client names, commercial discussions, personally identifiable information, or sensitive business correspondence.
What this means under Article 28
Under UK GDPR, any organisation that processes personal data on your behalf is a data processor. The email signature vendor, in this model, is unambiguously processing personal data on your behalf: the email body and recipient addresses contain personal data, and the vendor’s server is the mechanism by which that data moves.
Article 28 requires you to have a written contract — a Data Processing Agreement — with that processor before any personal data is processed. The DPA must cover, among other things:
- The scope and purpose of the processing
- The categories of personal data processed
- The technical and organisational security measures in place
- The sub-processor list and authorisation mechanism
- Breach notification obligations
- Data deletion on termination
For a server-side email signature vendor, the DPA scope is broad. It covers all outbound email content, which in practice means a significant proportion of your organisation’s business correspondence. Most vendors provide a standard DPA — but the scope of what you’re agreeing to is wider than many controllers appreciate when they accept it.
Sub-processors are particularly worth scrutinising. A server-side vendor’s infrastructure typically involves multiple third-party cloud services — hosting providers, CDN services, logging and monitoring tools. Each of these is a sub-processor. Under Article 28(2), you must be informed of and have authorised the use of sub-processors. Changes to the sub-processor list require notification and the right to object. Check the list in your DPA against what the vendor actually uses, and ensure the mechanism for notifying changes is active.
International transfers. If the vendor’s infrastructure is hosted outside the UK — including in the US, even if the vendor is a UK company — each email that passes through constitutes an international transfer under UK GDPR. The transfer must be covered by an adequacy decision, standard contractual clauses, or another valid transfer mechanism. The UK-US data bridge covers transfers to certified US organisations; verify your vendor’s certification status.
Model 2: Add-in architecture
How it works technically
In the add-in model, the signature vendor does not operate a relay in the email path. Instead, the vendor provides an Outlook add-in — a piece of software deployed centrally to your users via Microsoft 365 Centralised Deployment — that runs inside Outlook itself.
The flow looks like this:
- An employee opens a new compose window in Outlook
- The add-in fires an event (
OnNewMessageCompose) triggered by the Office.js event-based activation model - The add-in identifies the sender using
Office.context.mailbox.userProfile— this is available client-side, with no network call required - The add-in makes a single network request to a CDN to fetch the pre-rendered HTML signature for that user
- The signature is injected into the compose window using
setSignatureAsync() - The employee sends the email normally — it leaves Outlook and travels directly to the recipient via Exchange Online, without passing through any third-party infrastructure
The email itself never touches the vendor’s servers. The vendor’s infrastructure is involved only in serving the static HTML signature file from a CDN when the add-in requests it.
What data is actually processed
The data processing footprint of an add-in-based tool is substantially narrower:
At signature publish time (when an admin saves a template in the management portal):
- Employee profile data — name, job title, phone number, email address — used to render the personalised signature HTML
- This data is received from Azure AD / Entra ID via the Microsoft Graph API, or entered manually in the admin portal
At compose time (when an employee opens a new email):
- A CDN request is made for a static HTML file identified by a sender-keyed filename (e.g.
cdn.vendor.com/sigs/user@company.com/standard.html) - The CDN request contains the URL path — which includes the sender’s email address as an identifier — and standard HTTP metadata (IP address, timestamp, user agent)
- The email body, recipient addresses, subject line, and attachments are never transmitted to the vendor’s infrastructure
In the impression log (analytics, if implemented):
- Sender identifier (typically hashed — a pseudonymised reference rather than the full email address)
- Recipient domain only — not the full recipient email address
- Template identifier
- Timestamp
The email body is technically inaccessible to event-based add-ins at the LaunchEvent activation point in the Office.js API. This is not a policy constraint — it is an architectural property of the API surface available to the add-in. Body content is not exposed by OnNewMessageCompose event handlers.
What this means under Article 28
The vendor is still a data processor — they are processing employee profile data on your behalf to render signatures, and they may log impression data. An Article 28-compliant DPA is still required.
But the scope of that DPA is materially narrower than in the server-side model:
- It covers employee profile data (name, title, contact details) — personal data about your own employees, used to personalise signatures
- It covers impression log data — pseudonymised sender identifiers, recipient domains, timestamps
- It does not cover email body content, full recipient addresses, or any correspondence metadata
This distinction matters for several reasons. The data processed is lower-risk personal data — structured employee profile information rather than free-form business correspondence. The volume of personal data at risk in a breach is bounded and predictable. The legitimate interests basis for the processing is clear and proportionate.
The sub-processor list for an add-in-based vendor is also typically shorter and more predictable: a CDN provider (for signature asset delivery), a database host (for the admin portal), and a payment processor. In well-architected implementations, the CDN logs do not contain personal data because personal data is embedded in the pre-rendered HTML content, not in the URL path or request headers.
Side-by-side comparison
| Server-side | Add-in | |
|---|---|---|
| Email body processed by vendor | Yes | No |
| Recipient addresses processed by vendor | Yes | No (domain only, if logged) |
| Attachments pass through vendor infrastructure | Yes (in MIME stream) | No |
| Employee profile data processed by vendor | Yes (for template lookup) | Yes (for signature rendering) |
| DPA required | Yes | Yes |
| Scope of DPA | Broad — covers email content and metadata | Narrow — covers profile data and impression logs |
| International transfer risk | Higher — email content may be transferred | Lower — profile data only |
| Sub-processor exposure | Higher — email relayed through hosting chain | Lower — CDN and DB host only |
| Works on Outlook mobile | Yes | No (Outlook Mobile does not support event-based add-ins) |
| Compose-time preview for sender | No (signature added after sending) | Yes (injected before send) |
Practical implications for DPOs and IT teams
If you are using a server-side tool:
Review your DPA against the data processing scope described above. Confirm that the DPA covers email body content and recipient data — not just employee profile data. Check the sub-processor list and verify that any US-hosted infrastructure is covered by the UK-US data bridge or standard contractual clauses. Confirm breach notification timelines are specified.
Consider whether your organisation’s ROPA (Article 30 records of processing activities) reflects this processing activity accurately — specifically, whether it records that outbound email content is processed by a third-party vendor.
For organisations in regulated sectors — financial services, legal, healthcare — where email correspondence may contain client confidential information or sensitive personal data, consider whether a Data Protection Impact Assessment is warranted for this processing activity.
If you are evaluating a move to an add-in-based tool:
The DPA scope is narrower, but a DPA is still required. Confirm exactly what data the vendor logs at compose time — specifically whether impression logs contain full sender email addresses (which are personal data and require a lawful basis) or only pseudonymised identifiers and recipient domains.
Verify that the add-in is deployed via Microsoft 365 Centralised Deployment rather than a sideload or user-installed mechanism. Centralised Deployment gives your IT team control over deployment, updates, and removal — which is relevant to both operational governance and to your ability to terminate processing promptly if needed.
Be aware that add-in-based tools do not apply signatures to email sent from Outlook Mobile. For most organisations in the 50–250 employee range, mobile-sent external email is a minority of total volume, but confirm this matches your organisation’s usage pattern before committing.
A note on “privacy by architecture”
The distinction between these two models is not primarily about vendor trustworthiness or policy commitments. Both server-side and add-in vendors can be trusted, can have strong security practices, and can provide compliant DPAs.
The distinction is structural. In the server-side model, the privacy protection depends on the vendor’s policies, their security controls, and the DPA you’ve signed. In the add-in model, the privacy protection is a property of the architecture: the vendor’s infrastructure does not receive the email, not because of a policy that could change, but because the email is never routed through it.
For organisations where the privacy of outbound correspondence is a material concern — professional services, financial services, legal, regulated sectors generally — the architectural guarantee is more durable than the contractual one. A DPA can be breached. An architecture that never receives the data cannot breach what it doesn’t have.
This is the framing the ICO uses when discussing privacy by design under Article 25 of the UK GDPR: data minimisation as a technical control, not just a policy commitment.
For the foundational overview of GDPR obligations when using email signature tools, see Email Signature Tools and GDPR: What Your DPO Needs to Know. For the UK legal requirements that apply to email signature content regardless of deployment model, see Email Signature Compliance for UK Businesses: What the Law Actually Requires.
This article is for informational purposes and does not constitute legal advice. UK GDPR obligations are fact-specific — organisations in regulated sectors or with complex processing arrangements should take specialist legal advice. ICO guidance is available at ico.org.uk.