Пересылка почты с SRS: принцип работы и ограничения

Вы настроили пересылку: contact@yourdomain.com направляет письма в Gmail. Неделю всё работает, затем письма клиентов перестают приходить. Уведомления может не быть, хотя отказ SMTP также может привести к отчёту о недоставке. В журналах появляются 550 5.7.1 Unauthenticated email или 550 5.7.26 This message does not have authentication information. Эти ошибки не указывают на единственную причину, но пересылка почты с SRS решает одну распространённую проблему: сервер открывает новое соединение SMTP, сохраняя в конверте домен исходного отправителя. Если домен не разрешает отправку с новой IP, SPF может завершиться ошибкой. При p=reject в DMARC получатель может отклонить письмо, если также нет действительной согласованной подписи DKIM, с учётом своей политики.

Включение SRS не решает все проблемы. Даже при правильной настройке остаются риски нарушения согласования DMARC и подписей DKIM. Другие причины и способы диагностики описаны в руководстве по настройке и исправлению пересылки почты.

Что такое пересылка почты с SRS?

Пересылка почты с SRS, Sender Rewriting Scheme, изменяет адрес отправителя SMTP-конверта при повторной доставке письма на новый адрес. В техническом адресе возврата исходный домен заменяется доменом сервера пересылки. SPF может пройти проверку, если DNS этого домена разрешает отправку с IP пересылки. Видимое поле From сохраняет исходного отправителя. SRS меняет MAIL FROM, но не шифрует письмо и не скрывает личности: пользователи могут просматривать технические заголовки.

Существуют интеграции для Postfix через службу postsrsd, некоторых конфигураций Microsoft 365 и управляемых почтовых платформ. Проверяйте поддержку, версию и текущие настройки. SRS помогает согласовать пересылку SMTP с проверкой SPF, но не гарантирует доставку или прохождение DMARC.

Почему пересылка может нарушить проверку: новый участок SMTP

Пересылка создаёт новый участок SMTP, IP которого может быть не разрешена исходным доменом. У письма есть две идентичности. Header From (RFC 5322) обычно отображается в клиенте: From: alice@client.com. Envelope Sender (RFC 5321, MAIL FROM) служит адресом возврата для проверки SPF и уведомлений о недоставке. Обычно интерфейс его не показывает, но он доступен в заголовках, например Return-Path.

Эта последовательность иллюстрирует возможный сбой, а не обязательный результат:

1. Alice отправляет письмо с alice@client.com. Запись SPF разрешает её сервер, и на вашем сервере проверка проходит.
2. Ваш сервер открывает новое соединение SMTP с you@gmail.com. Теперь отправляющей IP становится ваша.
3. Envelope Sender остаётся alice@client.com, но в этом примере SPF домена client.com не разрешает IP вашего сервера.
4. Gmail проверяет SPF для client.com. Поскольку IP не разрешена, проверка завершается ошибкой.
5. Если client.com публикует p=reject и действительной согласованной подписи DKIM нет, DMARC не проходит. Gmail может отклонить письмо согласно своей политике; сервер пересылки может получить отказ и сформировать уведомление.

Как SRS помогает пройти SPF

Пересылка почты с SRS меняет Envelope Sender перед повторной доставкой, используя домен сервера пересылки. Получатель проверяет SPF этого домена, которому нужна действительная запись, разрешающая фактическую исходящую IP. Header From не изменяется, и получатель видит первоначального отправителя. Уведомления о недоставке проходят через домен пересылки, который может восстановить исходный адрес согласно реализации и настроенным проверкам.

Разбор синтаксиса SRS

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

До SRS: MAIL FROM: <alice@client.com>
После SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

При повторной пересылке (A → B → C) реализация может использовать SRS1, ограничивая рост адреса SRS0. Конкретная упаковка не обязательно включает только код и метку времени. Проверяйте, что локальная часть укладывается в предел 64 символа по RFC 5321: преобразование не гарантирует этого для любого адреса.

Почему SRS недостаточно: согласование DMARC

Администраторы нередко включают пересылку почты с SRS и считают задачу завершённой, но письма всё равно могут попадать в спам. SRS может обеспечить успешную проверку SPF, не сохраняя исходное согласование DMARC. DMARC требует успешного и согласованного результата SPF или DKIM относительно домена Header From. После преобразования SPF аутентифицирует yourdomain.com, а Header From сохраняет client.com. В этом примере домены не согласованы; в других случаях результат зависит от связи доменов и режима согласования.

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

• Добавление [EXTERNAL] в начало темы
• Вставка антивирусного примечания или юридического уведомления
• Преобразование 8-битной кодировки в 7-битную
• Изменение разделителей MIME

Эти изменения не обязательно нарушают любую подпись, но требуют проверки. Без успешного согласованного SPF и действительного согласованного DKIM проверка DMARC не проходит. Получатель может отклонить или отфильтровать письмо согласно своей политике, даже если SRS работала правильно.

Роль ARC (Authenticated Received Chain)

ARC (RFC 8617) позволяет серверу пересылки зафиксировать действительно наблюдавшиеся результаты аутентификации и подписать соответствующий набор данных. Добавляются три заголовка:

• ARC-Authentication-Results: Записывает результаты SPF/DKIM/DMARC, наблюдавшиеся посредником
• ARC-Message-Signature: Подписывает заголовки и тело в момент формирования набора ARC; последующие изменения подписанных частей могут нарушить эту подпись
• ARC-Seal: Подпись, связывающая набор ARC с предыдущей цепочкой

Если получатель проверяет цепочку и доверяет подписавшему её серверу, он может учесть ARC и принять письмо несмотря на последующий сбой DMARC. Это не превращает сбой в успешную проверку DMARC и не гарантирует доставку. Gmail оценивает ARC в рабочей среде с 2019 года.

Планируя пересылку в 2026 году, рассматривайте пересылку почты с SRS для SPF, сохранение подписанных частей DKIM и ARC, когда она поддерживается и полезна. Это не три универсальных требования и не достаточное условие гарантированной доставки.

Настройка SRS на разных платформах

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

Postfix (самостоятельный хостинг Linux)

Один из вариантов интеграции SRS с Postfix использует службу postsrsd. Следующая команда является примером: проверьте её применимость к дистрибутиву и версии:

apt-get install postsrsd

Этот пример для старых версий использует TCP-карты в /etc/postfix/main.cf. Перед согласованным изменением сохраните конфигурацию, объедините настройки с существующими картами и проверьте поддерживаемые сокеты, пути и форматы вашей версии postsrsd:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Важно: Проверьте способ настройки исключений в своей версии; в примере используется SRS_EXCLUDE_DOMAINS в /etc/default/postsrsd для локальных доменов. Неподходящие исключения могут преобразовать собственную исходящую почту или способствовать циклам вместе с правилами маршрутизации. Отсутствие одной опции не создаёт цикл неизбежно: до изменения проверьте входящие, исходящие и обратные маршруты.

Microsoft 365

Microsoft 365 поддерживает SRS для некоторых потоков; проверяйте актуальное поведение исходящих пулов, гибридных окружений и коннекторов. Ошибка вроде 550 5.7.520 Access denied, Your organization does not allow external forwarding указывает на ограничение исходящей пересылки в отправляющем окружении, а не сама по себе на сбой SRS.

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

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

Google применяет собственные механизмы и ограничения. В частности, проверяйте эти риски, которые встречаются не только в Workspace:

• Лимиты объёма: Пересылка catch-all в Gmail может превысить действующие квоты. Поток спама способен вызвать ограничения; проверяйте актуальные лимиты и состояние аккаунта, не предполагая автоматической блокировки.
• Циклы и отсутствующие письма: Правила и обнаружение циклов могут препятствовать определённым пересылкам. Изучайте доступные журналы, ответы SMTP и инструменты отслеживания, не считая удаление без следов обязательным результатом.

Диагностика проблем пересылки с SRS

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

Проверка 1: Return-Path

Без видимого преобразования SRS: Return-Path: <original@protonmail.com>
С видимым преобразованием SRS: Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

Если Return-Path сохраняет исходный домен, проверьте, нужна ли SRS на этом маршруте, не входит ли он в исключения и не обходит ли настроенные карты. Возможны также остановленная служба или неправильная интеграция, но заголовок сам по себе этого не доказывает.

Проверка 2: Authentication-Results

Ищите spf=pass с преобразованным доменом в доверенных заголовках аутентификации получателя. Значение dmarc=fail при успешном SPF может означать отсутствие согласования SPF и отсутствующую, недействительную или несогласованную подпись DKIM. Проверяйте подписи и изменения темы или тела, а не только наличие подписи.

Проверка 3: DNS

dig yourdomain.com TXT +short

Убедитесь, что домен SRS имеет действительную запись SPF для исходящей IP и доступный адрес возврата. Одной записи MX недостаточно, а её отсутствие не всегда исключает приём: возможен неявный маршрут MX через A/AAAA. Проверяйте адрес возврата и реальные ответы сервера получателя.

Проверка 4: журналы Postfix

grep "srs_forward" /var/log/mail.log

Ошибки hash mismatch или timestamp expired могут быть связаны с разными секретами на узлах, ротацией ключей, расхождением времени, неверной конфигурацией или старыми адресами. Они встречаются и при попытках повторного воспроизведения, но сами по себе не доказывают атаку.

Когда выбрать почтовый ящик вместо пересылки SRS

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

Сравните два подхода:

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

Прямое размещение ящика на TrekMail убирает этот промежуточный маршрут и может устранить потребность в SRS или ARC для него. Мастер помогает подготовить SPF, DKIM и DMARC, но каждый исходящий маршрут нужно разрешить и проверить, включая поддерживаемого тарифом внешнего SMTP-провайдера и его учётные данные. Роль MX-сервера домена не разрешает автоматически исходящую отправку SMTP и не гарантирует аутентификацию.

Попробуйте TrekMail: описанное предложение включает Nano без карты и пробный период 14 дней на Starter от $3.50/mo с управляемым SMTP. Проверяйте актуальные доступность, требования, функции и цены.

Итоги

Пересылка почты с SRS полезна для описанных потоков 2025-2026 годов, но не обязательна для любого сервера пересылки. Без SRS проверка SPF может не пройти, если исходный домен не разрешает новую IP. С SRS она может пройти при правильной авторизации, но согласование с исходным From может отсутствовать. Для DMARC нужен успешный согласованный SPF или DKIM.

В Postfix проверяйте версию postsrsd, карты main.cf и исключения. В Microsoft 365 изучайте согласованные политики и действительно доступные функции, не применяя несовместимую команду. В Workspace проверяйте квоты, правила, журналы и состояние аккаунтов.

Используйте SRS при необходимости, сохраняйте подписи DKIM и добавляйте ARC, когда получатель поддерживает её и доверяет цепочке. Это не гарантирует доставку. Другой вариант: разместить ящик в конечном месте получения, сохраняя необходимые настройки и проверки аутентификации.