Как я ищу причину недоставки корпоративной почты

Если письмо отправлено, но не видно адресату, сначала выясните, принял ли его следующий SMTP-сервер, затем прочитайте Authentication-Results и сверьте SPF, DKIM и DMARC. Я показываю порядок проверки: от журналов и DNS до безопасного включения DMARC-политики. Ни одна из этих записей не гарантирует попадание во «Входящие».

SMTP-принятие не равно доставке во «Входящие»

Короткий ответ: если письмо не видно адресату, сначала установите, где оборвалась цепочка. Ваш сервер мог не отправить сообщение, следующий SMTP-узел мог принять его на обработку, а конечный почтовый сервис — положить в спам или отклонить. Это разные события и разные журналы. В проектах по корпоративной почте я начинаю с ответа сервера и очереди отправителя, а уже потом разбираю SPF, DKIM и DMARC. Запись «отправлено» в одном месте не показывает папку, куда сообщение попало у адресата.

Ищите не общий статус, а конкретный след сообщения: время отправки, адрес получателя, ответ следующего узла, повторные попытки и уведомление о недоставке. Если внешний сервер принял письмо, это подтверждает только передачу на следующий участок обработки. Письмо ещё может задержаться, быть перенаправлено или попасть под фильтр. Отсутствие ответа о возврате тоже не доказывает, что человек увидел сообщение: получательская система может принять его и применить собственные правила позже.

Аутентификация отвечает на более узкий вопрос: вправе ли этот отправляющий узел использовать домен и совпадает ли он с видимым автором письма. Репутация IP и домена, содержание сообщения, вложения, жалобы, настройки получателя и пересылка остаются отдельными факторами. Поэтому SPF, DKIM и DMARC — важная часть диагностики, но не волшебная кнопка доставки. *Порт открыт — это повод закрыть сетевой вопрос, а не объявлять почту исправной.*

Для поиска одного сообщения зафиксируйте адрес получателя и время отправки, а в журнале найдите внутренний идентификатор. Проследите его по очереди и каждому промежуточному серверу: один узел мог принять письмо, другой — поставить повторную попытку, третий — вернуть отказ. Если отправляющая система не показывает понятный ответ, сначала установите, дошёл ли трафик до границы организации. Не переходите сразу к DNS: транспортная ошибка и ошибка аутентификации требуют разной работы. Такой порядок отсекает сетевые и очередные сбои до изменения записей, которые к конкретному сообщению могут вообще не относиться.

• Сверьте исходящий журнал и очередь сообщений.
• Найдите ответ следующего SMTP-узла или отказ.
• Получите копию письма с полными заголовками.
• Сопоставьте результаты проверки с DNS домена.

Условный разбор: фабрика декора «Узор»

Разберу условный пример из исходного кейса: московская фабрика декора «Узор», 28 рабочих мест. Предположим, письма идут из нескольких мест: с рабочего сервера и из внешней формы для клиентов. Пользователь видит один адрес отправителя, но технически сообщение могли подписать и передать разные системы. В таком сценарии нельзя начинать с догадки «почта опять сломалась»; сначала нужно перечислить каждый реальный источник исходящих писем и понять, каким путём проходит тестовое сообщение.

Для одного тестового письма я записываю адрес в видимом поле From, домен отправителя SMTP-конверта, IP узла, принявшего соединение, и домен подписи DKIM. Эти значения отвечают на разные вопросы. SPF проверяет право SMTP-идентификатора, DKIM — цифровую подпись и домен подписанта, а DMARC сопоставляет один из прошедших механизмов с видимым From. Если перепутать поля, можно внести в DNS лишний сервер и оставить настоящую причину на месте.

Дальше смотрю, что именно показывает принимающая сторона: отказ при SMTP-передаче, задержку, недействительную подпись или результат DMARC без выравнивания. Проверяю также, не переписывает ли сообщение форма отправки, CRM или пересыльщик. В исходном варианте статьи фигурировали точные сроки «два часа» и «сутки» и доля потерянных писем, но никаких журналов или отчётов, которые это подтверждали бы, нет. Я убрал эти цифры: в условном кейсе лучше показать порядок проверки, чем выдать красивый результат за факт.

Чтобы не смешать эти маршруты, я отправляю отдельное тестовое письмо каждым каналом и записываю, какой домен оказался в MAIL FROM и какое значение указано в d=. Затем сравниваю результаты в почтовом ящике, который получает тест, с журналом исходной системы. Если сообщения из формы и с сервера дают разные результаты, общий рецепт «поправить SPF» не годится: возможно, один путь подписывает письмо, а другой нет, или сервис использует собственный обратный адрес. Это рабочая гипотеза для проверки, а не вывод по одному IP или жалобе пользователя.

• Составьте перечень всех систем отправки.
• Отправьте отдельное тестовое письмо через каждую.
• Сохраните полные заголовки и ответ SMTP.
• Свяжите найденные домены с нужными DNS-записями.

SPF: одна запись, общий перечень отправителей

SPF — DNS-политика для SMTP-идентификатора отправителя. Обычно это домен MAIL FROM, который после доставки отражается в Return-Path; при пустом обратном адресе проверяется HELO. SPF не проверяет напрямую видимый пользователю заголовок From. Поэтому spf=pass ещё не означает, что DMARC тоже пройдёт: проверка могла относиться к другому домену. В DNS для одного имени публикуют одну SPF-запись, а не отдельную запись для каждого сервиса. Все разрешённые источники нужно аккуратно свести в одну политику.

Лимит SPF — не «десять include». Считаются термы, которые вызывают DNS-поиск во время проверки: include, a, mx, ptr, exists и модификатор redirect; вложенные записи тоже влияют на сумму. Механизмы ip4, ip6 и all сами по себе таких поисков не запускают. Если итоговое число превысит десять, проверяющая система должна вернуть permerror. Это постоянная ошибка обработки SPF, но она не означает автоматически, что каждое письмо окажется в спаме: дальше применяются правила получателя.

Собирайте отправителей по факту, а не добавляйте подряд все адреса из логов. У внешнего сервиса обычно есть собственная инструкция для SPF; используйте её для конкретного домена и проверьте, что не оставили вторую запись v=spf1. Обозначение -all даёт результат fail для не перечисленных источников, ~all — softfail. Выбор зависит от полноты списка и последствий отказа. Я не советую механически заменять все включения на IP: адреса у сервисов меняются, и самодельный список быстро превращается в ещё одну причину отказа.

Проверяйте именно DNS-имя, которым пользуется отправитель. SPF не наследуется с корневого домена автоматически: если обратный адрес заканчивается на поддомен, запись ищут для этого поддомена. Не путайте SPF с другими TXT-записями в той же зоне; наличие текста v=spf1 в панели ещё не доказывает, что получатель видит одну корректную политику. После изменений запросите опубликованную запись у DNS и сравните её с согласованным перечнем сервисов. Особенно внимательно проверьте старые рассылки, формы сайта и устройства, отправляющие напрямую: о них часто вспоминают только после отказа.

• Проверьте домен MAIL FROM или HELO.
• Оставьте одну SPF-запись на имя DNS.
• Сосчитайте DNS-поиски вместе с вложенными include.
• Выберите -all или ~all после сверки отправителей.

DKIM: найдите домен подписи и селектор

DKIM добавляет к письму криптографическую подпись. В заголовке DKIM-Signature особенно важны два поля: d= — домен подписанта, s= — селектор, по которому получатель ищет открытый ключ. Если для примера d=example.com, а s=mail2026, ключ нужно искать по имени mail2026._domainkey.example.com. Публичный ключ публикуют в DNS; соответствующий закрытый ключ остаётся у системы, которая подписывает письмо. Имя селектора — это часть адреса поиска, а не домен, с которым DMARC сравнивает видимый From.

Если подпись отсутствует или не проходит, я проверяю, подписывает ли именно тот узел, который отправил тест, существует ли TXT-запись по точному имени селектора и совпадает ли опубликованный открытый ключ с парой на отправителе. Затем проверяю, не меняет ли промежуточная система заголовки или тело, покрытые подписью. Пересылка часто ломает SPF, потому что соединение приходит уже от другого сервера; DKIM может сохраниться, если подписанные данные не изменились. Это одна из причин не строить DMARC только на SPF.

Здесь легко попасть в ловушку одинаково звучащих имён: домен в поле From, домен DKIM d= и селектор s= не взаимозаменяемы. Для DMARC важен результат DKIM и выравнивание домена подписанта с доменом автора. В зависимости от режима выравнивания сравнение бывает строгим или расслабленным: совпадение может требоваться полностью либо на уровне организационного домена. Если подпись проходит, но домены не выровнены, DKIM остаётся pass, а DMARC через этот механизм — нет. Подробный частный случай разобран в статье о том, почему DKIM-подпись не проходит.

Селекторы позволяют обслуживать несколько ключей одного домена и менять ключ без необходимости использовать одно постоянное имя для всех подписей. Сверяйте s= именно с записью, опубликованной для этого отправителя; проверять первый попавшийся _domainkey бесполезно. При ротации сначала убедитесь, что новая запись доступна получателю и письмо подписывается новым селектором. Не удаляйте старую запись, пока ею ещё пользуются исходящие системы или пока в пути могут быть сообщения с прежней подписью. Закрытый ключ нельзя пересылать вместе с инструкцией по публикации: в DNS нужен только соответствующий открытый ключ.

• Сверьте `d=` и `s=` в подписи.
• Проверьте TXT-ключ по имени селектора.
• Убедитесь, что тест подписал нужный узел.
• Сравните домен `d=` с видимым From.

DMARC: выравнивание, политика и отчёты

DMARC связывает видимый домен From с результатами SPF и DKIM. Для dmarc=pass достаточно, чтобы прошёл и выровнялся хотя бы один механизм: SPF или DKIM. Оба сразу проходить не обязаны. При этом простой spf=pass или dkim=pass не решает задачу, если домен проверки не совпадает с доменом автора по выбранному режиму выравнивания. Именно поэтому я сравниваю не только слово pass, но и имена доменов в заголовках и отчёте получателя.

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

Я начинаю с наблюдения, сопоставляю источники из отчётов с реальными сервисами, настраиваю подписи и проверяю выравнивание на тестах. Только после этого имеет смысл обсуждать quarantine или reject. Эти значения сообщают политику, но не гарантируют, что каждый сервер получателя применит её одинаково; у него остаются собственные правила. Быстро включить reject легко. Потом можно долго выяснять, почему легитимная интеграция не была учтена. Ошибки при переходе к p=reject разобраны отдельно в материале о политике DMARC reject.

Разбирая агрегатный XML-отчёт, я группирую источники по домену и отправляющей инфраструктуре, затем смотрю отдельно на результаты SPF, DKIM и выравнивание. Незнакомый IP не стоит немедленно добавлять в SPF: сначала выясните, кто его использует и на каком домене отправляет. Чужой источник может быть легитимной интеграцией, пересылкой или попыткой подделки; один адрес не объясняет происхождение. Отчёт помогает найти кандидатов для расследования, но окончательное решение принимают по владельцу сервиса, настройкам отправки и контрольному письму, а не по одному красному полю в таблице.

• Сначала соберите все домены отправителей.
• Для отчётов задайте адрес `rua`.
• Исправьте невыравненные SPF и DKIM.
• Меняйте политику после контрольных проверок.

Проверка: заголовки, DNS и ответ получателя

Отправьте тест на адрес, к которому у вас есть доступ, и сохраните исходное сообщение целиком. В Authentication-Results ищите результаты SPF, DKIM и DMARC, но доверяйте только заголовку, который добавил известный получатель внутри своей доверенной границы. Произвольный такой заголовок отправитель может вложить сам. Если у получателя есть dmarc=fail, проверьте, какой механизм прошёл проверку, а затем сравните его домен с From. Например, spf=pass вместе с dmarc=fail часто указывает на проблему выравнивания, а не на отсутствие SPF-записи.

Для каждого теста сверяйте результаты с DNS именно для тех имён, которые использовали письмо и подпись: домена MAIL FROM, _dmarc и имени селектора _domainkey. Не копируйте запись из панели настройки вслепую — проверьте опубликованное значение через DNS-инструмент и убедитесь, что смотрите нужную зону и нужный поддомен. Если запись исправили только для корневого домена, а письмо отправляется от отдельного поддомена, диагностика по неправильному имени даст аккуратный, но бесполезный ответ. Повторяйте контроль после смены DNS и сохраните время правки вместе с ответом DNS-сервера. Панель может показывать уже сохранённое значение, тогда как проверяющий узел ещё получает прежнее; конкретный срок зависит от настроек и кэша. Не рассчитывайте на универсальное «через сутки точно заработает» — сравните опубликованную запись и новый тест.

Если SPF, DKIM и DMARC прошли с правильным выравниванием, не продолжайте бесконечно править DNS. Смотрите SMTP-ответы, задержки, репутацию отправляющего IP и домена, состав письма и правила фильтрации адресата. При пересылке сравните копии до и после промежуточного сервера. Настройки аутентификации сами по себе не управляют входящими сообщениями вашего сервера: не отклоняйте всю входящую почту только из-за отсутствия SPF или DKIM. Если все проверки уже проходят, а письма всё равно попадают в спам, это отдельная задача — ей посвящён разбор почему письма остаются в спаме.

Сверяйте один и тот же экземпляр сообщения на обоих концах маршрута. Если копия отправителя содержит одну подпись, а получатель видит другую или не видит её вовсе, зафиксируйте промежуточный узел до изменения DNS. spf=permerror ведёт к проверке синтаксиса и числа DNS-поисков; dkim=fail — к селектору, ключу и изменениям письма; dmarc=fail при pass у SPF или DKIM — к выравниванию. Так диагноз становится конкретным. Для повторной проверки используйте новый тест после изменения и сохраняйте заголовки, иначе сравнивать будете разные сообщения и разные состояния DNS.

• Сохраните полный исходник тестового письма.
• Проверьте доверенный `Authentication-Results`.
• Сравните `From`, MAIL FROM и домен `d=`.
• Если аутентификация прошла, исследуйте фильтрацию отдельно.

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