Как найти причину проблем с доставкой почты

Если письма попадают в спам или возвращаются с ошибкой, сначала сохраните полный ответ SMTP и заголовки письма, затем проверьте IP в DNSBL, обратный PTR и аутентификацию домена. Это помогает отделить локальный отказ получателя от общей проблемы с доставкой. Ни одна проверка сама по себе не обещает попадание во входящие; ниже — порядок диагностики и безопасного исправления.

С чего начать, если почта не доходит

Когда письмо не доходит, я начинаю с журнала отправляющего сервера и полного текста ответа получателя. Код 554 означает постоянный отказ на уровне SMTP-транзакции, но сам по себе не объясняет причину. Расширенный код 5.7.1 обычно относится к политике безопасности или авторизации; точная трактовка зависит от сервера и текста после кода. Поэтому фраза «554 5.7.1 — это точно плохая репутация IP» неверна: сервер мог отказать из-за правил ретрансляции, аутентификации или локальной политики. Если нужен системный разбор, мы проверим корпоративную почту вместе с маршрутом отправки.

Разделите симптомы. Если сервер вернул отказ при SMTP-обмене, ищите ответ и очередь на стороне отправителя. Если отправка завершилась успешно, но письма нет во входящих, проверьте папку «Спам», карантин и заголовки уже доставленного сообщения. Если проблема только у одного адресата, вероятнее локальная политика или фильтр его организации. Если жалобы идут от нескольких независимых получателей, тогда сравните IP, домен отправителя, результаты SPF/DKIM/DMARC и недавние изменения конфигурации.

Не делайте вывод о репутации по одной жалобе и не отключайте защитные проверки ради «быстрого решения». Я прошу сохранить время события, адрес назначения, исходный ответ SMTP и Message-ID — без этого администратор получателя будет гадать вместе с вами. Репутационные системы учитывают разные сигналы; ни ошибка, ни попадание в спам автоматически не доказывают, что именно IP оказался в блок-листе. Сначала данные, затем исправление. Так дешевле, чем менять сервер вслепую.

• Сохранить полный ответ SMTP и время отказа
• Определить: отказ, спам или задержка
• Сравнить результат у нескольких адресатов

Как проверить исходящий IP и DNS

Проверьте исходящий IP в нескольких актуальных DNS-based blocklist (DNSBL/RBL), включая список, который назвал принимающий сервер. Сверьте результат с официальной страницей проверки конкретного списка: агрегатор может не опрашивать нужную базу или показывать устаревший статус. Проверка IP в сервисе наподобие 2ip.ru — только первичный ориентир, а не приговор и не универсальное измерение «репутации». Разные получатели применяют разные списки и собственные правила; наличие записи в одном списке не означает автоматический отказ у всех адресатов.

Установите, какой именно IP отправлял письмо: при шлюзе, облачной почте или стороннем сервисе видимый получателю адрес может не совпадать с IP вашего веб-сервера. Сверьте этот адрес с журналом SMTP или заголовком сообщения, затем выполните обратный DNS-запрос и проверьте PTR. Для исходящей почты важна согласованность обратной и прямой записи: PTR должен вести на имя почтового узла, а имя — разрешаться обратно в ожидаемый адрес. Менять PTR обычно должен владелец адресного диапазона или хостер, а не редактор DNS-зоны домена.

Отдельно проверьте домен отправителя и заголовки Authentication-Results у полученного тестового письма. Важно увидеть не только pass/fail, но и проверенный домен: для DMARC значение имеет alignment домена From с доменом, прошедшим SPF или DKIM. Тестовое письмо полезно как снимок конкретного маршрута и получателя; оно не гарантирует такой же результат у всех почтовых систем. Зафиксируйте, откуда отправлено письмо и куда оно доставлено, чтобы сравнивать одинаковые условия, а не результаты разных маршрутов.

В DNSBL не попали — диагностика не закончена. Проверьте очередь исходящей почты, объём и характер отправок, ошибки аутентификации, настройки обратного DNS и жалобы получателей. Если IP действительно указан в списке, откройте карточку записи у оператора и прочитайте её основание и процедуру исправления. Не отправляйте запрос на исключение, пока поток нежелательной почты продолжается: сначала остановите источник и устраните причину. У каждой базы свои условия и сроки, поэтому обещание «снимут за несколько часов» технически нечестно.

• Установить фактический исходящий IP
• Проверить его в нужных DNSBL
• Сверить PTR и прямую DNS-запись
• Проверить Authentication-Results

Условный разбор: студия «Радуга-Строй»

Для примера возьму условную студию «Радуга-Строй» из этого разбора. Допустим, сотрудники сообщают о пропавших письмах, а администратор видит отказы у части адресатов. Это не доказательство взлома и не повод немедленно менять IP. Мы просим исходный ответ SMTP, сверяем время в очереди, выясняем, через какой узел вышло письмо, и сравниваем результат у нескольких получателей. Только после этого проверяем DNSBL, PTR и аутентификацию отправляющего домена.

Если проверка обнаружила массовые отправки, которых компания не планировала, сначала ограничиваем исходящую отправку и исследуем учётные записи, приложения, SMTP-реле и журналы. Пароль меняют после определения затронутых учётных записей, а не вместо расследования. Если IP внесён в список, сверяем причину у оператора и обращаемся к владельцу адреса или провайдеру по его инструкции. Запрос на снятие делаем после остановки злоупотребления. Само удаление из списка не исправит открытую форму сайта или скомпрометированный ящик, который продолжает отправлять письма.

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

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

• Сверить журнал и очередь SMTP
• Проверить список и основание записи
• Устранить источник лишней отправки
• Повторить проверку у адресата

Что проверять в SPF, DKIM и DMARC

SPF, DKIM и DMARC решают разные задачи. SPF публикует список разрешённых источников для домена envelope sender (MAIL FROM); это не список всех адресов в видимом поле From. DKIM добавляет криптографическую подпись, по которой получатель проверяет подписывающий домен и целостность подписанных частей сообщения. Изменение подписанных заголовков или тела в пути может нарушить проверку. Ни один из этих механизмов сам по себе не гарантирует папку «Входящие»: конечное решение принимает почтовая система получателя с учётом своей политики.

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

Перед изменением SPF составьте список всех легитимных отправителей: почтовый сервер, CRM, сайт и внешние рассылки. У домена должна быть одна SPF-политика, а не несколько независимых TXT-записей с v=spf1. RFC 7208 ограничивает десятью число механизмов и модификаторов, вызывающих DNS-поиск при одной проверке; превышение приводит к permerror. Это не лимит «десять серверов». Сначала проверьте существующую запись и вложенные include, затем согласуйте её с каждым сервисом. Не добавляйте чужую инструкцию целиком, не понимая, какие отправители она разрешает.

DKIM проверьте по заголовку полученного письма: подпись должна проверяться, а домен подписи и селектор — соответствовать настройке отправителя. При ротации ключей учитывайте опубликованный публичный ключ и период, когда ещё могут проверяться старые письма. DMARC внедряйте с пониманием реального потока: отчёты настраивают для анализа источников и alignment, а строгую политику включают после того, как легитимные сервисы проходят проверки. Непроверенный переход на reject способен остановить собственные письма. Сначала наблюдение, затем политика — скучно, зато без сюрпризов в бухгалтерии.

Практическая последовательность такая: инвентаризировать отправителей; проверить SPF и убрать дубли; включить подпись DKIM на каждом источнике; сверить результаты на письмах разных типов; настроить DMARC-отчёты; оценить их и только затем менять политику. После переезда почты перечень отправителей часто меняется: старые include или ключи остаются, новые сервисы забывают добавить. Из-за этого тестовое письмо с одного сервера проходит, а уведомление с сайта — нет. Проверяйте каждый маршрут отдельно и храните актуальную схему того, кто имеет право отправлять от имени домена.

• SPF: один перечень легитимных источников
• SPF: не больше 10 DNS-поисков
• DKIM: подпись и домен селектора
• DMARC: alignment и агрегированные отчёты

Как действовать при записи в DNSBL

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

Процедуру снятия записи определяет оператор конкретного DNSBL. Используйте его официальный lookup, изучите причину, выполните требуемые действия и подайте запрос в указанной форме. Не рассылайте одинаковое письмо всем операторам и не подменяйте IP: смена адреса не устраняет источник проблемы и может перенести её на новую инфраструктуру. Если оператор просит время на повторную проверку, выдержите его срок и следите за статусом по его инструменту. Снятие записи в одном списке не означает, что адрес исчез из остальных или что получатель обязан принять почту.

Для контроля после работ наблюдайте за журналами исходящих соединений, очередью, отказами и отчётами DMARC. Проверяйте DNS при изменении почтового маршрута и после подключения нового сервиса рассылки. Если адресат всё ещё отклоняет письмо, сопоставьте полный текст отказа и политику именно этой системы; не ждите произвольное количество дней в надежде на «обновление кэша». Кэши DNS имеют TTL, а репутационные решения могут пересматриваться по правилам конкретного получателя. Это разные процессы, и универсального таймера восстановления нет.

План действий короткий: сохранить диагностические данные, установить фактический исходящий IP, проверить DNSBL и PTR, сверить SPF/DKIM/DMARC, устранить источник нежелательной отправки и следовать процедуре оператора списка. Затем перепроверить тот же сценарий у адресата, который сообщил об отказе. Не обещайте руководителю доставку «100 %» или восстановление к определённому часу: ни администратор отправителя, ни оператор одного списка не управляет фильтрами всех получателей. Я предпочитаю показать конкретный ответ сервера и исправленный маршрут. Это не так эффектно, зато проверяемо.

• Остановить источник нежелательной почты
• Следовать процедуре оператора DNSBL
• Обратиться к владельцу IP при необходимости
• Наблюдать за очередью и отказами

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