Does Amazon SES Work in China? PIPL Cross-Border, Recipient Data & Delivery Compliance

Whether Amazon SES “works” in mainland China is a compliance question before it is a networking one, and for a transactional-email API the shape is specific: not whether you can call the endpoint, but what happens when you hand it your China recipients’ email addresses and the message you want delivered. Amazon SES is a send-only email service — you pass it a recipient address and the full body (one-time passcodes, password resets, order and shipping confirmations, account notices, marketing), and it sends from an AWS region. There is no Amazon SES region inside mainland China, and SES is absent even from AWS’s separate China partition — its China Region Table lists Amazon SNS, SQS and MQ in Beijing and Ningxia, but not SES. So a China-facing sender reaches a non-China region, and two legs open at once: a cross-border transfer of your recipients’ personal information — their addresses plus whatever the content reveals — and the delivery counterpart, getting mail into mainland mailboxes from offshore IPs, plus the ICP duty of the app that triggers it.

Amazon SES in China at a glance

What you actually hand it — your recipients’ contact data and content

Start with what an SES call actually is. Amazon SES does not deliver a reference to a message held somewhere safe; it delivers the message itself. You hand it the recipient’s email address and the full body, and the exposure is both — the address is personal information, and the content is whatever that message reveals. The jobs SES exists for are the sensitive ones: one-time passcodes and password resets, order and shipping confirmations, invoices and receipts, account and security notices, and marketing. Each of those carries a real person’s contact details, and many carry more inside the body — an order history, an account balance, a medical or financial notice.

Then the part teams forget: SES keeps data after the send. By AWS’s own developer guide, Amazon SES “might store certain data that could be considered personal.” It maintains an account-level suppression list — addresses that bounced or complained — where entries “remain on this list until you delete them.” Through configuration sets and event destinations it emits event data (deliveries, opens, clicks) that, in AWS’s words, “typically contains your email address and the IP address the email was sent from” and “also contains the email addresses of all the recipients the email was sent to,” streamed on to services like Amazon S3, OpenSearch or Redshift. It stores your sending identities (the addresses and domains you send from). And on account closure, AWS states the data is “retained for 90 days.” None of this is model-training — SES is a relay, not an AI service — but all of it is your recipients’ personal information, held in a non-China AWS region.

Where does it go? To a non-China AWS region. There is no Amazon SES region inside mainland China, and — the nuance that trips teams up — SES is not available even in AWS’s separate China partition. AWS runs that partition (the Beijing Region operated by Beijing Sinnet Technology Co., Ltd. and the Ningxia Region by Ningxia Western Cloud Data Technology Co., Ltd.), and its own China Region Table lists messaging services such as Amazon SNS, SQS and MQ there — but Amazon SES is absent, as is Pinpoint, and neither China region’s endpoint list carries an email or email-smtp host. So the “just use the China partition” move that works for some AWS services does not work for SES (see Does AWS work in China? for the two-door partition structure), exactly as it does not work for Amazon Translate. A China-facing sender reaches a region outside the mainland, and the recipient data — addresses, content, suppression lists, event logs — is processed and held offshore.

It’s a cross-border transfer — and, for email, a deliverability question

Because the recipient’s address and the message leave China to be processed and sent, handing them to Amazon SES is a cross-border transfer of personal information, not a routing detail. The duty sits on you as the handler, not on AWS as the processor. PIPL Articles 38–40 require that, before personal information is sent abroad, you give notice, obtain a separate consent distinct from any general agreement to use your product, and put one transfer mechanism in place — a CAC security assessment, the CAC standard contract, or certification. Where the message you send is marketing or other commercial communication, PIPL Articles 13 and 23 add a lawful basis and consent for the sending itself, and you must honor opt-out. Where the content carries sensitive personal information — a health, financial or identity notice — Article 28 adds a separate consent and a prior impact assessment. Above certain thresholds, genuinely necessary exports also run through China’s data-export security assessment (数据出境安全评估) before anything leaves.

Residency is the other half. If your organization is a critical information infrastructure operator — or a high-volume personal-information handler — the Cybersecurity Law’s Article 39 (formerly Article 37 — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, its substance unchanged) requires personal information generated in China to be stored in China, with any genuinely necessary export cleared through a security assessment (see also PIPL Article 40). A send-only service that keeps your suppression list and event logs in an offshore region is squarely in tension with that duty.

For email there is a second, practical leg where SMS would meet a telecom-licensing regime: deliverability. Reaching SES is trivial, but getting mail accepted into the big mainland mailboxes — QQ, 163, Sina and the Tencent and NetEase ecosystems — from an offshore IP is its own problem. Those providers routinely throttle and filter unfamiliar foreign senders, so an offshore SES send that technically leaves may still be delayed, spam-foldered or rejected. None of this turns on how fast the API responds; it turns on where the recipient data is processed and kept, on what lawful basis, and whether the mail is delivered through a path China mailboxes accept. For that reason this page publishes no China latency or deliverability figure for Amazon SES: speed is not the axis for a decision that turns on residency, cross-border transfer and delivery.

Reaching the API isn’t the question — a compliant in-country delivery path is

The reflex is to point SES at the nearest region — Tokyo, Singapore, Hong Kong — and treat the distance as the problem solved. But every Amazon SES region sits outside mainland China, so a nearer one changes the latency, not the law: the recipient’s address and message are still carried across the border, still processed offshore, and the suppression list and event logs are still kept there. A nearer region is not an in-country one, and Hong Kong is a separate jurisdiction from the mainland for data-export purposes.

So the honest levers are these, and none of them is “make the offshore API reachable.” First, because SES offers no mainland-China region and no self-hosted build, the durable option for China-recipient mail is a compliant in-country / China-deliverable path — a China-resident email or notification service that keeps the recipient data in the mainland and delivers through a route the big mailbox providers accept — while you keep Amazon SES for the markets it already serves. Second, minimize and obtain consent: send the least recipient PII the message needs, obtain the Article 13/23 consent for anything marketing and honor opt-out, and keep a lawful cross-border basis for anything that still leaves. Third, treat the licensing and legal conclusions as counsel’s: 21YunBox is advisory on which lawful basis and which in-country operator fit your case — it does not hold or imply a China telecom or messaging license. What none of this is: a tunnel that ships the recipient data offshore anyway and calls it local.

This is a risk map, not a verdict that Amazon SES is “blocked” or “illegal.” Which of these obligations bite depends on your entity, the recipient data and content your mail carries, your role under Chinese law and who your users are — worth settling the specifics with counsel before your messaging pipeline depends on it.

The lawful path — map, localize, deliver

There is a compliant way to send transactional and marketing email to a China-facing audience, and it has a shape.

First, map. Our China compliance team charts what mail actually flows through Amazon SES today — which messages reach China recipients, what contact PII and content each carries, which reach a non-China region, what SES retains (suppression lists, event logs, identities), the consent basis for anything marketing, and where you lack a lawful basis for the cross-border leg. We build the technical picture; the legal conclusions are settled with your counsel.

Then localize. Where China-recipient mail has to run on a China footing, we move its delivery onto a compliant in-country / China-deliverable path — a China-resident email or notification service, the recipient data kept in the mainland and delivered through a route mainland mailboxes accept — minimize the recipient PII you send, and keep the Article 13/23 consent and opt-out. Localize means your China users’ contact details and message content stop leaving the country by default — never a tunnel that ships the data offshore anyway. You keep Amazon SES for the markets and messages where it already serves you.

Then deliver. The China-facing site or app that triggers and manages the mail is itself a public service in the mainland, so it carries an ICP filing duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — set in front of the origin you already run, with no rebuild and no re-platform. The result is a China-facing product whose messaging and delivery both run legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind: we route China-recipient mail onto a consented, in-country path, deliver in-country, and never move personal information out of China by stealth. We are a compliant overlay and a partner to AWS, not a competitor and not a migration.

Get a compliance assessment →

Related reading:

• Cross-border data transfers under PIPL
• China’s Cybersecurity Law (data localization, Article 39)
• China’s data-export security assessment measures
• How to get an ICP filing for China

RELATED TECHNOLOGIES

Agora

Agora

Azure AI Speech

Azure AI Speech

Mailgun

Mailgun

MessageBird

MessageBird

Postmark

Postmark

Resend

Resend

SendGrid

SendGrid

Twilio

Twilio

Vonage

Vonage