EU-hosted email APIs: what GDPR actually requires and who delivers
A practical breakdown of EU data residency, GDPR processor requirements, and how the major transactional email APIs stack up against them.
"GDPR-compliant" is a marketing word on every email API's landing page. This article is for engineers who have to prove compliance to a legal team, DPO, or auditor. We'll work from what the regulation actually demands to what each vendor actually provides. For vendor-specific comparisons, we also maintain dedicated pages on SendGrid alternatives, Mailgun alternatives, Postmark alternatives, and Resend alternatives.
What GDPR requires when you process email
Sending transactional email to a user means you're processing personal data (at minimum: email address, IP, maybe name and transaction details). Under GDPR that makes the email API vendor a processor and you the controller.
The minimum contractual setup:
- Data Processing Agreement (DPA) between controller and processor, signed in advance
- Sub-processor disclosure — processor lists every downstream service they use
- Lawful transfer mechanism if any personal data leaves the EEA — typically Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment
- Security measures (Art. 32) — encryption in transit and at rest, access controls, incident response
- Audit rights — you can inspect or commission an audit of the processor
If your processor is in the US, the extra burden around transfers has real teeth since Schrems II. Many DPOs now treat "EU-only processing" as a shortcut past the transfer-assessment work.
What "EU-hosted" should mean
Watch for the weak version first:
"We have a data center in Frankfurt."
Could mean:
- Strong: all customer data processed and stored in Frankfurt, no replication outside the EEA, no US-subsidiary access.
- Weak: one of many data centers, with automatic failover to North Virginia, billing and support tickets still on AWS us-east-1, Zendesk tickets in US, backup to S3 US.
The strong version passes legal review. The weak version is a billboard.
Things to verify:
- Where are primary and backup copies of message content stored?
- Where are logs stored and for how long?
- Where is the web dashboard and its database?
- Where is the support ticketing system?
- Does any sub-processor process data outside the EEA?
- Is the vendor a US entity with a subsidiary in the EU, or an EU entity?
The last one matters because of the US CLOUD Act — a US-headquartered company can be compelled to produce data stored even on EU servers.
How the major vendors compare
I've compiled this from public DPAs, sub-processor lists, and Trust Centers as of 2026-04. Where a vendor's status is ambiguous I've noted it.
| Vendor | Primary HQ | EU-only data option | DPA standard | SCC needed |
|---|---|---|---|---|
| Resend | US (Delaware) | No — US-primary, EU replication available | Yes | Yes (Schrems II assessment) |
| Postmark | US (ActiveCampaign) | Via EU Servers product only | Yes | Yes |
| Mailgun | US (Sinch) | EU region selectable at account creation | Yes | Yes for cross-border |
| SendGrid | US (Twilio) | No dedicated EU option | Yes | Yes |
| SparkPost | US (MessageBird/Bird) | EU data residency available | Yes | Depends |
| Mailjet | EU (France) | Yes — EU native | Yes | Not needed for EU controllers |
| Postscale | EU (Estonia, DNScale OÜ) | Yes — EU-only processing | Yes | Not needed for EU controllers |
The table isn't "EU good, US bad" — it's about matching vendor posture to your threat model. A small B2B SaaS with German customers and a German DPO has genuine friction every time they deploy a US processor. A US-market-focused startup generally doesn't.
What to ask before signing
Here's a short questionnaire. The good vendors answer all in writing; the ambiguous ones wiggle:
- Is message content (headers, bodies, attachments) ever stored or replicated outside the EEA, including for backups? Yes/no/conditions.
- Is any part of your infrastructure hosted by a US company (AWS, GCP, Azure)? If yes — which region, under what data localization commitment?
- Under what circumstances would you disclose customer data to US authorities? (This is the CLOUD Act question.)
- What's your sub-processor list and how do I get notified of changes?
- Where are logs stored, and for how long? (Often the weak point — message content might be EU-hosted but logs and metrics often aren't.)
- Who inside your company has access to customer data? (Role-based access matters for Art. 32.)
- What's the process if I submit a GDPR data-subject access request for one of my users?
A vendor who can't answer #2 or #3 in a sentence is a vendor who hasn't done the work.
The reasonable default for an EU-based SaaS
If your customers are EU businesses or EU consumers, and you have any meaningful B2B relationships with German or French buyers, go EU-native. The legal overhead you avoid is worth more than most feature differences between vendors.
If your product is global and US-skewed, a US vendor with a reasonable EU option is usually fine — just make sure the option is actually in force for your account, not an opt-in you forgot to flip.
Our stake in this
Postscale is operated by DNScale OÜ (Estonia, EU) with all processing, storage, and delivery on EU infrastructure. No US parent, no CLOUD Act exposure. Our GDPR processor agreement is standard language — we'll sign it pre-sales with no lawyers-only meetings.
For teams specifically evaluating EU alternatives: we cover transactional sending, inbound email, masked addresses, and XRechnung e-invoicing through one API. See pricing or read the docs.