Does Your Email Signature Tool Route Your Emails Through Third-Party Servers? (A GDPR Question Worth Asking)
TL;DR: A significant number of email signature management tools work by routing your outbound email through their own cloud infrastructure before delivery. Under UK GDPR, this makes the vendor a data processor of your email content — which creates legal obligations you are responsible for meeting. This article explains what that means, what a Data Processing Agreement must cover, what questions to ask any vendor, and what a privacy-safe architecture looks like. It is written for IT admins, DPOs, and compliance managers who want to understand the issue before choosing or renewing a tool.
Your organisation’s outbound email probably contains personal data. Employee names and contact details in signatures. Customer names in the body of messages. References to individuals in the normal course of business correspondence. Under UK GDPR, your organisation is the data controller for that data — you determine the purposes and means of processing it, and you’re responsible for ensuring it’s handled appropriately.
The question most organisations don’t ask when evaluating email signature management tools is: what happens to that email on its way to the recipient?
For a significant portion of the market, the answer is: it passes through the vendor’s servers.
How Server-Side Email Signature Tools Work — and Why It Matters for GDPR
Many email signature management tools — particularly the larger, more established players in the market — use an architecture called server-side routing. When an employee sends an email, it doesn’t go directly from Microsoft 365 (or Google Workspace) to the recipient. Instead, it is redirected — via a connector configured in Exchange Online — through the vendor’s cloud infrastructure. The vendor’s platform receives the email, identifies the sender, appends the correct signature, and forwards the email to its destination.
This approach has a legitimate technical rationale: it works across every mail client and device, regardless of what the employee is using to send.
But it has a legal consequence that deserves attention.
When your employees’ outbound emails — including message bodies, attachments, and any personal data contained within them — pass through the vendor’s servers for processing, the vendor is acting as a data processor of that content under UK GDPR.
This is not a technicality. It is a defined legal relationship with specific obligations attached.
What “Data Processor” Actually Means Under UK GDPR
The UK GDPR makes a fundamental distinction between data controllers and data processors.
A controller determines the purposes and means of processing personal data — in this case, your organisation. You decide that email will be used for business communications, and you’re responsible for ensuring that processing is lawful.
A processor processes personal data on behalf of a controller. When a vendor’s platform receives your employees’ emails and processes them to append a signature, that vendor is operating as a processor of the personal data in those emails.
Under Article 28 of UK GDPR, this relationship creates a specific legal requirement: processing by a processor must be governed by a written contract — commonly called a Data Processing Agreement (DPA) — that binds the processor to the controller and sets out specific provisions.
The ICO is explicit on this: every time a controller uses a processor to process personal data, there must be a written contract. There is no threshold below which this requirement doesn’t apply. It is not optional.
If you are using a server-side email signature tool and you do not have a signed DPA with the vendor, you are not compliant with Article 28 — regardless of how reputable the vendor is, or how long you’ve been using the product.
What a Data Processing Agreement Must Cover
The DPA isn’t just a formality. Article 28(3) of UK GDPR specifies a set of provisions it must contain. In practical terms, for an email signature vendor acting as a processor of your email content, the DPA should address:
1. Processing only on your instructions The vendor must process personal data only on your documented instructions. In the context of an email signature tool, this means the vendor processes email content solely for the purpose of appending your organisation’s signature — not for any other purpose.
2. Confidentiality obligations on vendor staff Anyone authorised to access personal data at the vendor must be under a confidentiality obligation. Ask specifically whether vendor personnel have access to email content in the course of their work, and what controls exist.
3. Security measures The DPA must address the technical and organisational measures the vendor has in place to protect the data. This includes encryption in transit, access controls, and incident response procedures. ISO 27001 certification is a relevant indicator here, though it isn’t the only standard.
4. Sub-processors If the vendor uses sub-processors — other third parties involved in the processing — the DPA must specify this. You should be able to see a list of sub-processors and must have either given specific consent to each, or general authorisation subject to the right to object if the list changes. Cloud providers (AWS, Azure, GCP) used to host the signature processing infrastructure are typically sub-processors.
5. Data subject rights The vendor must assist you in responding to requests from individuals exercising their data subject rights — access requests, erasure requests, and so on — where the data involved has been processed through their platform.
6. Deletion or return of data at contract end At the end of the relationship, the vendor must either delete or return all personal data processed on your behalf. The DPA should specify which, and within what timeframe.
7. Audit rights You should have the right to audit or inspect the vendor’s processing to verify compliance with the DPA. In practice this is often fulfilled by the vendor providing SOC 2 reports or third-party certification, but the right should be documented.
8. Data residency and international transfers Where is the vendor’s infrastructure located? If email content is processed outside the UK — for example, on servers in the US — an adequacy decision or appropriate transfer mechanism (such as UK Standard Contractual Clauses) must be in place. Post-Brexit, UK GDPR has its own international transfer framework, and “the vendor is US-based” is not itself compliant.
The Question Most Organisations Don’t Ask
Most procurement checklists for software tools include data security questions — does the vendor have ISO 27001, do they encrypt data at rest. These are useful. But for email signature tools, the more foundational question comes before all of those:
Does email content pass through your servers at all?
This question determines whether you have a data processor relationship to manage, or whether you don’t. The answer changes the entire compliance picture.
If the answer is yes — as it is for server-side routing tools — you have a data processing relationship that requires a DPA, requires you to assess the vendor’s security measures, requires you to understand their sub-processors, and makes your organisation accountable for their compliance.
If the answer is no — as it is for add-in-based tools that inject signatures at compose time within Outlook, before the email is sent — the vendor is not processing your email content at all. The email goes from Microsoft’s infrastructure directly to the recipient. The data processing relationship is narrower: the vendor handles employee directory data (names, job titles, photos) to build personalised signatures, but the content of your employees’ emails never passes through their systems.
This is not a trivial distinction. For organisations in regulated industries — financial services, healthcare, legal, any sector with heightened sensitivity to where data goes — it is often the decisive factor in an evaluation.
Why This Is Rarely Discussed
It is worth being direct about something: the largest vendors in the email signature management market use server-side routing. They process billions of emails through their infrastructure each year. They have DPAs available, and their compliance documentation is generally in order.
The issue isn’t that server-side tools are non-compliant. Reputable vendors offering server-side tools have invested in compliance infrastructure, and a properly executed DPA with a reputable vendor is a legitimate and workable arrangement.
The issue is that this is rarely surfaced in sales conversations or product evaluations, and many organisations using server-side tools have not verified that their DPA is in place, have not reviewed its terms, and have not confirmed where the vendor’s infrastructure is located.
That gap is a compliance risk — not because the vendor is doing anything wrong, but because the controller (your organisation) has an ongoing responsibility to verify and document that its processors are meeting the required standards. “We assumed it was fine” is not a satisfactory response to an ICO investigation.
Who Specifically Needs to Be Asking This Question
IT admins evaluating or renewing email signature tools: add the DPA question to your evaluation checklist before the demo. A vendor who can’t produce a DPA quickly is a red flag. A vendor who actively walks you through their data processing practices is a good sign.
Data Protection Officers: if your organisation uses an email signature tool and you haven’t reviewed the data processing arrangements, this is worth adding to your next audit cycle. The DPA (or its absence) should be documented in your Records of Processing Activities under Article 30.
Compliance managers in regulated industries: the argument for an add-in-based architecture — where email content never leaves Microsoft’s infrastructure — is particularly strong in sectors where the contents of business emails are sensitive, where regulatory obligations around data handling are heightened, or where client confidentiality is a professional requirement.
Legal and finance leads who initiated the email signature purchase: if you commissioned the tool because you needed consistent legal disclaimers on outgoing email, the irony of that tool creating a data processing exposure worth examining is worth flagging to IT.
What to Ask Any Email Signature Vendor
Before signing a contract with any email signature management vendor — server-side or otherwise — these questions should have explicit, documented answers:
1. Does email content pass through your servers? Get a direct yes or no. If the vendor is unclear, that is itself informative.
2. Do you provide a Data Processing Agreement? Any reputable vendor should provide a DPA as standard. Ask for it before the commercial conversation concludes.
3. Where is your infrastructure located? UK, EU, US, or elsewhere? For UK-based organisations, the server location determines what transfer mechanism (if any) must be in place.
4. Who are your sub-processors, and how are we notified of changes? You need a list. General written authorisation to use sub-processors is acceptable, but the DPA should give you the right to object if the list changes.
5. What personal data do you actually process? For a server-side tool: email content, metadata (sender, recipient, timestamp), attachments. For an add-in tool: employee directory data only. Knowing the scope of processing helps you assess the DPA and your own ROPA entry.
6. How long do you retain data? Does any email content persist after signature processing? If so, for how long, and for what purpose?
7. What are your deletion and return obligations at contract end? Are you able to request deletion of any retained data? What is the process and the timeline?
8. What security certifications do you hold? ISO 27001 is the most relevant for information security management. For cloud processing, ISO 27018 (personal data in the cloud) is a meaningful additional signal. These aren’t a substitute for a DPA, but they support the “sufficient guarantees” requirement in Article 28(1).
9. Have you been subject to any data breaches involving customer email data? The answer may be no. But it is a legitimate question, and you should ask it.
10. Will you allow audit rights or provide SOC 2 / penetration test reports on request? The right to verify compliance isn’t just good practice — it’s a required term in a compliant DPA under Article 28(3)(h).
What a Privacy-Safe Architecture Looks Like
The architectural alternative to server-side routing is compose-time injection via an Outlook add-in. In this approach, a small software component is deployed to employees’ Outlook clients. When an employee opens a compose window, the add-in fetches the correct signature — a pre-rendered HTML file served from a CDN — and injects it into the email body before the employee sends.
The email then travels from Outlook through Microsoft’s infrastructure to the recipient. The vendor’s infrastructure is not involved in mail delivery at any point.
What this means for data processing:
- Email content is never received, stored, or processed by the vendor’s platform
- The vendor’s data processing relationship is limited to: employee directory attributes (name, title, department, phone number, photo) used to personalise the signature
- The appropriate DPA for this relationship covers directory sync — not email content
The compliance obligations are real but narrower. Your organisation still needs a DPA for the directory sync. But the question “where do my employees’ emails go?” has a straightforward answer: directly from Microsoft to the recipient, as they always did.
For organisations with heightened data sensitivity, this architectural choice is the most direct way to reduce the GDPR surface area of your email signature tooling.
Summary
The question is simple: does your email signature tool route email through its own servers?
If yes — and many do — you have a data processing relationship under UK GDPR Article 28 that requires a written DPA, and your organisation is accountable for verifying the vendor’s compliance. This is manageable with a reputable vendor and a properly drafted DPA. But it must be actively managed, not assumed.
If no — if your tool injects signatures at compose time without handling email in transit — the compliance obligations are narrower and the risk exposure is lower.
Either way, the answer to this question should be on record before any contract is signed.
Vendor Checklist: GDPR Questions for Email Signature Software
Print or save this checklist for your evaluation process. Every question should have a documented answer before you proceed to contract.
- Does email content pass through your servers? (Yes / No — be specific)
- Is a Data Processing Agreement available? (Request it in writing)
- Where is your processing infrastructure located? (Country/region)
- Do you have a list of sub-processors? (Request a current copy)
- How are we notified if sub-processors change?
- What categories of personal data do you process on our behalf?
- How long is any personal data retained after processing?
- What is the deletion/return process at contract end?
- What security certifications do you hold? (ISO 27001, ISO 27018, SOC 2)
- Can you provide audit rights or third-party assurance reports on request?
Frequently Asked Questions
Does using an email signature tool make the vendor a GDPR data processor?
It depends on the architecture. If the tool works by routing outbound email through the vendor’s servers — which is how most server-side signature tools operate — then yes, the vendor is processing personal data contained in those emails on your behalf, making them a data processor under UK GDPR. If the tool works by injecting signatures at compose time within Outlook, without email ever passing through the vendor’s infrastructure, the processing relationship is different and narrower. In either case, a Data Processing Agreement is appropriate — the scope of what it needs to cover differs significantly between the two architectures.
What must a Data Processing Agreement with an email signature vendor include?
Under Article 28(3) of UK GDPR, the contract must require the processor to: process data only on your instructions; maintain confidentiality; implement appropriate security measures; use sub-processors only with your authorisation; assist you in responding to data subject rights requests; assist with your security, breach notification, DPIA, and consultation obligations; delete or return data at contract end; and allow you to audit compliance. The ICO’s guidance on contracts and liabilities between controllers and processors covers these requirements in detail.
What happens if I use a server-side email signature tool without a DPA?
You are non-compliant with Article 28 of UK GDPR. The ICO can take enforcement action against controllers who process personal data through processors without appropriate contractual arrangements in place. Separately, if the vendor experiences a breach affecting your email data and no DPA is in place, your organisation’s exposure is significantly greater — both legally and practically, in terms of demonstrating to regulators that you exercised appropriate due diligence.
Is it enough to have a DPA — or do I need to actively monitor the vendor’s compliance?
Having a DPA in place is necessary but not sufficient. Article 28 requires that you use only processors who provide “sufficient guarantees” of appropriate technical and organisational measures. That means you need reasonable assurance — not just a signed document — that the vendor is actually meeting those standards. In practice, this is typically evidenced through ISO 27001 certification, SOC 2 reports, or audit rights exercised periodically. The DPA should give you the right to request this evidence.
Are add-in-based email signature tools better for GDPR than server-side tools?
“Better” depends on your organisation’s specific context, but the compliance position is simpler. Add-in tools that inject signatures at compose time do not process email content — the email never reaches the vendor’s infrastructure. The data processing relationship covers only employee directory attributes used for personalisation. For organisations in regulated industries, or those where the sensitivity of email content is high, this architectural choice removes a category of compliance obligation rather than managing it. For more on the architectural differences, see Email Signature Management for Microsoft 365: Server-Side vs Add-In — What’s the Difference?.
Does the location of the vendor’s servers matter for UK GDPR?
Yes. If personal data is transferred outside the UK for processing, an appropriate international transfer mechanism must be in place. The UK has its own adequacy framework following Brexit — some countries have adequacy decisions, others require the UK’s International Data Transfer Agreement (IDTA) or UK Addendum to EU Standard Contractual Clauses. If your email signature vendor processes data on US-based infrastructure, for example, check specifically what transfer mechanism applies and ensure the DPA references it. This is an area where many organisations rely on assumptions rather than verified documentation.