

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 什麼是 Amazon SES？
<a name="Welcome"></a>

[Amazon Simple Email Service (SES)](https://aws.amazon.com/ses) 為電子郵件平台，為您提供簡單且符合經濟效益的方式來使用自有電子郵件地址和網域傳送和接收電子郵件。

例如，可傳送行銷電子郵件，例如特別優惠、交易電子郵件如訂單確認，以及其他類型的通訊內容，如電子報。當您使用 Amazon SES 來接收郵件時，可開發軟體解決方案，例如電子郵件自動回應程式、電子郵件取消訂閱系統以及可自傳入的電子郵件中產生客戶支援票證的應用程式。

如需 Amazon SES 各種相關主題的更多資訊，請參閱 [AWS 簡訊與目標鎖定部落格](https://aws.amazon.com//blogs/messaging-and-targeting/)。

## 優勢
<a name="why-use-ses"></a>

建構大規模電子郵件解決方法對於企業來說通常是項複雜又所費不貲的挑戰。需面對基礎設施挑戰，例如電子郵件伺服器管理、網路組態以及 IP 地址評價等。此外，許多第三方電子郵件解決方案需要協議合約與價格以及可觀的前期成本。Amazon SES 屏除這些難關，讓您從 Amazon.com 多年來累積的經驗，以及為大規模顧客群所打造的成熟電子郵件基礎建設中獲得最佳效益。

## 相關服務
<a name="ses-and-aws"></a>

Amazon SES 與其他 AWS 產品無縫整合。例如，您可以：
+ 將電子郵件傳送功能新增到任何應用程式。
+  若要從 Amazon EC2 傳送電子郵件，您可以使用 [AWS 軟體開發套件](https://aws.amazon.com/tools/#sdk)、使用 [Amazon SES SMTP 界面](send-email-smtp.md)，或直接呼叫 [Amazon SES API](https://docs.aws.amazon.com/ses/latest/APIReference/)。
+ 使用 [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) 建立啟用電子郵件功能的應用程式，例如使用 Amazon SES 來將電子報傳送給客戶的程式。
+ 設定 [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/) 來通知您遭到退信、產生投訴，或者成功遞送到收件人電子郵件伺服器的電子郵件。當您使用 Amazon SES 接收電子郵件時，您的電子郵件內容可發佈到 Amazon SNS 主題。
+ 使用 AWS 管理主控台 設定 Easy DKIM，這是驗證電子郵件的方法。雖然您可透過任何 DNS 供應商來使用 Easy DKIM，使用 [Route 53](https://aws.amazon.com/route53/) 來管理網域可讓設定過程更為簡單。
+ 使用 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 來控制使用者的電子郵件傳送存取權。
+ 將收到的電子郵件存放在 [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)。
+ 觸發 [AWS Lambda](https://aws.amazon.com/lambda/) 函數來對收到的電子郵件採取動作。
+ 使用 [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) 來選擇性加密您在 Amazon S3 儲存貯體中收到的電子郵件。
+ 使用 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 來記錄您使用主控台或 Amazon SES API 執行的 Amazon SES API 呼叫。
+ 將您的電子郵件傳送事件發佈至 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 或 [Amazon Data Firehose](https://aws.amazon.com/firehose/)。如果您將電子郵件傳送事件發佈至 Firehose，您可以在 [Amazon Redshift](https://aws.amazon.com/redshift/)、[Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/) 或 [Amazon S3](https://aws.amazon.com/s3/) 中存取它們。

## 定價
<a name="ses-pricing"></a>

使用 Amazon SES，您可以根據傳送和接收的電子郵件數量付費。如需詳細資訊，請參閱 [Amazon SES 定價](https://aws.amazon.com/ses/pricing/)。

# 區域和 Amazon SES
<a name="regions"></a>

SES AWS 區域 在全球數個 中提供。在每個區域中， AWS 會維護多個可用區域。這些可用區域各自實體隔離，但以私有、低延遲、高輸送量、高度冗餘的網路連線加以整合。這些可用區域讓我們能提供極高的可用性和備援，同時減少延遲。

如需所有 SES 區域端點的清單，請參閱《》中的 [Amazon Simple Email Service 端點和配額](https://docs.aws.amazon.com/general/latest/gr/ses.html)*AWS 一般參考*。若要進一步了解每個區域中可用的可用區域數量，請參閱 [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)。

本節包含您計劃在多個 SES 中使用時需要知道的資訊 AWS 區域。將探討下列主題：
+ [SES 區域和端點](#region-endpoints)
+ [沙盒移除與提高傳送限制](#region-quota-increases)
+ [電子郵件地址和網域驗證](#region-verification)
+ [Easy DKIM](#region-dkim)
+ [帳戶層級禁止名單](#region-suppression-list)
+ [意見回饋通知](#region-feedback-notifications)
+ [SMTP 登入資料](#region-smtp)
+ [傳送授權](#region-sending-authorization)
+ [用於自訂「寄件人」網域的意見回饋端點](#region-feedback)
+ [電子郵件接收](#region-receive-email)
+ [設定 (MX) 記錄](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html)

如需 的一般資訊 AWS 區域，請參閱《 一般參考》中的[AWS 服務端點](https://docs.aws.amazon.com/general/latest/gr/rande.html)。 *AWS *

## SES 區域和端點
<a name="region-endpoints"></a>

當您使用 SES 傳送電子郵件時，您會連線到提供 SES API 或 SMTP 界面端點的 URL。*AWS 一般參考* 包含您用來透過 SES 傳送和接收電子郵件的完整端點清單。如需詳細資訊，請參閱《》中的 [Amazon Simple Email Service 端點和配額](https://docs.aws.amazon.com/general/latest/gr/ses.html) AWS 一般參考— 以下參考特定章節：
+ **[API 端點](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_region)** – 當您透過 SES 傳送電子郵件時，您可以使用此表格中列出的 URLs 向 SES API 提出 HTTPS 請求。
+ **[SMTP 端點](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_smtp_endpoints)** – 您可以使用此表格中列出的 URLs，在使用 SMTP 界面時傳送電子郵件。
+ **[電子郵件接收端點](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_inbound_endpoints)** – 如果您已設定 SES 接收傳送到網域的電子郵件，您可以在[網域的 DNS 設定中設定郵件交換 (MX) 記錄](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html)時，使用此表格中列出的傳入 SMTP 端點 URLs。
**注意**  
傳入 SMTP URL 並非 IMAP 伺服器地址。換言之，您無法使用它們來接收電子郵件，例如使用 Outlook 之類的應用程式。有關為傳入電子郵件提供 IMAP 伺服器的服務，請參閱 [Amazon WorkMail](https://aws.amazon.com/workmail)。

## 沙盒移除與提高傳送限制
<a name="region-quota-increases"></a>

您帳戶的沙盒狀態可能不同 AWS 區域。換句話說，如果您的帳戶已從美國西部 （奧勒岡） 區域的沙盒中移除，它可能仍位於美國東部 （維吉尼亞北部） 區域的沙盒中，除非您也將其從該區域的沙盒中移除。

傳送限制也可能因 而異 AWS 區域。例如，如果您的帳戶可以在歐洲 （愛爾蘭） 區域中每秒傳送 10 則訊息，您可能可以在其他區域中傳送更多或更少的訊息。

當您[提交請求以從沙盒中移除帳戶](request-production-access.md)，或[提交請求以增加帳戶的傳送配額時](manage-sending-quotas-request-increase.md#user-requested-increased-sending-quotas)，請務必選擇 AWS 區域 您請求適用的所有 。您可以在一個支援中心案例中提交多個請求。

## 電子郵件地址和網域驗證
<a name="region-verification"></a>

在使用 SES 傳送電子郵件之前，您必須驗證您擁有計劃傳送的電子郵件地址或網域。電子郵件地址和網域的驗證狀態也不同 AWS 區域。例如，如果您在美國西部 （奧勒岡） 區域驗證網域，您將無法使用該網域在美國東部 （維吉尼亞北部） 區域傳送電子郵件，直到您再次完成該區域的驗證程序。如需驗證電子郵件地址或網域的詳細資訊，請參閱[在 Amazon SES 中驗證身分](verify-addresses-and-domains.md)。

## Easy DKIM
<a name="region-dkim"></a>

您必須對要使用 Easy DKIM 的每個 AWS 區域 執行 Easy DKIM 設定程序。也就是說，在每個區域中，您必須使用 SES 主控台或 SES API 來產生 CNAME 記錄。接著，您必須將所有 CNAME 記錄新增至網域的 DNS 組態。如需設定 Easy DKIM; 的詳細資訊，請參閱「[Amazon SES 中的 Easy DKIM](send-email-authentication-dkim-easy.md)」。

並非所有 都 AWS 區域 使用預設 SES DKIM 網域，`dkim.amazonses.com`若要查看您的區域是否使用區域特定的 DKIM 網域，請檢查 中的 [DKIM 網域資料表](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_dkim_domains)*AWS 一般參考*。

## 帳戶層級禁止名單
<a name="region-suppression-list"></a>

您的 SES 帳戶層級禁止名單 AWS 帳戶 僅適用於目前 中的 AWS 區域。您可以使用 SES API v2 或主控台，手動新增或移除您帳戶層級禁止名單中的個別或大量地址。如需使用帳戶層級禁止名單的詳細資訊，請參閱 [使用 Amazon SES 帳戶層次禁止名單](sending-email-suppression-list.md)。

## 意見回饋通知
<a name="region-feedback-notifications"></a>

在多個 中設定意見回饋通知時，需要注意兩個重點 AWS 區域：
+ 已驗證的身分設定，例如您是否透過電子郵件或透過 SNS 收到意見回饋，僅適用於您設定意見回饋的區域。例如，如果您在美國西部 （奧勒岡） 和美國東部 （維吉尼亞北部） 區域驗證 *user@example.com*，並且想要透過 SNS 通知接收退信電子郵件，則必須使用 SES API 或 SES 主控台在這兩個區域中設定 *user@example.com* 的 SNS 意見回饋通知。
+ 您用於意見回饋轉送的 SNS 主題必須位於您使用 SES 的相同區域。

如需透過意見回饋通知監控傳送活動的詳細資訊，請參閱 [設定 Amazon SES 的事件通知](monitor-sending-activity-using-notifications.md)。

## SMTP 登入資料
<a name="region-smtp"></a>

您用來透過 SES SMTP 界面傳送電子郵件的登入資料對每個 都是唯一的 AWS 區域。如果您使用 SES SMTP 界面在多個區域中傳送電子郵件，則必須為每個區域[產生一組 SMTP 登入](smtp-credentials.md)資料。

**注意**  
如果您在 2019 年 1 月 10 日之前建立 SMTP 登入資料，您的 SMTP 登入資料會使用舊版 AWS Signature 建立。基於安全性考量，您應刪除在此日期之前建立的憑證，改用較新的憑證。您可以[使用 IAM 主控台刪除較舊的憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting)。

## 用於自訂「寄件人」網域的意見回饋端點
<a name="region-feedback"></a>

如果您使用自訂「寄件人」網域，SES 會要求您發佈 MX 記錄，讓您的網域可以接收電子郵件提供者傳送給您的退信和投訴通知。您可以將相同的自訂「寄件人」網域用於不同 中的已驗證身分， AWS 區域 因為退信和投訴通知會傳送到區域特定的意見回饋端點。

當您設定自訂「寄件人」網域時，SES 會自動為設定自訂「寄件人」的區域指定正確的意見回饋端點。此端點會在 MX 記錄的值欄位中提供，供您發佈 （新增） 至網域的 DNS 組態。

自訂「寄件人」設定程序如 [使用自訂「寄件人」網域](mail-from.md) 中所述。做為參考，SES 用於不同 的意見回饋端點 AWS 區域 會列在 的[意見回饋端點](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_feedback_endpoints)表格中 AWS 一般參考。

## 傳送授權
<a name="region-sending-authorization"></a>

委派寄件者只能從驗證 AWS 區域 身分擁有者身分的 傳送電子郵件。提供委派寄件者權限的傳送授權政策必須連接到該區域內的身分。如需關於傳送授權的詳細資訊，請參閱 [透過 Amazon SES 使用傳送授權](sending-authorization.md)。

## 電子郵件接收
<a name="region-receive-email"></a>

除了 Amazon S3 儲存貯體之外，您用於透過 SES 接收電子郵件的所有 AWS 資源都必須與 SES 端點 AWS 區域 位於相同位置。例如，如果您在美國西部 （奧勒岡） 區域使用 SES，則您使用的任何 SNS 主題、KMS 金鑰和 Lambda 函數也必須位於美國西部 （奧勒岡） 區域。同樣地，若要接收區域內包含 SES 的電子郵件，您必須在該區域中建立作用中的接收規則集。電子郵件接收概念和設定程序會在 中說明[使用 Amazon SES 接收電子郵件](receiving-email.md)。

中的[電子郵件接收端點](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_inbound_endpoints)表格 AWS 一般參考 列出 SES AWS 區域 支援電子郵件接收的所有 的電子郵件接收端點。

# Amazon SES 中的服務配額
<a name="quotas"></a>

下列章節列出並說明適用於 Amazon SES 資源和操作的配額。有些配額可以增加，有些則無法增加。若要判斷是否可以請求增加配額，請參閱 **Adjustable** (可調整) 一欄。

**注意**  
SES 配額適用於 AWS 區域 您在 中使用的每個配額 AWS 帳戶。

## 電子郵件傳送份額
<a name="quotas-email-sending"></a>

下列配額適用於透過 SES 傳送電子郵件。

### 傳送份額
<a name="quotas-sending"></a>

配額是以收件人數量為基礎，而不是以郵件數量為基礎。


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
| 每 24 小時期間內可傳送的電子郵件數量 |  若您的帳戶位於沙盒內，則配額為每 24 個小時最多可以傳送 200 封電子郵件。 如果您的帳戶在沙盒外，此數字會根據您的特定使用案例而不同。  |  [是](manage-sending-quotas-request-increase.md)  | 
| 每秒可傳送的電子郵件數量 (傳送率) |  若您的帳戶位於沙盒內，則配額為每秒可傳送 1 封電子郵件。 如果您的帳戶在沙盒外，此速率會根據您的特定使用案例而不同。  |  [是](manage-sending-quotas-request-increase.md)  | 

### 訊息配額
<a name="quotas-message"></a>


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  **使用 [SES v1 API](https://docs.aws.amazon.com/ses/latest/APIReference/)** - 最大訊息大小 (包括配件)  |  每則訊息 10 MB (採用 base64 編碼)。  |  否 *(對於訊息大小超過 10MB 的工作負載，請考慮遷移到 [SES v2 API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/)。)*  | 
|  **使用 [SES v2 API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/) 或者 [SMTP](send-email-smtp.md)** - 最大訊息大小 (包括配件)  |  每則訊息 40 MB (採用 base64 編碼)。  |  否  | 

**注意**  
大於 10MB 的訊息會受到頻寬限制的調節，並且根據您的傳送速率，您可能會被調節至 40MB/s。例如，您可以以每秒 1 則訊息的速率傳送 40MB 訊息，也可以每秒傳送兩則 20MB 訊息。

### 寄件者和收件人配額
<a name="quotas-sender-recipient"></a>


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  租用戶數量上限  |  10,000  |  [ 是 ](manage-sending-quotas-request-increase.md#user-requested-increased-sending-quotas)  | 
|  每則訊息的最高收件人數量  |  每則訊息 50 個收件人。  收件人可以是「收件人」、「副本」或「密件副本」地址。   |  否。  | 
|  您可以驗證的最大身分數量  |  每個 10，000 個身分 AWS 區域。  *身分*是您用來透過 SES 傳送電子郵件的網域或電子郵件地址。   |  請聯絡您的 AWS 帳戶經理以討論您的使用案例。  | 
|  專用 IP 集區的最大數量 (包括受管理和標準 IP 集區)  |  50  |  否  | 

### 與事件發佈相關的配額
<a name="quotas-publishing"></a>


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  組態設定的最高數量  |  10,000  |  否  | 
|  組態集名稱的長度上限  |  組態集名稱可包含最多 64 個英數字元。他們也可以包含連字號 (-) 和底線 (\$1)。名稱不可包含空格、重音字元，或任何其他特殊字元。  |  否  | 
|  每個組態設定的事件目的地最高數量  |  10  |  否  | 
|  每個 CloudWatch 事件目的地的最高維度數量  |  10  |  否  | 

### 電子郵件範本配額
<a name="quotas-templates"></a>


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  每個 中的電子郵件範本數量上限 AWS 區域  |  20,000  |  否  | 
|  範本大小上限  |  500 KB  |  否  | 
|  每個範本中替換值的數量上限  |  無限制  |  N/A  | 
| 每個範本化電子郵件的收件人數量上限 | 50 個目標 *目標*是任何位於 "To"、"CC" 或 "BCC" 行上的電子郵件地址。  在對 API 發出的單一呼叫中，您可聯絡的目標數可能會受到帳戶的最高傳送速率限制。   |  否  | 

## 電子郵件接收配額
<a name="quotas-email-receiving"></a>

下表列出透過 SES 接收電子郵件的相關配額。


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  每個接收規則集的最高規則數量  |  200  |  否  | 
|  每個接收規則集的最高動作數量  |  10  |  否  | 
|  每個接收規則集的最高收件人數量  |  500  |  否  | 
|  每個 的接收規則集數目上限 AWS 帳戶  |  40  |  否  | 
|  每個 的 IP 地址篩選條件數目上限 AWS 帳戶  |  100  |  否  | 
|  可儲存於 Amazon S3 儲存貯體的電子郵件大小上限 (包含頁首)  |  40 MB  |  否  | 
|  可使用 Amazon SNS 通知發佈的電子郵件大小上限 (包含頁首)  |  150 KB  |  否  | 
|  可使用 Amazon SNS 通知發佈的電子郵件標頭大小上限  |  10 KB  |  否  | 
|  可使用 AWS Lambda 函數發佈的電子郵件標頭大小上限  |  50 KB  |  否  | 

## Mail Manager 配額
<a name="quotas-mail-manager"></a>

下表列出與 Mail Manager 相關聯的配額。


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  開啟的輸入端點數目上限  |  10  |  否  | 
|  授權的輸入端點數目上限   |  50  |  否  | 
|  每則訊息的最高收件人數量  |  100  |  否  | 
|  電子郵件大小上限 （包括標頭）  |  40 MB  |  否  | 
|  流量政策陳述式的數量上限  |  20  |  否  | 
|  流量政策陳述式條件數目上限  |  10  |  否  | 
|  每個區域的流量政策數目上限  |  100  |  否  | 
|  SMTP 轉送的數量上限  |  40  |  否  | 
|  每個區域的最大地址清單數量  |  100  |  否  | 
|  每個地址清單的地址數目上限  |  100,000  |  否  | 
|  規則集的數量上限  |  40  |  否  | 
|  每個規則集的規則數目上限  |  40  |  否  | 
|  每個規則的條件數目上限  |  10  |  否  | 
|  每個規則的動作數量上限  |  10  |  否  | 
|  每個規則集的轉送或傳送動作數量上限  |  10  |  否  | 
|  *作用中*封存的數量上限  |  10  |  否  | 
|  封存搜尋結果的數量上限  |  1000  |  否  | 
|  匯出的封存搜尋結果數目上限  |  250,000  |  否  | 
|  平行執行中搜尋請求的數量上限  |  1  |  否  | 
|  平行執行中匯出請求的數量上限  |  1  |  否  | 
|  每週封存的保留變更數目上限  |  1  |  否  | 

## 一般配額
<a name="quotas-email-general"></a>

下表列出適用於透過 SES 傳送和接收電子郵件的配額。

### SES API 傳送配額
<a name="quotas-api"></a>


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  可呼叫 Amazon SES API 動作的速率  |  所有動作 (除了 `SendEmail`、`SendRawEmail` 和 `SendTemplatedEmail`) 皆受每秒執行一次請求的調節。  |  否  | 
|  MIME 部分  |  500  |  否  | 

### SES 其他配額
<a name="quotas-misc"></a>


| 資源 | 預設配額 | 可調整 | 
| --- | --- | --- | 
|  並行匯入任務的數量上限  |  20  |  否  | 
|  並行匯出任務的數量上限  |  20  |  否  | 

# Amazon SES 憑證的類型
<a name="send-email-concepts-credentials"></a>

若要與 Amazon Simple Email Service (Amazon SES) 互動，請使用安全憑證來驗證您的身分以及您是否有與 Amazon SES 互動的許可。有不同類型的登入資料，且您使用的登入資料取決於想要執行的操作。例如，使用 Amazon SES API 傳送電子郵件時需使用 AWS 存取金鑰，而在使用 Amazon SES SMTP 界面傳送電子郵件時則需使用 SMTP 憑證。

下表列出使用 Amazon SES 時可能用到的憑證類型，取決於您所執行的操作。


****  

| 如果您想要存取… | 使用這些登入資料 | 登入資料的組成內容 | 如何取得登入資料 | 
| --- | --- | --- | --- | 
| Amazon SES API（您可以直接存取 Amazon SES API，或透過 AWS SDK AWS Command Line Interface、 或 間接存取 AWS Tools for Windows PowerShell。) | AWS 存取金鑰 | 存取金鑰 ID 和私密存取金鑰 | 請參閱 [https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)* 中的AWS 一般參考 Access Keys* (存取金鑰)。  為了安全最佳實務，請使用 AWS Identity and Access Management (IAM) 使用者存取金鑰，而非 AWS 帳戶 存取金鑰。您的 AWS 帳戶 登入資料會授予所有 AWS 資源的完整存取權，因此您應該將它們存放在安全的地方，並改為使用 IAM 使用者登入資料與 day-to-day互動 AWS。如需詳細資訊，請參閱 *AWS 一般參考* 中的[根帳戶登入資料與 IAM 使用者憑證](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html)。   | 
| Amazon SES SMTP 界面 | SMTP 登入資料 | 使用者名稱和密碼 | 請參閱 [取得 Amazon SES SMTP 憑證](smtp-credentials.md)。  雖然您的 Amazon SES SMTP 憑證與您的 AWS 存取金鑰及 IAM 使用者存取金鑰不同，但 Amazon SES SMTP 憑證其實是一種 IAM 憑證。IAM 使用者可建立 Amazon SES SMTP 憑證，但是根帳戶擁有者必須確保 IAM 使用者的政策給予他們存取下列 Amazon SES 動作的許可：「iam:ListUsers」、「iam:CreateUser」、「iam:CreateAccessKey」和「iam:PutUserPolicy」。  | 
| Amazon SES 主控台 | IAM 使用者名稱和密碼或電子郵件和密碼 | IAM 使用者名稱和密碼或電子郵件和密碼 | 請參閱 [https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#iam-user-name-and-password](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#iam-user-name-and-password)[ 的 ](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#email-and-password-for-your-AWS-account)IAM User Name and Password* (IAM 使用者名稱和密碼) 和AWS 一般參考 Email Address and Password* (電子郵件地址和密碼)。  做為安全最佳實務，請使用 IAM 使用者名稱和密碼，而非電子郵件地址和密碼。電子郵件地址和密碼組合適用於您的 AWS 帳戶，因此您應該將它們存放在安全的地方，而不是用於與 day-to-day互動 AWS。如需詳細資訊，請參閱 *AWS 一般參考* 中的[根帳戶登入資料與 IAM 使用者憑證](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html)。  | 

如需不同類型 AWS 安全登入資料 (SMTP 登入資料除外，僅用於 Amazon SES的詳細資訊，請參閱 中的[AWS 安全登入](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)資料*AWS 一般參考*。

# 如何在 Amazon SES 中傳送電子郵件
<a name="send-email-concepts-process"></a>

此主題說明當您使用 SES 傳送電子郵件時可能發生的情況，以及在送出電子郵件後會發生的不同結果。下方圖表是傳送程序的高階概觀：

![\[Email sending process with Amazon SES, showing potential bounces, complaints, and delivery outcomes.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/arch_overview-diagram.png)


****

1. 扮演電子郵件寄件者角色的客戶端應用程式對 SES 提出請求，以傳送電子郵件給一或多個收件人。

1. 如果請求有效，SES 將接受電子郵件。

1. SES 透過網際網路傳送訊息給收件人的接收者。一旦訊息傳送到 SES，通常會立即傳送，而第一次傳遞嘗試正常來說會在千分之一秒內發生。

1. 此時會發生幾種不同的可能性。例如：

   1. ISP 將成功傳遞訊息到收件人的收件匣。

   1. 收件人的電子郵件地址不存在，因此 ISP 將傳送退信通知給 SES。SES 接著會轉送此通知給寄件者。

   1. 收件人會收到訊息，但會認為訊息是垃圾郵件並對 ISP 提出投訴。已設定與 SES 的回饋迴圈之 ISP 會傳送投訴給 SES，然後轉寄投訴給寄件者。

下列章節將審閱寄件者傳送電子郵件請求給 SES 以及在 SES 傳送電子郵件訊息給收件人後可能發生的個別結果。

## 在寄件者傳送電子郵件請求給 SES 之後
<a name="send-email-concepts-process-after-request"></a>

當寄件者對 SES 發出請求來傳送電子郵件時，呼叫可能成功或失敗。以下章節說明在每個案例中會發生的情況。

### 成功的傳送請求
<a name="send-email-concepts-process-after-request-success"></a>

如果對 SES 的請求成功，SES 會傳回成功回應給寄件者。此訊息包含 *訊息 ID* (一個可唯一識別請求的字元字串)。您可以使用訊息 ID 來識別傳送的電子郵件，或追蹤傳送期間遇到的問題 (您必須[儲存自己的映射](faqs-enforcement.md#cm-feedback-loop-q8)，記錄識別符如何映射到 SES 接受電子郵件時傳遞回來給您的 SES 訊息 ID)。SES 接著會根據請求參數來組合電子郵件訊息、掃描訊息中的可疑內容以及病毒，然後使用簡易郵件傳輸協定 (SMTP) 透過網際網路傳送訊息。您的訊息通常會立即傳送；而第一次傳遞嘗試一般來說會在千分之一秒內發生。

**注意**  
若 SES 接受寄件者的請求並判斷訊息包含病毒，SES 便會停止處理訊息，且不會嘗試將它遞送到收件人的電子郵件伺服器。

### 傳送請求失敗
<a name="send-email-concepts-process-after-request-failure"></a>

如果寄件者對 SES 的電子郵件傳送請求失敗，SES 將以錯誤回應並刪除該封電子郵件。此請求的失敗有幾項原因。例如，請求的格式可能不正確或電子郵件地址可能尚未由寄件者驗證。

用於判斷請求是否失敗的方法將取決於您呼叫 SES 所用的方法。下列範例是錯誤與例外狀況傳回的範例：
+ 如果您是透過查詢 (HTTPS) API (`SendEmail` 或 `SendRawEmail`) 呼叫 SES，動作將傳回錯誤。如需詳細資訊，請參閱 [Amazon Simple Email Service API 參考資料](https://docs.aws.amazon.com/ses/latest/APIReference/)。
+ 如果您針對使用例外狀況的程式設計語言使用 AWS 開發套件，對 SES 的呼叫將會擲回 *MessageRejectedException*。(例外狀況的名稱可能根據開發套件有些許不同。)
+ 如果您使用 SMTP 界面，則寄件者會收到 SMTP 回應程式碼，但如何傳遞錯誤將取決於寄件者的用戶端。部分客戶端可能顯示錯誤碼；其他客戶端可能不會。

如需使用 SES 傳送電子郵件時可能發生的錯誤相關資訊，請參閱 [Amazon SES 電子郵件傳送錯誤](troubleshoot-error-messages.md)。

## Amazon SES 傳送電子郵件後
<a name="send-email-concepts-process-after-send"></a>

如果寄件者對 SES 的請求成功，那麼 SES 將傳送電子郵件，並會發生以下其中一個結果：
+ **成功遞送且收件人未拒絕電子郵件 - **ISP 接受該封電子郵件，且 ISP 將電子郵件遞送給收件人。下圖顯示成功交付狀況。  
![\[Email flow diagram showing sender, Amazon SES, receiver ISP, and recipient with successful delivery.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/successful-diagram.png)
+ **硬退信 - **電子郵件遭到 ISP 拒絕的原因為持續性狀況或者 SES 因為電子郵件地址不在 SES 禁止名單中而拒收該封電子郵件。若電子郵件地址最近造成任何 SES 客戶硬退信，電子郵件將被列於 SES 禁止名單中。因為收件人的地址無效而導致 ISP 產生的硬退信可能會發生。硬退信通知由 ISP 寄回至 SES，將透過電子郵件或 Amazon Simple Notification Service (Amazon SNS) 通知寄件者，方法取決於寄件者的設定。SES 會以相同方式通知寄件者關於禁止名單的退信。來自 ISP 的硬退信路徑顯示於下列圖表中。  
![\[Email flow diagram showing sender, Amazon SES, and receiver with arrows indicating message path.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/hard_bounce-diagram.png)
+ **軟退信 - **由於暫時性狀況，例如 ISP 過於繁忙而無法處理請求或者收件人的信箱已滿等問題，ISP 無法遞送電子郵件給收件人。若網域不存在，也可能發生軟退信。ISP 會將軟退信通知傳回 SES，或是在網域不存在的情況下，SES 會找不到該網域的電子郵件伺服器。無論何種狀況，SES 將在一段時間內持續重試電子郵件。如果 SES 在該段時間內仍無法遞送電子郵件，便會透過電子郵件或 Amazon SNS 傳送退信通知給您。如果 SES 可以在重試期間內將電子郵件傳送給收件人，表示交付成功。下圖顯示軟退信狀況。在這種情況下，SES 將重新嘗試傳送電子郵件，而 ISP 最終將能將郵件交付給收件人。  
![\[Email flow diagram showing sender, Amazon SES, receiver, and recipient with soft bounce scenario.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/soft_bounce-diagram.png)
+ **投訴 - **ISP 已接受電子郵件並已傳送給收件人，但收件人認為該電子郵件是垃圾郵件並在自己的電子郵件用戶端點選了按鈕，例如「標示為垃圾郵件」。若 SES 已設定與 ISP 的回饋迴圈，那麼投訴通知將會傳送給 SES，然後再轉寄投訴通知給寄件者。大部分 ISP 都不會提供提出投訴的收件人電子郵件，因此來自 SES 的投訴通知將提供寄件者一份可能曾提出投訴的收件人清單，此清單包根據原始訊息與向 SES 發出投訴的 ISP 之收件人而產生。投訴的路徑顯示於下方圖表中。  
![\[Diagram showing email flow from sender through Amazon SES, ISP, and recipient, with complaint feedback loop.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/complaint-diagram.png)
+ **自動回應 - **ISP 會接受電子郵件，再由 ISP 遞送給收件人。然後，ISP 將傳送自動回應給 SES，例如不在辦公室 (OOTO) 訊息。SES 會轉送此自動回應通知給寄件者。自動回應顯示於下列圖表中。  
![\[Diagram showing email flow from sender through Amazon SES, ISP, recipient, and auto-response back to sender.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/auto_response-diagram.png)

  請確定支援 SES 的程式不會重試傳送產生自動回應的訊息。
**提示**  
您可以使用 SES 信箱模擬器測試成功交付、退信、投訴，OOTO 等狀況，或者了解當地址被列於禁止名單上時會發生的情況。如需詳細資訊，請參閱[手動使用信箱模擬器](send-an-email-from-console.md#send-email-simulator)。

# Amazon SES 中的電子郵件格式
<a name="send-email-concepts-email-format"></a>

用戶端對 Amazon SES 發出請求時，Amazon SES 會建構符合網際網路訊息格式規格 ([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt)) 的電子郵件訊息。電子郵件包含*標頭*、*內文*及*信封*，如下所述。
+ **標題 - **包含路由指示與訊息相關資訊。範例為寄件者的地址，收件人的地址、主旨和日期。標題類似於郵寄信件上方的資訊，但是可以包含許多其他類型的資訊，例如訊息格式。
+ **內文 - **包含訊息本身的文字。
+ **信封 - **包含 SMTP 工作階段期間，電子郵件用戶端與電子郵件伺服器之間進行通訊的實際路由。此電子郵件信封資訊類似於郵寄信封上的資訊。電子郵件信封的路由資訊通常與電子郵件標題中的路由資訊是相同的，但並非絕對。例如，當您送密件副本 (BCC) 時，實際的收件人地址 (自信封衍生) 與顯示在收件人電子郵件客戶端的「收件人」地址 (自標題衍生) 不同。

以下為電子郵件的簡易範例。此標頭後接空白列，然後試電子郵件的內文。信封不會顯示，因為信封是用於在 SMTP 工作階段於客戶端與郵件伺服器之間通訊，而非做為電子郵件本身的一部分。

```
 1. Received: from abc.smtp-out.amazonses.com (123.45.67.89) by in.example.com (87.65.43.210); Fri, 17 Dec 2010 14:26:22
 2. From: "Andrew" <andrew@example.com>;
 3. To: "Bob" <bob@example.com>
 4. Date: Fri, 17 Dec 2010 14:26:21 -0800
 5. Subject: Hello
 6. Message-ID: <61967230-7A45-4A9D-BEC9-87CBCF2211C9@example.com>
 7. Accept-Language: en-US
 8. Content-Language: en-US
 9. Content-Type: text/plain; charset="us-ascii"
10. Content-Transfer-Encoding: quoted-printable
11. MIME-Version: 1.0
12. 
13. Hello, I hope you are having a good day.
14. 
15. -Andrew
```

以下章節說明電子郵件標題與內文，並指出您使用 Amazon SES 時需要提供的資訊。

## 電子郵件標題
<a name="send-email-concepts-email-format-header"></a>

每個電子郵件訊息有一個標題。每個一標題行都包含後面接著冒號、再接著欄位內文的標題。當您在電子郵件客戶端中讀取電子郵件時，電子郵件客戶端通常會顯示下列標題欄位的值：
+ **收件人 - **訊息收件人的電子郵件地址。
+ **副本 - **訊息副本收件人的電子郵件地址。
+ **寄件人 - **傳送電子郵件的地址。
+ **主旨 - **訊息主題摘要。
+ **日期 - **電子郵件傳送的時間和日期。

有許多其他標題欄位，提供路由資訊並說明訊息內容。電子郵件用戶端通常不會對使用者顯示這些欄位。如需 Amazon SES 接受的標題欄位完整清單，請參閱 [Amazon SES 標頭欄位](header-fields.md)。使用 Amazon SES 時，尤其需要了解「寄件人」、「回覆至」、和「傳回路徑」標題欄位之間的差別。如之前的說明，「寄件人」地址為訊息寄件者的電子郵件地址，而「回覆至」和「傳回路徑」則如下所述：
+ **回覆至 - **回覆電子郵件時將傳送的目標電子郵件地址。在預設情況下，回覆會傳送到原始寄件者的電子郵件地址。
+ **傳回路徑 - **訊息退信與投訴應傳送的目標電子郵件地址。「傳回路徑」有時稱為「信封來自」(envelope from)、「信封寄件者」(envelope sender) 或「寄件人」(MAIL FROM)。
**注意**  
使用 Amazon SES 時，建議您一律設定「傳回路徑」參數，才能得知退信狀況並在發生時採取修正動作。

若要將退回的訊息與其原本設定的收件人配對，您可以使用可變信封返回路徑 (VERP)。有了可變信封返回路徑 (VERP)，可為每個收件人設定不同的「傳回路徑」，若訊息被退回，您就能自動知道哪個收件人退回訊息，而不用開啟退信訊息並進行解析。

## 電子郵件內文
<a name="send-email-concepts-email-format-body"></a>

電子郵件內文包含訊息的文字。內文可使用下列格式傳送：
+ **HTML - **如果收件人的電子郵件客戶端可以解譯 HTML，內文可以包含格式化文字和超連結
+ **純文字 - **如果收件人的電子郵件客戶端以文字為基礎，內文不可包含任何無法列印的字元。
+ **同時使用 HTML 和純文字 - **當您使用兩種格式在單一訊息中傳送相同內容時，收件人的電子郵件客戶端將根據其功能來決定要顯示何種格式。

若您傳送電子郵件訊息給大量的收件人，那麼同時使用 HTML 和文字傳送是可以理解的。部分收件人會有支援 HTML 的電子郵件客戶端，他們可以按一下內嵌的超連結訊息。使用以文字為基礎的電子郵件用戶端收件人將需要您加入 URL，讓他們可以複製並使用 Web 瀏覽器開啟。

## 您需要提供給 Amazon SES 的電子郵件資訊
<a name="send-email-concepts-email-required-information"></a>

透過 Amazon SES 傳送電子郵件時，您需要提供的資訊取決於您呼叫 Amazon SES 的方式。您可以提供最少量的資訊，並讓 Amazon SES 處理所有格式。或者，如果您想要執行更進階的操作，例如傳送附件，您可以自行提供原始訊息。以下各節會說明您在使用 Amazon SES API、Amazon SES SMTP 界面或 Amazon SES 主控台傳送電子郵件時需要提供的資訊。

### Amazon SES API
<a name="send-email-concepts-email-required-information-api"></a>

如果您直接呼叫 Amazon SES API，您呼叫的是 `SendEmail` 或 `SendRawEmail` API。您需要提供的資訊量將取決於您的呼叫何種 API。
+ `SendEmail API` 需要您提供來源地址、目的地地址、訊息主旨和訊息內文。您可以選擇提供「回覆至」地址。當您呼叫此 API 時，Amazon SES 將自動組合一封格式正確的分段多用途網際網路郵件延伸 (MIME) 電子郵件訊息，由電子郵件用戶端軟體針對顯示進行最佳化。如需詳細資訊，請參閱「[使用 Amazon SES API 傳送格式化電子郵件](send-email-formatted.md)」。
+ `SendRawEmail` API 可提供透過指定標頭、MIME 部分和內容類型格式化及傳送您自己電子郵件原始碼訊息的彈性。`SendRawEmail` 通常是由進階使用者使用。您需要提供訊息內文以及網際網路訊息格式規格 ([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt)) 中指定為必要的所有標頭欄位。如需詳細資訊，請參閱[使用 Amazon SES API v2 傳送原始電子郵件](send-email-raw.md)。

如果您使用 AWS SDK 呼叫 Amazon SES API，您可以將上述資訊提供給對應的函數 （例如，適用於 Java `SendRawEmail`的 `SendEmail`和 )。

如需使用 Amazon SES API 傳送電子郵件的詳細資訊，請參閱 [使用 Amazon SES API 來傳送電子郵件](send-email-api.md)。

### Amazon SES SMTP 界面
<a name="send-email-concepts-email-required-information-smtp"></a>

當您透過 SMTP 界面存取 Amazon SES 時，您的 SMTP 用戶端應用程式會組合訊息，因此您需要提供的資訊取決於您所使用的應用程式。客戶端與伺服器間的 SMTP 交換至少將需要來源地址、目的地地址以及訊息中繼資料等資訊。

如需使用 Amazon SES SMTP 界面傳送電子郵件的詳細資訊，請參閱 [使用 Amazon SES SMTP 界面來傳送電子郵件](send-email-smtp.md)。

### Amazon SES 主控台
<a name="send-email-concepts-email-required-information-console"></a>

當您使用 Amazon SES 主控台傳送電子郵件時，您需要提供的資訊量將取決於您選擇傳送的是格式化或原始電子郵件。
+ 若要傳送格式化電子郵件，您需要提供來源地址、目的地地址、訊息主旨和訊息內文。Amazon SES 將自動組合一封格式正確的分段 MIME 電子郵件訊息，由電子郵件用戶端軟體針對顯示進行最佳化。您也可以指定「回覆到」和「傳回路徑」欄位。
+ 若要傳送原始電子郵件，您需要提供來源地址、目標地址和訊息內容，其中必須包含訊息內文與網際網路訊息格式規格 ([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt)) 中指定為必要的所有標頭欄位。

# 了解 Amazon SES 中的電子郵件可交付性
<a name="send-email-concepts-deliverability"></a>

您希望收件人能夠讀取您的電子郵件並認為內容是有價值的，而非將電子郵件標記為垃圾郵件。換言之，您想要最大限度提升電子郵件的*遞送度* - 電子郵件送達收件人信箱的比例。此主題將檢視使用 Amazon SES 時應該熟悉的電子郵件遞送度的概念。

若要讓電子郵件可交付性最大化，需了解電子郵件傳遞問題、積極採取步驟來避免問題、隨時掌握您傳送的電子郵件狀態、然後改善您的電子郵件傳送程式。若需要，更要進一步提升成功送達的可能性。以下章節將檢視這些步驟背後的概念，並了解 Amazon SES 如何在這些程序中如何為您帶來幫助。

![\[Circular diagram showing four steps to improve email delivery: understand issues, be proactive, stay informed, and improve program.\]](http://docs.aws.amazon.com/zh_tw/ses/latest/dg/images/deliverability_concepts-diagram.png)


## 了解電子郵件交付問題
<a name="send-email-concepts-deliverability-understanding"></a>

在大多數情況下，您的訊息傳將成功傳送給預期收到這封電子郵件的收件人。不過，在某些情況下，傳遞可能會失敗，或者收件人可能不想要收到您傳送的郵件。退信、投訴與禁止名單都與這些交付問題相關，也將在接下來的章節中說明。

### Bounce
<a name="send-email-concepts-deliverability-bounce"></a>

如果您的收件人的接收者 (例如電子郵件供應商) 無法交付您的訊息給收件人，接收者會把訊息退回 Amazon SES。然後　Amazon SES 會透過電子郵件或 Amazon Simple Notification Service (Amazon SNS) 來通知您有退回的電子郵件，方式將取決於您的系統設定。如需詳細資訊，請參閱[設定 Amazon SES 的事件通知](monitor-sending-activity-using-notifications.md)。

退信分為*硬退信*和*軟退信*，如下所示：
+ **硬退信 - **持久性電子郵件交付失敗。例如信箱不存在。Amazon SES 不會重試硬退信，除非有 DNS 查詢失敗的例外情況。我們強烈建議您不要重複嘗試傳遞到發生硬退信的電子郵件地址。
+ **軟退信 - **暫時性電子郵件交付失敗。例如信箱已滿、有太多連線 (也稱為*調節*) 或連線逾時。Amazon SES 會重試軟退信多次。如果電子郵件仍無法送達，Amazon SES 便會停止重試。

Amazon SES 將通知您不會再重試的硬退信與軟退信。但是，只有硬退信會計入您使用 Amazon SES 主控台或 `GetSendStatistics` API 擷取的退信率及退信指標。

退信可能是*同步*或*非同步*。同步退信會在寄件者與接收者的電子郵件伺服器進行積極通訊時發生。非同步退信發生的情況是因為接收者一開始先接受電子郵件訊息供交付，但後來卻無法交付收件人所致。

### 投訴
<a name="send-email-concepts-deliverability-complaint"></a>

大多數的電子郵件用戶端程式提供標示為「標記為垃圾郵件」或類似的按鈕，此功能會將郵件移到垃圾郵件資料夾並轉寄給電子郵件提供者。此外，大多數電子郵件提供者會提供濫用回報地址 (例如，abuse@example.net)，讓使用者可以轉發不想收到的電子郵件訊息至此地址，並要求電子郵件提供者採取行動來防止這類郵件。在這兩種情況下，收件人便是在提出投訴。如果電子郵件供應商判斷您是濫發垃圾郵件者，而 Amazon SES 向電子郵件供應商設定了回饋迴圈，則電子郵件供應商會將投訴傳回 Amazon SES。Amazon SES 收到這類投訴後，會根據您設定系統的方式，使用電子郵件或 Amazon SNS 通知將投訴轉送給您。如需詳細資訊，請參閱[設定 Amazon SES 的事件通知](monitor-sending-activity-using-notifications.md)。我們建議您不要重複嘗試傳遞到提出投訴的電子郵件地址。

### 全域禁止名單
<a name="send-email-concepts-deliverability-suppression-list"></a>

Amazon SES *全域禁止名單*是由 SES 擁有和管理，以保護 SES 共用 IP 集區中地址的評價，其中包含最近造成任何 SES 客戶硬退信的收件人電子郵件地址。如果您嘗試透過 SES 傳送電子郵件給禁止名單上的地址，針對 SES 的呼叫雖然會成功，但是 SES 會將電子郵件視為硬退信而不會嘗試傳送。正如任何硬退信，禁止名單的退信將會計入您的傳送份額與退信率中。電子郵件地址可能被列於禁止名單中高達 14 天。如果您確定要傳送的電子郵件地址有效，您可以複寫全域禁止名單，方法是確保該地址未列在您的帳戶層級禁止名單中，而 SES 仍會嘗試傳遞，但是如果退信，則此退信將影響您自己的評價；如果不使用自己的帳戶層級禁止列表，他們就無法傳送到該電子郵件地址，也因此不會有其他人取得退信。若要進一步瞭解帳戶層級禁止清單，請參閱 [使用 Amazon SES 帳戶層次禁止名單](sending-email-suppression-list.md)。

## 主動性
<a name="send-email-concepts-deliverability-be-proactive"></a>

在網際網路上的電子郵件最大的問題是未經要求的大量電子郵件 (垃圾郵件)。電子郵件供應商會採取廣泛措施來防止客戶收到垃圾郵件。Amazon SES 也會採取步驟來降低電子郵件供應商將您的電子郵件視為垃圾郵件的可能性。Amazon SES 採用驗證、身分驗證、傳送配額和內容篩選功能。Amazon SES 同時也維護受電子郵件供應商信任的評價，並要求您傳送高品質電子郵件。Amazon SES 會自動為您執行部分作業 (例如內容篩選)；在其他情況下，它會提供工具 (像是身分驗證)，或引導您正確使用 (傳送配額)。以下章節提供各個概念的詳細資訊。

### 驗證
<a name="send-email-concepts-deliverability-verification"></a>

很抱歉，垃圾郵件寄件者可能會假冒電子郵件標題並冒充來源電子郵件地址，讓信件看起來像是從另一個來源寄出。為了保持電子郵件供應商和 Amazon SES 之間的信任關係，Amazon SES 必須確保寄件者確實與宣稱的身分相符。因此，將要求您驗證所有您自 Amazon SES 傳送電子郵件的電子郵件地址，以保護您的傳送身分。您可以使用 Amazon SES 主控台或使用 Amazon SES API 來驗證電子郵件地址。您也可以驗證整個網域。如需更多詳細資訊，請參閱 [建立電子郵件地址身分](creating-identities.md#verify-email-addresses-procedure) 和 [建立網域身分](creating-identities.md#verify-domain-procedure)。

若您的帳戶仍在 Amazon SES 沙盒中，除了由 Amazon SES 信箱模擬器提供的電子郵件地址外，您仍需要驗證所有收件人的電子郵件地址。如需有關離開沙盒的更多資訊，請參閱 [請求生產存取權 （移出 Amazon SES 沙盒）](request-production-access.md)。如需信箱模擬器的詳細資訊，請參閱 [手動使用信箱模擬器](send-an-email-from-console.md#send-email-simulator)。

### 身分驗證
<a name="send-email-concepts-deliverability-authentication"></a>

*身分驗證*是您可以向電子郵件提供者表明身分的另一種方式。當您驗證電子郵件時，便提供證據證明您是帳戶的所有人，而您的電子郵件在傳輸中未遭到修改。在某些情況下，電子郵件供應商將拒絕轉發未經身分驗證的電子郵件。Amazon SES 支援兩種身分驗證方法：寄件者政策架構 (SPF) 和網域金鑰識別郵件 (DKIM)。如需詳細資訊，請參閱[在 Amazon SES 中設定身分](configure-identities.md)。

### 傳送份額
<a name="send-email-concepts-deliverability-sending-quotas"></a>

如果電子郵件提供者偵測到您的傳送數量或速率突然發生預期外的遽增時，電子郵件提供者可能會懷疑您是垃圾郵件寄件者並封鎖您的電子郵件。因此，每個 Amazon SES 帳戶都會有一組傳送配額。這些配額會限制可在 24 小時期間內傳送的電子郵件數量，以及每秒可傳送的數量。這些傳送配額可協助保護您與電子郵件提供者之間的互信。

在大多數情況下，如果您是全新的使用者，Amazon SES 可讓您每天傳送少量的電子郵件。如果您傳送的是電子郵件提供者可接受的郵件，我們會自動提高此配額。您的傳送配額在一段時間後會穩定提升，如此便能以更快的速率傳送更大量的電子郵件。您也可以建立 [SES 傳送限制提高案例](https://aws.amazon.com/ses/extendedaccessrequest/)以要求增加額外的配額。

如需傳送配額的與提高配額的相關資訊，請參閱[管理您的 Amazon SES 傳送限制](manage-sending-quotas.md)。

### 內容過濾
<a name="send-email-concepts-deliverability-content-filtering"></a>

許多電子郵件提供者使用內容過濾來判斷傳入的電子郵件是否為垃圾郵件。內容篩選條件會尋找可疑的內容，若電子郵件符合垃圾郵件描述，便會封鎖該電子郵件。Amazon SES 也使用內容篩選條件。當您的應用程式傳送請求至 Amazon SES 時，Amazon SES 會代您組合電子郵件訊息，然後掃描郵件標題和內文，判斷它們是否包含電子郵件供應商可能將其視為垃圾郵件的內容。若您的訊息對 Amazon SES 使用的內容篩選條件來說像是垃圾郵件，將會對您使用 Amazon SES 的評價造成負面影響。

Amazon SES 也會針對所有訊息掃描病毒。若訊息包含病毒，Amazon SES 便不會嘗試將訊息遞送到收件人的電子郵件伺服器。

### 信譽
<a name="send-email-concepts-deliverability-reputation"></a>

針對電子郵件傳送作業，*評價* (判定 IP 地址、電子郵件地址或傳送網域並非垃圾郵件的信心度指標) 非常重要。Amazon SES 對電子郵件供應商維持著高度正面評價，讓電子郵件供應商可將您的電子郵件遞送到收件人信箱。同樣地，您需要維持使用 Amazon SES 的受信賴評價。傳送高品質的內容來建立使用 Amazon SES 的評價。當您傳送高品質的內容時，您的評價將隨時間變得更受信任，而 Amazon SES 會提高您的傳送配額。退信和投訴過多可能會對您的評價造成負面影響，並可能導致 Amazon SES 降低您帳戶的傳送配額或終止您的 Amazon SES 帳戶。

其中一種協助維持您的評價的方法，是使用信箱模擬器來測試您的系統，而非傳送到您自行建立的電子郵件地址。傳送到信箱模擬器的電子郵件不會計入您的退信與投訴指標。如需信箱模擬器的詳細資訊，請參閱 [手動使用信箱模擬器](send-an-email-from-console.md#send-email-simulator)。

### 高品質電子郵件
<a name="send-email-concepts-deliverability-high-quality-email"></a>

高品質電子郵件代表收件人認為電子郵件內容有價值且想要收到。價值對不同的收件人來說意味著不同的東西，而且可以是優惠訊息、訂單確認、收據、電子報的形式寄送。最後，您的遞送度將完全仰賴您傳送的電子郵件品質，因為電子郵件供應商會封鎖他們認為品質低落的電子郵件。

## 掌握狀態
<a name="send-email-concepts-deliverability-stay-informed"></a>

無論您的遞送是否失敗、收件人是否對您的電子郵件提出投訴，或者 Amazon SES 是否成功將電子郵件遞送到收件人的電子郵件伺服器，Amazon SES 都會提供通知及讓您輕鬆監控使用狀況統計資料，協助您追蹤問題。

### 通知
<a name="send-email-concepts-deliverability-feedback-notifications"></a>

當電子郵件退信時，電子郵件供應商會通知 Amazon SES，而 Amazon SES 會通知您。Amazon SES 將通知您，告知 Amazon SES 不會再重試的硬退信與軟退信。許多電子郵件供應商也會轉送投訴，而 Amazon SES 會對主要電子郵件供應商設定投訴回饋迴圈，因此您不需要設定。Amazon SES 會以兩種方式通知您退信、投訴與成功交付：您可以設定帳戶來透過 Amazon SNS 接收通知，或者可透過電子郵件來接收通知 (僅限退信與投訴)。如需詳細資訊，請參閱「[設定 Amazon SES 的事件通知](monitor-sending-activity-using-notifications.md)」。

### 用量統計資料
<a name="send-email-concepts-deliverability-usage-statistics"></a>

Amazon SES 提供使用狀況統計資料，讓您可以檢視失敗的遞送，以判斷並解決根本原因。您可以使用 Amazon SES 主控台或呼叫 Amazon SES API 來檢視您的使用狀況統計資料。您可以檢視交付、退信、投訴和因病毒感染而遭拒絕的電子郵件數量，您也可以檢視傳送限制以確認您尚未超過配額。

## 改善您的電子郵件傳送程式
<a name="send-email-concepts-deliverability-improve"></a>

如果您收到大量的退信與投訴，代表您需要重新評估電子郵件傳送策略。請記住，過度退信、投訴和嘗試傳送低品質電子郵件會構成濫用，並使您 AWS 帳戶 面臨終止的風險。最後，您需要確保您使用 Amazon SES 傳送高品質電子郵件，並只傳送電子郵件給希望收到這些電子郵件的收件人。

## 至少傳遞一次
<a name="send-email-concepts-at-least-once-delivery"></a>

Amazon SES 會在多個伺服器上存放訊息的副本，以供備援使用並提供高可用性。偶爾在接收或刪除訊息時，存放訊息副本的其中一個伺服器可能會無法使用。

若發生此種情況，則該訊息位於無法使用的伺服器上的副本並未刪除，而當您接收訊息時可能會再次收到該則訊息副本。請將您的應用程式設為等冪 (若相同訊息處理一次以上應不會有不良影響)。

# 使用 Amazon SES 傳送電子郵件的最佳實務
<a name="best-practices"></a>

管理您與客戶間電子郵件通訊的方法稱為您的*電子郵件計畫*。有幾個因素可能會導致您的電子郵件計畫成功或失敗，這些因素一開始可能令人感到混淆或難以理解。但是，了解電子郵件傳遞的方法並遵循幾項最佳實務，便能提升電子郵件成功送達客戶收件匣的機率。

**Topics**
+ [電子郵件計畫成功指標](success-metrics.md)
+ [維持正面寄件者評價](tips-and-best-practices.md)

# 電子郵件計畫成功指標
<a name="success-metrics"></a>

有幾個指標可協助衡量電子郵件程式是否成功。

**Topics**
+ [退信](#metrics-bounce-rate)
+ [投訴](#metrics-complaints)
+ [訊息品質](#metrics-quality)

## 退信
<a name="metrics-bounce-rate"></a>

當電子郵件無法遞送給指定收件人時，便會發生*退信*。退信有兩種類型：*硬退信*和*軟退信*。硬退信可能會在電子郵件因持久性的問題而無法遞送時發生，例如電子郵件地址不存在。軟退信則會在暫時性的問題阻擋電子郵件遞送時發生。軟退信也可能在收件人收件匣已滿，或者接收伺服器暫時無法使用時發生。Amazon SES 處理軟退信的方法，是將嘗試在一段時間後重新遞送遭退信的電子郵件。

監控電子郵件程式中的硬退信數量，以及從您的收件人清單中移除硬退信電子郵件地址都非常重要。當電子郵件接收工具偵測到高硬退信率時，他們將假設您不了解自己的收件人。因此，高硬退信率可能對您的電子郵件訊息可交付性造成負面影響。

以下準則可協助您避免退信並改善您的寄件者評價：
+ 試著讓您的硬退信率低於 5%。電子郵件計畫中的硬退信數量越少，ISP 將越有可能將您的訊息視為具正當性且有價值的內容。此比率應被視為合理且可達成的目標，但是並非所有 ISP 皆通用的規則。
+ 千萬不可租用或購買電子郵件清單。這些清單可能包含大量的無效地址，且可能因此導致您的硬退信率大幅增加。此外，這些清單可能包含垃圾郵件陷阱 - 專門用於抓捕不正當寄件者的電子郵件地址。如果您的訊息落入垃圾郵件陷阱中，便可能對您的交付率與寄件者評價造成無法修復的傷害。
+ 讓清單內容保持為最新狀態。如果您已有長時間未寄出電子郵件給收件人，可嘗試透過其他方法來驗證您的客戶狀態 (例如網站登入活動或購買歷史記錄)。
+ 如果您沒有可驗證客戶狀態的方法，請考慮傳送一封 *win-back* (找回客戶) 電子郵件。典型的 win-back 電子郵件會提到您已有段時間未與客戶聯絡，並鼓勵客戶確認是否仍想收到您的電子郵件。傳送 win-back 電子郵件之後，自清單中清除所有未回應的收件人。

當您收到退信時，適當的回應非常重要。您可以參考下列規則：
+ 如果電子郵件地址硬退信，便立即從清單中移除該地址。不要嘗試重新傳送訊息到發生硬退信的地址。重複的硬退信將增加，最終便會對您在收件人 ISP 中的評價造成傷害。
+ 確認您用來接收退信通知的地址能接收電子郵件。如需設定退信和投訴通知的詳細資訊，請參閱「[設定 Amazon SES 的事件通知](monitor-sending-activity-using-notifications.md)」。
+ 如果您的傳入電子郵件來自於 ISP，而非透過您自有的內部伺服器，湧入的退信通知可能送入您的垃圾郵件資料夾或完全遭到刪除。理想情況下，您不應該使用託管的電子郵件地址來接收退信。但是，若您必須使用，請時常檢查垃圾郵件且不要將退信訊息標記為垃圾郵件。在 Amazon SES 中，您可以指定傳送退信通知的目標地址。
+ 退信通常會提供拒絕傳遞的信箱地址。不過，如果您需要更多精細資料來將收件人地址對應到特定的電子郵件行銷活動，請將可回溯追蹤至內部追蹤系統的 X - 標題值加入郵件中。如需詳細資訊，請參閱「[Amazon SES 標頭欄位](header-fields.md)」。

## 投訴
<a name="metrics-complaints"></a>

當電子郵件收件人在基於 Web 的電子郵件客戶端中點選「標記為垃圾郵件」(或相同功能) 按鈕時，就會發生抱怨。如果您累積大量此類的抱怨，ISP 便假設您傳送的是垃圾郵件。這將對您的可交付性和寄件者評價造成負面影響。部分但並非所有 ISP 會在收到投訴回報時通知您；稱之為*回饋迴圈*。Amazon SES 會自動轉送來自 ISP 的投訴，為您提供回饋迴圈。

以下準則可協助您避免抱怨和並改善寄件者評價：
+ 試著讓您的抱怨率低於 0.1%。電子郵件計畫中的抱怨數量越少，ISP 將越有可能將您的訊息視為具正當性且有價值的內容。此比率應被視為合理且可達成的目標，但是並非所有 ISP 皆通用的規則。
+ 如果客戶提出與行銷電子郵件相關的抱怨，應立即停止傳送行銷電子郵件給該客戶。但是，如果您的電子郵件計畫也包含其他類型的電子郵件 (如通知或交易電子郵件)，也許可繼續傳送那些類型的訊息給提出抱怨的收件人。
+ 與硬退信相同，如果您的郵寄清單已有一段時間未用於傳送電子郵件，請確認您的收件人了解為什麼他們會收到您的訊息。我們建議您傳送歡迎訊息，提醒他們您的身分並說明與他們聯絡的目的。

當您收到抱怨時，適當的回應非常重要。您可以參考下列規則：
+ 確認您用來接收抱怨通知的地址能接收電子郵件。如需設定退信和投訴通知的詳細資訊，請參閱「[設定 Amazon SES 的事件通知](monitor-sending-activity-using-notifications.md)」。
+ 請確定您的抱怨通知未遭 ISP 或郵件系統標記為垃圾郵件。
+ 抱怨通知通常包含電子郵件內文；這與退信通知不同，因為退信通知通常只會包含電子郵件標頭。但是，在抱怨通知中，通常會移除發出抱怨的當事人電子郵件地址。使用自訂 X-header 或內嵌於電子郵件內文中的特殊識別符，來找出發出抱怨的電子郵件地址。此技術可讓您更輕鬆地識別抱怨的地址，讓您可以從收件人清單中移除他們。

## 訊息品質
<a name="metrics-quality"></a>

電子郵件接收工具使用*內容篩選條件*來偵測您的訊息中的特定屬性，由此判定您的訊息是否具正當性。這些內容篩選條件將自動檢閱您的訊息內容，以從中辨認出不想要的訊息或惡意訊息的常見特徵。在訊息傳出前，Amazon SES 會使用內容篩選技術來協助偵測並封鎖包含惡意軟體的訊息。

如果電子郵件接收工具的內容篩選條件判斷您的訊息包含垃圾郵件或惡意電子郵件特性，您的訊息將非常有可能被標記並自收件人信箱中轉移。

設計您的電子郵件時請謹記下列要點：
+ 現代的內容篩選條件非常智慧，會持續調整和變更。他們不會倚賴預先定義的規則集。第三方服務 (例如 [ReturnPath](https://returnpath.com/) 或 [Litmus](https://litmus.com/)) 可協助識別您電子郵件中可能觸發內容篩選條件的內容。
+ 若您的電子郵件包含連結，請將這些連結的 URL 與DNS 黑名單 (DNSBL) 相互對照，例如 [URIBL.com](http://uribl.com/) 和 [SURBL.org](http://www.surbl.org/) 提供的黑名單。
+ 避免使用縮址連結。惡意寄件者可能會使用縮址連結來隱藏連結的實際目標。當 ISP 注意到縮址服務被用於惡意用途時，可能會拒絕存取那些服務，即使是聲譽良好的服務也無法豁免。若您的電子郵件包含連結到被列入拒絕名單的縮址服務網址，將不會送達客戶的收件匣中，且您的電子郵件行銷活動會受到負面影響。
+ 請測試電子郵件中的每個連結，以確認連結導向的是正確的頁面。
+ 請確定您的網站包含隱私權政策與使用條款文件，且這些文件皆為最新版。最佳實務是在每封您傳送的電子郵件連結到這些文件。提供這些文件的連結表示您對客戶沒有隱瞞之意，可協助建立信賴關係。
+ 如果您計劃傳送高頻率內容 (例如「每日優惠」訊息)，請確保在每次部署時您的電子郵件內容皆不同。當您傳送高頻率訊息時，必須確保這些訊息的及時性與相關性，而非只是重複且惱人的內容。

# 維持正面寄件者評價
<a name="tips-and-best-practices"></a>

在 Amazon SES 中，寄件者評價是指電子郵件寄件者對電子郵件提供者和垃圾郵件篩選條件的可信度和可信度。這是衡量您的電子郵件被視為合法並成功交付給收件人收件匣的可能性的指標。

以下各節介紹了您必須注意的核心電子郵件傳送主體，以確保您的電子郵件通訊可到達您預期的受眾，同時保持良好的寄件者評價。

## 網域和「寄件人」地址考量
<a name="domain-and-from-address-considerations"></a>
+ 謹慎考慮用於傳送電子郵件的地址。「寄件人」地址是收件人將看到的第一個資訊片段，因此這個第一印象將持續產生影響。此外，一些 ISP 會依據「寄件人」地址來判斷您的評價。
+ 您可以考慮使用適用於不同通訊類型的子網路。例如，假設您從網域 *example.com* 中傳送電子郵件，而您計劃傳送行銷和交易兩種訊息。與其自 *example.com* 傳送所有訊息，不如使用如 *marketing.example.com* 子網域來傳送行銷訊息、再從 *orders.example.com* 子網域中傳送交易訊息。獨特的子網域將建立自己的評價。使用子網域可降低對評價造成傷害的風險，例如，您的行銷通訊內容落入垃圾郵件陷阱或者觸發內容篩選條件等情況。
+ 如果您計劃傳送大量訊息，不要使用以 ISP 為基礎的地址傳送這些訊息，例如 *sender@hotmail.com*。如果 ISP 發現有大量訊息自 *sender@hotmail.com* 傳入，該電子郵件採取的處理方式就會與使用您所有的外寄電子郵件傳送網域所傳送的電子郵件不同。
+ 與您的網域註冊機構合作，以確保您的網域 WHOIS 資訊是準確的。維持誠實且最新的 WHOIS 記錄，表示您重視資訊透明度，並允許使用者快速判斷您的網域是否具真實性。
+ 避免使用 *no-reply* 地址，例如將 *no-reply@example.com* 做為您的 "From" 或 "Reply-to" 地址。使用 *no-reply@* 電子郵件地址，會讓收件人明顯感受到您刻意不提供與您聯絡的方式，而且您也對他們的意見不感興趣。

## 身分驗證
<a name="authentication-considerations"></a>
+ 使用 [SPF](send-email-authentication-spf.md) 和 SenderID 對您的網域進行身分驗證。這些驗證方法可向電子郵件收件人確認，您傳送的每封電子郵件皆確實自其聲稱使用的網域寄出。
+ 使用 [DKIM](send-email-authentication-dkim.md) 簽署您的對外電子郵件。此步驟可向收件人確認，內容在寄件者與接收者間的傳輸過程中未遭到變更。
+ 您可以傳送電子郵件給您所擁有且以 ISP 為基礎的電子郵件地址來測試 SPF 和 DKIM 的驗證設定，例如個人的 Gmail 或 Hotmail 帳戶，然後檢視訊息標題。可從標題看出您對於驗證與簽署訊息的嘗試是否正確。

## 建置並維護您的清單
<a name="building-and-maintaining-lists"></a>
+ 採取雙重選擇使用策略。當使用者註冊接收您的電子郵件時，將傳送內含確認連結的訊息給使用者，且在他們點選該連結來確認地址前不會開始傳送電子郵件訊息給這些使用者。雙重選擇使用策略可協助降低因輸入錯誤而導致的硬退信數量。
+ 當使用基於 Web 的表單來收集電子郵件地址時，請在送出表單時針對這些地址執行最基礎的驗證。例如，確認您收集的地址格式正確 (也就是格式為 *recipient@example.com*)，且他們皆指向具備有效 MX 記錄的網域。
+ 允許在不檢查便將使用者定義的輸入交付到 Amazon SES 時，須特別注意。論壇註冊和表單提交有其特殊的風險，因為內容完全由使用者產生，而垃圾郵件發信者可使用自己的內容來填寫表單。您有責任確認自己傳送的電子郵件皆為高品質的內容。
+ 以標準別名 (例如 *postmaster@*、*abuse@* 或 *noc@*) 刻意註冊您電子郵件的情況非常少見。請確認您傳送訊息的對象是真人且他們確實想要收到您的訊息。此規則對於標準別名來說更為重要，因為標準別名皆為電子郵件監視程式習慣性預留的名稱。這些別名可能以破壞性的形式被惡意加入您的清單中來傷害您的評價。

## 合規
<a name="compliance-considerations"></a>
+ 請注意您傳送電子郵件對象收件人所在國家及區域的電子郵件行銷和反垃圾郵件法律及法規。您有責任確保您傳送的電子郵件符合這些法律。本指南並未涵蓋這些法律，因此研究他們對您來說相當重要。如需法律清單，請參閱 Wikipedia 上的 [Email Spam Legislation by Country](https://en.wikipedia.org/wiki/Email_spam_legislation_by_country)。
+ 請一律諮詢律師以取得法律建議。

# 搭配 SDK 使用 Amazon SES AWS
<a name="sdk-general-information-section"></a>

AWS 軟體開發套件 (SDKs) 適用於許多熱門的程式設計語言。每個 SDK 都提供 API、程式碼範例和說明文件，讓開發人員能夠更輕鬆地以偏好的語言建置應用程式。


| SDK 文件 | 代碼範例 | 
| --- | --- | 
| [適用於 C\$1\$1 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-cpp) | [適用於 C\$1\$1 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) | 
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI 程式碼範例](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) | 
| [適用於 Go 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-go) | [適用於 Go 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) | 
| [適用於 Java 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-java) | [適用於 Java 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) | 
| [適用於 JavaScript 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-javascript) | [適用於 JavaScript 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) | 
| [適用於 Kotlin 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-kotlin) | [適用於 Kotlin 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) | 
| [適用於 .NET 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-net) | [適用於 .NET 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) | 
| [適用於 PHP 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-php) | [適用於 PHP 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) | 
| [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell) | [AWS Tools for PowerShell 程式碼範例](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) | 
| [適用於 Python (Boto3) 的 AWS SDK](https://docs.aws.amazon.com/pythonsdk) | [適用於 Python (Boto3) 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) | 
| [適用於 Ruby 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-ruby) | [適用於 Ruby 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) | 
| [適用於 Rust 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-rust) | [適用於 Rust 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) | 
| [適用於 SAP ABAP 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-sapabap) | [適用於 SAP ABAP 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) | 
| [適用於 Swift 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-swift) | [適用於 Swift 的 AWS SDK 程式碼範例](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) | 

如需 Amazon SES 的特定範例，請參閱 [使用 AWS SDKs 的 Amazon SES 程式碼範例](service_code_examples.md)。

**可用性範例**  
找不到所需的內容嗎？ 請使用本頁面底部的**提供意見回饋**連結申請程式碼範例。