本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon Connect 电子邮件的工作原理
Amazon Connect 电子邮件提供许多内置功能，让您能轻松对客户服务电子邮件进行优先级排序、分配和自动化解决，从而提高客户满意度和座席的工作效率。您可以接收和回复客户发送到您配置的电子邮件地址的电子邮件，也可以通过调用 StartEmailContact API，接收和回复使用您的网站或移动应用程序上的 web 表单提交的电子邮件。
Amazon Connect 电子邮件与 Amazon Simple Email Service（SES）集成，可收发电子邮件，监控标记为垃圾邮件或包含病毒的内容、送达成功率和发件人信誉结果。
本主题阐述 Amazon Connect 电子邮件与 Amazon SES 如何协同工作来提供无缝的客户体验。
接收电子邮件
Amazon Connect 可以通过三种主要方式接收电子邮件：
-
方法 1：通过 Amazon Connect 中定义的电子邮件地址（例如 support@
customer-domain.com），该地址要么使用来自 Amazon SES 的经过验证的电子邮件域，例如您的 Amazon Connect 实例自带的电子邮件域（例如 @instance-alias.email.connect.aws），要么使用您拥有或由您公司提供的经过验证的自定义域（例如 @customer-domain.com）。有关引入自定义电子邮件域的详细信息，请参阅为您的实例启用电子邮件中的步骤 3：使用您自己的自定义电子邮件域。 -
方法 2：通过在您的电子邮件服务器上使用路由规则（例如 Microsoft 365 Connectors
、Google Workspace Mail Routes ），通过一个已引入 Amazon SES 的已验证的电子邮件域（例如 @ customer-domain.com），将入站电子邮件发送到 Amazon SES 的 SMTP 端点之一。 -
方法 3：使用您网站或移动应用程序中的 Web 表单，通过调用 StartEmailContact API，来发起电子邮件联系。这会启动入站电子邮件联系，类似于客户向您的电子邮件地址发送电子邮件。
以下示意图展示了对上述提到的每一种方法使用 StartEmailContact API，Amazon Connect 如何接收从您的客户处发送的电子邮件。
要集成方法 1 或 2，您需要先在 Amazon SES 上一个验证电子邮件域，然后才能在 Amazon Connect 中使用该电子邮件域。有关说明，请参阅与您的 DNS 提供商一起验证 DKIM 域身份。
要集成方法 3，您需要使用 StartEmailContact API。这是入站电子邮件联系的所有集成方法的主要 API。它的功能与 StartTaskContact 类似。它需要您执行以下步骤之一：
-
在入站电子邮件联系的“收件人”或“抄送”属性中，至少包含一个来自 Amazon Connect 实例的电子邮件地址。
- 或者 -
-
从您的 Amazon Connect 实例定义一个入站流以路由所创建的入站电子邮件联系。
如果两者都定义了，则默认行为是优先采用来自您的 Amazon Connect 实例的入站流处理所创建的入站电子邮件联系。如果“收件人”或“抄送”电子邮件地址属性中包含来自您的 Amazon Connect 实例的多个电子邮件地址，将在您的 Amazon Connect 实例中创建多个入站电子邮件联系。
电子邮件消息如何变成电子邮件联系
对于 Amazon Connect 中的普通电子邮件接收，包括基于 web 表单的电子邮件，StartEmailContact API 在请求对象上暴露了基本的电子邮件字段。此对象用于填充电子邮件信息并在 Amazon Connect 中发起电子邮件联系。包括以下字段：
-
“发件人”电子邮件地址
-
“收件人”电子邮件地址
-
“抄送”电子邮件地址
-
主题
-
纯文本或 HTML 消息正文
-
附件
有关如何将电子邮件联系信息填充到电子邮件联系中的更多信息，请参阅“Amazon Connect 电子邮件联系数据模型”。
当 StartEmailContact API 完成请求参数验证并确保至少一个“收件人”或“抄送”电子邮件地址有效且存在于 Amazon Connect 实例中时，会发生以下情况：
-
生成一个联系 ID 并作为 API 响应正文的一部分返回。
-
触发异步工作流来执行额外的电子邮件消息处理。
-
流启动。这是与在 Amazon Connect 实例中找到的电子邮件地址关联的流。
作为此过程的一部分，您需要为 Amazon Connect 实例设置电子邮件消息和附件存储。
-
电子邮件消息和附件都在您自己的 Amazon SES S3 存储桶中被存储和访问。
-
其余的电子邮件联系属性（例如“收件人”、“抄送”、“主题”和其他属性）则存储在电子邮件联系中；请参阅 Amazon Connect 联系记录的数据模型。
下图展示电子邮件消息先从客户流向 Amazon SES，然后流向 Amazon Connect。它展示了电子邮件消息内容被存储在您的 S3 存储桶中，然后再从该存储桶中获取数据显示给座席。
每个电子邮件消息就是一个唯一的电子邮件联系
Amazon Connect 电子邮件与语音、聊天和任务不同。
-
每个电子邮件消息，无论是入站 Amazon Connect 还是从中出站，都是其自己的唯一电子邮件联系。
-
每个电子邮件联系都包含特定于该电子邮件消息的详细信息，例如“发件人”地址、“收件人”地址、“抄送”地址、主题、relatedContactId、电子邮件正文和附件存储位置的链接，以及与个人电子邮件联系相关的其他详细信息。
但是，与 Amazon Connect 中的其他渠道一样，电子邮件联系也有类似的发起方法，例如 INBOUND、OUTBOUND、TRANSFER、API、QUEUE_TRANSFER 和 END/DISCONNECT。它也有类似的状态，例如 CREATED、QUEUED、CONNECTING、CONNECTED、MISSED、TRANSFERRED、ERROR、ENDED/DISCONNECTED、REJECTED。
有关如何将电子邮件联系信息填充到电子邮件联系中的更多信息，请参阅 Amazon Connect 联系记录的数据模型。
电子邮件线程
电子邮件线程功能可确保与同一个客户咨询相关的出站电子邮件和入站回复按照时间顺序整齐地彼此关联在一起。
为了维持整个电子邮件对话，Amazon Connect 使用电子邮件联系上的几个字段 [例如 relatedContactId 和一个遵循常规电子邮件客户端标准（RFC 5256）的电子邮件标头列表] 将电子邮件联系链接在一起。
大多数电子邮件客户端（例如 Gmail、Apple Mail 和 Outlook）都支持电子邮件线程。但是，请记住，也有一些电子邮件客户端不支持它。
当客户回复线程中的最新一封电子邮件消息时，线程会遵循一个直接的模式，如下图所示。
当客户回复电子邮件线程中一个较早的消息时，会形成一个电子邮件线程树，电子邮件线程模式看起来像下图中的示例这样：
在这两种情况下，Amazon Connect 都会为每一个与同一线程相关的电子邮件消息保存一份记录。每个电子邮件消息都可以被它之后的电子邮件访问。
发送电子邮件
所有来自 Amazon Connect 的电子邮件消息都是从 Amazon SES 直接发送给您的客户。无论您使用的是 Amazon Connect 实例自带的电子邮件域（例如 @instance-alias.email.connect.aws），还是经过验证的自定义域（例如 @customer.com），都通过验证域身份来授权 Amazon SES 直接向您的客户发送电子邮件。
下图显示 StartOutboundEmailContact API 向 Amazon SES 发送电子邮件，Amazon SES 将其发送给您的客户。
StartOutboundEmailContact API 是适用于出站电子邮件联系（包括座席回复的联系和座席发起的联系）的所有集成方法的主要 API，
-
它的功能与 StartEmailContact API 类似，但由于是出站操作，所以方向刚好相反。
-
它要求在“收件人”或“抄送”电子邮件地址属性中至少有一个电子邮件地址，并且需要一个出站提示流来处理出站联系。
