обзор · SMTP-релей Google

Что продуктовой команде оценивать при выборе SMTP-релея Google?

Выбирайте SMTP-релей Google Workspace, только если его модель администрирования, идентификации и квот подходит для нагрузки. Уточните, кто владеет доменом Workspace и настройкой в консоли администратора, может ли приложение использовать стабильный публичный IP из разрешённого списка или SMTP-аутентификацию, защищённую TLS, какие отправители конверта разрешены и как обеспечивается TLS. До запуска смоделируйте текущие лимиты Google на пользователя, на клиента и на транзакцию. Протестируйте временные и постоянные ошибки, сохраняйте SMTP-ответы, аутентифицируйте видимого отправителя через SPF, DKIM и DMARC и разделяйте приём, доставку на сервер получателя и попадание во «Входящие» как разные результаты.

Начните с соответствия нагрузке и модели администрирования

SMTP-релей Google — это административный маршрут Google Workspace для приложений, устройств и почтовых серверов, которые отправляют письма через smtp-relay.gmail.com. Оценивайте его как часть границы Workspace и почтовой безопасности организации, а не как универсальный анонимный SMTP-эндпоинт. Определите суперадминистратора Workspace, домены в аккаунте, системы-источники, публичные исходящие IP-адреса, адреса отправителей, классы писем, пиковый и дневной объём получателей, профиль вложений и контакт для инцидентов. Решите, к какому типу относится нагрузка: транзакционные письма, внутренние служебные, написанные пользователями, массовые рассылки по подписке или письма, генерируемые устройствами. Разделяйте эти классы, потому что требования к авторизации, согласию, стоп-листу, аудиту и репутации у них разные. Убедитесь, что тестовые окружения не могут использовать продакшен-маршруты или адреса клиентов. Релей может передать авторизованное письмо, но не решает, легитимно ли бизнес-событие, дал ли получатель согласие и должно ли продвигаться дальше состояние приложения.

Сравните авторизацию по IP и SMTP-аутентификацию

Текущая настройка Google позволяет администраторам ограничить приём релея указанными публичными IP-адресами, требовать SMTP-аутентификацию через TLS или сочетать варианты политики согласно задокументированной настройке. Авторизация по стабильному IP подходит для контролируемых дата-центров или фиксированных исходящих шлюзов, но становится хрупкой за меняющимся облачным NAT, при нескольких регионах, резервных сервисах или сетях третьих сторон. SMTP-аутентификация идентифицирует аккаунт Workspace и домен отправки, но добавляет жизненный цикл учётных данных, зависимость от статуса пользователя, взаимодействие с многофакторной аутентификацией и политиками, а также жёсткое требование TLS. Никогда не используйте одни широкие учётные данные для разных тенантов или несвязанных приложений. Для каждого варианта задокументируйте, кто может добавить IP или аккаунт, как проверяются изменения, как обнаруживается компрометация, как отзывается доступ и что происходит при переключении на резерв. Делайте разрешённые диапазоны IP как можно меньше и проверяйте публичный исходящий адрес из реальной среды выполнения, а не копируйте внутренний адрес.

Определите разрешённых отправителей и идентичность домена

Настройка релея в консоли администратора определяет, каким отправителям разрешена отправка. Google документирует варианты, привязанные к зарегистрированным пользователям Apps и адресам в собственных доменах, а также более широкий вариант «любой адрес», который повышает риск злоупотреблений. Выбирайте самый узкий вариант, который устраивает нагрузку. Учитывайте отправителя SMTP-конверта отдельно от видимых полей From и Reply-To. Google отмечает, что если отправитель находится вне доменов аккаунта, то SMTP AUTH или домен, указанный в HELO или EHLO, могут влиять на то, как отправитель конверта определяется или перезаписывается. Не полагайтесь на перезапись вместо собственной модели отправителей. Требуйте утверждённого соответствия между приложением, тенантом, классом писем, отправителем конверта, видимым доменом From и обратным путём (return path). Блокируйте произвольные заголовки от пользователей, внедрение переводов строк и адреса From чужих тенантов до подключения к Google. Протестируйте маршрутизацию отказов (bounce) и автоответов, включая пустого отправителя конверта, не ослабляя настройку целиком.

Осознанно требуйте защиты транспорта

Текущее руководство Google по релею направляет локальные системы с поддержкой TLS на smtp-relay.gmail.com, порт 587, и поясняет, что SMTP-аутентификация требует TLS. Настройка в консоли администратора также может требовать TLS для соединений от отправляющего сервера. Включите обязательный TLS для продакшена, если только задокументированное ограничение старой системы не имеет временного исключения. Проверьте имя сервера, цепочку сертификатов, поддерживаемые протоколы и политику шифров, согласование STARTTLS и поведение при сбое. Клиент должен прерывать соединение, если обязательный TLS установить не удалось; молчаливый откат к открытому тексту сводит политику на нет. Храните SMTP-учётные данные в управляемом хранилище секретов и не допускайте их попадания в командные строки, URL, исходный код, логи, аналитику, отчёты о сбоях и тикеты. Транспортный TLS защищает участок до Google, а не весь жизненный цикл письма или почтовый ящик. Для чувствительного контента могут понадобиться механизмы на уровне приложения, минимизация данных, сроки хранения и отдельные решения о сквозном шифровании.

Смоделируйте текущие квоты до выбора релея

В текущей документации Google по настройке SMTP-релея сказано, что каждый пользователь может отправить до 10 000 писем и не более чем 10 000 уникальным получателям за 24 часа, причём в пробном периоде лимиты могут быть ниже. Там же задокументированы лимит в 100 получателей на одну SMTP-транзакцию и дополнительные ограничения на уровне клиента, пиковые и дневные. Считайте это текущими задокументированными потолками, а не целевой мощностью или постоянным договором. Перепроверьте официальную страницу для своего аккаунта и нагрузки перед запуском. Считайте получателей, а не только письма, — по To, Cc, Bcc, повторам и рассылке по множеству адресатов. Установите ограничения частоты, параллелизма, возраста очереди и справедливого распределения между тенантами на уровне приложения ниже лимитов Google. Настройте оповещения об ускорении и оставшемся запасе. Не реагируйте на лимит распределением трафика по неавторизованным аккаунтам, ротацией отправителей конверта или открытием неконтролируемых соединений. Нагрузке, которая регулярно приближается к общей границе Workspace, может понадобиться оценка специализированного транспорта.

Постройте надёжный процесс отправки

Разместите SMTP-клиент за авторизованным серверным воркером или очередью. Сохраняйте одну задачу исходящей отправки со стабильным ключом бизнес-события, тенантом, классом письма, ревизией шаблона, утверждёнными отправителем и получателями, основанием согласия или необходимости, решением по стоп-листу и историей попыток. Захватывайте задачу один раз, рендерите и проверяйте содержимое, затем подключайтесь к настроенному эндпоинту Google. Ограничивайте число получателей на транзакцию и размер письма согласно текущим лимитам и политике продукта. Записывайте полный SMTP-ответ, расширенный код состояния, удалённый хост, время и идентификатор попытки, не логируя учётные данные и лишнее содержимое. Если релей принял транзакцию DATA, отмечайте только этап приёма провайдером или релеем. Если у клиента истёк тайм-аут после отправки данных, но до получения итогового ответа, оставьте попытку в неизвестном состоянии и выполните сверку перед повторной отправкой. В SMTP нет ключа идемпотентности приложения, поэтому контроль дублей — задача очереди и модели событий продукта.

Классифицируйте ошибки релея, а не повторяйте всё подряд

Страница ошибок SMTP-релея Google описывает разные состояния, включая отказ в ретрансляции (mail relay denied), неверные учётные данные релея или идентификацию домена, превышение дневного лимита, временную отсрочку из-за пикового лимита и слишком большое число получателей в одной транзакции. Сохраняйте точный ответ и сопоставляйте его с узким внутренним классом. Исправляйте ошибки конфигурации, домена отправителя, учётных данных, IP и числа получателей на транзакцию до повторной отправки. Приостанавливайте или переносите работу после исчерпания дневного лимита. Повторяйте допустимые временные ошибки пикового лимита или транспорта с экспоненциальной задержкой, случайным разбросом (jitter), ограничением числа попыток и возраста очереди. Никогда не повторяйте постоянный ответ бесконечно. Если ошибка указывает на незарегистрированный IP, проверьте реальный публичный исходящий адрес среды выполнения и правильную настройку Workspace, а не расширяйте список разрешённых адресов. Сохраняйте агрегированные счётчики с минимумом персональных данных по системе-источнику, ревизии конфигурации, домену отправителя, классу статуса и времени. Настройте оповещения о новых ответах и всплесках ошибок аутентификации: они могут указывать на дрейф политики, отзыв учётных данных, смену NAT или злоупотребление.

Аутентифицируйте отправителя, а не только доступ к релею

Разрешение использовать релей Google — не то же самое, что аутентификация отправителя для получателей. Опубликуйте SPF-политику, которая авторизует фактический путь отправки для идентификатора в конверте, настройте подпись DKIM для домена, контролируемого организацией и выровненного по DMARC, и опубликуйте проверенную политику DMARC для видимого домена From. Проверьте исходное полученное письмо в контролируемых внешних ящиках. Зафиксируйте результат и домен SPF, результат DKIM, домен d= и селектор, видимый домен From, выравнивание и результат DMARC. Технически корректная подпись провайдера или Workspace может остаться невыровненной с собственным доменом From. Пересылка также может изменить результаты SPF. Не добавляйте вторую SPF-запись и не ослабляйте DMARC для всей организации только ради прохождения одного теста. Согласовывайте действия администраторов DNS и почты, сохраняйте прежние записи, проверяйте ответы авторитетных и рекурсивных серверов и меняйте идентификаторы по одному за раз.

Требуйте наблюдаемости и проверенного пути выхода

Используйте поиск по журналу писем в консоли администратора Google и журналы на стороне релея, где они доступны, но источником решений оставляйте журнал исходящих писем, которым владеет продукт. Отслеживайте возраст очереди, приём, временные и постоянные ответы, использование лимитов, сигналы отказов и жалоб, аутентификацию и задержку по классам писем и доменам отправителей. Ограничивайте доступ и не включайте полные адреса или содержимое в регулярные метрики. Протестируйте смену исходного IP, ротацию учётных данных, сбой TLS, отключение настройки в консоли администратора, блокировку пользователя, исчерпание лимита, рассылку множеству получателей, изменения DNS и сбой провайдера. Определите откат, который может приостановить затронутую группу, не теряя сохранённые задачи. Для миграции изолируйте специфичные для провайдера поля SMTP в одном адаптере и сохраняйте ключи бизнес-событий, состояние стоп-листа, авторизацию отправителей и историю попыток. Второй релей не должен становиться автоматическим обходом постоянных отказов по политике или со стороны получателей. Совместимость требует тестов на уровне полей и ошибок, а не просто смены имени хоста.

Как SendHQ вписывается в эту схему

SendHQ — email API в рамках рабочего пространства для ожидаемой продуктовой коммуникации: отправка с подтверждённого домена, входящая почта, хранимые шаблоны, события доставки, стоп-листы и веб-панель управления. Сравните его с Google Workspace SMTP relay по актуальной документации и контролируемым тестам границ аккаунтов и тенантов, учётных данных и их ротации, контроля разрешённых отправителей, идентификаторов конверта и видимых идентификаторов, сбоев TLS, лимитов получателей, временных и постоянных ответов, неоднозначных результатов, стоп-листов, получения событий и миграции.

Частые вопросы

Какое имя хоста использует Google Workspace для SMTP-релея?

В текущем руководстве Google по настройке используется smtp-relay.gmail.com. Выбирайте порт и режим TLS по официальным инструкциям и принятой в организации политике безопасности.

Можно ли ограничить SMTP-релей Google по исходному IP?

Да. Настройка в консоли администратора позволяет принимать соединения только с указанных публичных IP-адресов. Делайте диапазоны узкими и проверяйте фактический исходящий адрес среды выполнения и поведение при переключении на резерв.

Работает ли SMTP-аутентификация на этом релее без TLS?

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

Сколько получателей может быть в одной транзакции SMTP-релея?

Сейчас Google документирует лимит в 100 получателей на одну транзакцию smtp-relay.gmail.com. Перепроверяйте актуальную официальную страницу: лимиты провайдера и условия аккаунта могут меняться.

Нужно ли повторять запрос после ошибки пикового лимита релея?

Google описывает исчерпание пикового лимита как временное состояние. Сохраните ту же задачу и используйте ограниченную задержку, случайный разброс (jitter), лимит попыток и ограничение возраста очереди вместо немедленной массовой повторной отправки.

Означает ли приём релеем, что получатель получил письмо?

Нет. Приём релеем — лишь один этап передачи. Приём сервером получателя, последующий отказ, фильтрация в ящике, попадание во «Входящие» и реакция человека — отдельные наблюдения.

Может ли доступ к релею Google заменить SPF, DKIM и DMARC?

Нет. Авторизация релея управляет доступом к сервису Google. Аутентификация для получателей и выравнивание DMARC требуют правильных адресов отправителя, DNS-записей, подписей и проверки полученных писем.

Доказывает ли эта страница совместимость SendHQ с SMTP-релеем Google?

Нет. Сравните документированные возможности SendHQ с требованиями Google Workspace SMTP relay и используйте контролируемые тесты аутентификации, TLS, квот, ошибок и получения событий доставки.

Источники

Что почитать дальше

Как выбрать сервис SMTP-релеяОценка SMTP-релеев по безопасности отправки, аутентификации, очередям, повторным попыткам, лимитам, событиям доставки, стоп-листу, изоляции и удобству миграции.Почтовый протокол SMTP: как передаются письма приложенияКак отправка через SMTP, релей, конверты, коды ответов, TLS, повторные попытки и содержимое письма формируют процесс отправки писем приложения.SMTP-порты 25, 465 и 587: практическое руководствоВыбор SMTP-порта по роли и режиму TLS и диагностика сбоев соединения, рукопожатия, аутентификации и приёма писем.Как выбрать сервис доставляемости emailОценка сервисов доставляемости по охвату, доказательствам, аутентификации, петлям обратной связи, стоп-листам, приватности, переносимости и удобству эксплуатации.Gmail API: руководство по внедрению для продуктовых командКак внедрить доступ к Gmail API: OAuth с минимальными правами, надёжная синхронизация почтового ящика, безопасная отправка, ограниченные повторы и понятная модель сервисных аккаунтов.