Пересылка почты домена: диагностика с SRS и ARC

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

Без подходящей настройки аутентификации пересылка может приводить к попаданию в спам или отказам Gmail, отказам 550 у Yahoo и блокировкам политиками Microsoft 365. Отсутствие письма само по себе не показывает, на каком участке возникла проблема.

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

Почему пересылка почты домена может нарушать SPF

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

Типичная последовательность сбоя:

1. alice@bank.com отправляет письмо на info@yourdomain.com. SPF банка разрешает его собственные почтовые серверы.
2. Ваш сервер пересылает письмо на you@gmail.com. Gmail видит IP вашего сервера, но Return-Path по-прежнему указывает bank.com.
3. Ваш IP отсутствует в SPF домена bank.com. Поэтому проверка SPF может завершиться ошибкой.
4. Если сервер изменил подписанные данные, например добавил подпись сканера или метку темы, DKIM тоже может не пройти. Без согласованного SPF или DKIM проверка DMARC не проходит; дальнейшее действие зависит от политики получателя.

Уведомление о недоставке может уйти исходному отправителю или отразиться в журналах. В целевом ящике вы можете его не увидеть.

Пересылка через catch-all может усугубить ситуацию: весь пересылаемый спам связывается с вашим IP. Это способно ухудшить его репутацию у Gmail, привести к попаданию обычных писем в спам или отказам. Такой результат не неизбежен для каждого письма.

Прежде чем выбирать эту архитектуру, ознакомьтесь с преимуществами и ограничениями пересылки через почтовые алиасы.

3 подхода к безопасной пересылке почты домена

Эти три подхода решают разные задачи. Нужная комбинация зависит от маршрута и принимающей системы; все три не обязательны в каждом случае. В частности, сохраненная действительная DKIM-подпись с согласованием домена может обеспечить успешный DMARC даже после пересылки.

1. Sender Rewriting Scheme (SRS)

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

До SRS:

MAIL FROM: <alice@bank.com>

После SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

Ограничение: SRS может исправить SPF конверта, но не обеспечивает согласование с исходным доменом From для DMARC. DMARC по-прежнему может пройти через сохраненный согласованный DKIM. Если и он не проходит, SRS сам по себе не заменяет согласованную аутентификацию.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617) защищает историю результатов аутентификации при прохождении промежуточных узлов. Сервер пересылки добавляет три заголовка, криптографически защищающих его наблюдения и состояние письма. Это не гарантирует истинность всех утверждений или доверие принимающей стороны.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google и Microsoft могут учитывать ARC от доверенных промежуточных систем. Даже при ошибке DMARC на последнем участке такая история может повлиять на локальное решение о доставке. Действительная цепочка ARC не обязывает получателя принять письмо.

Ограничение: доверие определяется получателем. Новый домен подписи или IP не получает его автоматически; хорошая репутация также не гарантирует доверия к ARC.

3. Пересылка без изменения содержимого: сохранение DKIM

Даже без SRS или ARC важно сохранять исходные DKIM-подписи. Не добавляйте подписи в текст, не переписывайте тему и избегайте изменений содержимого сканерами. DKIM подписывает канонизированный текст и выбранные заголовки. Изменение подписанных данных может нарушить подпись, но не каждое изменение байта приводит к этому. В зависимости от режима канонизации некоторые изменения пробельных символов не влияют на проверку; неподписанные заголовки непосредственно не защищены этой подписью.

Особенно сложны сбои из-за изменения письма. Например, сканер добавляет в текст уведомление о проверке MailGuard. В журнале отправки явной ошибки может не быть. Значение dkim=fail (body hash did not verify) в Authentication-Results у получателя может указывать на изменение подписанного текста, если письмо доступно для анализа.

Пересылка без изменения содержимого помогает, когда действительная DKIM-подпись с согласованным доменом сохраняется на всем пути. Если SPF на новом участке не проходит и DKIM тоже становится недействительным, согласованной аутентификации для DMARC не остается. ARC и локальная политика получателя могут учитываться отдельно.

Как крупные провайдеры обрабатывают сбои пересылки

Microsoft, Google и Yahoo по-разному учитывают аутентификацию, репутацию и политики пересылки. Microsoft может блокировать исходящую автоматическую пересылку политикой; Gmail может менять размещение писем, а Yahoo, например, отклонять их с кодом 550. Начальная точка диагностики определяется полным текстом ошибки и узлом, на котором она возникла.

Microsoft 365 (Exchange Online)

Исходящая антиспам-политика Defender может запрещать автоматическую внешнюю пересылку на уровне организации. В таком случае отправка прекращается до оценки внешним получателем. Проверьте эффективную политику конкретного ящика.

Уведомление с 5.7.520 может получить исходный отправитель, а не целевой ящик. Используйте трассировку сообщений и полный текст уведомления: отсутствие письма не подтверждает конкретную причину.

Google Workspace / Gmail

Явный отказ может выглядеть так: 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. При p=reject он возможен, если нет согласованной аутентификации. Сохраненный согласованный DKIM может обеспечить DMARC после пересылки; SRS сам по себе согласование не восстанавливает.

Другой риск связан с репутацией. Спам из catch-all может за дни или недели ухудшить оценку IP пересылки. Обычные письма могут попадать в спам или отклоняться. Универсального кода ошибки и неизбежной бесшумной потери здесь нет.

Yahoo / AOL

Пересылка на Yahoo с недостаточной аутентификацией может вызвать отказ 550. Метки темы [FWD] или [External] способны нарушить DKIM, если тема подписана. При одновременном сбое согласованного SPF риск DMARC возрастает. Это не означает гарантированный отказ для 100% таких писем: сохраненные подписи и политика получателя остаются важны.

Проверка для диагностики пересылки

При сбое пересылки почты домена пройдите эти шаги, прежде чем менять настройки:

1. Прочитайте Authentication-Results в целевом ящике: «Показать оригинал» в Gmail или исходный текст письма в Outlook.

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → проверьте домен конверта, отправляющий IP и настройку SRS.
   dkim=fail (body hash) → проверьте подписанный текст и изменения в пути.
   Обе ошибки → проверьте согласование, другие DKIM-подписи, ARC и политику получателя; отказ не гарантирован только этими значениями.
2. Проверьте петли маршрутизации. 5.4.14 Hop count exceeded означает превышение лимита переходов, часто из-за обратной пересылки. Нарисуйте всю цепочку: A→B→C→A является типичной причиной.
3. Проверьте Reply-To. Ответьте на пересланное письмо. Клиент обычно использует Reply-To, если он есть, иначе From. Если ответ уходит пересыльщику, проверьте оба заголовка и настройки клиента.
4. Проверьте все компоненты обработки. Спам-фильтры, антивирусы, рассылки и защита от фишинга могут менять подписанные данные. Разберите весь маршрут: не каждое изменение нарушает DKIM, и причина не всегда явно видна в журналах.
5. Проверьте объем catch-all. Большой объем спама через IP пересылки может со временем ухудшить доставку Gmail, даже если отдельные письма проходят аутентификацию.

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

Как TrekMail организует инфраструктуру пересылки

Для самостоятельного Postfix могут понадобиться postsrsd для SRS, OpenARC для ARC, ротация RSA-ключей и маршрут без изменения содержимого. Эти четыре области могут давать независимые сбои. Необходимость каждой зависит от архитектуры, а похожие внешние симптомы требуют отдельной проверки.

Порядок обработки ARC и DKIM важен. Дополнительная DKIM-подпись пересыльщика может аутентифицировать его домен, но не является универсальным требованием ARC и не восстанавливает автоматически согласование с исходным From для DMARC. Сохраняйте исходные действительные подписи и проверяйте ARC и дополнительный DKIM раздельно. Отсутствие повторной подписи не объясняет любой сбой доставки.

Использует ли текущая конфигурация TrekMail OpenARC, дополнительную DKIM-подпись и автоматический SRS на ваших маршрутах, следует проверить по актуальным настройкам и заголовкам полученных писем. Пересылка должна сохранять текст без дополнительных подписей и меток темы. Адрес назначения задается в настройках пересылки ящика; там же проверьте доступность функций для вашего тарифа.

Указанные здесь параметры тарифов нужно проверить перед оплатой: пересылка для Pro ($10/мес.) и Agency ($23.25/мес.), 14 дней бесплатного пробного периода с обязательной кредитной картой. Для Nano ($0, 10 доменов, свой SMTP) и Starter ($3.50/мес., 50 доменов) здесь пересылка не заявлена. Актуальные условия смотрите в сравнении тарифов на trekmail.net/pricing.

Заключение

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

Начинайте с заголовка Authentication-Results. Он показывает проверки конкретного узла; вместе с трассировкой сообщений и журналами SMTP помогает локализовать сбой.

Если не хотите настраивать Postfix самостоятельно, изучите настройку профессиональной почты домена с TrekMail. Ориентир составляет около 15 минут; актуальные возможности SRS, ARC и DKIM для вашей конфигурации нужно проверить.