Пересылка почтовых алиасов: причины сбоев и решения

Вы настроили пересылку почтового алиаса: письма на contact@yourdomain.com поступают в Gmail. Несколько месяцев всё работает. Затем клиент отправляет письмо о подписанном договоре. Вы его не видите и узнаёте об этом через три недели, когда возможность уже упущена.

У вас нет уведомления о недоставке, нет письма в спаме. Только пропавшее сообщение и потерянная возможность.

Такой сценарий возможен, когда алиас с внешней пересылкой сталкивается со строгой политикой DMARC. Сбой может остаться незамеченным, но он не неизбежен и не всегда происходит без уведомления. Понимание протоколов помогает снизить риск. Это руководство описывает точки отказа, коды для поиска в журналах и два взаимодополняющих механизма, которые могут улучшить обработку аутентификации пересылаемой почты.

Если сначала нужны основы, начните с руководства по настройке и устранению проблем пересылки почты. Здесь речь пойдёт о сбоях.

Что на самом деле делает пересылка почтового алиаса

Алиас представляет собой правило маршрутизации: у него нет собственных входящих, учётных данных и квоты хранения. Когда кто-то пишет на sales@yourdomain.com, сервер направляет сообщение в другое место, часто в личный Gmail или Outlook. Это распространённый вариант для функциональных адресов малого бизнеса, но внешняя пересылка может создавать проблемы аутентификации и доставки.

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

Два уровня почтового сообщения

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

Когда client@bank.com пишет на алиас sales@yourdomain.com, сообщение отправляет сервер bank.com. В этом примере SPF проходит, поскольку домен разрешает используемый IP отправителя.

При пересылке на founder@gmail.com ваш сервер открывает новое SMTP-соединение и становится отправляющим сервером на этом участке. Без перезаписи адрес отправителя конверта может остаться исходным. В заголовке по-прежнему указан client@bank.com.

Gmail может проверить SPF для bank.com по IP вашего сервера, который этот домен не разрешает. В таком сценарии SPF не проходит. Если bank.com публикует p=reject и нет успешно проверенной выровненной подписи DKIM, DMARC тоже не проходит, а получатель может отклонить письмо по своей политике. Это не означает обязательного немедленного удаления без уведомлений: исходный отправитель может получить отчёт, даже если вы ничего не получите.

Три вида сбоев пересылки алиасов

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

1. Ошибка SPF

SPF проверяет, разрешён ли IP отправляющего сервера для проверяемого домена, обычно домена отправителя MAIL FROM. На новом SMTP-участке используется IP сервера пересылки. Если исходный отправитель конверта сохранён и его SPF не разрешает этот IP, проверка у получателя не проходит. Это может стать первым звеном проблемы.

2. Отклонение по DMARC

DMARC требует успешной проверки SPF или DKIM и выравнивания с доменом From:. Если SPF не прошёл, а при пересылке изменились подписанные данные, например добавилась подпись в конце письма или были переписаны охваченные подписью заголовки, DKIM также может не пройти. Если не осталось успешной выровненной проверки, получатель учитывает DMARC в своей политике: p=quarantine запрашивает карантин, обычно папку спама, а p=reject запрашивает отклонение, не обязательно незаметное удаление.

3. Отбрасывание без уведомления получателю

Худший случай: принимающий сервер отбрасывает письмо без NDR, отчёта о недоставке. Отправитель может не получить возврат, а в вашем ящике ничего не появится. Это возможный сценарий, не обязательное свойство пересылки: часть ошибок сопровождается уведомлениями или видна в журналах.

Коды ошибок для поиска в журналах SMTP

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

Блокировка Microsoft 365 (5.7.520)

Microsoft Exchange Online может блокировать автоматическую внешнюю пересылку по политике организации. Эта мера против утечки данных затрагивает и разрешённые рабочие сценарии; проверьте действующую конфигурацию тенанта.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Решение: уполномоченный администратор должен проверить политику исходящего спама Microsoft 365 в актуальном портале безопасности и при необходимости согласованно разрешить нужные назначения. Правило перенаправления не гарантирует обход этой проверки и не должно использоваться для обхода политики организации.

Петля маршрутизации (5.4.14 / 5.4.6)

Петля может возникнуть, если два алиаса пересылают письма друг другу или маршрут catch-all возвращает их в исходный домен.

554 5.4.14 Hop count exceeded - possible mail loop

Решение: проверьте транспортные правила и обратные маршруты. Catch-all для *@yourdomain.com в сочетании с автоматическими ответами может порождать повторяющийся трафик. Сам по себе ответ об отсутствии не обязательно образует транспортную петлю.

Ошибка аутентификации DMARC (550 5.7.1)

Принимающий сервер отклонил сообщение согласно своей политике аутентификации. Если письмо пересылалось, проверьте, повлияли ли новый SMTP-участок или изменения сообщения на SPF и DKIM.

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

Этот пример может соответствовать сбою DMARC при пересылке. Изучите заголовки и журналы: SRS и ARC могут помочь на уровне сервера, но также нужно проверить DKIM и относящиеся к нему настройки DNS. Один код не доказывает причину и не определяет универсальное решение.

Снижение риска: SRS и ARC

Локальный список разрешённых отправителей не обязывает внешний сервер принять письмо. Получатель оценивает опубликованную политику отправителя вместе со своими проверками. SRS и ARC представляют собой взаимодополняющие механизмы, которые может внедрить оператор MTA, агента передачи почты. Если сервер обслуживает провайдер, уточните поддерживаемую конфигурацию; ни один механизм не гарантирует доставку.

SRS (Sender Rewriting Scheme)

SRS переписывает отправителя SMTP-конверта, отражаемого в Return-Path, используя домен службы пересылки. SPF у получателя может пройти, если запись этого домена разрешает сервер и проверка не сталкивается с другими ошибками.

Без SRS:
Отправитель конверта: client@bank.com
IP отправителя: ваш сервер пересылки
Результат SPF: FAIL в этом примере, поскольку bank.com не разрешает ваш IP

С SRS:
Отправитель конверта: SRS0=Hash=TT=bank.com=client@yourdomain.com
IP отправителя: ваш сервер пересылки
Результат SPF: PASS в этом примере, если yourdomain.com разрешает ваш IP

SRS включает хеш и временную метку для проверки переписанных адресов и ограничения злоупотреблений. Срок действия обычно задаётся в днях и зависит от реализации. Он не исключает все атаки повторного использования и не защищает адрес от сбора злоумышленниками.

ARC (Authenticated Received Chain)

SRS может исправить SPF на участке пересылки, но не его выравнивание DMARC с исходным отправителем. DMARC сравнивает домен From: (bank.com) с аутентифицированными доменами. После SRS конверт использует yourdomain.com, а From: сохраняет bank.com. SPF с ним не выровнен, однако действительная выровненная подпись DKIM всё ещё может обеспечить успешную проверку DMARC.

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

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

Ни один механизм не включается простым изменением DNS. SRS и подписи ARC реализуются в транспорте, хотя настройка может требовать DNS. Без подходящей обработки внешняя пересылка более уязвима к строгим политикам DMARC; сохранённая выровненная подпись DKIM может позволить доставку и без ARC.

Две операционные ловушки

Даже при наличии SRS и ARC стоит проверить две распространённые конфигурации.

Раскрытие личного адреса при ответе

Пересылка управляет только входящей почтой. При ответе из Gmail отправителем может оказаться founder@gmail.com, а не sales@yourdomain.com, в зависимости от настроек. Тогда клиент увидит ваш личный адрес.

Вариант решения: настройте «Отправлять письма как» в разделе аккаунтов Gmail с учётом текущего интерфейса. Добавьте адрес алиаса и разрешённые SMTP-учётные данные домена, если они требуются. Проверьте адрес отправителя и путь доставки тестовыми письмами. Параметры подключения приведены в настройках управляемого SMTP TrekMail.

Такой подход может работать, но описанная процедура добавляет три шага настройки для каждой учётной записи. Если меняется SMTP-пароль, используемый Gmail, нужно обновить соответствующие учётные данные.

Ловушка внешней пересылки catch-all

Избегайте внешней пересылки catch-all (*@yourdomain.com). Спамеры проверяют адреса вроде billing@, admin@ и noreply12345@. Catch-all может принять и переслать эти сообщения, если фильтры их не заблокируют.

Если сервер пересылает в Gmail большие объёмы спама, его репутация может ухудшиться. Важные письма, в том числе из других ящиков на том же IP, могут попадать в спам или блокироваться. Восстановление требует времени и исправления причин; фиксированного срока нет.

Если catch-all нужен, направляйте его в изолированный локальный ящик, проверяйте вручную и применяйте фильтры и ограничения. Поддерживаемая настройка описана в документации по пересылке ящиков в TrekMail. Локальное назначение снижает усиление внешнего спама, но не устраняет все риски.

Пересылка алиаса или отдельный ящик: что выбрать

Полный подход к выбору описан в руководстве по сравнению алиасов и ящиков на своём домене. Ниже краткая памятка именно для пересылки:

Не заменяйте полноценный ящик постоянной пересылкой алиаса только ради экономии. При оплате за пользователя сравните выгоду с дополнительной работой. Без такой оплаты пересылка может добавлять операционную нагрузку: настройки, особые случаи и ошибки аутентификации, требующие наблюдения.

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

Самостоятельная поддержка SRS и ARC требует настройки транспорта MTA, управления ключами подписи ARC и их ротации. Конкретные шаги зависят от сервера и реализации. Это задача серверного администрирования, а не простое переключение параметра в панели.

В исходной статье описана пересылка ящиков на тарифах Pro и Agency TrekMail через транспорт с OpenARC и автоматической подписью пересылаемых сообщений. В ней также описаны выбор назначения в панели и обработка аутентификации на уровне MTA. Уточните текущую доступность и работу SRS, DKIM и DNS; это описание не гарантирует приём внешним сервером.

Во многих случаях проще отказаться от пересылки. В источнике TrekMail описан с фиксированной оплатой без отдельных сборов за пользователя или ящик: support@yourdomain.com относится к одной модели оплаты независимо от того, работает с ним один человек или десять, в пределах применимых ограничений. Перед выбором проверьте поддерживаемый общий доступ, квоту и текущие цены. Отказ от пересылки в личный Gmail может сократить настройку «Отправлять как» при подключении новых доменов.

• Малый и средний бизнес: Выделите support@ собственный доступ IMAP, если он поддерживается. Настройте SMTP и адрес ответа. Прямой доступ уменьшает зависимость от «Отправлять как», но не исключает ошибок и необходимости обновлять пароли.
• Агентства: Создавайте отдельные ящики для функциональных адресов клиентов вместо пересылки в личные аккаунты сотрудников. Используйте поддерживаемые права доступа и проверяйте адреса ответа, чтобы клиент видел согласованного отправителя.

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

Итог

Пересылка почтового алиаса может подходить для некритичных сценариев. Особого внимания требуют следующие случаи:

1. Отправитель публикует строгий DMARC (p=quarantine или p=reject), а успешной выровненной аутентификации не остаётся
2. Сервер не использует SRS или другую подходящую обработку, и SPF у получателя не проходит
3. Сервер не использует ARC: после SRS нет выравнивания SPF с исходным From:, хотя DKIM может обеспечить успешный DMARC
4. Catch-all пересылается наружу, создавая риск усиления спама
5. Нужно отвечать с алиаса: сама пересылка не настраивает эту идентичность отправителя

Можно проверить обработку аутентификации у провайдера, включая SRS, ARC и DKIM, либо заменить пересылающий алиас ящиком с прямым доступом. При оплате за пользователя учитывайте и операционные затраты. В описанной для TrekMail фиксированной модели ящик в пределах лимитов может не требовать дополнительной лицензии; уточните текущие условия.

Источник указывает стоимость Pro в TrekMail от $10 в месяц, до 100 доменов, пересылку ящиков с подписью ARC и отсутствие сборов за ящик. Описана пробная версия на 14 дней с банковской картой, тогда как Nano её не требует. Это условия, зафиксированные в исходной статье: проверьте актуальные.