Почему Exchange Online отклонил письмо с кодом 5.7.1

Код 550 5.7.1 в Exchange Online сообщает о постоянном отказе по правилу безопасности или доступа, но сам не называет причину. Я разбираю полный NDR, маршрут письма и результаты SPF, DKIM и DMARC: начинаю с симптома, а не с догадки, что виновата DNS-зона.

Что означает 550 5.7.1 в Exchange Online

Код 550 5.7.1 в отчёте о недоставке NDR означает, что сообщение отклонено по правилу безопасности или доступа. Это не диагноз «сломался SPF». Microsoft перечисляет разные причины: у отправителя может не быть права писать конкретному адресату или группе, промежуточный почтовый сервер может не разрешать пересылку, а письмо может идти не на тот сервер. Аутентификация домена тоже имеет значение, но цифры сами по себе не подтверждают ни одну из этих версий. В NDR важны текст ответа удалённого сервера, этап обработки и адрес назначения. Общая надпись вроде Access denied не заменяет эти подробности. (Искать тут неисправный сервер — самый дорогой способ не прочитать NDR.)

Начните с полного, исходного отчёта, а не с пересказа «письмо не дошло». Сохраните enhanced status code целиком, ответ удалённого сервера, время отправки, отправителя и получателя; если есть идентификатор сообщения, он поможет найти запись в трассировке. Проверьте, возник отказ внутри вашей организации или после передачи письма внешнему серверу. Один и тот же код может требовать разных действий: права на группу меняет её владелец, запись SPF исправляет администратор домена, а неверный маршрут разбирают вместе с теми, кто управляет почтовым потоком. Я не обещаю вылечить это одной правкой DNS: сначала нужен ответ на вопрос, кто именно отказал и на каком основании. Если почтовая система требует отдельного аудита, мы начинаем с настройки корпоративной почты и данных NDR, а не с универсального рецепта.

Ещё одна важная граница: если 5.7.1 вернул сервер получателя, причину чаще выясняет администратор получателя; если сообщение отклонил собственный Exchange Online до передачи наружу, начинать нужно с администрирования своей организации. Полный NDR помогает определить эту границу по имени ответившего сервера и строке с диагностикой. Если вам переслали только короткую пользовательскую выдержку, попросите исходный отчёт как вложение: в нём могут сохраниться технические сведения, которых нет в скриншоте. Затем приложите к запросу время, адреса и идентификатор сообщения. Так обе стороны смогут обсуждать одну попытку доставки, а не спорить о пересказах. Никакой универсальный проверяющий сайт не покажет внутреннее правило чужого тенанта.

С чего начать разбор NDR

Для наглядности возьму условную студию «Берест-Логистик» из исходного примера. У нас нет журналов, реального NDR или DNS-зоны этой студии, поэтому утверждать, что её письма отклонялись из-за старого IP или выключенной подписи, нельзя. Ниже — учебный сценарий диагностики, а не отчёт о клиенте. Допустим, сотрудник отправил письмо на внешний адрес, а Exchange Online вернул 550 5.7.1. Сначала я выясняю масштаб: проблема только с одним адресом, со всеми адресами одного домена или с любыми внешними получателями? Затем уточняю направление потока: исходящее письмо из Microsoft 365, входящее сообщение в вашу организацию или пересылка через промежуточный шлюз. Это простое разделение отсекает массу случайных изменений, которые иначе начинают вносить в DNS наугад.

Если отказ касается только одного получателя или одной группы, проверяйте разрешения адресата, ограничения группы и правила потока у получателя. В такой ситуации замена SPF отправителя может вообще ничего не изменить. Если не доходят письма ко всему внешнему домену, сопоставьте несколько NDR: совпадает ли удалённый сервер, одинаков ли текст отказа, есть ли в сообщениях общий домен-отправитель или один путь маршрутизации. Если отклонения появляются у разных адресатов, смотрите собственный журнал отправки, результат трассировки и заголовки успешно доставленного тестового письма. При наличии конкретного признака блокировки или жалоб на репутацию отдельно проверьте почтовые чёрные списки, но не считайте любой 5.7.1 доказательством попадания в список. Короткая таблица причин в NDR полезнее длинного списка «попробуйте включить всё».

Результат такого разбора фиксируйте по сторонам. Отправитель передаёт NDR и запись трассировки со временем и идентификатором; получатель ищет тот же запрос у себя и проверяет правило, группу или состояние ящика. Если удалённая система сообщает о проблеме маршрута, сравнивают домен адресата, MX-направление и фактический сервер, который принял соединение. Если письмо шло через шлюз, его владелец проверяет собственный журнал и настройки пересылки. Эта переписка нужна не для перекладывания ответственности, а чтобы локализовать точку отказа: каждая сторона видит только свою часть потока. В условном примере студии это и есть проверяемый результат работы — не выдуманная история о починке, а понятное заключение, на каком участке надо менять настройку.

• Один адрес — проверить права и состояние получателя.
• Один домен — сравнить NDR и удалённый сервер.
• Все внешние адреса — проверить трассировку, маршрут и аутентификацию.
• Пересылка — проверить промежуточный сервер и заголовки.

SPF: одна запись и реальные отправители

SPF публикует в DNS список источников, которым разрешено отправлять письма от имени домена в SMTP-идентичности отправителя. Для одного имени домена должна быть одна SPF-запись в TXT, начинающаяся с v=spf1. Если завести две независимые записи, получающая система не складывает их в общий список: проверка SPF возвращает PermError. Это ошибка публикации политики, но она не означает автоматически, что Exchange Online обязан выдать именно 550 5.7.1. Microsoft рассматривает такой результат как отдельную неисправность аутентификации; итоговая доставка всё равно зависит от содержимого NDR и правил принимающей стороны. Нужный способ добавить новый сервис — внести его механизм в существующую запись после проверки того, что он действительно отправляет почту от вашего домена.

Не разрешайте в SPF источники «на всякий случай». Составьте перечень систем, которые реально отправляют почту с вашим доменом в видимом поле From или SMTP MAIL FROM: корпоративная почта, сайт, CRM и сервис рассылки — если они действительно отправляют. Проверяйте фактический исходящий адрес сервера по заголовкам Authentication-Results и журналу отправки, а не по догадке. Microsoft указывает ещё одну частую ошибку: SPF возвращает PermError, если проверка требует больше 10 DNS-поисков или опубликовано несколько SPF-записей. Механизмы, которые обращаются к DNS, в том числе include, a и mx, расходуют этот лимит; вложенные include тоже имеют значение. Поэтому длинное «разрешить всё, что когда-либо подключали» не становится надёжнее от количества строк. Если SPF проходит, а DMARC всё равно не проходит, проверьте совпадение домена MAIL FROM с доменом в From: одного SPF pass для этого недостаточно. (Зона DNS не обязана угадывать, какой источник вы имели в виду.)

У SPF есть граница, из-за которой его часто читают неправильно: он проверяет SMTP-идентичность, прежде всего MAIL FROM, а не просто видимое человеку поле From. Поэтому факт «отправитель написан верно» ещё ничего не говорит о результате SPF. При пересылке письмо может выйти с IP пересылающего сервера, которого нет в SPF исходного домена; Microsoft прямо считает такой SPF fail ожидаемым для обычной пересылки. В этом случае нельзя механически дописывать IP чужого пересылающего сервера в собственную зону. Проверьте DKIM и выравнивание DMARC, а при поддерживаемой конфигурации — механизм сохранения результатов аутентификации при пересылке. Сначала отделите исходную отправку от пересланной: это два разных сетевых пути с разными отправляющими IP и часто разными результатами проверки.

• Оставьте одну SPF-запись на имя домена.
• Добавьте только действующие источники отправки.
• Проверьте результат SPF и лимит DNS-поисков.

DKIM и DMARC: подпись должна совпадать с доменом

DKIM добавляет к исходящему письму криптографическую подпись, а принимающий сервер сверяет её с открытым ключом из DNS. Microsoft 365 использует для пользовательского домена CNAME-записи DKIM-селекторов: значения нужно взять в Defender или Exchange Online PowerShell, опубликовать у DNS-провайдера и после проверки включить подпись. Не нужно сочинять ключи вручную или искать универсальную кнопку для всех версий интерфейса. У каждого пользовательского домена своя конфигурация. В заголовке Authentication-Results, добавленном доверенной принимающей системой, ищите результат dkim=pass, dkim=fail или dkim=none; последний обычно означает, что подписи нет либо сообщение не было подписано. Если запись селектора отсутствует или указывает не туда, подпись не подтвердится. Отсутствие DKIM само по себе ещё не объясняет код 5.7.1: оно становится критичным, когда политика получателя требует аутентификацию или когда без него не проходит DMARC.

DMARC публикует владелец домена отправителя, а не получатель. Проверка связывает домен из видимого заголовка From с результатом SPF или DKIM: достаточно, чтобы прошла одна из двух проверок и её домен был выровнен с From. Если обе проверки не выровнены или не прошли, DMARC может завершиться неудачей. Политика p=none просит получателя не применять специальное DMARC-действие, p=quarantine просит поместить письмо в карантин, а p=reject — отклонить; фактическое решение о конкретном письме остаётся за принимающей системой и её локальными правилами. Поэтому p=none не означает «всё доставится», а p=reject не следует включать вслепую. Сначала соберите отчёты, найдите все легитимные источники, наладьте выравнивание SPF или DKIM и только затем ужесточайте свою политику. Подробный разбор пригодится в статье о том, почему DKIM не подписывает письма.

Если в DMARC-записи настроен адрес для агрегированных отчётов, используйте их как инвентаризацию источников: отчёты помогают заметить легитимную CRM или сайт, о которых забыли при настройке домена, и случайную отправку от неизвестного источника. Сверяйте отчёты с собственным списком сервисов, а не принимайте каждую строку за инцидент: агрегированные данные описывают проверки принимающих систем и могут требовать пояснений. До p=quarantine или p=reject убедитесь, что у каждого законного источника проходит хотя бы SPF или DKIM с выравниванием. Менять политику стоит небольшими контролируемыми шагами и после повторной проверки отчётов. У DMARC есть задача защиты домена от подделки; это отдельная настройка, она не является универсальным переключателем для исправления любого NDR 5.7.1.

• Опубликуйте CNAME-селекторы из панели Microsoft.
• Проверьте подпись DKIM в заголовке письма.
• Сверьте домены SPF или DKIM с полем From.
• Меняйте политику DMARC после анализа отчётов.

Порядок проверки и безопасная правка DNS

Я свожу диагностику к последовательности, которую можно повторить. Сначала сохраняю исходный NDR и выписываю удалённый сервер, полный ответ, время и затронутые адреса. Затем проверяю трассировку исходящего сообщения в Exchange Online, если отправка шла через Microsoft 365, и сравниваю её с ответом удалённой стороны. Успешное тестовое письмо помогает увидеть заголовок Authentication-Results: в нём ищут spf=, dkim= и dmarc= вместе с доменами, которые система проверяла. Далее сверяю DNS с тем, что заявлено в админ-панели: для примера тестовой зоны можно выполнить dig TXT example.com +short и dig TXT _dmarc.example.com +short; DKIM-проверку делайте по точным CNAME-именам и целевым значениям, которые выдал Microsoft для вашего домена. example.com здесь только пример, его нельзя заменить реальным доменом, не проверив сначала собственную схему отправки.

После изменения записи проверьте её у DNS-провайдера и через несколько независимых резолверов; кеши могут хранить прежний ответ до истечения TTL, поэтому обещать фиксированные «15 минут» или «сутки» нельзя. После обновления DNS отправьте тестовое письмо сначала на собственный контролируемый адрес, затем попросите адресата подтвердить результат, если проблема была у него. Изменяйте один фактор за раз и фиксируйте результат: иначе успешная доставка не покажет, какая именно правка помогла, а новый отказ будет трудно воспроизвести. Если блокировка возникает только у одной организации, передайте её администратору полный NDR и время отправки, чтобы он проверил разрешения и локальные правила. Если отправка не проходит к нескольким независимым доменам, проверьте все реальные источники и выравнивание. Для смежной диагностики пригодится материал о SPF, DKIM и DMARC при проблемах с доставкой. Не переводите p=reject или не добавляйте широкое разрешение IP как «проверку»: так вы меняете защиту домена, не выяснив причину.

Перед правкой сохраните текущие значения TXT и CNAME и проверьте, у кого обслуживается авторитетная DNS-зона: изменения в панели одного регистратора бесполезны, если домен фактически делегирован на другие серверы имён. Уточните имя записи, тип и целевое значение у своего почтового провайдера; у DKIM это особенно важно, потому что селектор должен указывать именно на опубликованное Microsoft значение. После сохранения сначала запросите запись у DNS-провайдера, затем проверьте ответ через публичный резолвер и только после этого отправляйте тест. Если результат не изменился, вернитесь к NDR и сравните сервер и диагностическую строку с предыдущей попыткой. Не добавляйте сразу новый SPF include, меняйте DMARC и переключайте DKIM в одном пакете: без промежуточной проверки вы не узнаете, какая настройка была неверной.

Для повторного теста оставьте прежними отправителя, адрес получателя и маршрут, но отправьте короткое нейтральное письмо без вложения. Оно не заменяет проверку исходного сообщения, зато помогает понять, срабатывает ли правило на сам канал отправки или только на конкретное письмо. Сравните результаты с исходной попыткой: одинаков ли отвечающий сервер, изменились ли SPF, DKIM или DMARC в заголовке Authentication-Results доверенной принимающей системы, повторяется ли тот же текст отказа. Если тест проходит, не закрывайте заявку автоматически: возможна зависимость от получателя, содержимого или правила для конкретного сообщения. Если тест не проходит тем же образом, у вас появляется повторяемый сценарий для трассировки и запроса администратору второй стороны. Это короткий эксперимент с одним изменением за раз, а не доказательство, что причина уже найдена.

Частые вопросы