Пересылка почты на другой адрес: аутентификация и диагностика

Вы создаёте правило пересылки, отправляете тестовое письмо. Всё работает. Можно заниматься другими делами.

Но затем клиент сообщает, что ваш ответ не пришёл. Вы не видите ни возврата, ни отчёта NDR. Кажется, письмо исчезло где-то между серверами. Установить причину можно только по журналам доставки.

При пересылке письма на другой адрес ваш сервер открывает новое SMTP-соединение с получателем. Получатель проверяет SPF для вашего IP, а не IP исходного отправителя. Если этот IP не разрешён для домена конвертного отправителя, SPF может завершиться неудачей. Если при этом не сохранилась действительная DKIM-подпись, согласованная с видимым доменом From, не пройдёт и DMARC. Политика p=reject запрашивает отклонение письма, но конкретная обработка и наличие уведомления об ошибке зависят от принимающей стороны.

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

Почему аутентификация может не пройти при пересылке

Принимающий MTA проверяет SPF по IP сервера пересылки. У письма есть разные идентификаторы отправителя, которые при пересылке могут перестать согласовываться. SPF проверяет конвертного отправителя. Для DMARC нужен успешный SPF или DKIM с доменом, согласованным с видимым From. Без обоих согласованных подтверждений DMARC не проходит; дальнейшую обработку определяет политика получателя.

Цепочка выглядит так: сервер A отправляет письмо вашему серверу B, а B устанавливает новое TCP-соединение с получателем C. C видит IP сервера B. SPF обращается к DNS домена конвертного отправителя: "Разрешено ли этому IP отправлять почту от этого домена?" Если B не разрешён, SPF может не пройти. Это распространённый результат, но не неизбежный для каждой пересылки.

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

Три типичных вида сбоев

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

1. Блокировка исходящей пересылки Microsoft 365 (550 5.7.520)

Microsoft 365 рассматривает автоматическую внешнюю пересылку как возможный канал утечки данных. Действующая политика по умолчанию может заблокировать правило пересылки за пределы организации ещё до выхода письма из Exchange Online.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Это ограничение политики, а не ошибка протокола. Уполномоченный администратор может выполнить следующие действия:

1. Откройте Microsoft 365 Defender Portal.
2. Перейдите в Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Создайте или измените Outbound spam filter policy только для явно одобренных учётных записей.
4. Для этой ограниченной политики установите Automatic forwarding в On - Forwarding is enabled, если пересылка разрешена администратором.

Не включайте пересылку глобально через общую политику по умолчанию: это повышает риск при взломе любого аккаунта. Используйте адресную политику, MFA и контроль объёма исходящей почты; проверьте также другие действующие ограничения пересылки.

2. Отсутствуют оба подтверждения DMARC

Такой сбой легко пропустить. Изменившийся IP может привести к неудаче SPF. Действительная согласованная DKIM-подпись всё ещё позволяет пройти DMARC. Однако изменения подписанного содержимого или подписанных заголовков могут нарушить и DKIM. Результат зависит от охвата подписи и канонизации, а не от самого факта любого изменения.

Типичные изменения, способные нарушить DKIM:

• Добавляемая антивирусом подпись внизу письма: "Проверено [Название продукта]"
• Метки в теме от принимающего шлюза, если тема подписана: [EXT] или [EXTERNAL]
• Предупреждения "Внешний отправитель", вставленные в HTML-тело
• Системы рассылок, меняющие подписанные заголовки или добавляющие блок отписки

Без успешного согласованного SPF и действительной согласованной DKIM-подписи DMARC (RFC 7489) возвращает FAIL. При p=reject домен отправителя запрашивает отклонение. Получатель может применить собственную политику: возможны отказ с отчётом об ошибке, карантин или другая обработка. Отсутствие уведомления само по себе не доказывает незаметное удаление письма.

3. Петли маршрутизации (554 5.4.14)

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

Возможные причины:

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

554 5.4.14 Hop count exceeded - possible mail loop

Перед включением пересылки в рабочей среде проверяйте всю цепочку маршрутизации, включая автоответы и адреса назначения catch-all.

Меры защиты: SRS и ARC

Два серверных механизма могут улучшить пересылку, но не гарантируют доставку. SRS переписывает конвертного отправителя, позволяя пройти SPF для домена пересылки, если его DNS разрешает исходящий IP. ARC фиксирует предыдущие результаты аутентификации, чтобы доверяющий посреднику получатель мог по своей политике сделать исключение для DMARC. Обычное правило почтового клиента не реализует эти механизмы самостоятельно.

SRS: Sender Rewriting Scheme

SRS заменяет конвертного отправителя (P1) адресом в вашем домене. Вместо сохранения alice@bank.com, для домена которого ваш IP может быть не разрешён, сервер пересылки формирует, например, такой адрес возврата:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

Теперь SPF проверяет домен пересылки. Если его SPF-запись разрешает исходящий IP и нет других ошибок SPF, проверка может пройти. Само по себе это не обеспечивает согласование DMARC с исходным доменом From.

Хеш и временная метка помогают контролируемо возвращать ошибки: NDR на действительный SRS-адрес можно декодировать и направить настоящей Alice. Такие адреса ограничены по времени и предназначены для возвратов. Но надёжный секрет SRS сам по себе не предотвращает открытый ретранслятор: нужны отдельные ограничения доступа к relay и проверка адресов возвратов.

ARC: Authenticated Received Chain

SRS может обеспечить SPF для домена пересылки, но не устраняет разрыв согласования с исходным From. ARC (RFC 8617) также не устраняет этот разрыв. Он добавляет криптографически защищённую запись о наблюдавшейся аутентификации: "Вот что я проверил при получении письма."

Google, Microsoft и другие получатели могут учитывать действительные ARC-цепочки доверенных посредников. Решение доверять подписи и отступить от политики DMARC остаётся за получателем. Хорошая репутация IP и успешная проверка ARC не гарантируют ни принятия письма, ни попадания во входящие.

ARC похож на журнал передачи письма между посредниками. Каждый участвующий узел добавляет подписанную запись о наблюдавшемся состоянии аутентификации. Следующий получатель может проверить цепочку и учитывать её по собственной политике, даже если текущая проверка DMARC не находит согласованного успешного SPF или DKIM.

Gmail и Microsoft 365 поддерживают ARC в определённых потоках почты. Проверяйте реальные заголовки и актуальную документацию, а не предполагайте наличие подписи всегда. Без ARC эта дополнительная запись отсутствует, но это не означает неизбежный провал DMARC: сохранившейся согласованной DKIM-подписи может быть достаточно.

Реализация: два подхода

Можно управлять собственным MTA или выбрать платформу, которая предоставляет SRS и, при наличии поддержки нужного маршрута, ARC. Управляемый вариант тоже требует правильного DNS, правил и тестов доставки. Ни один подход не исключает все сбои.

Вариант A: самостоятельный Postfix + postsrsd

На Linux-сервере с Postfix можно использовать postsrsd для переписывания конверта. Следующий пример относится к старым версиям с TCP-картами; его нельзя без изменений перенести на версию с интерфейсом socketmap. Сверьтесь с установленной версией и настройками в её документации. Этот пример здесь не выполнялся:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

При таком подходе вы отвечаете за следующее:

• Управление секретами SRS. Утечка может позволить подделывать адреса возвратов; ограничения relay нужны независимо от этого.
• Корректные исключения для локальных доменов. Слишком широкое переписывание может повредить внутренней доставке.
• Репутацию исходящего IP, которая наряду с другими факторами влияет на доставку в Gmail и Outlook.
• Отдельную настройку ARC: одного postsrsd для этого недостаточно.

Правильно настроенная система может работать, но требует постоянного обслуживания. Специализированная почтовая платформа способна взять на себя часть этой работы.

Вариант B: управляемая пересылка TrekMail

Для выбранного тарифа и маршрута TrekMail подтвердите актуальную доступность автоматического SRS, ARC и управляемых SMTP-релеев. Эти возможности могут избавить от части серверных настроек и управления ключами. Утверждения о включении ARC в платные тарифы и использовании конкретных релеев нужно проверять перед покупкой; репутация релея не гарантирует доставку.

Если вы развиваете бизнес в одиночку и платите $6 в месяц за каждый ящик только ради пересылки info@yourdomain.com в личную почту, сравните это с тарифами с оплатой за домен. Указанные здесь условия Starter, $3.50 в месяц за максимум 50 доменов без оплаты за пользователя, необходимо сверить с текущими ценами и ограничениями пересылки. См. как работает пересылка из ящика в TrekMail.

Для агентств с множеством клиентских доменов поиск ошибок SPF может быть дорогим. Централизованное управление пересылкой способно упростить работу, если нужные функции доступны. Руководство по пересылке через почтовые псевдонимы объясняет различия между псевдонимами и правилами ящиков.

Что проверить перед включением пересылки

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

1. SRS работает. Посмотрите заголовок Return-Path доставленного тестового письма. Если для этого маршрута предусмотрен SRS, он должен показывать домен пересылки; отдельно проверьте разрешение исходящего IP в SPF.
2. Сохранение подписанного содержимого. Избегайте добавляемых блоков внизу письма, меток темы и баннеров, которые нарушают DKIM. Не отключайте антивирус и другие проверки безопасности: используйте равноценную защиту без изменения подписанного содержимого, учитывая канонизацию и подписанные заголовки.
3. Защита от петель. Проверьте обратную пересылку, ответы об отсутствии, catch-all и механизмы подавления циклов автоответов.
4. Исходящая политика M365. Для Exchange Online проверьте действующие ограничения. Разрешайте автоматическую внешнюю пересылку только в одобренной политике для нужных аккаунтов, а не глобально.

Когда пересылка не подходит

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

Сравнение доменного почтового псевдонима и ящика поможет выбрать вариант. Для переноса старой почты инструмент IMAP-миграции может быть удобнее живой пересылки. Проверьте текущую доступность инструмента TrekMail; копирование истории по IMAP не заменяет настройку маршрута для новых входящих писем.

Итоги

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

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

Если вы не хотите самостоятельно управлять ключами SRS, ARC и SMTP-релеями, уточните нужные возможности TrekMail. Указанные здесь $3.50 в месяц за максимум 50 доменов на Starter без платы за пользователя нужно сверить с текущим тарифом и его ограничениями пересылки. Все тарифы.