Amazon SES Privacy Guide

When developers use Amazon SES to send and receive email, several categories of data are involved in the service's operation. The specific data processed depends on how developers configure and use the service. According to AWS data classification and Amazon SES documentation, the data categories can be understood as customer data (controlled by developers) and service metadata (managed by AWS for operational purposes).

Email Message Content (Customer Data): The primary category of data processed by Amazon SES is the actual email message content that developers send through the service. According to AWS documentation, this customer-controlled content includes email addresses of senders and recipients (including To, CC, BCC, Reply-To addresses), subject lines of messages, message bodies in both plain text and HTML formats, file attachments including documents, images, and other media transmitted with messages, custom email headers added by developers for tracking, routing, or application-specific purposes, and MIME-encoded content for multipart messages.

According to AWS privacy principles, this email message content is customer data that customers own and control. AWS processes this data strictly according to customer instructions (the act of sending an email through the API or SMTP interface constitutes the instruction to process and deliver that email). AWS does not use email message content for any purpose other than providing the Amazon SES service, including specifically that AWS does not scan message content for advertising purposes, use message content to train machine learning models without explicit customer opt-in for specific AI services, or share message content with third parties except as essential to delivering emails to recipients.

Email Addresses and Identity Verification Data: Before developers can send email through Amazon SES, they must verify ownership of email addresses or domains they intend to send from. According to verification documentation, this process involves developers providing email addresses or domain names for verification, AWS sending verification emails with confirmation tokens or requesting DNS record creation, and storing verification status and associated tokens/records.

For domain verification, according to technical documentation, additional data is collected including DNS records (TXT records for verification, MX records for receiving email, DKIM records for authentication), DMARC policy records specifying authentication policies, and SPF (Sender Policy Framework) records identifying authorized sending servers.

Sender Reputation and Email Performance Metrics: Amazon SES automatically collects and processes data related to email sending performance and sender reputation. According to monitoring documentation, this includes bounce data (email addresses that generated bounces, bounce types such as hard or soft bounces, bounce timestamps and diagnostic messages), complaint data (email addresses that marked messages as spam, complaint timestamps, feedback loop identifiers from ISPs), delivery status (successful deliveries, delivery attempts, SMTP response codes from receiving servers), and sending metrics (volume of emails sent over time, sending rate patterns, message size statistics).

This reputation and performance data is used by AWS to provide services such as calculating sender reputation scores displayed in account dashboards, automatically suppressing problem addresses to maintain deliverability, providing recommendations for improving sending practices, and enforcing AWS acceptable use policies to prevent spam and abuse.

Configuration and Account Data: Developers configure Amazon SES through various settings that constitute configuration data. According to service documentation, this includes verified identities (list of verified email addresses and domains), configuration sets (logical groupings of email sending with associated tracking and analytics settings), sending authorization policies (rules for allowing other AWS accounts to send on behalf of verified identities), suppression list entries (globally or account-level suppressed addresses), and email templates (reusable message structures with variable substitution).

Account-level information is also processed including AWS account identifiers, IAM user and role information for access control, sandbox status and sending quotas for anti-abuse protection, SMTP credentials generated for SMTP interface access, and billing information for service charges.

Received Email Data (When Email Receiving is Used): For developers using Amazon SES to receive inbound email, according to receiving documentation, additional data categories are involved including received email content (sender addresses, recipients, subject, body, attachments), S3 object identifiers if emails are stored in Amazon S3 buckets, Lambda function invocation data if received emails trigger serverless functions, SNS notification payloads if received emails generate notifications, and receipt rules and actions defining how received email is processed.

CloudWatch Metrics and Logging Data: When developers enable logging and monitoring, according to AWS monitoring documentation, Amazon SES publishes data to CloudWatch including sending statistics (sends, deliveries, bounces, complaints, rejections), rejection reasons and error messages, event publishing data from configuration sets, and custom metrics defined by developers through configuration set dimensions.

Customer-Selected Analytics and Event Data: Through configuration sets, according to event publishing documentation, developers can send detailed email event data to various AWS services. This event data includes email send events (timestamp, message ID, configuration set, email headers), bounce events (bounce type, recipients, SMTP response), complaint events (feedback type, user agent, arrival date), delivery events (SMTP response, processing time), open and click events (if enabled, though this requires specialized implementation), rendering failure events (for template problems), and reject events (when sending is rejected due to reputation or policy issues).

Data Amazon SES Does NOT Collect or Use: It is critical to understand what Amazon SES and AWS do not do with customer email data. According to AWS privacy commitments and data protection principles, AWS does not read email content for advertising or marketing purposes, does not use customer email data to train AI models unless customers explicitly opt into specific AI services with clear notice, does not share customer email content with third parties except to deliver emails to intended recipients, does not sell customer data to data brokers or marketers, and does not access customer content unless specifically requested by the customer for support purposes, required to prevent fraud and abuse, or required by law.

Data Retention Practices: According to AWS documentation, data retention in Amazon SES varies by data type. Email message content is processed for immediate delivery and is not retained by AWS after successful delivery (except for brief caching periods for performance and retry purposes). However, if developers configure Amazon SES to store received emails in S3 or publish events to other AWS services, that data is retained according to the retention settings developers configure for those destination services.

Bounce and complaint data is retained by AWS for operational purposes including maintaining suppression lists and calculating sender reputation, with specific retention periods not publicly detailed but subject to AWS's general data retention principles (retaining only as long as necessary for service provision). Configuration data including verified identities, configuration sets, and templates is retained until explicitly deleted by developers or when accounts are closed. Billing data is retained according to standard AWS account management and financial record retention requirements.

Amazon SES's legal basis for processing personal data depends on the roles of the parties involved, the type of processing, and the jurisdictions of data subjects. According to AWS's Data Processing Addendum and privacy documentation, the legal framework is structured around AWS acting as a data processor on behalf of customers who are data controllers.

Contractual Necessity for Service Provision (Processor Role): When developers use Amazon SES to send or receive email containing personal data, AWS processes that data as a data processor. According to the AWS Data Processing Addendum, the fundamental legal basis is contractual necessity - AWS must process the email data to fulfill its contractual obligation to provide the Amazon SES email delivery service that customers have subscribed to.

This processing is strictly limited to what is necessary to provide the service, including accepting email submission through API or SMTP interfaces, validating sender verification and account quotas, processing email for delivery including applying DKIM signatures and routing through appropriate infrastructure, transmitting email to recipient mail servers globally, processing bounce and complaint notifications from recipient servers, and providing performance metrics and logging as configured by customers.

According to the AWS DPA, AWS processes customer data only on documented instructions from customers. The act of submitting an email for delivery through the Amazon SES API or SMTP interface constitutes the customer's instruction to AWS to process and deliver that email. AWS does not process customer email content for any purpose beyond providing the service unless customers explicitly configure additional processing through AWS services.

Customer's Legal Basis for Using Amazon SES: While AWS as processor relies on contractual necessity with customers, customers themselves (as data controllers) must establish appropriate legal bases for collecting email addresses and sending emails to data subjects. According to privacy principles that AWS guidance references, customers typically rely on user consent (particularly for marketing emails where recipients have explicitly opted in to receive communications), contractual necessity (for transactional emails required to fulfill contracts with users, such as order confirmations or password resets), or legitimate interests (for certain operational emails where processing is necessary for legitimate business purposes and not overridden by data subject rights).

AWS's Data Processing Addendum makes clear that customers are responsible for determining and maintaining their legal bases for processing. AWS provides tools and infrastructure to support compliance (such as unsubscribe management, suppression lists, and consent tracking mechanisms that can be integrated with applications), but customers must implement these tools appropriately for their use cases.

Legitimate Interests for Service Operation and Security: For certain operational processing activities, according to AWS privacy policy, AWS may rely on legitimate business interests. This includes security monitoring and abuse prevention where AWS analyzes sending patterns, content characteristics, and bounce/complaint rates to detect spam, phishing attempts, and policy violations. These activities protect AWS infrastructure, maintain email deliverability for all customers, comply with anti-spam regulations, and prevent AWS IP addresses from being blacklisted.

Performance optimization and service improvement involve analyzing aggregated, anonymized metrics about service performance, reliability, and usage patterns to improve Amazon SES features and infrastructure. These activities use aggregated data rather than individual message content. Fraud prevention includes detecting account compromise, unusual sending patterns, or other security threats.

According to privacy principles, these legitimate interests are balanced against customers' and email recipients' privacy rights through implementing processing only to the extent necessary for stated purposes, using aggregated and anonymized data where possible, maintaining strict access controls for any individual-level data access, and providing transparency through documentation and privacy notices.

AWS as Independent Controller for Account Management: For certain activities related to AWS account management (not email content), AWS acts as an independent data controller. According to AWS privacy notice, this includes customer account information (names, email addresses, phone numbers, billing information associated with AWS accounts) processed for account management, billing, customer support, security purposes, and AWS service improvement based on AWS's own business requirements.

For this account-level data, AWS's legal bases include contractual necessity (to provide AWS services including Amazon SES), legitimate interests (for service improvement, security, fraud prevention), and legal obligations (for regulatory compliance, tax requirements, responding to legal process).

Compliance with Legal Obligations: In certain circumstances, according to AWS legal documentation, data processing may be necessary to comply with legal requirements. This includes responding to valid legal process such as subpoenas, court orders, or lawful government requests (when legally required and after appropriate verification), complying with anti-spam laws including CAN-SPAM (USA), CASL (Canada), and similar regulations globally, meeting regulatory reporting requirements in various jurisdictions, and cooperating with law enforcement investigations when legally mandated.

According to AWS's government request principles, AWS carefully reviews all legal demands, provides customers with notice of government requests when legally permitted, challenges overbroad or inappropriate requests, and maintains transparency through publishing government request reports where legally allowed.

Special Considerations for HIPAA: Amazon SES is a HIPAA-eligible service, meaning it can be used to transmit protected health information (PHI) when appropriate agreements are in place. According to HIPAA compliance documentation updated in March 2026, AWS will execute a Business Associate Agreement (BAA) with customers who need to use Amazon SES for PHI transmission. Under HIPAA, the legal basis for BAA-covered entities processing PHI is compliance with HIPAA regulations themselves, which require appropriate administrative, physical, and technical safeguards.

For customers using Amazon SES under a BAA, AWS's processing of PHI occurs as a business associate with specific obligations defined by HIPAA including implementing appropriate safeguards for PHI, limiting use and disclosure of PHI to purposes allowed under HIPAA and the BAA, assisting covered entities with breach notification obligations, and maintaining documentation of safeguards and compliance measures.

Geographic Considerations and Jurisdictional Variations: The legal basis for processing varies by jurisdiction. For data subjects in the European Economic Area, United Kingdom, and Switzerland, processing is governed by GDPR and equivalent data protection laws. According to AWS's approach, international transfers from these regions are conducted under Standard Contractual Clauses incorporated in the AWS Data Processing Addendum, with supplementary measures including encryption and access controls.

For data subjects in California and other US states with comprehensive privacy laws (CCPA, Virginia CDPA, Colorado CPA, etc.), AWS implements required privacy rights and disclosures. According to AWS documentation, AWS complies with applicable state privacy requirements and provides mechanisms for customers to fulfill their own compliance obligations.

For data subjects in other jurisdictions including India, Brazil, Canada, and others with data protection laws, AWS applies its global privacy standards while implementing jurisdiction-specific requirements where applicable.

Developer Responsibilities Regarding Legal Basis: AWS's Data Processing Addendum and privacy guidance consistently emphasize that developers remain responsible as data controllers for establishing legal bases for their email processing. According to compliance guidance, developers must determine legal basis for collecting email addresses from users, maintain required consents where consent is the appropriate legal basis (particularly for marketing emails), implement and respect unsubscribe mechanisms as required by anti-spam laws, provide privacy notices explaining how email addresses are collected and used, include disclosure that Amazon SES (an AWS service) is used for email delivery, and maintain records demonstrating compliance with applicable laws.

AWS provides tools that support compliance but does not implement compliance automatically. For example, AWS provides suppression lists for managing unsubscribes, but developers must implement the UI and workflow for users to unsubscribe. AWS provides bounce and complaint tracking, but developers must respond appropriately to maintain list hygiene. AWS provides DKIM and SPF for authentication, but developers must configure domains correctly.

Amazon SES's subprocessor landscape is part of the broader AWS ecosystem. According to AWS's Data Processing Addendum and the publicly maintained AWS Sub-processors page (https://aws.amazon.com/compliance/sub-processors/), AWS provides comprehensive, regularly updated information about sub-processors engaged to provide processing activities on customer data.

AWS Infrastructure Entities: The primary sub-processors for Amazon SES are AWS entities that provide the infrastructure on which AWS services run. According to the subprocessor documentation, these AWS-affiliated entities operate AWS Regions and Edge Locations globally. For Amazon SES specifically, the relevant infrastructure entities depend on which AWS Region developers select for sending email.

According to the infrastructure entity list regularly updated on the AWS subprocessors page, AWS infrastructure entities include Amazon Web Services, Inc. (United States - headquarters and primary operations), AWS EMEA SARL (Luxembourg - European operations), Amazon Web Services South Africa Proprietary Limited (South Africa), Amazon Data Services India Private Limited (India), Amazon Internet Services Private Limited (India), Amazon Web Services Korea LLC (South Korea), Amazon Web Services Japan G.K. (Japan), Amazon Web Services Australia Pty Ltd (Australia), Amazon Web Services China (Beijing) Co., Ltd. and affiliates (China - note that AWS China operates under different governance), and dozens of additional AWS entities in countries including Brazil, Canada, Singapore, Israel, UAE, and newly added entities in Costa Rica, Ecuador, Morocco, Qatar, Rwanda, Saudi Arabia, and Sri Lanka according to recent updates.

When developers use Amazon SES in a particular AWS Region, email processing infrastructure is primarily provided by the AWS entity operating that region. For example, when using Amazon SES in the Europe (Frankfurt) region, AWS EMEA SARL and related European entities are the primary infrastructure subprocessors. When using Amazon SES in US East (Virginia), Amazon Web Services, Inc. is the primary infrastructure provider.

Service-Specific AWS Entities: According to Section 2 of the AWS subprocessors page, certain AWS entities are engaged for specific service functions. For services involving communication and content delivery (which would include email transmission through Amazon SES), AWS entities located in various countries may be engaged for development, support, monitoring, or service improvement purposes.

According to the documentation, AWS development entities may access customer content for service improvement purposes. These entities are located in Australia, Austria, Canada, China, Czech Republic, Germany, India, Ireland, Israel, Japan, Luxembourg, Romania, Singapore, South Africa, South Korea, Spain, United Kingdom, and United States. However, according to AWS privacy commitments, such access occurs only as necessary to develop and improve services, and customers can opt out of data transfer for service improvement purposes where available.

Third-Party Subprocessors: AWS has historically minimized reliance on third-party subprocessors for core infrastructure services, preferring to use AWS-owned entities and infrastructure. According to the third-party subprocessors section on the AWS compliance page, specific third-party providers are engaged for particular AWS services.

For Amazon SES specifically, based on available documentation, third-party subprocessors are minimal because email delivery is a core AWS infrastructure capability. However, when email is transmitted to recipients, it necessarily passes through recipient email servers and internet infrastructure providers globally, which are not subprocessors in the technical sense (as they are chosen by recipients, not AWS) but are part of the data flow that developers should understand.

CloudWatch and Logging Infrastructure: When developers configure Amazon SES to publish events to Amazon CloudWatch or other AWS logging services, the subprocessors for those destination services become relevant. According to AWS architecture, CloudWatch data is processed by AWS infrastructure entities in the selected AWS Region, with potential cross-region processing for service monitoring and aggregation purposes in some cases.

Email Receiving Subprocessors: For developers using Amazon SES email receiving capabilities, according to service architecture, received emails may be processed through various AWS services based on customer configuration including Amazon S3 for email storage (subprocessed by AWS entities operating the S3 service in the selected region), AWS Lambda for email processing (subprocessed by AWS entities operating Lambda infrastructure), Amazon SNS for notifications (subprocessed by AWS entities operating SNS), and Amazon WorkMail if integrated (though WorkMail has specific subprocessor arrangements as a distinct service).

Subprocessor Notification and Management: AWS provides a mechanism for customers to receive notifications about subprocessor changes. According to the AWS DPA and subprocessors page, customers can subscribe for email notifications at least 30 days before AWS engages a new subprocessor. To subscribe, customers provide their email address through a form at https://pages.awscloud.com/sub-processors/.

According to the AWS DPA, customers have rights regarding subprocessors including the right to receive notice before new subprocessors are engaged, the right to object to new subprocessors (though objection options are limited to terminating the service agreement, ceasing use of the specific AWS service, or moving to another region where the subprocessor is not engaged), and the right to audit subprocessor compliance (typically exercised through AWS's SOC 2 and other audit reports rather than direct customer audits).

The subprocessor page at https://aws.amazon.com/compliance/sub-processors/ is updated regularly with a 'What's Changed' page at https://aws.amazon.com/compliance/sub-processors/what_has_changed/ documenting recent additions, removals, and modifications to the subprocessor list. According to recent updates as of May 2026, AWS has added infrastructure entities in several new countries as AWS's global infrastructure expands.

Material Subcontractors for AWS European Sovereign Cloud: AWS has introduced a European Sovereign Cloud option with enhanced data sovereignty controls. According to documentation, this offering has a separate subprocessor list with more restrictive access controls. While Amazon SES's availability in the European Sovereign Cloud is not specifically documented as of May 2026, customers with stringent data sovereignty requirements should review European Sovereign Cloud offerings and their specific subprocessor limitations.

Transparency and Documentation: AWS's approach to subprocessor transparency is comprehensive compared to many cloud providers. The public subprocessors page provides entity names, types of processing, relevant services, processing locations (country level), and regular updates. However, some details are not publicly specified including specific data center locations within countries, contractual relationships and data processing agreements with each subprocessor entity, and detailed processing activities performed by each entity.

For customers requiring enhanced transparency, AWS provides additional information through AWS Artifact (a portal for compliance reports accessible through the AWS Console), SOC 2 reports describing AWS's control environment including subprocessor management, and direct engagement with AWS enterprise support and compliance teams for specific questions.

Developer Implications: For developers using Amazon SES, the subprocessor landscape has several implications. Developers should select AWS Regions based on desired data residency and subprocessor locations (e.g., using Europe Frankfurt region if European subprocessor entities are preferred). Developers should subscribe to subprocessor change notifications to maintain current understanding of the data processing chain. For privacy policy disclosures, developers should reference AWS's role as processor and direct users to AWS's subprocessor page for details. Developers with strict data sovereignty requirements should evaluate whether AWS's subprocessor arrangements meet their needs or whether additional measures (such as encryption key management or European Sovereign Cloud when available) are necessary.

International data transfer is inherently central to Amazon SES's functionality as an email delivery service. According to AWS privacy documentation, Amazon SES is explicitly categorized as a service where data transfer from the selected AWS Region is an essential function of the service - when you send messages via Amazon SES to recipients, the content of those messages is transferred to the locations of recipients globally.

Essential Data Transfer Function: Unlike many AWS services where customer data remains within the selected AWS Region by default, Amazon SES necessarily involves international data transfer. According to privacy features documentation, when developers send email through Amazon SES, email content is transmitted from the AWS Region where SES is invoked, through internet infrastructure, to recipient mail servers located anywhere in the world based on recipient email addresses.

This means that even if a developer selects the Europe (Frankfurt) AWS Region for sending email through Amazon SES, email content will be transferred internationally when sent to recipients with email addresses hosted in other countries. This transfer is fundamental to email's nature as a global communication protocol and cannot be prevented while still delivering emails.

Regional Selection for SES Endpoints: While international transfer during email delivery is unavoidable, developers do have control over which AWS Region processes email before delivery. According to regional documentation, Amazon SES is available in 27 AWS Regions worldwide as of 2026. Developers select a region when configuring SES endpoints, and this choice determines where AWS processes the email before transmission to recipients.

For example, according to regional architecture, when a developer uses the Europe (Frankfurt) SES endpoint, email processing occurs within AWS infrastructure in the Frankfurt region, AWS entities operating the Frankfurt region serve as the primary subprocessors, reputation data and metrics are stored in the Frankfurt region, and bounces and complaints are processed within the Frankfurt region. However, once emails are transmitted to recipients, they flow through global internet infrastructure to their destinations.

Standard Contractual Clauses for European Transfers: For transfers of personal data from the European Economic Area, United Kingdom, and Switzerland to countries outside these regions, AWS relies on Standard Contractual Clauses. According to the AWS Data Processing Addendum, which incorporates the European Commission-approved SCCs, these clauses govern international transfers from European customers to AWS infrastructure in other countries and onward transfers to subprocessors globally.

The AWS DPA, available as a document that customers can execute through their AWS account or as part of AWS Service Terms, includes the Standard Contractual Clauses as Appendix 3 (the current EU SCCs adopted in 2021). According to the DPA structure, AWS acts as the data importer when receiving data from European customers, AWS commits to implementing appropriate safeguards for transferred data, customers (as data exporters) authorize AWS to engage subprocessors as listed on the AWS subprocessors page, and customers have audit rights (typically exercised through AWS's published audit reports).

Supplementary Measures Beyond SCCs: Following the Schrems II decision by the Court of Justice of the European Union, which invalidated the Privacy Shield framework and required supplementary measures for transfers relying on SCCs, AWS has implemented additional technical and organizational safeguards. According to AWS security documentation and DPA commitments, these measures include encryption of data in transit using TLS 1.2 or higher for all AWS API communications and SMTP transmissions (with opportunistic or required TLS for email delivery to recipient servers), encryption of data at rest for certain stored data within AWS services (though email in transit through SES is not typically stored at rest by AWS), access controls limiting which AWS personnel can access customer data, multi-factor authentication requirements for administrative access to production systems, security monitoring and logging to detect unauthorized access attempts, regular third-party security audits and certifications (SOC 2, ISO 27001, etc.), and contractual limitations on government access with commitments to challenge inappropriate requests.

According to AWS's public statements on government requests and the Schrems II decision, AWS designs systems to prevent remote access by AWS personnel to customer data unless access is requested by customers, required to prevent fraud and abuse, or required to comply with law. AWS has publicly stated commitment to challenging overly broad government data requests and notifying customers of such requests when legally permitted.

Email Delivery Transfers (Essential to Service): The most significant international data transfer in Amazon SES is the email delivery itself. According to technical architecture, when an email is sent to a recipient at example.com, Amazon SES performs DNS lookups to find the MX (mail exchanger) records for example.com, establishes SMTP connections to the mail servers identified by those MX records (wherever they are located globally), transmits the email content using SMTP protocol with TLS encryption (opportunistic by default, required if configured), and receives delivery confirmation or bounce notifications from the recipient server.

This transfer occurs regardless of AWS Region selection and regardless of where the developer or recipient is located. It is the fundamental mechanism of email delivery and cannot be prevented without defeating the purpose of using an email service.

Practical Implications for Developers: For developers using Amazon SES, international data transfer implications include recognizing that email delivery inherently involves global data transfer regardless of AWS Region selection, selecting AWS Regions based on where email processing (before delivery) should occur, understanding that European users sending emails to recipients globally will involve transfers outside the EEA despite using EU-based AWS regions, disclosing in privacy policies that email transmission occurs globally to deliver messages to recipients, implementing TLS requirements for email delivery where security during transmission is critical, and considering whether email content should be end-to-end encrypted at the application layer for highly sensitive communications (AWS provides infrastructure, but application-layer encryption must be implemented by developers).

Data Residency for Email Processing Infrastructure: While email delivery necessarily involves international transfer, the data generated by email processing (reputation metrics, bounce/complaint data, sending logs) can be confined to a specific AWS Region. According to architectural documentation, when developers select an AWS Region for Amazon SES, sending metrics and reputation data are stored within that region, configuration sets and verified identities are region-specific, suppression lists are maintained within the region, and CloudWatch logs published by SES reside in the selected region (unless customers configure cross-region log aggregation).

China Special Considerations: AWS operates in China through separate legal entities under different governance models to comply with Chinese legal requirements. According to AWS China documentation, AWS services in China regions (operated by Beijing Sinnet Technology Co., Ltd. and Ningxia Western Cloud Data Technology Co., Ltd.) are subject to Chinese data localization laws. Amazon SES is available in AWS China regions with specific limitations and data residency requirements for customers operating in China.

For international businesses, this creates complexity: emails sent from AWS China regions to international recipients will transfer data outside China, emails sent from international AWS regions to recipients in China will transfer data into China, and compliance with both Chinese data localization requirements and international privacy laws requires careful architecture and legal analysis.

Developer Responsibilities for International Transfers: Developers using Amazon SES for email delivery to international recipients bear responsibility for several international transfer compliance requirements. According to privacy law principles, developers should disclose in privacy policies that email transmission involves international data transfer to deliver messages, implement appropriate legal bases for international transfers (consent, SCCs, legitimate interests depending on jurisdiction), execute AWS Data Processing Addendum for GDPR compliance when serving European users, consider whether application-layer encryption is necessary for sensitive email content, understand that recipient mail servers and internet infrastructure are outside AWS/developer control, and implement monitoring and logging to demonstrate compliance with transfer requirements.

Recent Developments: As of May 2026, the international data transfer landscape continues to evolve. The EU-US Data Privacy Framework (Privacy Shield's successor, adopted in 2023) remains subject to legal challenges in European courts. AWS's approach continues to rely primarily on Standard Contractual Clauses rather than solely on adequacy frameworks that may be subject to invalidation. New countries continue to adopt data localization requirements (recent examples include Indonesia, Vietnam, Turkey) that may affect where developers can legally use AWS services for residents of those countries. The AWS global infrastructure continues to expand with new regions, providing more options for data residency even though email delivery still involves international transfer.

When developers integrate Amazon SES into their applications, they assume extensive privacy compliance responsibilities as data controllers. The division of responsibilities between AWS and developers follows the AWS Shared Responsibility Model, which according to AWS security documentation specifies that AWS is responsible for security 'of' the cloud (infrastructure, regions, availability zones, managed services), while developers are responsible for security and compliance 'in' the cloud (configuration, content, access management, compliance with regulations).

Privacy Policy Requirements and Disclosures: Developers must maintain comprehensive privacy policies explaining their use of Amazon SES and associated data flows. According to privacy law requirements and AWS guidance, these policies should clearly identify Amazon SES (an Amazon Web Services service) as the email infrastructure provider, describe what email addresses and personal data are collected from users, explain the purposes of email communications (transactional, marketing, notifications), disclose that Amazon SES necessarily transmits emails internationally to deliver to recipients globally, reference AWS's privacy policy at https://aws.amazon.com/privacy and data processing addendum for details about AWS's data handling, explain users' rights regarding their email addresses including unsubscribe mechanisms, and provide contact information for privacy inquiries.

For developers sending marketing emails, according to anti-spam law requirements globally (CAN-SPAM in USA, CASL in Canada, GDPR in EU, etc.), additional disclosures and mechanisms are required including clear unsubscribe links in every marketing email, accurate 'From' addresses and subject lines, physical postal address of the sender, and prompt processing of unsubscribe requests (typically within 10 business days under CAN-SPAM).

Obtaining User Consent and Managing Subscriptions: Developers are responsible for obtaining appropriate consent before sending emails. According to anti-spam regulations and privacy laws, this means implementing opt-in mechanisms for marketing emails (with express consent required in many jurisdictions like Canada and Europe), documenting consent with timestamps and method of obtaining consent, providing clear information about what users are consenting to receive, implementing easy-to-use unsubscribe mechanisms in every email, honoring unsubscribe requests promptly (CAN-SPAM requires within 10 business days, CASL requires 'as soon as feasible'), and maintaining suppression lists to ensure unsubscribed users do not receive further marketing emails.

Amazon SES provides tools to support subscription management including account-level suppression lists that automatically prevent sending to addresses that have bounced or complained, configuration sets to organize different types of email sending, tracking of bounces and complaints through SNS notifications or event publishing, and SMTP credentials and API access that can be integrated with subscription management platforms.

However, according to AWS documentation, these are tools that developers must configure and use appropriately. AWS does not automatically manage subscriptions, implement consent collection, or enforce compliance with anti-spam laws. Developers must build these compliance mechanisms into their applications or use third-party email marketing platforms integrated with Amazon SES.

Data Processing Agreement Execution: For developers subject to GDPR or similar laws requiring Data Processing Agreements with vendors, executing AWS's Data Processing Addendum is mandatory. According to AWS GDPR resources, the AWS DPA is available through AWS Artifact (accessible via the AWS Console) or can be incorporated by reference through AWS Service Terms for certain customer types.

The DPA establishes AWS's role as processor and developer's role as controller, incorporates Standard Contractual Clauses for international transfers from Europe, defines permitted subprocessors and notification mechanisms, establishes security obligations and breach notification procedures, defines how data subject rights requests will be supported, and sets terms for data deletion or return upon contract termination.

According to compliance best practices, developers serving European users should formally execute the AWS DPA (if not already incorporated in service terms) as this is required under GDPR Article 28 for using a processor.

List Hygiene and Bounce/Complaint Management: Developers are responsible for maintaining email list quality. According to Amazon SES usage policies and industry best practices, this includes implementing double opt-in for email list subscriptions where appropriate, monitoring bounce rates and promptly removing hard bounce addresses, monitoring complaint rates and removing addresses that mark emails as spam, using Amazon SES's account-level suppression list to automatically prevent sends to problematic addresses, never purchasing email lists or sending to scraped addresses, regularly cleaning email lists to remove inactive or invalid addresses, and maintaining bounce rates below 5% and complaint rates below 0.1% to preserve sender reputation.

Amazon SES provides detailed bounce and complaint notifications through Amazon SNS or CloudWatch Events. According to service documentation, developers must implement systems to process these notifications and update their databases accordingly. Failure to manage bounces and complaints can result in sender reputation damage, account suspension by AWS, and violation of anti-spam regulations.

Email Authentication (DKIM, SPF, DMARC): Developers are responsible for properly configuring email authentication to prevent spoofing and improve deliverability. According to technical best practices and Amazon SES documentation, this includes setting up DKIM (DomainKeys Identified Mail) signatures by verifying domain ownership in Amazon SES and publishing DKIM DNS records, configuring SPF (Sender Policy Framework) by publishing TXT records identifying Amazon SES as authorized sender for the domain, implementing DMARC (Domain-based Message Authentication, Reporting and Conformance) policies to specify how recipients should handle authentication failures and receive aggregate reports, and using custom MAIL FROM domains to align SPF authentication with the domain used in the email's From address.

According to current email deliverability requirements in 2026, DMARC is increasingly required by major email providers (Gmail, Yahoo, Microsoft) for bulk senders. Developers sending significant email volumes must implement proper DMARC policies to ensure delivery.

Content and Abuse Prevention: Developers are responsible for ensuring email content complies with AWS Acceptable Use Policy and applicable laws. According to AWS policies, prohibited content includes spam or unsolicited bulk email, phishing attempts or fraudulent content, malware or malicious code, illegal content or content promoting illegal activities, content violating intellectual property rights, sexually explicit content (with limited exceptions for certain business purposes), content promoting violence or illegal discrimination, and child sexual abuse material.

According to SES usage policies, AWS monitors account sending patterns and investigates abuse complaints. Accounts found to be sending prohibited content can be immediately suspended or terminated. Developers must implement content filtering and abuse prevention measures including validating that recipients have consented to receive emails, implementing reasonable security to prevent account compromise and unauthorized sending, monitoring sending patterns for anomalous activity that might indicate compromise, and responding promptly to AWS notices about policy violations or abuse complaints.

Account Sandbox and Production Access Management: New Amazon SES accounts begin in a 'sandbox' mode with restricted capabilities. According to sandbox documentation, sandbox mode limits sending to verified email addresses only (cannot send to arbitrary addresses), imposes low sending limits (typically 200 emails per 24 hours, 1 email per second), and prevents sending to general recipients (only verified addresses or domains).

To move out of sandbox, developers must submit a request through AWS Support explaining intended use case (transactional, marketing, or mixed), expected sending volume (daily and monthly), process for managing bounces and complaints, list building practices (confirming opt-in methods and no purchased lists), and details about compliance with anti-spam regulations.

According to AWS's review process, requests with clear legitimate use cases, proper compliance procedures, and reasonable volumes are typically approved. Requests for sending to purchased lists, vague use cases, or lacking compliance procedures are denied. Developers should prepare comprehensive request documentation demonstrating understanding of email best practices and compliance requirements.

Sending Quotas and Rate Limits: Even after leaving the sandbox, Amazon SES accounts have sending quotas that affect how many emails can be sent and how quickly. According to quota documentation, these quotas include daily sending quota (maximum emails per 24-hour period), maximum send rate (maximum emails per second), and per-message limits (message size, recipients per message).

Developers are responsible for implementing proper rate limiting in their applications to stay within these quotas, requesting quota increases through AWS Support when legitimate growth requires higher limits, designing applications to gracefully handle quota-exceeded errors, and monitoring quota usage to prevent unexpected sending failures.

Security and Access Control: Developers are responsible for securing access to Amazon SES resources. According to AWS security best practices, this includes using IAM policies to limit SES access to only necessary users and applications (following least-privilege principles), enabling MFA (multi-factor authentication) for AWS console users who can access SES, rotating SMTP credentials regularly and storing them securely (never in source code or client applications), using IAM roles for applications running on EC2 to access SES without hardcoded credentials, monitoring AWS CloudTrail logs for SES API calls to detect unauthorized access, implementing network security controls such as VPC endpoints if appropriate, and encrypting sensitive configuration data including SES credentials in application configurations.

Monitoring and Incident Response: Developers must monitor email sending activity and respond to issues. According to operational best practices, this includes monitoring reputation dashboard in SES console for sender reputation scores, configuring CloudWatch alarms for high bounce rates, complaint rates, or sending failures, implementing logging of all email sending activity for audit and troubleshooting, responding promptly to AWS notifications about reputation issues or policy violations, investigating and remediating any account compromise or unauthorized sending, and maintaining incident response procedures for email-related security events.

Data Subject Rights Fulfillment: Under privacy regulations like GDPR and CCPA, users have various rights regarding their email addresses and communication preferences. According to compliance requirements, developers must implement processes to fulfill access requests (providing users with information about what email addresses are stored and what emails have been sent to them), rectification requests (allowing users to update their email addresses), deletion requests (removing email addresses from mailing lists and suppression lists when no longer needed), objection and unsubscribe requests (immediately honoring requests to stop receiving marketing emails), and portability requests (providing email addresses and communication preferences in portable format).

Amazon SES does not automatically implement these rights. According to AWS guidance, developers must build systems to track consent, manage user preferences, export data when requested, and delete data when required. AWS provides the infrastructure, but developers implement the compliance mechanisms.

Testing and Validation: Before using Amazon SES for production email sending, according to implementation best practices, developers should test in the SES sandbox with verified email addresses to ensure proper integration, verify email authentication (DKIM, SPF) using email header analysis tools, test bounce and complaint notification handling to ensure application properly processes feedback, verify that rate limiting and error handling work correctly under quota limits, test unsubscribe link functionality to ensure compliance with anti-spam laws, and send test emails to various email providers (Gmail, Outlook, Yahoo) to verify deliverability and correct rendering.

Compliance with Regional Requirements: Email regulations vary by jurisdiction. According to global compliance principles, developers sending to European recipients must comply with GDPR (requiring consent for marketing, data minimization, user rights), Canadian recipients must follow CASL (Canadian Anti-Spam Legislation, one of the strictest globally, requiring express consent even for existing business relationships in many cases), US recipients must comply with CAN-SPAM (requiring unsubscribe mechanisms, accurate headers, physical address), and recipients in other jurisdictions must comply with local anti-spam and privacy laws in countries including Australia, Brazil, China, India, Japan, and others.

Developers operating internationally must understand and comply with the most restrictive requirements applying to their recipient base, or segment sending by recipient location to apply appropriate rules.

For developers seeking authoritative information and documentation regarding Amazon SES and AWS data protection, the following official resources are available:

Amazon SES Technical Documentation:

AWS Privacy and Compliance:

Developers should bookmark these resources and monitor them regularly for updates. AWS frequently updates documentation, compliance certifications, and regional availability. The AWS Blog and 'What's New' page provide announcements about new features, regions, and compliance updates that may affect SES implementations.

This Privacy & Data Handling Profile provides a comprehensive overview of Amazon SES's data processing practices within the broader AWS ecosystem. As part of Amazon Web Services, Amazon SES benefits from AWS's extensive compliance infrastructure, regular third-party audits, and global scale while maintaining the privacy and security standards that apply across all AWS services.

However, this profile represents a snapshot of publicly available information and should be considered a starting point for developers' privacy due diligence, not a substitute for thorough legal analysis tailored to specific use cases. Email delivery through Amazon SES involves unique privacy considerations that differ from other AWS services, particularly regarding international data transfer and the inherently global nature of email as a communication protocol.

Critical Considerations for Amazon SES Implementation:

Email Necessarily Involves International Transfer: Unlike many cloud services where data can remain within selected geographic regions, email delivery fundamentally requires international data transfer. When you send an email to a recipient anywhere in the world, that email content travels through global internet infrastructure to reach its destination. This means that even if you select the Europe (Frankfurt) AWS Region for Amazon SES, emails sent to recipients outside Europe will be transferred internationally as an essential function of delivery. Developers must disclose this reality in privacy policies and cannot guarantee data residency for email content once it leaves AWS infrastructure for delivery.

AWS as Processor, Developer as Controller: The privacy responsibility model is clear: AWS processes email data strictly according to customer instructions (sending emails you submit), while developers remain data controllers responsible for obtaining consent, managing subscriptions, honoring unsubscribe requests, maintaining list hygiene, and complying with anti-spam laws. Amazon SES provides powerful infrastructure and tools (suppression lists, bounce tracking, reputation monitoring), but these tools must be configured and used appropriately. AWS does not implement compliance automatically.

Regional Selection Still Matters: While email delivery involves international transfer, selecting the appropriate AWS Region for Amazon SES still has important implications. Email processing (before delivery to recipients) occurs within your selected region. Reputation metrics, bounce/complaint data, and configuration are stored in the selected region. Subprocessors are primarily AWS entities operating that region. Developers should select regions based on where they want email processing to occur and which AWS entities they prefer as subprocessors, even though final delivery will cross borders.

Execute the AWS Data Processing Addendum: For developers subject to GDPR or serving European users, executing AWS's Data Processing Addendum is not optional - it is a legal requirement under GDPR Article 28 for using a data processor. The DPA establishes the legal framework for international transfers through Standard Contractual Clauses, defines subprocessor arrangements and notification rights, commits AWS to security and confidentiality measures, and establishes procedures for data subject rights and security incidents.

Anti-Spam Compliance is Critical: Email providers globally have zero tolerance for spam. Developers must understand that sending unsolicited email through Amazon SES will result in immediate bounce and complaint rates that damage sender reputation and may lead to account suspension. Implement proper opt-in mechanisms for all marketing emails (express consent in jurisdictions like Canada and Europe). Maintain scrupulous list hygiene by processing bounces and complaints immediately. Monitor reputation metrics closely and respond to degradation. Never purchase email lists or send to scraped addresses. Provide clear unsubscribe mechanisms in every marketing email.

Reputation Management is Developer Responsibility: Amazon SES provides shared IP pools for most users, meaning your sender reputation can affect and be affected by other SES users. However, AWS monitors accounts individually and will suspend accounts with poor sending practices regardless of shared infrastructure. Developers must actively manage reputation by monitoring bounce rates (keep below 5%), monitoring complaint rates (keep below 0.1%), responding promptly to AWS notices about reputation issues, requesting dedicated IPs if sending volume and quality warrant them, and implementing proper email authentication (DKIM, SPF, DMARC).

Sandbox Exit Requires Demonstrated Legitimacy: AWS protects its email infrastructure reputation by carefully vetting accounts before allowing production sending. To exit the sandbox, prepare comprehensive documentation explaining your legitimate use case, describing list-building practices with emphasis on opt-in consent, demonstrating understanding of bounce/complaint management, and providing realistic volume estimates. Vague requests or requests involving purchased lists will be denied. This process protects all SES users by preventing spammers from abusing the shared infrastructure.

Security is Shared Responsibility: While AWS secures the infrastructure, developers must secure their use of it. Protect SMTP credentials and API keys (never hardcode in applications or commit to source control). Implement IAM policies following least-privilege principles. Enable MFA for AWS console access. Monitor CloudTrail logs for unauthorized API calls. Rotate credentials regularly. An account compromise leading to spam sending can permanently damage reputation and result in account termination.

Understand Comprehensive Cost Structure: Amazon SES pricing starts at $0.10 per 1,000 emails, which appears inexpensive. However, total costs include data transfer fees (for emails sent from outside EC2 or for large attachments), dedicated IP costs (if needed for reputation control), monitoring costs (CloudWatch metrics, Kinesis Firehose for event publishing), storage costs (for received emails stored in S3), and potential costs of third-party platforms integrated with SES for campaign management. Accurately estimate total cost of ownership rather than considering only per-email charges.

HIPAA Eligibility Requires BAA: While Amazon SES is HIPAA-eligible (confirmed in March 2026 updates), using it for protected health information requires executing a Business Associate Agreement with AWS. HIPAA eligibility does not equal automatic HIPAA compliance - developers must implement appropriate administrative, physical, and technical safeguards beyond what SES provides as baseline infrastructure. Consult HIPAA compliance specialists when building healthcare communication systems.

Monitor AWS Updates Actively: Amazon SES continues to evolve with new regions (three new regions added in June 2025), new features (Mail Manager enhancements in April 2026), and changes to compliance certifications. Subscribe to AWS 'What's New' announcements, monitor the SES documentation changelog, subscribe to subprocessor change notifications at https://pages.awscloud.com/sub-processors/, and review AWS Artifact regularly for updated compliance reports.

The information presented here is derived from AWS's official documentation, technical guides, compliance materials, and community resources as of May 2026. Amazon SES is a mature service with millions of emails sent daily by customers ranging from startups to enterprises. Its integration with the broader AWS ecosystem provides powerful capabilities for developers who understand both its potential and its requirements.

Developers should actively monitor AWS's official resources, consult legal counsel for jurisdiction-specific compliance guidance, engage with AWS support for implementation questions, and remember that while AWS provides infrastructure and tools, the ultimate responsibility for privacy compliance, anti-spam compliance, and data protection rests with developers as data controllers.

The email landscape in 2026 includes increasingly strict deliverability requirements from major providers (Gmail, Yahoo, Microsoft requiring DMARC), heightened enforcement of anti-spam laws globally, growing privacy expectations from users, and continued evolution of email authentication standards. Amazon SES provides the infrastructure to meet these challenges, but success requires developers to use that infrastructure thoughtfully, compliantly, and with constant attention to reputation and regulatory requirements.