Пересылка почты не работает: письма пропадают, отправитель не видит возврата, а правило во всех проверенных панелях выглядит правильным. Без сообщения об ошибке особенно трудно понять, где искать причину.
Если пересылка почты не работает, причиной могут быть правила, аутентификация или политика получателя. При пересылке другой сервер отправляет письмо от имени исходного адреса, и 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.26 | Gmail сообщает недостаточную аутентификацию, например 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 может намеренно блокировать автоматическую внешнюю пересылку политикой, в том числе для ограничения утечки из захваченных аккаунтов. Пользовательское правило не отменяет организационные ограничения. Разрешать исключение должен уполномоченный администратор после проверки, по возможности для узкого круга аккаунтов, не для всей организации.
- Откройте Microsoft 365 Defender с необходимыми правами; уточните текущий интерфейс.
- Перейдите в Электронная почта & совместная работа → Политики & правила → Политики угроз → Защита от спама.
- Проверьте действующую политику, включая исходящую антиспам-политику по умолчанию; для исключения предпочтителен узкий охват.
- Выберите Изменить настройки защиты только с правами и согласованием.
- Установите Правила автоматической пересылки в Включено: пересылка разрешена только для согласованной области, учитывая другие ограничения.
Недоступность параметра может означать отсутствие прав или организационное ограничение. Пользовательские настройки не обходят его. Обратитесь к ответственному администратору среды организации, не ослабляя защиту самостоятельно.
Шаг 5: найдите циклы маршрутизации
Применимость: при признаках цикла | Симптом: ошибка 5.4.14 или несколько копий
Цикл возникает, когда сервер A пересылает в B, а B обратно в A. Передача может повторяться до ограничения переходов или другой защиты от циклов. Возможный сценарий: catch-all домена A ведет в B, а правило отдельных адресов B возвращает письма в A.
В заголовках задержанного или дублированного письма ищите:
X-LoopX-MS-Exchange-Inbox-Rules-LoopDelivered-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.