Пересылка почты домена в Gmail: настройка и проверка

Вы настроили пересылку с contact@yourdomain.com в Gmail. Клиент отправляет договор, банк присылает уведомление безопасности. Оба письма не появляются.

В спаме тоже ничего нет. В этом сценарии вы не видите ни сообщений, ни уведомлений. Однако исходный отправитель мог получить отчёт, который вам недоступен.

Причиной может быть сбой аутентификации, а не особенность интерфейса Gmail. Когда вы пересылаете почту своего домена в Gmail, сервер передаёт сообщение другого домена со своего IP. Если исходный отправитель конверта сохранён, а его SPF не разрешает этот IP, проверка не проходит. При строгой политике DMARC (p=reject) и отсутствии действительной выровненной подписи DKIM Gmail может отклонить письмо с ошибкой вроде 550-5.7.26. SMTP-отказ может вызвать отчёт о недоставке отправителю; он не означает обязательного удаления без уведомления обеим сторонам.

SRS (Sender Rewriting Scheme) переписывает отправителя SMTP-конверта, а ARC (Authenticated Received Chain) сохраняет подписанные результаты аутентификации. Они могут помочь при пересылке, но не гарантируют доставку и не обязательны одновременно во всех случаях. Сохранённая действительная выровненная подпись DKIM может обеспечить успешную проверку DMARC.

Здесь разобраны перезапись SRS, предотвращение петель и настройка «Отправлять как» в Gmail. Взаимодействие SPF, DKIM и DMARC и работу SRS объясняет полное руководство по настройке и устранению проблем пересылки почты.

Почему Gmail может отклонять пересылаемую почту

Исходный SPF может не пройти, потому что домен отправителя конверта не разрешает IP сервера пересылки. SRS позволяет проверять SPF по домену службы пересылки, если он разрешает этот сервер. Это не гарантирует выравнивание DMARC с исходным From:. DKIM, ARC, фильтры и политика получателя тоже влияют на результат.

Возможный сбой при пересылке письма от client@bank.com на you@gmail.com:

1. bank.com доставляет письмо на сервер пересылки
2. Ваш сервер передаёт его в Gmail
3. Gmail проверяет SPF по сохранённому отправителю конверта: client@bank.com
4. SPF bank.com не разрешает IP вашего сервера: SPF FAIL
5. Политика DMARC содержит p=reject, а выровненный DKIM не проходит: Gmail может вернуть 550-5.7.26
6. Письмо отклоняется. Вы можете не получить уведомление, хотя отправитель может получить отчёт о недоставке. Сохранение сообщения зависит от сервера.

Подпись DKIM может остаться действительной после пересылки, если данные, охваченные подписью, не меняются. Избегайте добавления текста в конце письма и изменения подписанного поля темы. Успешная проверка DKIM с согласованным доменом может обеспечить прохождение DMARC даже при сбое SPF. Параметр aspf=s касается только выравнивания SPF, не DKIM. Изменение подписанных данных может нарушить DKIM, но не любое изменение делает это. Проверяйте оба механизма: SRS не является гарантированным решением для DMARC.

Три способа пересылать почту домена в Gmail

Риски у разных конфигураций различаются. Перед включением пересылки выберите архитектуру для своего сценария.

Catch-all может ухудшать доставляемость. Спамеры пробуют адреса вроде abc123@yourdomain.com и junk@yourdomain.com. Если сервер принимает и пересылает эти письма, он передаёт и спам. Приведённые в источнике 90% иллюстрируют сценарий, а не порог блокировки Gmail. Репутация IP может ухудшиться, а нормальные письма попасть в спам; фиксированного срока восстановления нет.

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

SRS: почему стоит проверить его при пересылке в Gmail

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

Без SRS, сценарий сбоя:
Отправитель конверта: client@bank.com
IP отправителя: 203.0.113.10 (сервер пересылки в примере)
SPF: запись bank.com → FAIL (203.0.113.10 не разрешён)
DMARC: FAIL, если нет действительного выровненного DKIM (p=reject) → возможный отказ, не обязательное удаление

С SRS, SPF исправлен в примере:
Отправитель конверта: SRS0=HASH=TT=bank.com=client@yourdomain.com
IP отправителя: 203.0.113.10 (сервер пересылки в примере)
SPF: запись yourdomain.com → PASS (203.0.113.10 разрешён)
From: в заголовке: client@bank.com (без изменений, исходный видимый отправитель сохранён)

SPF домена, используемого SRS, должен разрешать IP или службу отправки подходящими механизмами. Без этого перезаписи недостаточно: SPF может не пройти, хотя новый адрес принадлежит вашему домену.

Инфраструктура пересылки также может добавлять заголовки ARC (Authenticated Received Chain). ARC записывает результаты аутентификации в подписанную цепочку. Gmail может учитывать их в зависимости от доверия к пересылающему серверу и своих правил. Нужна корректная конфигурация подписи ARC, не просто обычная подпись DKIM. Это задача оператора сервера; если вы его не администрируете, уточните поддержку у провайдера.

SPF определён в RFC 7208. ARC, документирующий результаты аутентификации на нескольких участках доставки, определён в RFC 8617.

Предотвращение петель: четыре проверки перед запуском

Петли могут вызывать ошибки вроде 5.4.14 Hop count exceeded и препятствовать доставке. Выполните эти проверки перед рабочим запуском.

1. Исключите круговую маршрутизацию. Убедитесь, что you@gmail.com не пересылает письма фильтром обратно на you@yourdomain.com и затем снова в Gmail. Такой маршрут может зациклиться до срабатывания серверных ограничений.
2. Контролируйте ответы об отсутствии. Для функционального адреса (team@domain.com → несколько аккаунтов Gmail) проверьте автоответы и предотвращение циклов. Precedence: bulk может помогать в некоторых системах, но не заменяет полноценную политику подавления автоматических ответов.
3. Тестируйте с третьего аккаунта. Gmail может устранять дубликаты. Тест из самого аккаунта назначения может остаться в отправленных, не появившись во входящих. Используйте другой аккаунт, например Yahoo или Outlook, и проверяйте журналы.
4. Проверьте исходящую политику M365. При использовании Microsoft 365 уполномоченный администратор должен проверить разрешение нужной пересылки в политике исходящего спама. Блокировка может дать 550 5.7.520. Не меняйте защиту без согласования и не считайте все маршруты одинаковыми.

Это частые причины проблем при первой настройке. Коды ошибок сами по себе не всегда указывают на ответственный параметр.

Как пересылать почту домена в Gmail через TrekMail

В источнике описаны перезапись SRS и подпись ARC на уровне MTA TrekMail для пересылаемых писем, а назначение выбирается в панели. Уточните текущую реализацию и охват в документации. Автоматизация не гарантирует приём каждого письма Gmail.

В исходной статье пересылка ящиков отнесена к тарифам Pro и Agency, не Free и Starter. Перед сменой тарифа проверьте актуальные требования. Описанные шаги приведены в документации по пересылке ящиков TrekMail:

1. Откройте Ящики (Mailboxes) в панели
2. Нажмите Управление (Manage) у нужного ящика
3. Включите Пересылку (Enable forwarding)
4. Введите Gmail-адрес в поле Пересылать на (Forward to)
5. Включите Сохранить копию (Keep a copy) на время начальной настройки
6. Нажмите Сохранить настройки пересылки (Save Forwarding Settings)

«Сохранить копию» важно. В описанной конфигурации локальная копия сохраняется вместе с попыткой доставки в Gmail, если позволяют квота и локальная доставка. Без неё внешний отказ может оставить вас без доступной копии в ящике. Держите опцию включённой во время проверки писем и заголовков; она не равнозначна гарантированной резервной копии.

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

Замыкаем рабочий процесс: «Отправлять как» в Gmail

Пересылка обрабатывает входящие, но не настраивает адрес ответа. Без «Отправлять как» ответы могут уходить с личного @gmail.com вместо ceo@yourdomain.com, в зависимости от клиента и его настроек.

При необходимости настройте «Отправлять как» с разрешёнными внешними SMTP-учётными данными. Проверьте способ отправки и параметр «Считать псевдонимом»: один флажок не определяет используемый сервер и не гарантирует выравнивание DMARC. Тестируйте From:, Return-Path и результаты аутентификации.

Ориентировочный путь в Gmail: Настройки → Аккаунты и импорт → Отправлять письма как → Добавить другой адрес электронной почты. Проверяйте действие «Считать псевдонимом» в текущей конфигурации, а не отключайте его автоматически.

Настройки SMTP TrekMail, описанные для Starter, Pro и Agency:

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano: собственный внешний SMTP (SES, SendGrid, Mailgun и другие) согласно источнику:

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

Эти блоки являются примерами: проверьте актуальные параметры и учётные данные. При добавлении адреса Gmail может отправить код подтверждения. Подтвердите адрес и при необходимости назначьте отправителем по умолчанию, затем проверьте адрес, который действительно выбирается при ответе.

Проверка результата: заголовки аутентификации Gmail

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

В Gmail: откройте письмо → меню с тремя точками → Показать оригинал. Найдите Authentication-Results.

Источник приводит такой пример результатов. Сам по себе он не доказывает выравнивание DMARC с исходным отправителем:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

spf=softfail или spf=fail могут указывать на проблему SRS, недостаточную авторизацию SPF или другие условия проверки. arc=fail может быть вызван изменением подписанных данных, ошибками ключей, подписей или цепочки, а не одной определённой причиной. Проверьте также From:, DKIM, DMARC и доверие к ARC. Официальные рекомендации Google по пересылке в Gmail помогают проверить обработку отправителя конверта.

Самостоятельная настройка или управляемый сервис: реальный компромисс

На собственном Postfix один из вариантов состоит в настройке postsrsd, защите и управлении srs_secret, планировании ротации и интеграции OpenARC с подходящими ключами подписи ARC. При возможности следите за репутацией через Google Postmaster Tools. Детали зависят от архитектуры. Обновления, неверная ротация и новые политики могут потребовать разбирательства, даже в 11 вечера.

Источник описывает управление SRS и ARC на уровне MTA после выбора назначения в TrekMail. Проверяйте актуальные требования, авторизацию DNS и результаты доставки. Последующее наблюдение за конфигурацией всё равно нужно.

С чего начать

В источнике Nano без карты предлагается для подключения и проверки домена, но не как тариф с пересылкой ящиков. Для этой функции указан Pro от $10 в месяц без оплаты за пользователя в пределах лимитов. Перед оформлением проверьте актуальную доступность и цену.

В исходной статье описан бесплатный пробный период на 14 дней для платных тарифов с банковской картой и Nano без карты. На trekmail.net/pricing проверьте текущие условия.

Проверьте четыре аспекта: перезапись SRS при необходимости, подписанные результаты ARC, разрешение сервера пересылки в SPF и исходящий адрес «Отправлять как». Это полезные меры, не гарантия доставки на годы. DKIM, фильтры, политика получателя и наблюдение тоже важны; ошибки не всегда происходят без уведомлений.

Настройте, проверьте заголовки и продолжайте наблюдение.