Аккаунт Amazon WorkMail не может получить электронную почту

Ранее я настроил организацию AWS WorkMail и адрес электронной почты, и я использую свой собственный домен, размещенный по маршруту 53. Это успешно работает.

Однако теперь я создал второй адрес рабочей почты, я не могу получать на него электронную почту (хотя я могу отправлять электронную почту с него). Я получаю следующее сообщение об ошибке:

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 и что этот домен выбран для адреса электронной почты. Тем не менее, это не решило проблему.

Источник

6 ответов

Лучше поздно (2019!), Чем никогда.

Мне пришлось установить записи MX и CNAME вручную в консоли Route 53 Hosted Zones.

Итак, сначала: убедитесь, что у вас есть наборы записей для получения почты, настроенные в Route 53! Вы можете проверить это, выполнив следующие действия:

  1. В Консоли AWS WorkMail перейдите в домен
  2. Предполагая, что ваш домен используется по умолчанию, нажмите на него
  3. На экране " Статус проверки домена" убедитесь, что записи в разделе " Настройка почты" (обязательные) проверены, что означает, что они установлены на маршруте 53 (для меня я пропустил записи MX и CNAME). Если они отсутствуют или что-то еще, кроме проверенного, то это проблема, которую вам нужно исправить в Route 53.
  4. Если записи отсутствуют в наших записях Route 53 / Hosted Zones, добавьте их вручную
  5. Теперь вы сможете получать почту в Amazon WorkMail.

Работал на меня.

Источник

Несколько лет назад, но вот что я сделал, чтобы решить:

1. Убедитесь, что домен по умолчанию тот, который вы хотите

Рабочая почта> Домены> Выберите домен> Нажмите Set as Default

2. Убедитесь, что у пользователя есть домен, назначенный его почтовому ящику.

  1. Пользователи> Нажмите на пользователя> Нажмите Edit
  2. в Email address убедитесь, что в раскрывающемся списке доменов указано правильное поле

Это должно быть все. Если у вас все еще есть проблемы, то это могут быть записи MX, все еще распространяющиеся. Подождите несколько часов и попробуйте снова

Источник

Хорошо, у меня была такая же проблема. В моем случае это произошло потому, что я настраивал новый домен для получения электронной почты через Amazon SES. Я не понимал, что Amazon SES используется для обработки Amazon Workmail.

Итак, я здесь, слепо прорабатываю документацию, настраивая новый набор правил приема SES и делая его активным. Все отлично работает!

Через некоторое время я понимаю, что ни одна из моих учетных записей Amazon Workmail не работает! Я отправляю себе электронное письмо с адреса Gmail, и оно возвращается с

550 5.1.1 Requested action not taken: mailbox unavailable

Примерно через 10 минут безумной паники я понимаю, что способ восстановления - это отключить новый набор правил, который я только что создал для SES, и включить набор правил INBOUND_MAIL, который содержит все правила, управляющие Amazon Workmail.

Затем я добавляю свое новое правило в конце этого правила набора и теперь у меня есть как Amazon SES и Amazon Workmail работать одновременно.

Так что мой сценарий отличается от OP. Однако я подозреваю, что, учитывая идентичное сообщение об ошибке, произошли изменения Amazon SES, о которых OP либо не знает, либо не считает актуальными.

Источник

В моем конкретном случае я забыл, что у меня был настроен AWS Simple Email Service (SES) с активными правилами, указывающими на Lambda. Эти правила не различали адреса электронной почты получателя, поэтому они перехватывали все электронные письма, идущие в домен WorkMail, и фильтровали их, отбрасывая и предотвращая доставку.

Я вошел и отключил наборы правил в консоли SES, и в настоящее время я работаю над тем, чтобы сделать правила более конкретными, чтобы адресовать только целевые электронные письма, идущие в один конкретный домен, а не куда-либо.

Чтобы убедиться, что это не ваш случай:

  • Перейдите к SES в веб-консоли Amazon Web Services.
  • На левой панели перейдите в "Наборы правил" в разделе "Получение электронной почты".
  • Щелкните "Просмотр активного набора правил".
  • Вам будет представлен набор правил. Здесь вы должны увидеть набор правил, причем ваше правило WorkMail предположительно находится внизу списка.
  • Чтобы убедиться, что правила SES не препятствуют получению вашей почты, отключите любые другие правила, кроме правила WorkMail.
  • Отправьте электронное письмо на свою учетную запись WorkMail и убедитесь, что она работает.

Это был ответ для меня, но это потому, что я забыл, что сделал это.

Как упоминалось выше, лучшим решением, чем просто отключение правил, является указание критериев фильтрации для каждого правила, чтобы гарантировать, что оно применяется только там, где оно допустимо.

Источник

Я проголосовал за ответ @AQuirky, но вот что я нашел.

Ранее я настроил правило для своего домена, но не для той же учетной записи электронной почты, чтобы получать электронную почту в SES. Я отправлял их на S3, где они хранятся в формате, похожем на RFC822. План состоял в том, чтобы разбить их и добавить в папку «Входящие» imap с помощью клиентского сценария imap на Perl или Python, чтобы сэкономить 4 доллара.

Workmail может хорошо справляться с обновлением Route53, хотя я боролся с адресами «awsapps», пока не изменил значение по умолчанию.

По-видимому, оно не исправило SES автоматически, и я сдул правило, думая, что это проблема.

Мне пришлось создать новое правило и выбрать «Интеграция с Workmail». Он сказал мне, что это не должно было быть необходимо, но да, это было.

Источник

После проверки всех шагов из текущих ответов здесь, вам нужно подождать, пока запись DNS MX не будет правильно распространена.

Например, вы можете перейти на https://www.whatsmydns.net/, ввести свой домен и выбрать MX запись.

Затем убедитесь, что входящие SMTP-записи указывают на AWS.

В противном случае, чтобы найти нужные записи MX, проверьте по адресу: Регионы и конечные точки AWS.

В общем, перейдите в зону размещения вашего домена на маршруте 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 не существует почтовый ящик с лямбда

Источник
Другие вопросы по тегам