Вы настраиваете пересылку: contact@your-agency.com → you@gmail.com. Проверяете: всё работает. Через две недели договор от корпоративного клиента не приходит ни в спам, ни во входящие. В журналах появляется 550 5.7.1 Unauthenticated email, ошибка с несколькими возможными причинами. Также можно встретить 550 5.7.520 Access denied, если Microsoft 365 блокирует исходящую пересылку по политике. Отсутствие письма не доказывает, что оно было молча удалено.
Механизм перезаписи адреса отправителя SRS может решить часть проблемы при правильной настройке. Без него SPF может не пройти, если домен исходного отправителя конверта не разрешает IP пересылающего сервера. В 2026 требования Google и Yahoo делают проверку аутентификации особенно важной, но не обязывают всех публиковать p=reject в DMARC (требования Google к отправителям). Даже при строгой политике действительная согласованная подпись DKIM может обеспечить прохождение DMARC. Эта статья объясняет работу SRS на уровне протокола, его ограничения и компоненты подходящей конфигурации.
Общую картину даёт руководство по настройке пересылки почты и устранению распространённых сбоев.
Что такое Sender Rewriting Scheme (SRS)
SRS заменяет отправителя конверта, чтобы снизить риск отказа SPF при пересылке. Перед передачей письма он меняет SMTP-адрес конверта (MAIL FROM) на адрес домена пересылающего сервера. Этот адрес обычно не показан в интерфейсе клиента, но виден в Return-Path при просмотре исходных заголовков. Получатель проверяет SPF нового домена, который должен разрешать фактический IP. Тогда SPF может пройти, но это не гарантирует доставку или согласование DMARC с видимым From. Один отказ SPF не доказывает подмену.
Два уровня идентификации в почте
При проверке SRS важно различать два идентификатора отправителя, которые часто смешивают. SPF проверяет домен конверта; DMARC сравнивает домены, аутентифицированные через SPF или DKIM, с видимым From. Пересылка меняет соединение и может по-разному влиять на эти проверки.
| Уровень | RFC | Поле | Что проверяет | Виден получателю? |
|---|---|---|---|---|
| Конверт (P1) | RFC 5321 | MAIL FROM / Return-Path | SPF | Обычно не в интерфейсе; доступен в исходных заголовках |
| Заголовок (P2) | RFC 5322 | From: | Согласование DMARC | Да |
Конверт используется при передаче и возвратах, а его домен проверяется через SPF. From в заголовке отображается клиентом и служит ориентиром для согласования DMARC. Новое соединение пересылки может привести к отказу SPF, если IP не разрешён, но не обязательно нарушает все механизмы: действительный согласованный DKIM может сохранить прохождение DMARC.
Проблема нового перехода: почему SPF может не пройти
Для пересылки сервер открывает новое SMTP-соединение с получателем. Если отправителем конверта остаётся alice@bank.com, а IP уже ваш, SPF проверяет его по записи bank.com. В этом примере он не разрешён, поэтому SPF не проходит. Если bank.com публикует DMARC p=reject и нет действительного согласованного DKIM, получатель может отклонить письмо. Отказ SMTP может привести к уведомлению о недоставке: это не всегда исчезновение без предупреждения.
| Шаг | Действие | Отправитель конверта | IP соединения | Результат SPF в примере |
|---|---|---|---|---|
| 1 | Alice → ваш сервер | alice@bank.com | IP банка | PASS |
| 2 | Ваш сервер → Gmail | alice@bank.com | IP вашего сервера | FAIL: не разрешён для bank.com |
Проблема возможна даже при правильно настроенном правиле: она зависит от того, разрешено ли новому серверу отправлять почту от имени домена отправителя конверта. Не каждая пересылка неизбежно сталкивается с ней. SRS позволяет адаптировать этот идентификатор к новому соединению.
Как SRS заменяет отправителя конверта
SRS меняет адрес MAIL FROM на адрес домена пересылающего сервера до нового SMTP-соединения. Видимый заголовок From: остаётся таким, каким его указал исходный отправитель. Следующий пример предполагает, что новый домен правильно разрешает сервер:
# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)
# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)Получатель проверяет SPF домена your-domain.com, который должен разрешать сервер. Тогда SPF может пройти. Пользователь по-прежнему видит From: alice@bank.com. SRS меняет идентификатор, проверяемый SPF, но согласование его домена с исходным From нужно оценить отдельно.
Как устроен адрес SRS
Адрес SRS в Return-Path может выглядеть непривычно, но каждый сегмент выполняет свою задачу. Понимание формата помогает проверить замену и разобраться в проблеме вместе с журналами и результатами аутентификации.
Пример: SRS0=4fac=PM=bank.com=alice@your-domain.com
| Компонент | Значение | Назначение |
|---|---|---|
| Префикс | SRS0 | Метка первой замены. SRS1 может использоваться при второй пересылке, ограничивая рост адреса, но не гарантируя неограниченную цепочку. |
| Код аутентификации | 4fac | Пример HMAC с секретом сервера. Помогает проверять адреса возврата SRS и снижать риск подделки, но не устраняет все угрозы. |
| Временная метка | PM | Пример циклической метки в base32. Ограничение срока действия снижает некоторые злоупотребления повторно используемыми адресами; формат и срок зависят от реализации. |
| Источник | bank.com=alice | Данные исходного отправителя для направления уведомлений о недоставке на alice@bank.com. |
Вторая проблема: согласование SPF после SRS
SRS может обеспечить успешную проверку SPF, не сохранив согласование с исходным From. DMARC требует успешной проверки и согласования хотя бы по одному механизму, SPF или DKIM. Поэтому правильной настройки SRS недостаточно, чтобы гарантировать прохождение DMARC.
DMARC требует, чтобы хотя бы один аутентифицированный домен был согласован с доменом видимого заголовка From:. В примере с SRS:
- Проверка SPF: PASS: ваш IP разрешён доменом конверта
your-domain.com - Согласование SPF: FAIL: конверт
your-domain.com≠ заголовокbank.com
В такой ситуации DMARC может зависеть от DKIM. Исходная действительная согласованная подпись может сохраниться, если подписанные части не меняются так, что это нарушает проверку с учётом каноникализации. Добавление предупреждений «внешнее письмо», уведомлений антивируса внизу или преобразование MIME с 8 бит на 7 бит может нарушить подпись, если затронуто подписанное содержимое.
Если SPF не согласован, а изменения нарушили согласованный DKIM, DMARC не проходит. Получатель может отклонить письмо по своей политике, даже если SRS правильно заменил адрес. Это не означает потерю всей пересылаемой почты.
ARC как дополнение к SRS
ARC (Authenticated Received Chain, RFC 8617) может дополнить SRS. SRS адаптирует конверт для SPF, а ARC позволяет заверить подписью реально наблюдавшиеся результаты аутентификации и передать их следующему получателю. ARC не удостоверяет отсутствие спама и не гарантирует приём.
ARC добавляет ARC-Authentication-Results, ARC-Message-Signature и ARC-Seal. Предыдущие результаты могут дать контекст, если DKIM позже не проходит, но подпись ARC самого сообщения тоже может пострадать от дальнейших изменений подписанных частей. Не все компоненты ARC выдерживают любое изменение тела.
Ограничение: получатель решает, доверять ли подписывающему серверу и цепочке. В поддерживаемом окружении Microsoft 365 уполномоченный администратор может настроить доверенные серверы ARC через PowerShell (Set-ArcConfig), когда это применимо и они ещё не включены. Настройка должна соответствовать политике организации. Gmail определяет доверие по своим критериям: навязать его вручную нельзя.
В рабочей системе оцените SRS для SPF и ARC как дополнительный контекст, если DKIM не сохраняется. Они не являются универсально обязательными для каждой доставки и вместе не гарантируют приём всеми провайдерами. Также важны DNS, фильтрация, политики и репутация.
Диагностика SRS: список проверок
Если пересылаемые письма не приходят, этот список поможет отличить проблему SRS от предварительной блокировки или других причин.
1. Проверьте Return-Path
Отправьте тестовое письмо с внешней учётной записи через пересылающий сервер и изучите исходные заголовки в месте назначения. Ниже показаны примеры неразрешённого IP до SRS и разрешённого после; проверьте фактический результат своего маршрута.
# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)
# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)2. Проверьте исходящие блокировки Microsoft 365
Если вы пересылаете из Microsoft 365 и возникает следующая блокировка политики, письмо может остановиться ещё до выхода из окружения. SRS не снимает это ограничение.
550 5.7.520 Access denied, Your organization does not allow external forwarding.Уполномоченный администратор должен проверить исходящую антиспам-политику в портале Defender и решить, разрешён ли маршрут. Не отключайте меры защиты для обхода политики. SRS на принимающем сервере эту блокировку не устраняет.
3. Проверьте петли маршрутизации
Если A пересылает B, а B пересылает обратно A, петля возможна, когда правила допускают повторение маршрута и защита не останавливает его раньше. Ищите в журналах такие сообщения:
554 5.4.14 Hop count exceeded
5.4.6 Routing loop detectedОткажитесь от пересылки и используйте настоящие ящики
Настройка postsrsd, управление секретами HMAC и устранение ошибок согласования DMARC могут добавлять работы при направлении деловой почты в личные ящики ради экономии на оплате за ящик. SRS решает часть проблемы, созданной новым переходом. Настоящий ящик может устранить этот маршрут, если подходит вашим задачам.
| Подход с пересылкой | Альтернатива TrekMail с учётом плана |
|---|---|
| Пересылать sales@ в Gmail и разбирать ошибки SRS | Разместить sales@ как настоящий IMAP-ящик с прямой доставкой |
| Настраивать SRS, ARC и секреты HMAC на каждом сервере | Без этого перехода пересылки SRS для маршрута не нужен |
| Недействительный DKIM может нарушить DMARC, если SPF не согласован | Без пересылки исключается этот источник изменений; аутентификацию всё равно нужно проверять |
| Отсутствующие письма без видимой информации о доставке | Журналы и отслеживание сообщений, когда их поддерживают план и конфигурация |
Вместо пересылки contact@client-domain.com в Gmail и обслуживания SRS можно разместить contact@client-domain.com как IMAP-ящик на TrekMail. Используйте совместимый клиент, включая поддерживаемую интеграцию приложения Gmail: письмо доставляется в ящик без этого нового перехода. Это снижает проблемы пересылки, но не гарантирует сквозную аутентификацию или попадание во входящие. Сравните варианты в руководстве по пересылке доменной почты в Gmail или сравнении алиаса и почтового ящика.
Управляете несколькими клиентскими доменами? Централизация их ящиков на TrekMail может уменьшить работу по поддержке SRS на разных серверах. Разделение ящиков требует правильных разрешений и настройки, но не гарантирует безопасность или фиксированный срок создания. Руководство по почтовому хостингу нескольких доменов объясняет организацию управления с учётом лимитов плана.
Описанное предложение TrekMail начинается от $3.50 в месяц и включает бесплатный пробный период на 14 дней. Проверьте текущие цены, условия и функции плана, прежде чем создавать настоящие ящики и заменять маршруты пересылки, которые больше не нужны.
