AWS SES EU Alternative 2026: Email Sending, Bounce Data, and the GDPR Problem

Post #686 in the sota.io EU Compliance Series

AWS Simple Email Service (SES) is the default email infrastructure for applications built on AWS. Transactional emails — password resets, order confirmations, invoice delivery, account notifications — flow through SES at scale across thousands of European applications. SES offers reliable deliverability, generous free tiers, and deep integration with the rest of the AWS ecosystem.

Amazon operates SES in European regions: eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-west-3 (Paris). Data about emails sent through these regional endpoints is stored in Europe. Many development teams treat this as a compliant configuration.

It is not. Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) compels US companies to produce data stored anywhere in the world when ordered by US authorities. A valid government order served on Amazon in Seattle can reach your SES email metadata in Frankfurt: bounce records, complaint data, suppression lists, delivery events, and the full content of any email your application sends or receives.

This is the same structural US jurisdiction problem documented across the AWS stack: AWS RDS, AWS S3, AWS Lambda, AWS DynamoDB. Email adds a particularly sensitive dimension: the recipient email address — a core piece of personal data under GDPR Art.4(1) — appears in nearly every operational record SES generates.

What AWS SES Stores About Your Email Recipients

SES is not a simple SMTP relay. It maintains extensive operational data around every email it sends, and much of that data directly concerns natural persons identifiable by their email address.

Bounce Records: Recipient PII in Failure Notifications

When SES sends an email that cannot be delivered — a hard bounce (address does not exist) or soft bounce (mailbox full, server temporarily unavailable) — SES generates a bounce notification record. This record contains:

• The recipient's email address (the bounced address)
• The bounce type and subtype (permanent vs. transient, specific SMTP diagnostic code)
• The timestamp of the bounce event
• The message ID linking back to the original send
• The sending domain and configuration set that produced the bounce

Bounce records are transmitted to your configured feedback endpoint (SNS topic, SQS queue, or configuration set event destination). They are also retained in SES's operational infrastructure under the AWS (US) legal entity. A database of which email addresses failed to deliver is a database of personal data under GDPR — and it sits under CLOUD Act reach.

Complaint Data: ISP Feedback Loops as PII Records

Internet Service Providers (Gmail, Outlook, Yahoo) operate feedback loop programs: when a recipient marks an email as spam, the ISP forwards a complaint notification to the sender. SES participates in these feedback loops automatically and forwards complaint data to your configured endpoint.

Complaint notifications include:

• The recipient email address that generated the complaint (when the ISP includes it — Gmail does not, most others do)
• The timestamp of the complaint
• The message ID of the complained-about email
• The feedback type (abuse, fraud, virus, other)

When complaint data includes the recipient's email address, it is personal data under GDPR. This data is processed by AWS (US entity) as part of SES operations and is accessible under CLOUD Act compulsion. If you are using SES Dedicated IP pools, ISP complaint rates for your IPs are tracked by AWS infrastructure.

The SES Suppression List: A Direct Registry of Personal Data

SES maintains a suppression list — a registry of email addresses that should not receive further emails. An address is added to the suppression list when it generates a hard bounce or a spam complaint. The suppression list exists at two levels:

Account-level suppression list: Your SES account's suppression list. You can query it, add to it, and remove entries. It exists as a persistent data store in AWS (US entity) infrastructure containing email addresses of natural persons.

SES global suppression list: Amazon maintains a cross-account suppression list of addresses that have bounced or complained across multiple SES customers. If an address is on the global suppression list, SES will suppress sends to it even if it's not in your account-level list. You have no visibility into or control over this global list; it is managed entirely by AWS.

Both suppression lists are databases of personal data — the email addresses of natural persons — operated by a US company subject to CLOUD Act compulsion. Under GDPR Art.5(1)(e), personal data must be kept in a form that permits identification of data subjects for no longer than necessary. The suppression list is explicitly designed to persist indefinitely; Amazon recommends never removing addresses from it. Indefinite retention of personal data under US jurisdiction is incompatible with GDPR data minimization principles.

Configuration Sets and Event Publishing: Email Engagement Tracking

SES Configuration Sets are the mechanism for tracking email delivery events: sends, deliveries, bounces, complaints, opens, clicks, and rendering failures. Events are published to Amazon SNS, Amazon SQS, Amazon CloudWatch, Amazon Kinesis Data Firehose, or Amazon Pinpoint.

Open and click tracking are particularly sensitive under GDPR. When SES inserts a tracking pixel into your email, or rewrites links to pass through an SES tracking endpoint, it collects:

• The recipient's email address (to correlate the event with the send)
• The timestamp of the open or click
• The recipient's IP address (for open tracking via pixel)
• The link clicked (for click tracking)
• Approximate geographic location derived from IP

This is behavioral tracking of identifiable individuals — personal data requiring a valid legal basis under GDPR Art.6. SES open and click tracking operates through AWS infrastructure. Every tracking event is processed by the US entity. If you are using Configuration Sets with event publishing enabled, you are routing personal engagement data through a US company that is subject to compelled disclosure.

Amazon Pinpoint: Marketing Analytics Under US Jurisdiction

Amazon Pinpoint is AWS's marketing analytics service, tightly integrated with SES for email campaign management. Pinpoint tracks:

• Individual-level email engagement (opens, clicks, unsubscribes per recipient)
• Customer journey analytics (which emails a specific user received and interacted with)
• Audience segmentation based on engagement history
• A/B test results at the individual recipient level

Pinpoint is operated by Amazon Web Services, Inc. (US entity). A Pinpoint project is a database of marketing engagement records linked to identifiable individuals (email addresses). This is among the most sensitive categories of email data from a GDPR perspective: it enables detailed behavioral profiling of individual users based on email engagement patterns. Every record in Pinpoint is reachable under CLOUD Act compulsion.

If your marketing team uses SES + Pinpoint for email campaigns, the entire engagement analytics layer is under US jurisdiction.

Email Receiving: Full Content Under US Control

SES can receive inbound email on domains you configure. SES email receiving stores the full content of received emails — headers, body, attachments — in Amazon S3 (another US entity service) and optionally processes them through Lambda functions.

For applications that process inbound email — support ticket creation from customer emails, automated order processing from supplier emails, user reply handling — every received email is stored in AWS (US entity) infrastructure. Email bodies routinely contain personal data: customer names, addresses, account details, health information, financial data.

The standard SES email receiving pipeline (SES → S3 → Lambda) chains three US-entity AWS services. The full email content — which may include sensitive personal data — transits through all three and is accessible under CLOUD Act compulsion at each stage.

GDPR Articles Directly Implicated

Art.44-49 (International Transfers): SES involves a US entity with the ability to disclose data to US authorities. Standard Contractual Clauses (SCCs) are invalidated by the Schrems II ruling (CJEU C-311/18) when the service provider is subject to surveillance laws that override contractual obligations. The CLOUD Act provides exactly such override authority.

Art.5(1)(a) (Lawfulness): Email engagement tracking (opens, clicks) through SES requires a valid legal basis. Legitimate interest may be insufficient for detailed behavioral tracking of individual email recipients.

Art.5(1)(e) (Storage Limitation): The SES suppression list is designed for indefinite retention. GDPR requires that personal data be kept only as long as necessary for the specified purpose. Indefinite bounce-address retention under US jurisdiction is incompatible with this principle.

Art.6 (Lawful Basis): Marketing email sending, particularly when combined with Pinpoint engagement analytics, requires a lawful basis — typically consent under GDPR Art.6(1)(a) for marketing. The US entity having access to consent records and engagement data compounds the compliance exposure.

Art.32 (Security): Technical measures must protect personal data against unauthorized access. A service architecture where a US government order can produce email metadata and engagement records does not constitute adequate technical security for GDPR purposes.

Art.28 (Processors): AWS is a data processor for personal data processed via SES. A data processing agreement (DPA) with Amazon cannot protect against CLOUD Act compulsion — the CLOUD Act explicitly enables orders that override contractual obligations between AWS and its customers.

EU-Native Email Sending Alternatives

Brevo (formerly Sendinblue) — France

Brevo is a French email and marketing platform with data centers in France and Germany. As a French company operating under EU law, Brevo is not subject to the CLOUD Act. Brevo offers transactional email via SMTP and API (compatible with the SES API format in many SDKes), marketing email, SMS, and a marketing automation platform.

Brevo's key GDPR advantage over SES: engagement tracking data (opens, clicks), suppression lists, and bounce records are stored and processed by an EU entity under EU law. Brevo publishes a comprehensive DPA and processes all data under GDPR.

For teams migrating from SES, Brevo offers an SMTP endpoint and REST API that work with the same email libraries. AWS SDK SES calls require adaptation to Brevo's API, but the logic is identical.

Scaleway Transactional Email — France

Scaleway, a French cloud provider (part of Iliad Group), offers Transactional Email as a service specifically designed for developers who need EU data sovereignty. Scaleway's infrastructure is entirely in France (PAR-1, PAR-2 zones) — no US data center involvement.

Scaleway Transactional Email provides:

• SMTP and REST API sending
• Bounce and complaint handling with GDPR-compliant data retention
• DKIM and SPF configuration under your control
• Webhook delivery of events to your endpoint (not stored indefinitely)

Scaleway Transactional Email is a newer service with fewer features than SES, but it provides genuine EU sovereignty for the core email sending function.

OVHcloud Email API — France

OVHcloud (French, second-largest cloud provider in Europe) provides email delivery services via API. OVHcloud operates exclusively in EU data centers and is subject to French/EU law, not the CLOUD Act.

Postal — Open Source Self-Hosted

Postal is an open-source mail delivery platform that can be deployed on your own infrastructure. Self-hosting Postal eliminates the US jurisdiction problem entirely: your email infrastructure runs on servers under your control, in EU data centers of your choosing.

Postal provides:

• Full SMTP server functionality
• REST API for sending
• Bounce and complaint handling
• Open and click tracking (under your control, on your infrastructure)
• Web interface for administration

The operational overhead of self-hosted email (deliverability management, IP reputation, ISP relationships) is significant. Postal is most appropriate for organizations with dedicated infrastructure teams.

Infobip Email — Croatia (EU)

Infobip is a Croatian communications platform (CPaaS) that offers email sending as part of its communications API. As an EU company (Croatia has been an EU member since 2013), Infobip operates under GDPR and is not subject to the CLOUD Act.

Migration Path from SES

The minimal migration path for transactional email:

1. SMTP replacement (lowest friction): Most applications use SES via SMTP or AWS SDK. Brevo and Scaleway both offer SMTP endpoints with credentials (username/password). Changing the SMTP host, port, and credentials is often a configuration change, not a code change.

2. SDK migration: AWS SDK calls (ses.sendEmail(), sesv2.sendEmail()) need to be replaced with the target provider's SDK or REST API. The email content (to, from, subject, body) maps directly. Event handling (bounce callbacks, complaint callbacks) needs to be reconfigured to the new provider's webhook format.

3. Suppression list migration: Export your SES account-level suppression list before migration. Import it into the new provider's suppression system. Do not rely on the SES global suppression list being portable — it is not.

4. DKIM/SPF migration: Update your DNS records for DKIM and SPF to point to the new provider's infrastructure. Allow 24-72 hours for DNS propagation before switching production traffic.

5. Event endpoint reconfiguration: If you are using SES Configuration Sets to publish bounce and complaint events to SNS or SQS, reconfigure your event handling to receive webhooks from the new provider. The event structure will differ but the semantic content (bounce address, complaint address, event timestamp) is the same.

Comparison Table

The Suppression List Problem Is Structural

Every email service maintains a suppression list. The GDPR compliance question is not whether the list exists — it must exist for deliverability — but who controls it and where it is stored.

With SES, the suppression list is managed by AWS (US entity). You can export it, but you cannot control the underlying storage, retention policy, or what AWS does with it operationally. The global suppression list is entirely outside your control.

With EU-native alternatives, the suppression list is managed by an EU entity subject to GDPR. You can audit, export, and delete entries. The data processing agreement covers the suppression list explicitly. The controller-processor relationship is intact.

This structural difference — control versus dependency — is the core GDPR argument for moving email infrastructure to EU-native providers, independent of whether a government order is ever actually served.

Practical Steps for European Companies

1. Audit your SES usage: Which email types go through SES? Transactional only, or also marketing? Is Pinpoint enabled?
2. Inventory your Configuration Sets: Which event types are being tracked? Open and click tracking are the highest GDPR risk.
3. Export your suppression list: aws sesv2 list-suppressed-destinations — do this before migrating.
4. Choose your migration target: Brevo for maximum feature parity; Scaleway for maximum EU sovereignty; Postal for self-hosting.
5. Update your DPA: Terminate the AWS DPA for SES and execute a new DPA with your chosen EU provider.
6. Disable SES event tracking before migration: Reduces the window of tracking data under US jurisdiction during transition.

Related posts in this series:

• AWS RDS EU Alternative: The Managed Database GDPR Problem
• AWS S3 EU Alternative: Object Storage and the CLOUD Act
• AWS DynamoDB EU Alternative: NoSQL Under US Jurisdiction
• AWS Lambda EU Alternative: Serverless and the Execution Environment Problem
• AWS ElastiCache EU Alternative: In-Memory Data and GDPR