Вы настроили пересылку и проверили её: всё работает. Через две недели письмо клиента с договором не приходит. В спаме его нет, уведомления о недоставке вы не видите. В журналах обнаруживается: 550 5.7.1 Unauthenticated email from domain.com.
Одна из возможных причин: отсутствующий или неправильно настроенный механизм перезаписи адреса отправителя (SRS), хотя этот код не указывает на единственную причину. Аутентификация проверяет, разрешено ли серверу отправлять почту от имени домена отправителя конверта. Пересылка может нарушить эту связь. SRS адаптирует отправителя конверта к новой передаче, но в 2026 он не решает все проблемы самостоятельно: понимать ограничения не менее важно, чем знать принцип работы.
В статье рассмотрены назначение SRS, возможные сбои и компоненты работающей системы пересылки. Если вы также разбираетесь с более общими причинами недоставки, например неверными MX, настройками catch-all или изменениями DNS, нарушившими маршруты, начните с руководства по настройке пересылки почты и устранению сбоев.
Почему SPF может не пройти при пересылке
Если пересылающий сервер отправляет со своего IP, но сохраняет исходный домен в отправителе конверта, SPF может не пройти, когда этот домен не разрешает такой IP. При DMARC p=reject получатель может отклонить письмо, если нет и действительной согласованной подписи DKIM. Это не всегда происходит без уведомлений: передающий сервер может получить ошибку SMTP и сформировать уведомление о недоставке.
Почта идёт не по одному непрерывному каналу, а по цепочке SMTP-соединений с новым установлением TCP-соединения на каждом переходе. Вот пример возможного сбоя:
alice@client.comотправляет письмо наcontact@your-agency.com- Ваш сервер принимает его: передающий IP разрешён в SPF домена
client.com - Ваш сервер открывает новое SMTP-соединение с Gmail для пересылки
- Gmail видит соединение с вашего IP
- Отправителем конверта всё ещё указан
alice@client.com - Gmail проверяет SPF домена
client.com: в этом примере ваш IP не разрешён - SPF не проходит. Если
client.comпубликуетp=rejectи нет действительного согласованного DKIM, Gmail может отклонить письмо
RFC 7208, спецификация SPF, признаёт трудности, которые пересылка создаёт для этой проверки. Замена отправителя конверта позволяет проверять домен пересылающего сервера, не требуя от каждого исходного отправителя разрешать его IP.
Два уровня идентификации: конверт и заголовок
У письма есть два уровня идентификации отправителя. Отправитель конверта (RFC 5321, MAIL FROM, P1) используется для SPF и маршрутизации уведомлений о недоставке; его также можно увидеть в Return-Path при просмотре исходных заголовков. From в заголовке (RFC 5322, P2) показывает почтовый клиент, например Gmail или Outlook. SRS адаптирует идентификатор в конверте к новой отправке, но не обязательно согласует его домен с видимым From.
| Уровень | Техническое название | RFC | Назначение | Кто видит |
|---|---|---|---|---|
| Отправитель конверта | MAIL FROM / Return-Path | RFC 5321 (P1) | Проверка SPF и маршрутизация уведомлений о недоставке | Серверы и пользователи, просматривающие исходные заголовки |
| From в заголовке | Заголовок From: | RFC 5322 (P2) | Отправитель, отображаемый почтовым клиентом | Конечные пользователи |
При пересылке From в заголовке остаётся alice@client.com. Ваш сервер создаёт новую SMTP-транзакцию, и SPF проверяет отправителя конверта на этом переходе. Проблема возникает, если новый IP не разрешён; когда SRS меняет домен конверта, его согласование с From нужно оценивать отдельно.
Что именно делает SRS
SRS заменяет адрес отправителя конверта (P1) перед открытием нового SMTP-соединения. Видимый From остаётся прежним. Домен, разрешающий пересылающий сервер, может обеспечить успешную проверку SPF, но не гарантирует её результат или доставку. Такая замена также не устанавливает сама по себе согласование DMARC с исходным отправителем.
Аналогия с обычной почтой: вы получаете письмо Alice и отправляете его дальше в новом мешке, оставив её обратный адрес. Получатель видит, что вы доставляете письмо с адресом Alice, и может усомниться в полномочиях отправителя. С SRS вы заменяете обратный адрес своим: он соответствует новой отправке. Если мешок возвращается, он приходит к вам, после чего вы можете направить возврат Alice.
| Компонент | До пересылки | После замены через SRS |
|---|---|---|
| From в заголовке (P2) | alice@client.com | alice@client.com (без изменений) |
| Отправитель конверта (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| Отправляющий IP | Ваш сервер | Ваш сервер |
| Результат SPF в этом примере с правильной авторизацией | FAIL | PASS |
Как устроен адрес SRS
SRS преобразует отправителя конверта в закодированный адрес до перехода пересылки. Получатель проверяет домен пересылающего сервера. В адресе содержатся код аутентификации для проверки возвратов, временная метка для ограничения срока действия и исходный адрес для направления уведомлений отправителю. Это структурированные данные, а не случайные символы.
Пример адреса после замены через SRS:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: первый переход.
SRS1может появиться при дальнейшей пересылке и помогает ограничить рост адреса, но не гарантирует неограниченную длину цепочки - 4fac: пример кода HMAC-SHA1 в одной реализации. Он проверяет входящие уведомления о недоставке; отклонение неверных кодов помогает снизить злоупотребления незапрошенными возвратами. Алгоритм и длина зависят от реализации
- PM: временная метка. Срок от 7 до 21 дня приведён как пример, а не универсальное правило; отклонение просроченных адресов снижает некоторые риски повторного использования, но не устраняет их полностью
- client.com=alice: закодированный исходный отправитель для направления уведомлений о недоставке на правильный адрес
Когда нужен SRS
SRS полезен при пересылке между доменами, если IP пересылающего сервера не разрешён в SPF исходного отправителя. Без него SPF может не пройти, хотя согласованный DKIM ещё способен обеспечить успешный DMARC. Инфраструктуре с несколькими доменами нужны проверка этих условий и наблюдение за пересылаемой почтой.
Собственный домен и личный Gmail. Вы владеете cool-startup.com и пересылаете всю почту на founder@gmail.com. SRS может быть важен для SPF на этом маршруте. Без него SPF может не пройти, если исходный отправитель не разрешает пересылающий сервер; строгая политика DMARC не означает автоматическое отклонение, когда сохраняется действительный согласованный DKIM.
MSP или агентство с общим почтовым кластером. Вы размещаете 200 клиентских доменов, пользователи которых настраивают пересылку своим провайдерам, например Comcast, AT&T или Outlook. Пересылка спама может ухудшить репутацию IP и способствовать попаданию в списки вроде Spamhaus. Это не неизбежно и не обязательно происходит за несколько недель; SRS не заменяет фильтрацию и не гарантирует хорошую репутацию.
Microsoft 365 с исходящим коннектором. В M365 поведение SRS зависит от маршрута и настроек. Если вы используете коннектор, проверьте в документации его версии и типа, поддерживается ли SenderRewritingEnabled и как он применяется. Также проверьте исходящую антиспам-политику и блокировку внешней пересылки 5.7.520: это ограничение политики, а не доказательство отказа SRS. Любое изменение должно быть разрешено организацией.
Почему одного SRS недостаточно
SRS может обеспечить успешный SPF для домена пересылающего сервера, но это не то же самое, что согласование DMARC. DMARC требует согласования с видимым From хотя бы одного домена, аутентифицированного через SPF или DKIM. Если SRS использует другой домен, SPF не согласован; тогда DMARC может зависеть от сохранения действительной согласованной подписи DKIM.
Следующие изменения могут нарушить DKIM, если затрагивают подписанные части и меняют результат с учётом каноникализации подписи:
- Добавление
[EXTERNAL]в тему может нарушить DKIM, если этот заголовок подписан - Добавление текста внизу письма, например уведомления антивируса или ссылки для отписки, может изменить содержимое, покрываемое хешем тела
- Преобразование MIME, например смена кодирования с 8 бит на 7 бит, может изменить подписанное содержимое
Если SPF не согласован, а изменения нарушили согласованный DKIM, DMARC не проходит. Получатель применяет свою политику, которая может включать отклонение с последующим уведомлением отправителя или без него.
ARC (Authenticated Received Chain, RFC 8617) может передать получателю контекст аутентификации, не исправляя согласование. Пересылающий сервер заверяет подписью наблюдавшиеся результаты перед дальнейшей передачей. Добавляются три заголовка:
ARC-Authentication-Results: фиксирует реально наблюдавшиеся результаты SPF, DKIM и DMARC, не предполагая их успехARC-Message-Signature: подписывает части письма в состоянии на момент создания подписи, не обязательно в исходном состоянии при полученииARC-Seal: криптографическая подпись, связывающая этот экземпляр с цепочкой ARC
Получатель вроде Gmail может оценить ARC при отказе аутентификации пересланного письма. Если он доверяет подписывающему серверу и цепочке, он может сделать исключение из обычной обработки DMARC. Решение остаётся за получателем: репутация может влиять на него, но не гарантирует доверия или приёма.
Как проверить работу SRS
Отправьте письмо с внешней учётной записи на пересылаемый адрес и изучите исходные заголовки у получателя. Return-Path показывает, видна ли замена SRS или сохранён исходный адрес. Также проверьте результаты аутентификации: комментарии следующего примера сами по себе не диагностируют SPF.
Шаг 1: проверьте Return-Path у получателя
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>Шаг 2: проверьте DNS домена SRS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comДомену SRS нужны рабочий маршрут возврата и SPF, разрешающий сервер. Явный MX обычен, но его отсутствие не всегда означает недоступность домена: SMTP может использовать A или AAAA через механизм неявного MX. Проверьте фактический приём уведомлений о недоставке, а не только наличие записи.
Шаг 3: проверьте почтовый журнал в Linux
grep "srs_forward" /var/log/mail.logСообщения hash mismatch или timestamp expired могут возникать из-за рассинхронизации или ротации секретов, повреждённых адресов либо запоздалых возвратов; они не доказывают злонамеренное повторное использование. Для Postfix обычно нужна внешняя интеграция SRS; PostSRSd является одним из вариантов. Проверьте совместимую с вашей версией конфигурацию, включая SRS_EXCLUDE_DOMAINS, когда этот параметр применим, и локальные маршруты, чтобы избежать ненужной замены адресов или возможных петель.
Более простая альтернатива: отказаться от пересылки
SRS адаптирует конверт к новой SMTP-доставке. Настоящий ящик на своём домене и доступ по IMAP устраняют этот переход пересылки и снижают связанные с ним проблемы. Они не гарантируют сквозную аутентификацию и не устраняют все риски: входящая доставка и контроль доступа по-прежнему важны.
Пересылка популярна и по экономическим причинам: никто не хочет платить за пользователя ради ящика, получающего пять писем в месяц. SRS может обслуживать архитектуру, выбранную из-за цены, а не только технических потребностей.
Описанная здесь модель TrekMail предлагает планы от $3.50 в месяц, несколько доменов и общий пул хранения по фиксированной цене, без оплаты за пользователя в пределах плана. Можно использовать sales@yourdomain.com как настоящий IMAP-ящик в совместимом клиенте, например Outlook или поддерживаемой интеграции приложения Gmail, и убрать этот маршрут пересылки. Проверьте актуальные функции и условия: отсутствие такого перехода не гарантирует отсутствие ошибок аутентификации.
Для нескольких клиентов руководство по почтовому хостингу нескольких доменов объясняет организацию и управление множеством доменов. Если вы сохраняете гибридную схему с ящиками и старыми пересылками, руководство по алиасам и пересылке почты рассматривает настройку с SRS на маршруте.
Сохраняете ли вы пересылку или переходите на ящики, разберитесь в назначении SRS, проверьте его работу и оцените ARC с учётом получателя. Неполная настройка может препятствовать доставке легитимной почты: это риск для бизнеса, а не просто техническая тонкость.
Начните с бесплатной учётной записи TrekMail, без карты и окончания пробного периода в описанных условиях, и проверьте актуальные функции и лимиты для работы с несколькими доменами без этой сложности пересылки.
