Amazon WorkMail 账户无法接收电子邮件

Question

我之前设置了一个 AWS WorkMail 组织和电子邮件地址，并且我正在使用托管在 Route 53 的自定义域。这已经成功。

但是现在我创建了第二个 WorkMail 地址，我无法接收到它的电子邮件（尽管我可以从它发送电子邮件）。我收到以下错误消息：

The response from the remote server was:
550 5.1.1 Requested action not taken: mailbox unavailable

Final-Recipient: rfc822; email@my-domain.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; inbound-smtp.us-east-1.amazonaws.com. ([my-ip], the
server for the domain [my-domain.com].)
Diagnostic-Code: smtp; 550 5.1.1 Requested action not taken: mailbox 
unavailable
Last-Attempt-Date: Wed, 13 Dec 2017 09:07:52 -0800 (PST)

谁能提供建议，说明为什么第二封电子邮件会出现问题，而第一封电子邮件却没有？

编辑： 根据 kiwicple 的建议，我已确保自定义域为 Set as Default，并且为电子邮件地址选择了此域。但是，这并没有解决问题。

Answer 1

晚了几年，但这是我要解决的问题：

1。确保默认域是您想要的域

工作邮件 > 域 > 选择域 > 点击Set as Default

2。确保用户已将域分配给他们的邮箱

1. 用户>点击用户>点击Edit
2. 在 Email address 字段中确保域下拉列表中的字段正确

应该就是这样。如果您仍然遇到问题，则可能是 MX 记录仍在传播。等待几个小时再试一次

Answer 2

迟到（2019 年！）总比没有好。

我必须在 Route 53 Hosted Zones 控制台中手动设置 MX 和 CNAME 记录。

所以首先：确保您在 Route 53 中设置了接收邮件的记录集！您可以通过执行以下操作来检查：

1. 在 WorkMail AWS 控制台中，转到 域
2. 假设您的域是默认域，请单击它
3. 在 域验证状态 屏幕中，确保 Mail Setup (Required) 下的记录已验证，这意味着它们设置在Route 53（对我来说，我错过了 MX 和 CNAME 记录）。如果它们丢失或除了 已验证 之外的其他内容，那么这是您需要在 Route 53 中解决的问题。
4. 如果记录不在我们的Route 53 / Hosted Zones记录中，请手动添加
5. 您现在应该可以在 Amazon WorkMail 中接收邮件了。

为我工作。

Answer 3

好的，我遇到了同样的问题。就我而言，这是因为我正在设置一个新域以通过 Amazon SES 接收电子邮件。我没有意识到 Amazon SES 用于处理 Amazon Workmail。

所以我在这里，盲目地通过文档设置新的 SES 接收规则集并使其处于活动状态。一切都很好！

不久之后，我意识到我的所有 Amazon Workmail 帐户都无法正常工作！我从 gmail 地址给自己发了一封电子邮件，但它被退回了

550 5.1.1 Requested action not taken: mailbox unavailable

在大约 10 分钟的疯狂恐慌之后，我意识到恢复的方法是禁用我刚刚为 SES 创建的新规则集，并启用包含管理 Amazon Workmail 的所有规则的 INBOUND_MAIL 规则集。

然后我在此规则集的末尾添加我的新规则，现在我有 Amazon SES 和 Amazon Workmail同时工作。

所以我的场景与 OP 的不同。但是，鉴于相同的错误消息，我怀疑存在 OP 不知道或认为不相关的 Amazon SES 更改。

Answer 4

在此处验证当前答案的所有步骤后，您需要等待 DNS MX 记录正确传播。

例如，您可以转到whatsmydns.net，输入您的域并选择MX 记录。

然后确保入站 SMTP 记录指向 AWS。

---

否则，要查找正确的 MX 记录，请查看：AWS Regions and Endpoints。

所以基本上，在 Route 53 中转到您域的 Hosted zone，您应该有如下 MX 记录：

10 inbound-smtp.us-east-1.amazonaws.com 
20 inbound-smtp.eu-west-1.amazonaws.com 
30 inbound-smtp.us-west-2.amazonaws.com 

另见：AWS SES handle doesn't exist mailbox with Lambda

Answer 5

在我的特殊情况下，我忘记了我已经设置了 AWS 简单电子邮件服务 (SES)，其中包含指向 Lambda 的活动规则。这些规则不会根据目标电子邮件地址进行区分，因此它们会捕获 所有 发往 WorkMail 域的电子邮件并过滤它们，将它们丢弃并阻止传递。

我进入并禁用了 SES 控制台中的规则集，我目前正在努力使规则更加具体，只针对发往一个特定域而不是任何地方的电子邮件。

为了确保您不是这种情况：

• 在 Amazon Web Services Web 控制台中转到 SES。
• 在左侧窗格中，转到“电子邮件接收”部分下的“规则集”。
• 点击“查看活动规则集”。
• 您将看到一组规则。您应该在此处看到一组规则，您的 WorkMail 规则大概位于列表底部。
• 为确保 SES 规则不会阻止您的邮件被接收，请禁用除 WorkMail 规则之外的任何其他规则。
• 向您的 WorkMail 帐户发送一封电子邮件并验证它是否正常工作。

这是给我的答案，但这是因为我尴尬地忘记了我做过这个。

如上所述，比仅仅禁用规则更好的解决方案是确保在每个规则上指定过滤条件，以确保它仅适用于有效的地方。

Answer 6

我赞成@AQuirky 的回答，但这是我发现的。

我之前为我的域设置了规则，但不是同一个电子邮件帐户在 SES 中接收电子邮件。我将它们发送到 S3，它们以 RFC822 格式存储在那里。计划是将它们批量处理，然后使用 perl 或 Python imap 客户端脚本将它们添加到 imap 收件箱，以节省 4 美元。

Workmail 可以很好地更新 Route53，尽管在我更改默认值之前，我一直在努力使用“awsapps”地址。

它似乎没有自动为我修复 SES，我打破了规则，认为这是一个问题。

我必须创建一个新规则，然后选择“与 Workmail 集成”。它确实告诉我这不应该是必要的，但确实如此。