Пересылка почты, вероятно, становится одной из первых функций, которые вы настраиваете после приобретения домена. И нередко она первой незаметно перестает работать.
На первый взгляд все просто: взять письмо, отправленное на info@yourdomain.com, и перенаправить его в учетную запись @gmail.com. На практике пересылка является посреднической операцией и напрямую сталкивается с основными моделями доверия современного интернета: SPF, DKIM и DMARC. При ошибочной настройке письмо не возвращается с заметным сообщением об ошибке. Оно просто исчезает.
Для основателя компании неработающая пересылка означает пропущенные письма от инвесторов. Для MSP, управляющего 50 клиентскими доменами, это означает поток обращений в поддержку утром в понедельник.
В этом руководстве разобрано, как пересылка почты работает на уровне протокола, почему она дает предсказуемые сбои и как подготовить конфигурацию, способную работать со строгими политиками DMARC в 2026 году.
Модель процесса: почему пересылка почты сложнее, чем кажется
Чтобы исправить неработающую пересылку, сначала нужно понять происходящее на уровне SMTP. Это не передача записки, а повторная отправка письма. Такая разница имеет принципиальное значение.
Когда сервер A отправляет письмо вашему серверу (серверу B, выполняющему пересылку), а сервер B передает его конечному получателю (серверу C), происходит важная смена идентификатора. Сервер назначения видит IP-адрес сервера B, а не сервера A. В этом заключается причина почти всех сбоев пересылки.
Конверт и заголовок: два идентификатора письма
У каждого письма есть два отдельных уровня идентификации, которые при пересылке перестают соответствовать друг другу:
- Конверт (P1): сведения, по которым почтовые серверы физически маршрутизируют сообщение. Содержит
Return-Path. Этот уровень проверяет SPF. - Заголовок (P2): адрес отправителя, который почтовый клиент показывает в поле «От». Этот уровень используют проверки выравнивания DKIM и DMARC.
Проблема возникает следующим образом. При пересылке сервер открывает новое SMTP-соединение с получателем. SPF сверяет IP отправителя с SPF-записью исходного отправителя, однако IP-адрес вашего сервера пересылки в ней не разрешен. Проверка SPF завершается ошибкой. Если исходный отправитель применяет строгую политику DMARC (p=reject), а SRS не настроен, сервер назначения отклоняет сообщение.
Представьте конкретный пример. Алиса отправляет письмо Бобу. Боб кладет письмо Алисы в новый конверт со своим обратным адресом и отправляет Кэрол. Кэрол спрашивает Алису, отправляла ли та письмо с адреса Боба. Алиса отвечает отрицательно. Так выглядит ошибка DMARC, и почтовый сервер Кэрол реагирует соответствующим образом.
Понимание различий между конвертом и заголовком служит основой. Из него следуют все описанные далее решения.
Пересылка, псевдонимы и catch-all: в чем разница
Администраторы постоянно путают эти три способа маршрутизации. Неверный выбор быстро приводит к заявке о пропавшем письме, диагностика которой занимает три часа.
Пересылка почты
Письмо, отправленное на один адрес, доставляется на совершенно другой сервер, например с contact@startup.com на founder@gmail.com. Происходит сетевой переход. Если специально не учесть аутентификацию, ее цепочка нарушается. Такой вариант подходит для объединения нескольких доменов в одном ящике. Риск: высокий без корректной обработки SRS/ARC. Подробнее о компромиссах читайте в нашем материале о сочетании псевдонимов и пересылки.
Почтовые псевдонимы
Это другое имя существующего ящика на том же сервере. Письма на support@company.com попадают в тот же ящик, что и письма на admin@company.com, без сетевого перехода и изменения аутентификации. Вариант подходит одному человеку с несколькими ролями. Риск: низкий. Подробное сравнение ситуаций, когда псевдонима уже недостаточно и требуется полноценный ящик, приведено в руководстве по выбору между псевдонимом и ящиком.
Catch-all (маршрутизация по шаблону)
Принимает все письма, отправленные на несуществующие адреса домена, то есть *@domain.com. Это удобно для перехвата опечаток и разовых адресов кампаний. Риск: критический, если письма направляются прямо в Gmail. Весь спам на домен попадет в ваш ящик, и со временем Gmail может начать считать источником спама сервер пересылки. Catch-all следует изолировать. Все компромиссы рассмотрены в нашем руководстве по настройке деловой почты.
| Способ | Сетевой переход? | Риск для аутентификации | Оптимальное применение |
|---|---|---|---|
| Пересылка | Да | Высокий (нарушение SPF/DMARC) | Маршрутизация между доменами и провайдерами |
| Псевдоним | Нет | Отсутствует | Несколько ролей, один ящик |
| Catch-all | Зависит от конфигурации | Критический (притягивает спам) | Перехват опечаток и временные адреса |
Варианты настройки: хороший, плохой и нерабочий
Пересылку почты можно настроить тремя способами. Два из них создают проблемы. Один обычно надежно работает в производственной среде.
1. Маршрутизация на стороне провайдера (правильный способ)
Она выполняется на уровне MTA до попадания сообщения в ящик. Сервер принимает письмо, переписывает конверт с помощью SRS и сразу передает его дальше. Платная лицензия на ящик не требуется. Место в хранилище не расходуется. SPF и ARC обрабатываются на уровне инфраструктуры.
Именно на этом подходе стоит строить конфигурацию. Маршруты пересылки TrekMail работают так: вы задаете назначение, а инфраструктура обрабатывает заголовки аутентификации. Точные инструкции приведены в руководстве по настройке пересылки из ящика.
2. Правила почтового ящика (старый способ)
Вы создаете полноценную учетную запись, платите $6-$30/month за фактически ненужную лицензию, входите в систему и задаете правило: «Если сообщение поступило, переслать его X».
Иногда это оправдано: при условной пересылке («пересылать только счета»), требованиях аудита или необходимости хранить сообщение локально до передачи. Но в большинстве случаев вы оплачиваете место пользователя только ради маршрутизации. DMARC нарушается так же, как при любой иной пересылке, а Microsoft 365 по умолчанию блокирует автоматическую пересылку. Подробнее об этом рассказано в разделе о видах сбоев.
3. Пересылка на стороне клиента (полностью избегайте)
Это правило в Outlook Desktop или Apple Mail на локальном компьютере. Для пересылки ноутбук должен быть включен, не находиться в спящем режиме и иметь подключение к интернету. В поездке это не работает. Во время перезапуска это не работает. Это не работает в 2am, когда приходит важное письмо.
В производственной среде нет сценария, в котором это было бы правильным решением. Если вы сейчас полагаетесь на такой вариант, исправьте конфигурацию.
Контрольный список безопасной настройки
Перед включением маршрута пересылки выполните четыре проверки. Пропуск любой из них способен впоследствии создать проблемы.
1. Проверка цикла
Убедитесь, что адрес назначения не пересылает почту обратно на исходный адрес. A→B→A образует бесконечный цикл. Современные серверы обнаруживают его по лимиту переходов и возвращают NDR 5.4.14 hop count exceeded, но к этому моменту репутация отправителя уже может пострадать. Составьте схему маршрутов до запуска.
2. Проверка заголовков
Отправьте тестовое письмо с внешнего адреса (личного Gmail, Yahoo или любого сервиса вне вашего домена) на адрес с пересылкой. В конечном ящике откройте полные заголовки сообщения и найдите Authentication-Results. Желательный результат: spf=pass (после переписывания SRS) или dkim=pass. Значение dmarc=fail означает, что настройка еще не готова к эксплуатации.
3. Проверка Reply-To
Ответьте на пересланное письмо. Ответ направляется исходному отправителю или серверу пересылки? Он должен направляться исходному отправителю. Если ответ уходит посреднику, конфигурация конверта неверна, а цепочка переписки станет непонятной для участников.
4. Проверка политики исходящей почты
Если назначением ретрансляции служит Microsoft 365 или Google Workspace, убедитесь, что автоматическая пересылка разрешена в настройках фильтра исходящего спама. M365 по умолчанию блокирует ее. При неверной настройке пересылаемые письма могут отбрасываться без уведомления исходного отправителя.
Распространенные виды сбоев
При нарушении пересылки почти всегда наблюдается один из перечисленных ниже вариантов. Знание типичных признаков экономит час бесцельного изучения заголовков.
1. Незаметное отбрасывание из-за DMARC
В 2026 году это одна из наиболее частых причин исчезновения писем, причем видимых признаков нет: ни NDR, ни ошибки, ничего. Сообщение просто не приходит.
Сценарий таков: банк, платежный сервис или поставщик SaaS отправляет на ваш домен письмо со строгой политикой DMARC p=reject. Вы пересылаете его в Gmail. Из-за IP посредника нарушается SPF. Если сервер также меняет тело (добавляет уведомление) или тему (добавляет [External]), нарушается и DKIM. Ошибка SPF + ошибка DKIM = ошибка DMARC. Gmail отклоняет сообщение.
Для исправления настройте SRS на сервере пересылки, чтобы проверка SPF проходила, и не меняйте содержимое, чтобы сохранить DKIM. Если инфраструктура вам неподконтрольна, потребуется провайдер пересылки, который выполняет эти операции. Подробнее о сбоях DMARC именно в цепочках пересылки читайте в нашем разборе DMARC и защищенной почты.
2. Блокировка Microsoft 550 5.7.520
Признак: исходный отправитель получает NDR с кодом 550 5.7.520 Access denied, your organization does not allow external forwarding.
Фильтр исходящего спама M365 делает именно то, для чего предназначен: блокирует автоматическую пересылку на внешние адреса. Для исправления откройте портал Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → задайте для «Automatic forwarding rules» значение «On: forwarding is enabled».
Путь неочевиден и спрятан глубоко в интерфейсе Microsoft. Однако код ошибки дает точный диагноз: увидев его, вы знаете, где менять настройку.
3. Цикл автоматических ответов
Пользователь A пересылает письма пользователю B. Пользователь B включает автоматический ответ. Пользователь A пишет пользователю B. Автоматический ответ B уходит пользователю A. Сервер A пересылает этот ответ пользователю B. Сервер B снова отвечает.
Современные серверы обнаруживают и останавливают это с помощью заголовков X-Loop и X-Auto-Response-Suppress. Старые или неверно настроенные системы по-прежнему способны создать тысячи писем за несколько минут. При межаккаунтной пересылке проверяйте параметры автоматических ответов.
4. Нарушение DKIM при изменении сообщения
DKIM подписывает криптографический хеш содержимого. Как только меняется что-либо в подписанной части, даже добавляется однострочный нижний колонтитул, подпись становится недействительной. Многие корпоративные системы добавляют юридическое уведомление ко всем исходящим письмам. Если оно вставляется после создания DKIM-подписи, у получателя подпись окажется недействительной.
Значение dkim=fail (body hash did not verify) в заголовках пересланного сообщения почти всегда указывает на эту причину.
Порядок диагностики: симптом → решение
| Симптом | Вероятная причина | Диагностическое действие |
|---|---|---|
Отправитель получает NDR 5.7.1 | SPF / отказ в ретрансляции | Проверьте наличие IP сервера пересылки в блок-листах. Изучите результат SPF в заголовках. |
Отправитель получает NDR 5.4.14 | Цикл маршрутизации | Проверьте все правила пересылки на наличие циклических путей (A → B → A). |
| Нет письма и NDR (незаметное отбрасывание) | Отклонение DMARC / спам-фильтр | Проверьте папку спама у получателя. Найдите dmarc=fail в заголовках. |
550 5.7.520 Access denied | Блокировка исходящей политики M365 | Измените политику исходящего спама в M365 Defender: разрешите автоматическую пересылку. |
| Письмо пришло, но отображается неверно | Ошибка хеша тела DKIM | Найдите в заголовках dkim=fail (body hash did not verify). Отключите добавление колонтитулов и уведомлений. |
| Ответ уходит посреднику, а не отправителю | Неверная настройка Reply-To / конверта | Убедитесь, что при пересылке сохраняется заголовок Reply-To исходного отправителя. |
Почему пересылка ломается в рабочей среде: SRS и ARC
Простых правил пересылки недостаточно для производственной среды. Нужна инфраструктура, понимающая SRS и ARC. Разберем назначение каждого механизма и важность обоих.
SRS: Sender Rewriting Scheme
SRS устраняет ошибку SPF, вызванную сетевым переходом. Сервер пересылки переписывает адрес отправителя конверта, чтобы получатель проверял SPF по вашему домену, а не по домену исходного отправителя.
До применения SRS:
MAIL FROM: alice@bank.comПосле переписывания SRS:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comСервер назначения выполняет SPF-проверку для forwarder.com, и она проходит, поскольку ваш сервер авторизован. Уведомления о недоставке все равно возвращаются на alice@bank.com с помощью закодированного адреса. Требования SPF соблюдаются без нарушения пути возврата.
SRS необходим. Без него каждое пересланное сообщение от отправителя со строгой политикой SPF не пройдет аутентификацию у получателя. Полное объяснение SRS в цепочках пересылки приведено в подробном руководстве по настройке почты на своем домене. При маршрутизации именно в Gmail воспользуйтесь пошаговым руководством о том, как безопасно пересылать доменную почту в Gmail с настроенными SRS и функцией отправки от другого имени.
ARC: Authenticated Received Chain
SRS исправляет SPF, но не полностью решает проблему выравнивания DMARC. Здесь нужен ARC. Он позволяет серверу пересылки криптографически подписать сообщение печатью со смыслом: «При получении я проверил аутентификацию этого сообщения, и она была действительной».
Google и Microsoft учитывают печати ARC от доверенных промежуточных серверов. При наличии доверенной печати провайдеры могут принять сообщение, даже если исходные проверки SPF/DMARC завершились бы ошибкой из-за перехода пересылки. По сути, это журнал цепочки обработки для аутентификации почты.
ARC определен в RFC 8617 и является действующим стандартом сохранения аутентификации при законной пересылке. Без ARC строгая политика DMARC p=reject исходного отправителя может привести к отклонению пересланных сообщений крупными провайдерами даже при наличии SRS.
Опасная зона catch-all
Пересылку часто сочетают с catch-all, и такая комбинация требует отдельного предупреждения. Если направить catch-all в Gmail, весь спам на случайные адреса домена попадет в Gmail, который видит источником сервер пересылки. Жалобы на спам могут быстро накапливаться для вашего IP и ухудшать репутацию домена при отправке обычной почты.
Если нужен catch-all, изолируйте его в отдельном ящике со спам-фильтрацией на сервере, а не пересылайте в личный ящик. Полная схема описана в нашем руководстве по настройке почты на домене.
Роль TrekMail
Раньше для пересылки приходилось либо создавать собственный MTA с поддержкой SRS и ARC, либо оплачивать пользовательские лицензии только ради маршрутизации почты. Ни один вариант не подходил операторам, управляющим более чем несколькими доменами.
Платить Google или Microsoft $6/user/month, иметь 10 адресов пересылки и потенциально оплачивать 10 неиспользуемых мест либо упереться в лимит псевдонимов и искать обходные решения. Это налог на маршрутизацию.
TrekMail использует хостинг с фиксированной платой. Вы оплачиваете тариф, а не пользовательские места. Маршруты пересылки, псевдонимы и catch-all входят в тариф и управляются на сервере, а совместимая с SRS пересылка встроена в инфраструктуру. Вы задаете маршрут, а платформа обрабатывает заголовки аутентификации, применение TLS и доставку. Нет платы за каждый адрес и необходимости разбираться с политиками исходящего спама ради базовой функции.
Для основателя-одиночки это означает надежную маршрутизацию hello@yourdomain.com в Gmail менее чем за пять минут без развертывания полноценного почтового сервера. Для команды каждое изменение выполняется в панели без археологических раскопок в DNS. Для агентства с 100+ клиентскими доменами правила управляются централизованно и применяются единообразно, не создавая ошибок аутентификации, которые превращаются в срочные обращения в 6pm пятницы.
Тариф Pro ($10/month или $8/month при годовой оплате) включает внешний catch-all и пересылку из ящиков. Тариф Agency ($29/month) рассчитан на 1,000+ доменов и предоставляет API для пакетного управления маршрутами. Все платные тарифы предлагают бесплатный пробный период 14-day (требуется карта).
Узнайте, как TrekMail управляет пересылкой в любом масштабе, на сайте trekmail.net.
Заключение
Пересылка почты не относится к функциям, которые можно один раз настроить и забыть. Это активная операция маршрутизации, затрагивающая основные модели аутентификации интернета. Сбои предсказуемы: SPF нарушается при смене IP, DKIM при изменении содержимого, а DMARC отклоняет письмо при нарушении выравнивания. Все они устранимы, если понимать процессы на уровне протокола.
Практические выводы: применяйте серверную пересылку с SRS и ARC, но не клиентские правила. Проверяйте заголовки перед запуском. Учитывайте блокировку исходящей политики M365. Изолируйте catch-all. При управлении пересылкой нескольких доменов не платите за каждое место только ради маршрутизации.
При правильной инфраструктуре пересылка работает надежно. При ошибках настройки самые важные письма могут исчезать бесследно. Выбор несложен.
