Пересылаемые или ретрансляционные сообщения электронной почты из Microsoft 365 отклоняются с ошибкой 5.7.367

Сводка

При пересылке или передаче сообщений электронной почты через Exchange Online вы получаете отчет о недоставке (NDR), в котором упоминается код ошибки "5.7.367" и "Удаленный сервер вернул: не разрешено передавать". Эта проблема чаще возникает в потоках почты, которые включают шлюзы не от Microsoft.

Симптомы

При автоматической пересылке или ретрансляции сообщений электронной почты через Microsoft 365 возникают периодические сбои. При пересылке сообщения электронной почты вы получите NDR, включающее сообщение об ошибке, похожее на следующее сообщение:

550 5.7.367 Удаленный сервер вернул: ретрансляция не разрешена -> 554 5.7.1 Ретрансляция запрещена

Кроме того, вы испытываете следующие симптомы:

  • Шлюз, отличный от Майкрософт (например, Proofpoint или Barracuda), отклоняет пересылаемые или ретрансляционные сообщения электронной почты.

  • Трассировка сообщения содержит следующие сведения:

    • 550 5.7.367 Удаленный сервер вернул: не разрешено для передачи

    • Значение OutboundIpPoolName свойства — RegularRelayOutboundPool для неудачных сообщений.

  • В журналах шлюзов, не являющихся продуктами Майкрософт, отображаются сообщения об ошибке "ретрансляция отклонена".

  • Результат проверки подлинности платформы политики отправителя (SPF) — это fail или softfail когда сообщение входит в среду Microsoft 365. Результат других методов проверки подлинности, таких как DomainKeys Identified Mail (DKIM) и аутентификация на основе домена, отчётность и соответствие (DMARC), является pass или fail в зависимости от отправителя.

Пример 1— SPF Softfail, No DKIM

Authentication-Results: spf=softfail (IP-адрес отправителя — <IP-адрес>)

smtp.mailfrom=contoso.com; dkim=none (сообщение не подписано)

header.d=none; dmarc=fail action=none header.from=contoso.com;

Пример 2. SPF Softfail, сбой DKIM

Authentication-Results: spf=softfail (IP-адрес отправителя — <IP-адрес>)

smtp.mailfrom=proseware.com ; dkim=fail (хэш тела не проверен)

header.d=proseware.com ; dmarc=fail action=none header.from=proseware.com;

Причина

Когда Microsoft 365 пересылает или передает сообщение от имени внешнего отправителя, Exchange Online должен решить, какой пул исходящей доставки следует использовать.

Чтобы предотвратить злоупотребление, например спуфинга, фишинга и других атак электронной почты, Microsoft 365 может использовать определенную стратегию. Он может пересылать или ретранслировать сообщения, используя IP-адрес из пула ретрансляторов, вместо IP-адреса из стандартного диапазона исходящих IP-адресов. Exchange Online, скорее всего, отправляет сообщение из пула ретрансляторов при сбое проверки подлинности электронной почты во время ввода сообщения в среду Microsoft 365.

Замечание

Пул ретрансляторов не публикуется, поскольку он часто меняется. Кроме того, это не часть опубликованной записи SPF для Microsoft 365. Пул ретранслятора не входит в диапазоны исходящих IP-адресов Microsoft 365.

Адресаты не считают Microsoft 365 отправителем электронных писем, отправляемых из пересылочного пула. Подчиненные почтовые шлюзы часто блокируют или ограничивают эти сообщения. Это поведение приводит к ошибкам, запрещенным ретранслятором.

Требования аутентификации, чтобы избежать пула ретрансляции

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

  • Отправитель исходящего сообщения находится в принятом домене клиента.

  • SPF успешно проходит, когда сообщение электронной почты попадает в среду Microsoft 365.

  • DKIM на домене отправителя успешно проверяется при поступлении сообщения в Microsoft 365.

Если ни одно из этих условий не выполнено, сообщение может быть перенаправлено через пул ретранслятора.

Резолюция

Убедитесь, что проверка подлинности отправителя проходит

При маршрутизации входящего сообщения электронной почты через шлюз, не являющийся решением Microsoft, например Proofpoint или Barracuda, состояние SPF завершается ошибкой или нефатальной ошибкой до достижения Microsoft 365. Это условие возникает, так как Exchange Online оценивает SPF с помощью IP-адреса шлюза вместо исходного IP-адреса отправителя.

Если запись MX для домена указывает на службу, отличной от Майкрософт или локальный почтовый сервер, используйте расширенную фильтрацию для соединителей. Расширенная фильтрация гарантирует правильность проверки SPF для входящей почты и позволяет избежать отправки сообщений электронной почты через пул ретранслятора.

Используйте принятые домены, если это возможно

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

Избегайте нескольких переходов и автоперенаправления, если это возможно

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

Отказ от ответственности за информацию третьих лиц

Продукты сторонних производителей, о которых говорится в этой статье, изготовлены компаниями, независимыми от Microsoft. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, о надежности или производительности этих продуктов.