AWS Security ChangesHomeSearch

AWS ses documentation change

Service: ses · 2026-04-01 · Documentation low

File: ses/latest/dg/eb-ingress.md

Summary

Added comprehensive documentation for TLS policies and mutual TLS (mTLS) authentication for SES ingress endpoints, including configuration details, regional availability, and console instructions.

Security assessment

This change adds extensive documentation about security features (TLS policies and mTLS authentication) but does not indicate it's addressing a specific security vulnerability or incident. The documentation explains how to configure security features like FIPS-validated encryption, TLS requirements, and client certificate authentication, which are proactive security enhancements rather than reactive fixes.

Diff

diff --git a/ses/latest/dg/eb-ingress.md b/ses/latest/dg/eb-ingress.md
index d5b38f754..4c4769bbe 100644
--- a//ses/latest/dg/eb-ingress.md
+++ b//ses/latest/dg/eb-ingress.md
@@ -5 +5 @@
-Configuring ingress endpointsCreating an ingress endpoint (console)
+Configuring ingress endpointsTLS policymTLS authenticationCreating an ingress endpoint (console)
@@ -62,0 +63,8 @@ At the time you create an ingress endpoint, an "A" record for the endpoint will
+  * mTLS endpoint – Mail sent to your domain must come from clients that present a TLS client certificate signed by one of the certificate authorities (CAs) in the ingress endpoint's trust store. See Mutual TLS (mTLS) authentication for ingress endpoints.
+
+    * Copy and paste the value of the "A" record directly into the SMTP configuration of an on-premise SMTP client.
+
+    * Supported port: 25
+
+    * Supports STARTTLS: Yes
+
@@ -187,2 +194,0 @@ To use a VPC endpoint with an SES ingress endpoint, the following requirements m
-  * US & Canada regions – FIPS endpoints are the only VPC endpoints available in US and Canada regions and are the correct ones to use in these regions.
-
@@ -196,0 +203,2 @@ To use a VPC endpoint with an SES ingress endpoint, the following requirements m
+  * TLS policy must match VPC endpoint service – When creating a private ingress endpoint, the TLS policy value must match the VPC endpoint service type. An ingress endpoint with a `FIPS` TLS policy must use a FIPS VPC endpoint service, and an ingress endpoint with a `REQUIRED` or `OPTIONAL` TLS policy must use a non-FIPS VPC endpoint service. They cannot be mixed.
+
@@ -212,0 +221,72 @@ After configuring your VPC endpoint and ingress endpoint:
+## TLS policy for ingress endpoints
+
+The TLS policy for an ingress endpoint controls whether connecting SMTP clients are required to use TLS encryption when sending email to your endpoint. You can specify a TLS policy when creating an ingress endpoint using the `CreateIngressPoint` API, and change it later using the `UpdateIngressPoint` API. The default TLS policy depends on your region: `FIPS` is the default in US and Canada regions, and `REQUIRED` is the default in all other regions.
+
+All ingress endpoint connections use opportunistic TLS through the STARTTLS command. The connection begins as plaintext and is upgraded to TLS if the connecting client supports it. Implicit TLS (TLS Wrapper), where the connection starts encrypted, is not supported.
+
+The following TLS policy values are available:
+
+  * FIPS – Requires TLS encryption using FIPS-validated cryptographic modules. This is the default in US and Canada regions and is only available in those regions.
+
+  * REQUIRED – Connecting SMTP clients must use TLS encryption. Connections that do not use TLS are rejected. This is the default in regions outside of the US and Canada.
+
+  * OPTIONAL – TLS encryption is supported but not required. Connecting SMTP clients can send email with or without TLS.
+
+
+
+
+###### Availability by ingress endpoint type
+
+Not all TLS policy values are valid for every combination of ingress endpoint type and network configuration:
+
+  * FIPS – Can be used with all ingress endpoint types (open, authenticated, and mTLS) on public networks, and with open and authenticated ingress endpoints on private networks, but only in US and Canada regions. Once set, `FIPS` cannot be changed to another value through an update. If you need a different TLS policy, you must create a new ingress endpoint.
+
+  * REQUIRED – Can be used with all ingress endpoint types in all regions. However, for authenticated and mTLS ingress endpoints on public networks, `REQUIRED` can only be set at creation time—it cannot be changed through an update. For open ingress endpoints (public or private) and authenticated ingress endpoints on private networks, `REQUIRED` can be set at creation time and changed through an update. Note that `REQUIRED` is not available for authenticated or mTLS ingress endpoints on public networks in US and Canada regions, where `FIPS` is used instead.
+
+  * OPTIONAL – Can be used with open ingress endpoints on both public and private networks, and with authenticated ingress endpoints on private networks. `OPTIONAL` is not available for mTLS ingress endpoints, and is not available for authenticated ingress endpoints on public networks.
+
+
+
+
+###### Rules for changing TLS policy
+
+The following rules apply when updating the TLS policy on an existing ingress endpoint:
+
+  * `FIPS` cannot be changed after creation.
+
+  * For open ingress endpoints and authenticated ingress endpoints on private networks, you can switch between `REQUIRED` and `OPTIONAL`.
+
+  * For mTLS ingress endpoints and authenticated ingress endpoints on public networks, the TLS policy cannot be changed after creation.
+
+
+
+
+## Mutual TLS (mTLS) authentication for ingress endpoints
+
+Mutual TLS (mTLS) authentication requires connecting SMTP clients to present a TLS client certificate signed by one of the certificate authorities (CAs) in the ingress endpoint's trust store. Only clients with trusted certificates can send email to your endpoint.
+
+###### Important
+
+mTLS authentication is only available for public ingress endpoints. Amazon VPC endpoints do not support mTLS authentication.
+
+To create an mTLS ingress endpoint, choose `MTLS` as the ingress endpoint type and provide a `TlsAuthConfiguration` containing a `TrustStore` in the `IngressPointConfiguration` parameter of the `CreateIngressPoint` API.
+
+###### Trust store configuration
+
+The trust store defines which client certificates are accepted by your ingress endpoint. It contains the following fields:
+
+  * CAContent (required) – A certificate authority (CA) certificate bundle in PEM format. This bundle contains the CA certificates used to validate client certificates. You can include multiple CA certificates in a single bundle, up to 500 KB.
+
+  * CrlContent (optional) – A certificate revocation list (CRL) in PEM format. If provided, client certificates that appear on the CRL are rejected even if they are signed by a trusted CA. Up to 500 KB.
+
+  * KmsKeyArn (optional) – The ARN of a AWS KMS customer managed key (CMK) used to encrypt the trust store data. If not specified, an AWS managed key is used. When using a CMK, the key policy must allow SES to use the key. See [KMS customer managed key (CMK) key policy for mTLS trust store](./eb-policies.html#eb-policies-ingress-mtls-cmk).
+
+
+
+
+Expired certificates are considered invalid and are not accepted in connections. SES also filters out expired CA certificates and expired certificate revocation lists (CRLs) from your trust store. If a CRL expires, the CA certificate associated with that CRL is also removed from the trust store, which means clients signed by that CA will no longer be able to connect until you provide an updated CRL.
+
+###### Using client certificate attributes in rule conditions
+
+When a client connects to an mTLS ingress endpoint with a valid certificate, the certificate attributes (such as Common Name, serial number, and Subject Alternative Name fields) are made available for use in rule conditions as string expressions. This allows you to route, filter, or act on email based on the identity of the connecting client. For the full list of available attributes, see the [Rule conditions](./eb-rules.html#rule-conditions) reference.
+
@@ -227 +307 @@ The following procedure shows you how to use the **Ingress endpoint** page in th
-  5. Choose whether it will be a **Open** or **Authenticated** endpoint.
+  5. Choose whether it will be an **Open** , **Authenticated** , or **mTLS** endpoint.
@@ -230,0 +311,2 @@ The following procedure shows you how to use the **Ingress endpoint** page in th
+     * If you choose **mTLS** , you must provide a trust store configuration containing your CA certificate bundle. Optionally, you can also provide a certificate revocation list and a AWS KMS key. See Mutual TLS (mTLS) authentication for ingress endpoints.
+
@@ -283 +365,3 @@ For **Key** , you must only enter `password` (anything else will cause authentic
-  9. Select **Create ingress endpoint**.
+  9. Select a TLS policy for your ingress endpoint. The default depends on your region—see TLS policy for details on available values and restrictions.
+
+  10. Select **Create ingress endpoint**.
@@ -285 +369 @@ For **Key** , you must only enter `password` (anything else will cause authentic
-  10. In **General details** , "Provisioning" will be displayed while your ingress endpoint is being created—refresh the page until "Active" is displayed and the **ARecord** field contains a value. Copy the "A" record value and paste it into your DNS configuration or your SMTP client as discussed in Public endpoint configuration.
+  11. In **General details** , "Provisioning" will be displayed while your ingress endpoint is being created—refresh the page until "Active" is displayed and the **ARecord** field contains a value. Copy the "A" record value and paste it into your DNS configuration or your SMTP client as discussed in Public endpoint configuration.
@@ -287 +371 @@ For **Key** , you must only enter `password` (anything else will cause authentic
-  11. Just above the **General details** container on the console, there is a large, unlabeled number prefixed by "inp" (also replicated in the breadcrumb trail at the top of the page), for example, **inp-1abc2de3fghi4jkl5mnop6qr**. This is referred to as the _ingress endpoint ID_ , its value is used as the _username_ to login to your ingress server. (You'll need to share this with your authorized senders to connect to your endpoint.)
+  12. Just above the **General details** container on the console, there is a large, unlabeled number prefixed by "inp" (also replicated in the breadcrumb trail at the top of the page), for example, **inp-1abc2de3fghi4jkl5mnop6qr**. This is referred to as the _ingress endpoint ID_ , its value is used as the _username_ to login to your ingress server. (You'll need to share this with your authorized senders to connect to your endpoint.)
@@ -289 +373 @@ For **Key** , you must only enter `password` (anything else will cause authentic
-  12. You can view and manage the ingress endpoints you've already created from the **Ingress endpoints** page. If there's an ingress endpoint you want to remove, select it's radio button followed by **Delete**.
+  13. You can view and manage the ingress endpoints you've already created from the **Ingress endpoints** page. If there's an ingress endpoint you want to remove, select it's radio button followed by **Delete**.
@@ -291 +375 @@ For **Key** , you must only enter `password` (anything else will cause authentic
-  13. To edit an ingress endpoint, select its name to open its summary page:
+  14. To edit an ingress endpoint, select its name to open its summary page:
@@ -293 +377 @@ For **Key** , you must only enter `password` (anything else will cause authentic
-     * You can change the endpoint's active status by choosing **Edit** in **General details** followed by **Save changes**.
+     * You can change the endpoint's active status or TLS policy (for supported configurations) by choosing **Edit** in **General details** followed by **Save changes**.