2

我之前设置了一个 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)

任何人都可以提供建议，说明为什么第二封电子邮件会出现问题，而不是第一封电子邮件？

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

4

6 回答 6

5

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

1.确保默认域是你想要的

工作邮件 > 域 > 选择域 > 单击Set as Default 在此处输入图像描述

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

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

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

于 2017-12-30T04:57:43.507 回答
4

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

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

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

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

为我工作。

于 2019-02-23T10:56:27.013 回答
2

好的，我遇到了同样的问题。就我而言，这是因为我正在设置一个新域以通过 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 更改。

于 2020-08-12T01:25:52.627 回答
1

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

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

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

否则，要查找正确的 MX 记录，请查看：AWS 区域和终端节点。

因此，基本上，转到Route 53中您域的托管区域，您应该拥有如下 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 句柄不存在 Lambda 邮箱

于 2019-04-09T22:19:08.653 回答
1

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

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

为确保您不是这种情况：

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

这就是我的答案，但这是因为我尴尬地忘记了我已经这样做了。

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

于 2020-07-20T20:46:39.977 回答
0

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

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

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

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

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

于 2021-12-11T00:23:03.213 回答