EU-hosted email APIs: what GDPR actually requires and who delivers

The question usually arrives late in vendor review:

Where does our email data actually go?

For a transactional email provider, that answer is rarely just "the region where messages are sent from." Email addresses, message bodies, attachments, event logs, bounce payloads, suppression lists, API logs, support tickets, and backups can all contain personal data.

That is why "GDPR-compliant" on a landing page does not settle much. This guide is for the engineer, founder, or procurement lead who needs to give a DPO or legal team a plain answer. What does GDPR require? What should "EU-hosted" mean in practice? And which parts of a vendor's setup still need transfer paperwork?

Postscale sells into this category, so we are not pretending to be a neutral observer. The table below is based on public vendor materials, and we spell out our own position at the end.

What GDPR requires when you process email

Sending a password reset, invoice, login code, receipt, or account notice means you are processing personal data. At minimum, there is an email address. Often there is also a name, IP address, order number, invoice metadata, or message content that points back to a person.

Under GDPR, your product is usually the controller and the email API vendor is a processor. The vendor is not deciding why the email is sent. They are processing the data because you asked them to.

In practice, you need to be able to show five things before you send production traffic through a provider:

1. Data Processing Agreement (DPA) between controller and processor, signed in advance
2. Sub-processor disclosure — processor lists every downstream service they use
3. Lawful transfer mechanism if any personal data leaves the EEA — typically Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment
4. Security measures (Art. 32) — encryption in transit and at rest, access controls, incident response
5. Audit rights — you can inspect or commission an audit of the processor

If your processor is in the US, or if customer data can move to US-controlled systems, the Schrems II transfer question does not go away. Many EU legal teams now ask two separate questions: where primary service data is hosted, and what happens to infrastructure metadata that may still be handled by global providers.

What "EU-hosted" should mean

This is where vendor wording can get slippery.

"We have a data center in Frankfurt."

That could mean something strong:

• message content is processed and stored in the EEA
• backups stay in the EEA
• the dashboard database is in the EEA
• access controls and support workflows are designed around EU-hosted data
• non-EEA transfers are documented and limited

It could also mean something much weaker:

• one EU sending region exists, but your account is not pinned to it
• failover or backups can land outside the EEA
• logs and analytics are stored in a US region
• support tickets are handled in a tool that stores customer data outside the EEA
• billing, abuse review, or infrastructure monitoring creates a second data path

The useful question is not "do you have an EU data center?" It is "does our account's normal path, including backups and operational tooling, keep personal data in the EEA unless you have a documented transfer mechanism?"

Before you rely on an EU-hosted claim, ask where each of these actually lives:

• 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 point is not just paperwork. A US-headquartered company can face disclosure obligations even when some infrastructure sits on EU servers. That does not automatically disqualify the provider, but it does change the legal analysis.

How the major vendors compare

Use this table as a starting point for vendor review, not as a substitute for your own legal sign-off. I compiled it from public DPAs, sub-processor lists, trust centers, product docs, and vendor-facing compliance pages as of 2026-04. Private contract terms may differ.

The "EU/EEA service-data option" column is deliberately narrow. It is about the normal home for service data such as message content, event data, and account records. A vendor can have a DPA and still require transfer safeguards if data or operational metadata leaves the EEA.

This is not "EU good, US bad." A US vendor can be the right choice for a US-market product, especially when the contract, region setting, and sub-processor review are clear. The friction appears when an EU company sells to German, French, Dutch, or Nordic customers and every US processor creates another round of transfer analysis.

If you are building a named shortlist, we also maintain vendor-specific notes on SendGrid alternatives, Mailgun alternatives, Postmark alternatives, Resend alternatives, Cloudflare Email Service alternatives, Amazon SES alternatives, Brevo alternatives, and Mailjet alternatives.

What to ask before signing

These questions are intentionally concrete. You want answers that can be pasted into an internal vendor review, not a promise that "our platform is GDPR-ready."

1. Is message content (headers, bodies, attachments) ever stored or replicated outside the EEA, including for backups? Yes/no/conditions.
2. Is any part of your infrastructure hosted by a US company (AWS, GCP, Azure)? If yes — which region, and under what data localization commitment?
3. Under what circumstances would you disclose customer data to US authorities? (This is the CLOUD Act question.)
4. What's your sub-processor list and how do I get notified of changes?
5. 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.)
6. Who inside your company has access to customer data? (Role-based access matters for Art. 32.)
7. What's the process if I submit a GDPR data-subject access request for one of my users?

You are not looking for perfection. You are looking for clarity. A vendor that can explain the region, data path, sub-processors, and transfer mechanism in plain language has probably done the internal work. A vendor that sends only a generic compliance page may still be fine, but your legal team will have more to untangle.

The reasonable default for an EU-based SaaS

If your customers are EU businesses or EU consumers, and you have meaningful B2B relationships with German or French buyers, start with an EU-operated processor with EU/EEA-hosted primary service data. The benefit is not only legal tidiness. It is fewer procurement loops, fewer security questionnaires that stall on transfer language, and fewer awkward answers when a customer asks where their message content is stored.

If your product is global and US-skewed, a US vendor with a credible EU option may be a perfectly reasonable default. Just make sure the option is actually in force for your account. "Available" and "enabled for us" are different states.

Our stake in this

For Postscale specifically: Postscale is operated by DNScale OÜ in Estonia, inside the EU. Primary production service data is hosted in the EU/EEA. Limited network, device, and operational metadata may be processed by infrastructure providers under appropriate transfer safeguards.

Our GDPR processor agreement is available before purchase, because this is exactly the kind of thing buyers should check early. For the product side, Postscale covers transactional sending, inbound email, masked addresses, and XRechnung e-invoicing through one API. Start with the EU transactional email provider overview, see pricing, or read the docs.