SRS для пересылки почты: сохраняем SPF и репутацию домена

Если вы администрируете почту и используете пересылку (alias/forward), рано или поздно столкнетесь с тем, что SPF при форвардинге ломается. От этого страдает deliverability: письма уходят в спам или отскакивают. Решение — Sender Rewriting Scheme (SRS). Он переписывает конвертный отправительский адрес так, чтобы пересылка не разрушала проверку SPF и не била по репутации домена.

Почему SPF ломается при пересылке

SPF проверяет, имеет ли право IP-сервер, который доставляет письмо, отправлять почту от имени домена в поле MAIL FROM (конвертный отправитель, не путать с заголовком From:). Когда письмо пересылается через ваш сервер, получатель видит исходный домен отправителя, но SMTP-сеанс идет уже с IP вашего узла. И если у исходного домена нет вашего IP в SPF-записи, SPF у получателя провалится. Это «ложный» фейл, но антиспам-системы учитывают его как сигнал риска, особенно в сочетании с другими факторами.

Попытка «ничего не трогать» выглядит привлекательно, но на практике приводит к проблемам при массовом форвардинге с корпоративных доменов, где политики строго настроены. Именно тут и нужен SRS, чтобы «переназначить» ответственность за доставку на пересылающий хост, сохранив возможность обратной доставки бонсов (NDR) оригинальному отправителю.

Как работает Sender Rewriting Scheme

SRS переписывает только конвертный адрес MAIL FROM (а также обратный путь Return-Path в доставленном письме), не трогая видимый получателю заголовок From:. Получатель видит письмо «от» прежнего отправителя, но в SMTP-потоке MAIL FROM становится адресом с вашим доменом. Так SPF проверяется уже на ваш домен и ваш IP, и проверка проходит, если ваш SPF корректен. При этом SRS кодирует внутри переписанного адреса оригинального отправителя, хеш-подпись и метку времени, чтобы возможно было вернуть бонс обратно первоначальному отправителю и не допустить подделок.

SRS0 и SRS1: что внутри адреса

Чаще всего вы увидите два формата: SRS0 и SRS1. Первый — при первичном переписывании, второй — при повторной пересылке через еще один хост с SRS. Адрес вида SRS0=TTT=HASH=orig.com=local@relay.example показывает, что на домене relay.example хранился секрет, посчитан хеш по полям, а TTT — таймштамп жизни. Это не просто «замена домена» — это криптографически подписанный алиас для возвращаемых сообщений и бонсов.

MAIL FROM против заголовка From:

Критично не путать: для прохождения SPF переписывается именно конвертный MAIL FROM. Заголовок From: отвечает за отображение для пользователя и участвует в DMARC-выравнивании. SRS не должен менять From:, иначе вы вмешаетесь в пользовательский опыт и рискуете разрушить DKIM-подпись исходного домена.

Итог: SRS чинит SPF на форварде, не затрагивая From:, а значит не ломает пользовательскую видимость и не конфликтует с DKIM.

Где SRS обязателен

Практически обязательно включать SRS, если:

• на сервере есть алиасы и пользовательские пересылки на внешние ящики (особенно на крупные почтовые сервисы);
• в домене-реципиенте действует строгая DMARC-политика, и вы ничего не должны менять в теле или заголовках письма;
• работают центральные «почтовые шлюзы», пересылающие поток в разные внешние ящики;
• используются автоматические правила, которые массово перенаправляют письма между доменами.

И наоборот, для локальной доставки внутри одного домена и без внешней пересылки SRS не нужен.

Внедрение SRS в Postfix

Самый распространенный путь — демон postsrsd. Он легкий, быстрый и интегрируется через каноникал-мэппинги Postfix. Идея проста: на исходящем трафике переписать конвертный отправитель (SRS forward), а на входящем — уметь «распаковать» адрес SRS назад, если прилетит бонс (SRS reverse).

Установка

На Debian/Ubuntu:

apt update
apt install postsrsd
systemctl enable --now postsrsd

На RHEL/AlmaLinux/Rocky:

dnf install postsrsd
systemctl enable --now postsrsd

Базовая конфигурация postsrsd

Типично конфигурация хранится в /etc/default/postsrsd или /etc/sysconfig/postsrsd (зависит от дистрибутива). Важно задать домен, секреты и TTL.

# /etc/default/postsrsd
SRS_DOMAIN=relay.example
SRS_SECRET="secret1;secret2"
SRS_FORWARD_PORT=10001
SRS_REVERSE_PORT=10002
SRS_EXCLUDE_DOMAINS="relay.example,localdomain"
SRS_HASHLENGTH=4
SRS_TTL=21
SRS_ALG=HMACSHA256

Секреты допускают ротацию по списку через точку с запятой: сначала используется первый для подписи, остальные — для проверки старых адресов до истечения TTL. Значение TTL в днях определяет «время жизни» переписанного адреса для корректной обработки отложенных бонсов.

Интеграция с Postfix

Подключаем postsrsd как источник каноникал-мэппингов для конверта. Важно ограничить переписывание только конвертного отправителя, не заголовков.

# /etc/postfix/main.cf
compatibility_level = 3.6
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:127.0.0.1:10001
recipient_canonical_classes = envelope_recipient
recipient_canonical_maps = tcp:127.0.0.1:10002
local_header_rewrite_clients =

# Рекомендуется: корректный HELO, PTR и SPF вашего домена
myhostname = mx.relay.example
smtp_helo_name = mx.relay.example

После изменений перезапустите Postfix и проверьте, что postsrsd слушает нужные порты, а Postfix успешно коннектится к tcp:127.0.0.1:10001 и 10002.

postfix reload
systemctl restart postsrsd
ss -lntp | grep -E "10001|10002"
postfix check

Если под форвард поднимаете отдельный шлюз, удобнее держать его на изолированном сервере. Для этого подойдет VDS с контролируемыми IP и PTR.

Исключения и локальные домены

Чтобы не переписывать адреса для «своих» доменов или доверенных направлений, используйте настройки SRS_EXCLUDE_DOMAINS в postsrsd. Это убережет от бессмысленного SRS для локальной доставки и поможет избежать путаницы с обратной маршрутизацией.

Оппортунистический и принудительный режим

Классический SRS — фактически принудительный для любого письма, покидающего ваш сервер через пересылку. Оппортунистический подход — применять SRS только если адрес не относится к вашим доменам и если письмо действительно пересылается (а не отправлено вашим пользователем). Этого обычно достаточно: исходящие письма ваших пользователей уже проходят SPF от вашего домена, а вот форварды от внешних доменов требуют SRS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проверка и диагностика

Начните с отправки тестового письма на внешний ящик через форвард и убедитесь, что на стороне получателя SPF для домена вашего пересылающего сервера проходит. В логе Postfix ищите переписывание обратного пути.

tail -f /var/log/mail.log

Вы должны увидеть, что Return-Path в доставленном письме стал вида SRS0=... на вашем домене, а заголовок From: остался прежним. Для генерации тестов удобно использовать swaks.

swaks --to external@example.net --from sender@orig.example --server 127.0.0.1
swaks --to bounce@test.invalid --from sender@orig.example --server 127.0.0.1 --quit-after RCPT

Во втором примере можно имитировать отказ и посмотреть, как бонс приходит обратно в ваш MTA с адресом SRS0 и корректно «разворачивается» в оригинального отправителя через reverse-порт 10002.

Взаимодействие SRS с DKIM, DMARC и ARC

Главная мысль: SRS меняет конвертный адрес, а DKIM подписывает содержимое и заголовки. Если ваш пересылающий сервер не модифицирует письмо (не добавляет футер, не меняет Subject), DKIM-подпись исходного домена сохранится, и у получателя DMARC пройдет по пути «DKIM-aligned pass». В таком сценарии SRS гарантирует «SPF-aligned pass» уже для вашего домена, но это и не требуется для DMARC, достаточно пройти одно из условий (SPF или DKIM) с выравниванием по From:.

Если же вы модифицируете письмо на пересылке, DKIM исходного домена чаще всего сломается. Тогда DMARC будет зависеть от SPF-выравнивания: SPF после SRS пройдет для вашего домена, но DMARC в таком случае проверяет выравнивание домена From: с доменом, прошедшим SPF. Они различаются — поэтому DMARC упадет. Чтобы смягчить это, применяют ARC: он позволяет заверять факт проверки исходного DKIM/DMARC на предыдущем хопе и передавать эту информацию дальше. SRS не конфликтует с ARC, и оба механизма решают разные задачи. Подробная практика по ARC и форвардам — в материале ARC на форварде с Postfix и Rspamd.

Rspamd и SRS: практические заметки

Если у вас Rspamd на исходящем потоке подписывает DKIM вашего домена, это не заменяет SRS. Подпись DKIM вашего домена не выровняет DMARC, потому что заголовок From: останется у исходного домена. Используйте DKIM-sign на исходящей почте, которую отправляют ваши пользователи, а на форвардах сохраняйте письмо «как есть». SRS в таком случае даст SPF pass на ваш домен, а DMARC пройдет за счет DKIM исходного домена. Важно настроить правила Rspamd так, чтобы не модифицировать тело/заголовки форвардов, если это не требуется политикой.

Отдельно проверьте счета правил, которые штрафуют SRS-адреса. Современные версии Rspamd корректно распознают SRS и не penalize такие адреса, но в кастомных правилах стоит исключить срабатывания на префиксы SRS0/SRS1, если они ошибочно добавляют балл.

Безопасность: секреты, TTL и повторная маршрутизация

Безопасность SRS держится на секрете, которым подписываются адреса. Рекомендации:

• Храните секреты вне репозитория, меняйте их по расписанию (ротация);
• Используйте несколько секретов: текущий для подписи, один‑два предыдущих для проверки до истечения TTL;
• TTL не делайте слишком коротким: отложенные бонсы могут идти неделями;
• Ограничьте доступ к порту reverse (10002) локальным интерфейсом;
• Логи SRS и Postfix отправляйте в централизованный сбор, чтобы видеть аномалии (шипы бонсов, циклы).

Типичные ошибки и ловушки

Несколько нюансов, которые портят deliverability:

• Переписывание заголовка From:. Это ломает DKIM и DMARC исходного домена, создавая лишние проблемы. SRS трогает только конвертный адрес.
• Отсутствие reverse SRS. Если не настроен разбор входящих SRS-адресов, бонсы потеряются или попадут в циклы.
• Неправильный порядок мэппингов. Убедитесь, что sender_canonical_maps вызывается для исходящих форвардов, а не конфликтует с другими преобразованиями (например, canonical_maps для заголовков).
• Игнорирование VERP. При массовых рассылках обратные пути уже закодированы. SRS совместим, но важно тестировать, чтобы верно возвращались бонсы.
• Слишком агрессивный контент-фильтр на форварде. Любая модификация тела ломает DKIM исходного домена, что делает DMARC зависимым от SPF-выравнивания и часто приводит к фейлам.

Чек-лист внедрения

1. Обновите MTA и антиспам-стек до актуальных версий.
2. Установите и запустите postsrsd, задайте домен, секреты, TTL, исключения.
3. Подключите sender_canonical_maps и recipient_canonical_maps к postsrsd, ограничьте переписывание конвертом.
4. Проверьте свой SPF: включите ваши исходящие IP и релей.
5. Прогоните тесты пересылки и бонсов, изучите логи.
6. Сверьте правила Rspamd: не ломайте DKIM на форварде без необходимости.
7. Настройте мониторинг доли бонсов и спам-скоринга по доменам.
8. Задокументируйте процедуру ротации SRS-секретов.

Практика deliverability: что еще важно

SRS решает именно проблему SPF при пересылке. Но общая доставляемость опирается на комплекс мер: корректный PTR для вашего IP, валидный HELO, TLS на входе/выходе, аккуратная политика ретраев, DKIM-подписи исходящей почты вашего домена, DMARC-репорты и их регулярный разбор, аккуратный rate limit. Про базовые настройки PTR/SPF и HELO читайте в «гайде по SPF/PTR для Postfix», а про анализ DMARC-отчетов — в «разборе DMARC-репортов».

Если используете отдельный домен под шлюз/форвардинг, заранее подготовьте его DNS и SPF. При необходимости оформите новый домен через регистрацию доменов и держите зону под контролем.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

FAQ

Нужен ли SRS, если у меня нет пересылок?

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

Сломается ли DMARC из‑за SRS?

Сам по себе SRS DMARC не ломает: он меняет MAIL FROM, а DMARC выравнивает домен From: с DKIM или SPF. На чистой пересылке DMARC обычно проходит по DKIM исходного домена. Если на форварде меняете письмо — подумайте об ARC.

Что если письма приходят с пустым конвертом (MAIL FROM:<>)?

Это нормальные бонсы. Такие сообщения SRS не переписывает, пустой обратный путь обязан оставаться пустым. Обрабатывайте их штатно.

Как часто ротировать SRS-секреты?

Минимум раз в 3–6 месяцев, с перекрывающимся окном проверки старых секретов не меньше значения TTL. Храните секреты отдельно от конфигураций и бэкапьте безопасно.

Можно ли заменить SRS на «SPF include» исходного домена?

Нет. Вы не контролируете чужие SPF, и их политика может запрещать включение сторонних IP. SRS — стандартный и совместимый способ легитимировать форвард.

Итоги

SRS — необходимый элемент любой инфраструктуры, где есть пересылка писем на внешние домены. Он сохраняет SPF и предотвращает ложные фейлы, защищая репутацию и повышая deliverability. В связке с аккуратной настройкой DKIM, DMARC, ARC и Rspamd вы получаете предсказуемую доставку и понятную диагностику. Настройка проста: postsrsd, два каноникал-мэппинга в Postfix, секреты и мониторинг — и ваши форварды перестают быть проблемой.