Inbound email processing for GDPR compliance
Every email you receive is personal data, so the service that parses it is your processor under the GDPR. Where it runs, who owns it and how long it keeps mail decide whether you are compliant.
By Xander Groesbeek, founder · Published February 2026 · Updated October 2026 · 7 min read
In brief
The issue. An inbound email processing service receives mail for you, parses it and posts it to your application. Every message holds personal data, so you are the controller, the service is your processor, and the GDPR applies to every step.
What it means for you. You need a legal basis, a Data Processing Agreement, short retention and a processing chain you can account for. A provider in an "EU region" of a US company still falls under US law, which a contract cannot override.
What to do.
- Ask where the provider is incorporated, who owns it, and where each sub-processor is.
- Sign a DPA and set the shortest retention your workflow allows.
- Keep the webhook endpoint in the EU, and store only the fields you need.
- Record the flow in your Article 30 record of processing activities.
What is inbound email processing?
Inbound email processing is a service that receives email on your behalf, parses the headers, body and attachments, and delivers the result as structured JSON to your application through a webhook.
You point a domain's MX records at the provider, or forward mail to an address it runs. When a message arrives, the provider extracts the sender, subject, text, HTML and attachments, and sends an HTTP POST to your URL. It handles mail others send to you, unlike outbound email APIs. Typical uses are support tickets, invoice intake, lead capture and document workflows. For the technical walkthrough, see what inbound email processing is and how it works.
Why the GDPR applies to every inbound email
Every email is personal data, and every pass through a third-party service is processing. A single message can carry a name, address, phone number, financial details or health information, with more in its attachments.
You decide why and how the mail is processed, so you are the controller. The service processes it on your behalf, so it is your processor, and Article 28 requires a Data Processing Agreement between you.
The legal basis is usually legitimate interest (Article 6(1)(f)) for business correspondence, or performance of a contract (Article 6(1)(b)) when processing the email is needed to serve the sender. Consent rarely fits: you cannot ask for it before someone writes to you.
| GDPR principle | For inbound email |
|---|---|
| Data minimisation | Process and keep only the fields your purpose needs |
| Purpose limitation | Mail received to open support tickets is not reused for marketing |
| Storage limitation | Raw email content is deleted as soon as it is no longer needed |
| Integrity and confidentiality | Content is protected in processing, in transit and in storage |
A US provider brings US law, whatever its contract says
If your provider is a US company, or owned by one, US authorities can compel it to hand over your email, even when the servers are in Frankfurt or Amsterdam. Three pieces of law and case law explain why.
| Law or ruling | What it does |
|---|---|
| Schrems II (Court of Justice of the EU, July 2020) | Invalidated the EU-US Privacy Shield because US surveillance law did not protect EU data adequately. Transfers relying on Standard Contractual Clauses need a case-by-case transfer impact assessment. |
| US CLOUD Act (2018) | Lets US law enforcement compel US-headquartered companies to produce data they control, wherever in the world it is stored. |
| FISA Section 702 | Allows surveillance of non-US persons' communications through US providers, which may be barred from telling you. |
Since July 2023, transfers to US companies certified under the EU-US Data Privacy Framework rely on an adequacy decision instead of a transfer impact assessment. The General Court upheld it in September 2025 (Latombe v Commission, T-553/23), and an appeal to the Court of Justice was filed in October 2025. Either way, it does not change what the CLOUD Act and FISA 702 allow.
In short
A Data Processing Agreement is a contract between you and your processor. It cannot override the laws of the country where the processor is incorporated: a US company that promises to keep your data in the EU must still comply with a CLOUD Act order.
EU data residency means more than an EU region
An "EU region" at AWS, Azure or Google Cloud puts the servers in the EU, but the companies behind them are American. Real EU data residency needs all four conditions below.
| Condition | What it means | EU region of a US cloud |
|---|---|---|
| Stored in the EU | Servers physically in EU member states | Yes |
| Processed in the EU | No processing outside the EU, including logging, analytics and debugging | Depends |
| EU company | The operating company is subject to EU law, not US law | No |
| No US parent | No ownership chain leading to a company covered by the CLOUD Act | No |
Questions to ask an inbound email provider
Look past the server location: incorporation, ownership and sub-processors decide jurisdiction. Your DPO or compliance team should get an answer to each of these.
| Question | Why it matters |
|---|---|
| Where is the company incorporated? | Sets the legal jurisdiction. US incorporation brings the CLOUD Act and FISA 702. |
| Is there a US parent company? | An EU subsidiary of a US company can still be compelled through its parent. |
| Where are the servers? | Needed for EU residency, but not enough on its own. |
| Who are the sub-processors, and where? | One US sub-processor in the chain undoes the rest. |
| What does the DPA say? | Watch for broad data use, transfers to "affiliates" and vague retention terms. |
| How long is mail kept? | Storage limitation: ask for the exact period and how deletion works. |
| Can you delete a message on request? | You need it to honour the right to erasure (Article 17). |
Also ask for the current sub-processor list with locations and for technical documentation of how mail is handled; reluctance to share them is a signal in itself. For how the main inbound providers compare, see How EmailConnect compares.
Building a compliant inbound email workflow
Every step must stay in EU jurisdiction. One weak link, such as a US-based processor, a webhook endpoint in a US region or an analytics tool that logs email content, breaks the chain.
- 1
Route mail to an EU-based provider
Point the MX records of your receiving domain or subdomain at a provider that meets the four conditions above. Once mail reaches a non-EU server, the transfer has happened.
- 2
Receive it on an HTTPS endpoint in the EU
HTTPS encrypts the data in transit. If your application runs in a US region, the data leaves the EU when the webhook fires.
- 3
Keep only the fields you need
If you need the sender and subject, do not store the body. This is data minimisation in practice.
- 4
Set retention on both sides
Configure automatic deletion at the provider and in your application, and write down the period and why.
- 5
Document the processing
Article 30: record the data categories, purpose, legal basis, processor and sub-processors, retention and security measures.
How EmailConnect fits
Against the questions above, this is where EmailConnect stands. Each item links to the page behind it.
- A Dutch company, processing in the EU. The application, database and mail server run at Hetzner in Germany; optional attachment storage and the mail we send you at Scaleway in Paris, and an encrypted backup copy (7 days) at Scaleway in Amsterdam. No US company is in the processing chain, apart from optional sign-in with Google or GitHub. Sub-processors →
- No access to your mailbox. You send or forward mail to addresses we run; we never hold a password or token for your mailbox. Security and privacy →
- A DPA on every plan, Free included. Sub-processor changes are announced 30 days ahead, and a personal data breach is notified without undue delay. Data Processing Agreement →
- Email content exists only as long as you choose: one hour on Free and Maker, 24 hours by default on Business and Platform (configurable up to 30 and 365 days), deletable through the API on Business and above. With Data Residency Mode, an option on Platform, the body and attachments are never stored. Data retention →
- Encrypted in transit, signed on delivery. TLS 1.2 and 1.3 for the dashboard, API and webhook deliveries, which go out over HTTPS only; every delivery can be signed (HMAC-SHA256). Webhook signing →
All answers for your security review: trust center →
Related
Trust center
Where your email is processed, who can access it and how long it is kept: the answers for a security review.
Built for European privacy
What to check when a vendor says it is built for European privacy.
Hidden risks of email automation
What connecting a mailbox to an automation platform gives away.
How EmailConnect compares
Postmark, Mailgun and SendGrid side by side on data location and privacy.
Assessing your inbound email setup for the GDPR? We're not lawyers, but we're happy to discuss the technical side. Get in touch.