Inbound email processing for GDPR compliance

Published February 2026 · 12 min read

What is inbound email processing?

Inbound email processing is the automated handling of incoming email by a third-party service that receives messages on your behalf, parses the headers, body, and attachments, and delivers the extracted data as structured JSON to your application via a webhook endpoint.

In practical terms, you point your domain's MX records at the processing provider. When someone sends an email to an address on that domain, the provider receives it, extracts the sender, subject, plain text, HTML content, and any attachments, then sends a structured HTTP POST request to your configured URL. Your application receives clean, machine-readable data instead of raw MIME-encoded email.

This is distinct from outbound email processing (sending email through an API). Inbound processing handles email that others send to you. Common use cases include customer support automation, invoice processing, lead capture, and document intake workflows. For a deeper technical walkthrough, see our guide on what inbound email processing is and how it works.

The compliance question arises because every email that passes through a third-party inbound processing service creates a data processing event. The content of those emails — names, email addresses, message text, attachments — is personal data under the GDPR. Where and how that processing happens determines whether you are compliant.

Why GDPR matters for email processing

Email is one of the most data-rich communication channels a business handles. A single inbound email can contain the sender's full name, email address, physical address, phone number, financial details, health information, and file attachments with further personal data embedded inside. Under the GDPR, all of this qualifies as personal data, and processing it triggers a full set of compliance obligations.

When you use a third-party service to process inbound email, you become the data controller — you determine the purpose and means of processing. The email processing service becomes the data processor — it processes personal data on your behalf. This relationship must be governed by a Data Processing Agreement (DPA) under Article 28 of the GDPR, and both parties carry specific legal responsibilities.

The legal basis for processing inbound email in a business context is typically legitimate interest (Article 6(1)(f)) for general business correspondence, or contract performance (Article 6(1)(b)) when email processing is necessary to fulfil a contract with the sender. Consent is rarely the appropriate basis for inbound email, since you cannot obtain consent from someone before they send you an email.

Four GDPR principles are particularly relevant to email processing:

• Data minimisation — only process the email data you actually need for your stated purpose
• Purpose limitation — email data collected for support ticket creation should not be repurposed for marketing
• Storage limitation — do not retain raw email content longer than necessary
• Integrity and confidentiality — ensure email content is protected during processing, transit, and storage

The US data transfer problem

In July 2020, the Court of Justice of the European Union issued its ruling in Data Protection Commissioner v. Facebook Ireland — commonly known as Schrems II. The court invalidated the EU-US Privacy Shield framework, finding that US surveillance laws do not provide adequate protection for EU personal data. This ruling did not just affect Facebook. It affected every organisation transferring personal data to the United States.

The current legal mechanism for EU-to-US data transfers is Standard Contractual Clauses (SCCs). However, the Schrems II ruling made clear that SCCs are not a rubber stamp. Organisations must conduct a case-by-case Transfer Impact Assessment (TIA) to determine whether the legal framework in the recipient country provides essentially equivalent protection to the GDPR. For transfers to the US, this assessment consistently runs into two statutes: the CLOUD Act and FISA Section 702.

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) grants US law enforcement the authority to compel US-headquartered companies to produce data stored anywhere in the world. This is not theoretical. It means that if your email processing provider is a US company — or is owned by a US parent company — the US government can legally require access to your email data, even if the servers are physically located in Frankfurt or Amsterdam.

FISA Section 702 enables mass surveillance of non-US persons' communications. US companies that handle electronic communications can be compelled to provide access under this programme, and they are legally prohibited from disclosing that they have done so.

A Data Processing Agreement does not change this reality. A DPA is a contract between you and your processor. It cannot override the legal obligations the processor has under the laws of its country of incorporation. A US company that signs a DPA promising to keep data in the EU is still legally required to comply with a CLOUD Act order, regardless of what the DPA says.

The practical impact for inbound email processing: if you use Postmark, Mailgun, SendGrid, or any other US-incorporated email processing service, your email content is accessible by US-jurisdictioned entities — regardless of which "region" you select in their dashboard.

EU data residency — what it actually means

Many cloud services now offer an "EU region" option. This is often presented as a data residency solution, but the term is frequently misleading. Selecting "EU region" on a US cloud provider means your data is stored on servers physically located in the EU. It does not mean your data is beyond the reach of US jurisdiction.

True EU data residency requires all of the following:

• Data stored in the EU — servers physically located within EU member states
• Data processed in the EU — no processing operations occur outside the EU, including logging, analytics, and debugging
• Company incorporated in the EU — the legal entity operating the service is subject to EU law, not US law
• No US parent company — no corporate ownership chain that leads to a US-incorporated entity subject to the CLOUD Act

An "EU region" on AWS, Azure, or GCP satisfies only the first condition. The parent companies — Amazon, Microsoft, and Google — are all US-incorporated and subject to US jurisdiction. A CLOUD Act order served on the US parent company can compel access to data stored on EU servers. This is not a loophole or edge case; it is the stated legal purpose of the CLOUD Act.

When evaluating an email processing provider for true EU data residency, look beyond the server location. Check: where is the company incorporated? Who owns the company? Where are their sub-processors based? Are any entities in the corporate chain subject to US jurisdiction? Only when all of these answers point to the EU can you claim genuine EU data residency.

How to evaluate an email processing provider

Before selecting an inbound email processing provider, conduct a structured assessment. The following checklist covers the essential questions your Data Protection Officer or compliance team should be asking:

Beyond the table, ask for documentation. A compliant provider should be able to produce their Article 30 records of processing activities, a list of current sub-processors with locations, and technical documentation of their data handling practices. Reluctance to share this information is itself a signal.

For a practical comparison of how major inbound email providers stack up on these criteria, see our provider comparison page.

Building a compliant email workflow

A GDPR-compliant inbound email processing workflow requires attention at every stage, from DNS configuration to data deletion. Here is a practical step-by-step approach:

1. Configure MX records to an EU-based provider

Point the MX records for your receiving domain (or subdomain) to an email processing provider that meets the EU data residency criteria outlined above. This is the entry point — once an email hits a non-EU server, the data has already been transferred.

2. Set up your webhook endpoint over HTTPS

Your webhook receiver must use HTTPS to ensure email data is encrypted in transit. Host this endpoint on EU infrastructure as well. If your application runs on a US cloud provider, the processed email data leaves the EU the moment the webhook fires.

3. Process structured JSON in your application

Receive the parsed email as structured JSON and extract only the fields you need. This is where data minimisation applies in practice: if you only need the sender address and subject line, do not store the full message body.

4. Implement data retention policies

Define and enforce how long processed email data is stored. Set automatic deletion schedules in both the email processing service and your own application. Document the retention period and the justification for it.

5. Document your processing activities

GDPR Article 30 requires controllers to maintain a record of processing activities. For inbound email processing, document: the categories of data processed, the purpose of processing, the legal basis, the processor and sub-processors involved, data retention periods, and the technical and organisational security measures in place.

The critical point: every step in this flow must remain within EU jurisdiction. One weak link — a US-based processor, a webhook endpoint on AWS US-East, an analytics service that logs email content — and the compliance chain breaks.

EmailConnect's approach

EmailConnect was built to make the workflow described above straightforward. Here is what that looks like in practice:

• EU-only infrastructure: All email processing runs on servers in Germany and the Netherlands (Hetzner data centres). There are no US sub-processors in the processing chain.
• Independent EU company: EmailConnect is an EU-incorporated company with no US parent entity. It is not subject to the CLOUD Act, FISA 702, or any other US jurisdiction statute.
• Data minimisation by design: Email content is parsed, the structured data is delivered to your webhook, and the raw email content is deleted according to your configured retention settings. There is no long-term storage of raw email content beyond what you explicitly configure.
• Purpose limitation: EmailConnect does one thing — receive email, parse it, and deliver the structured result via webhook. Email content is not used for analytics, training, advertising, or any secondary purpose.

This is not the only way to achieve GDPR-compliant inbound email processing, but it is the approach that eliminates the most common compliance gaps: US jurisdiction exposure, unnecessary data retention, and opaque sub-processor chains.

If this approach fits your requirements, see the pricing page or start a free account to test the workflow with your own email.

Need help assessing your email processing setup for GDPR compliance? Contact hello@emailconnect.eu.