Пересылка почты

Пересылка почты не работает: диагностика в 6 шагов

Автор: Alexey Bulygin
Шесть шагов диагностики пересылки почты с проверкой отказов, маршрутов и аутентификации

Пересылка почты не работает: письма пропадают, отправитель не видит возврата, а правило во всех проверенных панелях выглядит правильным. Без сообщения об ошибке особенно трудно понять, где искать причину.

Если пересылка почты не работает, причиной могут быть правила, аутентификация или политика получателя. При пересылке другой сервер отправляет письмо от имени исходного адреса, и SPF может не пройти. Но письмо не обязательно теряется: его могут принять, задержать, отклонить или поместить в спам в зависимости от DKIM, DMARC и проверки получателем. Отказ возможен уже через секунды, однако отсутствие уведомления само по себе не доказывает тихое удаление.

Пройдите этот список до изменения DNS. Подробности SPF, SRS и ARC разобраны в полном руководстве по настройке и исправлению пересылки. Здесь приведен порядок первичной проверки текущего сбоя.

Почему ошибка может остаться незаметной

Получатель может сообщить о проблеме иначе, чем сервер пересылки. Отказ SMTP способен вызвать возврат, после приема письмо может попасть под фильтрацию, а уведомление о недоставке может прийти пересыльщику или на переписанный адрес возврата. Отсутствие видимой ошибки не означает ни успешную доставку, ни удаление через секунды после отправки.

Заголовки, возвраты и журналы помогают, когда активное правило не дает подсказок. Шесть проверок ниже ведут от доступных исходных сведений к техническому разбору. Начав с DNS вместо папки спама, можно, например, потратить 45 минут на неверную причину.

Проверка за 60 секунд: сначала определите симптом

Уделите первые 60 секунд описанию поведения, прежде чем менять настройки. Четыре приведенных ниже сценария подсказывают направление поиска, но сами не устанавливают точную причину.

СимптомЧто видноВозможная причинаПервый шаг
Возврат (NDR)Отправитель сразу получает ошибку 5xxПолитика блокировки или неверный адресПрочитайте код SMTP и полный текст возврата
Письмо отсутствует без возвратаНет письма и видимого уведомленияФильтрация, ошибка аутентификации или другой сбойСначала проверьте спам конечного получателя
Цикл“Hop count exceeded” или повторные копииЗамкнутые правила пересылкиПроверьте маршрут A → B → A
ЗадержкаПисьмо приходит через несколько часовСерый список или ограничение сервераНайдите в журнале status=deferred

Порядок проверки неработающей пересылки

Шаг 1 и шаг 2 дают доступные исходные сведения: содержимое спама и возврата. Проверьте их, прежде чем, например, тратить 45 минут на ненужные правки DNS. Продвигайтесь по списку, пока не получите достаточно данных о причине.

Шаг 1: проверьте спам в конечном ящике

Приоритет: проверить в начале  |  Симптом: нет письма и возврата

Недошедшее письмо может находиться в спаме. Пересылка меняет путь, проверяемый SPF: при отправке от client@gmail.com к you@outlook.com Outlook может увидеть IP пересыльщика, не разрешенный исходной SPF-записью. Это влияет на оценку, но не обязательно приводит к спаму: сохранившаяся выровненная подпись DKIM и другие сигналы также учитываются.

Действие: войдите в конечный ящик и проверьте нежелательную почту.

Мера: для легитимного письма при необходимости выберите “Не спам”. Sender Rewriting Scheme (SRS) переписывает отправителя конверта и может обеспечить SPF для домена пересыльщика. Это не гарантирует выравнивание с исходным From или дальнейшую доставку; отсутствие SRS не делает любую пересылку в Gmail, Yahoo или Outlook невозможной.

Шаг 2: прочитайте возврат и коды NDR

Приоритет: при наличии возврата  |  Симптом: отправитель получает “Не доставлено”

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

Код ошибкиЗначениеПроверка или действие
550 5.7.520Отказ в доступе; политика M365 может запрещать внешнюю пересылкуПроверьте разрешенное узкое исключение в M365 (шаг 4)
550 5.7.26Gmail сообщает недостаточную аутентификацию, например SPF/DMARCПроверьте SPF, выровненную DKIM и DMARC; отсутствие SRS не единственная возможная причина
5.4.14 / 5.4.6Возможный цикл маршрутизации между серверамиРазомкните цепочку правил (шаг 5)
550 5.1.1Неизвестный получатель или неправильный адресПроверьте адрес назначения и наличие ящика

Шаг 3: проверьте выравнивание DMARC

Применимость: в том числе Gmail, Yahoo и Outlook  |  Симптом: нет письма или получен отказ

DMARC может влиять на пересылку, но не всегда является причиной. Даже при p=reject нельзя утверждать, что простая пересылка без SRS или ARC завершается отказом в 100% случаев: сохранившаяся подпись DKIM, которая успешно проверена и выровнена с видимым From, может обеспечить прохождение DMARC. Требуется успешная выровненная SPF или DKIM, не обязательно обе. Обработка зависит от решения получателя.

Запросите политику DMARC исходного домена в терминале:

dig _dmarc.originalsender.com TXT +short

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

Мера: подходящий сервер пересылки может поддерживать SRS при ретрансляции и ARC (Authenticated Received Chain). ARC сохраняет проверяемые предыдущие результаты аутентификации; доверие к цепочке и посреднику определяет получатель. Фильтры Gmail и правила Outlook выполняются по-разному в разных продуктах, а переадресация cPanel является серверной. Проверяйте реальную обработку MTA, не объявляя все такие правила клиентскими или заведомо несовместимыми с DMARC.

Шаг 4: проверьте политику внешней пересылки Microsoft 365

Применимость: Office 365 с соответствующим кодом  |  Симптом: NDR 550 5.7.520

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

  1. Откройте Microsoft 365 Defender с необходимыми правами; уточните текущий интерфейс.
  2. Перейдите в Электронная почта & совместная работа → Политики & правила → Политики угроз → Защита от спама.
  3. Проверьте действующую политику, включая исходящую антиспам-политику по умолчанию; для исключения предпочтителен узкий охват.
  4. Выберите Изменить настройки защиты только с правами и согласованием.
  5. Установите Правила автоматической пересылки в Включено: пересылка разрешена только для согласованной области, учитывая другие ограничения.

Недоступность параметра может означать отсутствие прав или организационное ограничение. Пользовательские настройки не обходят его. Обратитесь к ответственному администратору среды организации, не ослабляя защиту самостоятельно.

Шаг 5: найдите циклы маршрутизации

Применимость: при признаках цикла  |  Симптом: ошибка 5.4.14 или несколько копий

Цикл возникает, когда сервер A пересылает в B, а B обратно в A. Передача может повторяться до ограничения переходов или другой защиты от циклов. Возможный сценарий: catch-all домена A ведет в B, а правило отдельных адресов B возвращает письма в A.

В заголовках задержанного или дублированного письма ищите:

  • X-Loop
  • X-MS-Exchange-Inbox-Rules-Loop
  • Delivered-To, повторяющийся с одинаковым адресом.

Руководство по catch-all домена объясняет маршрутизацию. У каждой пересылки должен быть документированный путь в конечный ящик. Дополнительные псевдонимы или ретрансляторы допустимы, если цепочка проверена и не образует цикл.

Шаг 6: проверьте подтверждение назначения Gmail

Применимость: для неактивного правила  |  Симптом: правило есть, пересылки нет

Для личного Gmail отсутствие подтверждения назначения может остановить настройку. Google требует подтвердить адрес для этой функции пересылки. После подтверждения также проверьте, включена ли сама пересылка или соответствующий фильтр.

Действие: в конечном ящике найдите подтверждение от “Gmail Team”, при необходимости в спаме. Подтверждайте только проверенный запрос, который вы сами инициировали. Если письмо не пришло или срок истек, повторите запрос в настройках Gmail → Пересылка и POP/IMAP и проверьте включение пересылки.

Читайте заголовки для диагностики пересылки

Письмо в спаме уже доставлено, но его классификация может иметь разные причины. Authentication-Results показывает результаты аутентификации проверяющего сервера, не полную причину любого сбоя пересылки. Используйте доверенные результаты вместе с маршрутом и журналами.

Как открыть заголовки:

  • Gmail: откройте письмо → меню с тремя точками → “Показать оригинал”.
  • Outlook: Файл → Свойства → Интернет-заголовки; учитывайте версию продукта.

Условный пример с SRS и ARC: упрощенные строки ниже не являются полной эталонной записью заголовков.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)
Результат заголовкаЗначениеСледующая проверка
spf=failПроверяемый IP отправки не разрешен для проверяемой SPF-идентичностиПроверьте домен конверта, ретранслятор и нужную поддержку SRS
spf=pass + SRS0= в Return-PathПризнак переписывания и успешной SPF-проверки соответствующей идентичностиПроверьте DKIM и DMARC, включая выравнивание с From
dmarc=failНи одна успешная SPF или DKIM не удовлетворяет выравниванию с FromПроверьте аутентификацию, сохраненную DKIM и при необходимости доверие к ARC
arc=passЦепочка ARC проверена; доверие посреднику определяет получательПроверьте политику и фильтры получателя, не считайте это гарантией доставки
dkim=passПодпись проверена для подписанных частей, не обязательно для всего сообщенияСравните домен подписи с From: выровненной DKIM может хватить для DMARC

SRS0= в Return-Path может указывать на SRS, но сам не доказывает правильную настройку или выравнивание с From. Отсутствие префикса тоже не доказывает отсутствие переписывания или неизбежный отказ DMARC. Проверяйте реальный маршрут и аутентификацию. Требования Google с 2024 года относятся к определенным сценариям отправки и не доказывают единую политику всех деловых доменов.

Когда неработающая пересылка влияет на бизнес

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

Разовая ручная диагностика становится трудоемкой на многих доменах. Новые ящики и изменившиеся политики отправителей требуют повторной проверки. Google Postmaster Tools предоставляет агрегированные сведения для Gmail в зависимости от прав, объема и наличия данных, а не полную картину каждой пересылки в реальном времени. Ошибки аутентификации сами не означают рост пользовательских жалоб на спам или ухудшение репутации всей отправки.

Устраняйте повторяющиеся причины, не только отдельные сбои

При постоянных проблемах стоит проверить инфраструктуру с подходящей поддержкой SRS и ARC. Это может уменьшить ошибки аутентификации, но не отменяет мониторинг и последующую диагностику.

Подход через правила: настроить пересылку Gmail или cPanel, проверить фактическую серверную обработку, изучить аутентификацию доменов и ограничения M365.

Модель TrekMail: определить маршрут в панели и проверить доступное переписывание SRS и обработку ARC на MTA. Получатель по-прежнему решает, принять ли письмо.

TrekMail описывает пересылку на уровне Postfix с SRS и обработкой ARC перед повторной отправкой. Проверьте нынешнюю реализацию, сохранность подписей и результаты у получателя. ARC сохраняет предыдущие результаты аутентификации, не заменяет исходную DKIM и не гарантирует ни ее сохранность, ни прием Gmail, Outlook или Yahoo.

При десятках клиентских доменов централизованная настройка может упростить управление. Вместо, например, 30 отдельных панелей доступные маршруты можно вести в одном месте, но их действие нужно проверять для каждого домена. Руководство по управлению почтой клиентов рассматривает многодоменные маршруты и циклы A→B→A из шага 5.

Исторические примеры указывают Pro за $10 в месяц со 100 доменами и 50GB и Agency за $23.25 в месяц с 1,000+ доменами. Также указан 14-дневный пробный период. Уточните сегодняшние цены, лимиты, требования к платежной карте, условия пробного доступа и поддержку ARC/SRS до планирования: сравните планы на trekmail.net/pricing.

Повторяющимся сбоям пересылки нужны проверенные рабочие процессы. Проверьте инфраструктуру с подходящей поддержкой SRS и ARC.

Поделиться статьёй

Мы используем необходимые технологии для работы и защиты TrekMail. Подтверждая это, вы также разрешаете ограниченную аналитику и измерение рекламы, описанные в Политике cookie.

Вход в TrekMail

Доступ к панели, ящикам и DNS.

или

12 символов пароли совпадают

или

Письмо отправлено

Если для этого адреса есть аккаунт, мы отправили инструкции по сбросу пароля.

Продолжая, вы принимаете Условия и Политику конфиденциальности TrekMail.