НовостиМакроПравила Google и Yahoo для массовых отправителей: что должны делать компании для сохранения доставляемости писем

Правила Google и Yahoo для массовых отправителей: что должны делать компании для сохранения доставляемости писем

Автор: FinTechZoom·

Ключевые выводы

  • Google и Yahoo определяют массовых отправителей как домены, отправляющие около 5 000 и более сообщений в день, при этом объём учитывается по всем потокам почты основного домена, а не по отдельным серверам.
  • Соответствие требует SPF, DKIM, опубликованной DMARC-записи, совпадения заголовка From, заголовков однокоординатной отписки для маркетинговой почты и корректных прямой и обратной DNS.
  • Уровень жалоб на спам должен оставаться ниже 0,1% в Google Postmaster Tools, так как достижение 0,3% влечёт автоматическое попадание в спам независимо от статуса аутентификации.
  • Неаутентифицированные потоки почты сталкиваются с нарастающими штрафами: коды 4xx, попадание в спам и в конечном итоге жёсткие отказы 5xx.
  • Microsoft будет применять сопоставимые требования SPF, DKIM и DMARC для массовых отправителей Outlook.com с 2025 года, распространяя правила за пределы Google и Yahoo.
Правила Google и Yahoo для массовых отправителей: что должны делать компании для сохранения доставляемости писем

Ваши исходящие письма возвращаются с кодами ошибок 550? Получатели жалуются, что ваши сообщения попадают в папку спама, а не во входящие? На это есть явная причина. В феврале 2024 года Google и Yahoo перестали считать аутентификацию электронной почты необязательной — теперь это жёсткое требование. Для любого бизнеса, зависящего от электронной почты, игнорирование этих изменений ухудшит доставляемость, а вместе с ней и доходы.

Ключевые моменты:

  • Google и Yahoo требуют от массовых отправителей аутентифицировать исходящую почту с помощью SPF и DKIM, а также публиковать DMARC-запись.
  • Порог массового отправителя в 5 000 сообщений в день охватывает весь суммарный трафик по вашему основному домену.
  • Уровень жалоб на спам в Google Postmaster Tools должен оставаться ниже 0,1%; достижение 0,3% влечёт автоматические штрафы к доставляемости со стороны принимающих серверов.
  • Маркетинговые и подписочные письма должны поддерживать заголовки однокоординатной отписки RFC 8058.
  • Начало с p=none обеспечивает базовое соответствие, но переход к p=quarantine или p=reject важен для предотвращения подделки домена и построения долгосрочной репутации домена.

Что изменилось и почему: правила отправителей Gmail/Yahoo

Почему существуют эти правила? Коренная причина кроется в том, как изначально была устроена электронная почта. Протокол Simple Mail Transfer Protocol (SMTP), стандартизированный в 1982 году через RFC 821, не имел встроенного механизма проверки личности отправителя. Любой почтовый сервер мог передать сообщение, заявленное от любого адреса, и принимающие шлюзы принимали его — то есть любой мог с лёгкостью подделать доменное имя в видимом заголовке.

Инженеры по безопасности годами закрывали этот структурный изъян. В середине 2000-х появился SPF для проверки IP-адресов отправки по публичному DNS-списку. За ним последовал DKIM, использующий криптографию с открытым ключом, чтобы отправители могли подписывать исходящие заголовки. В 2012 году крупные отраслевые игроки опубликовали DMARC, объединяющий проверки SPF и DKIM и дающий владельцам доменов возможность устанавливать политики принудительного применения.

Годами провайдеры почтовых сервисов считали эти стандарты необязательными. Домены с SPF и DKIM получали дополнительные баллы; без них письма обычно всё равно доходили до входящих, если IP-адрес был чистым.

Это закончилось в феврале 2024 года. Как указано в руководстве Google для отправителей электронной почты, провайдеры перевели аутентификацию из разряда желательной рекомендации в разряд жёсткого требования доступа.

Вместо полной блокировки неаутентифицированной почты разом провайдеры вводили соблюдение правил поэтапно. В начале 2024 года они начали замедлять скорость соединений и возвращать временные коды отложенной доставки 4xx для неаутентифицированных потоков. В последующие месяцы они перешли к строгим кодам отказа 5xx и автоматическому помещению в спам. Microsoft быстро согласовала фильтры своих шлюзов с теми же стандартами для крупных отправителей и впоследствии объявила, что Outlook.com с 2025 года будет применять сопоставимые требования SPF, DKIM и DMARC для массовых отправителей — признак того, что эти правила становятся отраслевым стандартом, а не политикой только Google и Yahoo.

Кто считается массовым отправителем по правилам Gmail

Google определяет массового отправителя как любой домен, отправляющий примерно 5 000 и более сообщений в течение 24 часов на личные аккаунты Gmail; Yahoo применяет аналогичный стандарт. Но сосредотачиваться только на этом числе — распространённая ошибка.

Во-первых, объём рассчитывается по всему корневому домену, а не по каждому IP-адресу или имени сервера. Если маркетинговая платформа отправляет 3 500 писем рассылки, а сервер приложений отправляет 2 000 писем сброса пароля или квитанций от того же домена, порог превышен.

Во-вторых, правило распространяется на всю исходящую почту, а не только на маркетинговую. Системные уведомления, квитанции клиентам и повседневные деловые письма учитываются в дневном лимите. Любой домен, отправляющий около 3 000 сообщений в день, должен настроить полную аутентификацию, как если бы лимит уже был превышен.

Основные требования к отправителям электронной почты

Для соответствия требованиям Google и Yahoo к массовым отправителям почтовая инфраструктура должна пройти шесть технических проверок:

  1. Настроить корректные записи SPF и пары ключей DKIM для всех потоков исходящей почты.
  2. Опубликовать корректную DMARC TXT-запись в DNS домена.
  3. Убедиться, что домен в видимом заголовке «From:» совпадает с доменом, аутентифицированным через SPF или DKIM.
  4. Держать уровень жалоб пользователей на спам ниже 0,1% в Google Postmaster Tools и не допускать достижения 0,3%.
  5. Включать нативные заголовки однокоординатной отписки во все маркетинговые письма и рассылки.
  6. Обеспечить соответствие A/AAAA-записей IP-адресов отправляющих серверов и корректные записи обратного DNS (PTR).

Что произойдёт при несоблюдении требований

Провал проверок аутентификации ухудшает репутацию домена на принимающих почтовых серверах, как правило, в три этапа:

  1. Принимающие серверы отвечают кодами отложенной доставки 4xx; очереди почтового сервера переполняются, доставка задерживается на часы.
  2. Сообщения проходят через шлюз, но перенаправляются в папку спама получателя вместо основных входящих.
  3. Почтовые серверы полностью разрывают соединение и возвращают ошибки жёсткого отказа 5xx.

Как выполнить каждое требование: пошаговая инструкция

1. Настройте SPF и следите за лимитом в 10 запросов

Добавьте DNS TXT-запись в корне домена со списком всех авторизованных IP-адресов и сторонних почтовых поставщиков. Обратите внимание на лимит в 10 DNS-запросов: RFC для SPF ограничивает записи максимум 10 внешними DNS-запросами (include, a, mx, redirect). Превышение вызывает SPF PermError, который принимающие серверы считают сбоем аутентификации. Периодически проверяйте запись и удаляйте устаревшие include поставщиков, чтобы оставаться в лимите.

2. Настройте подписи DKIM на всех исходящих каналах

DKIM подписывает заголовки исходящих писем криптографической подписью, и эта функция должна быть включена для каждой платформы, отправляющей почту от имени домена. Сгенерируйте пару ключей DKIM длиной 2048 бит на портале почтового сервиса и опубликуйте открытый ключ как CNAME- или TXT-запись в DNS. После распространения DNS включите подписывание в административной консоли и проверьте необработанные заголовки тестового письма, чтобы убедиться, что заголовок DKIM-Signature присутствует и проходит проверку.

3. Опубликуйте DMARC-запись

Для соответствия базовому требованию DMARC, которое соблюдают Gmail и Yahoo, опубликуйте DMARC TXT-запись по адресу _dmarc.yourdomain.com. При первой настройке следует начать с мониторинговой политики (p=none), чтобы собирать данные отчётности без риска для доставки почты. Перед запуском проверьте DNS-запись с помощью публичного проверщика DMARC-записей, чтобы выявить синтаксические ошибки.

4. Добавьте заголовки однокоординатной отписки RFC 8058

Обычной HTML-ссылки отписки внизу письма недостаточно для маркетинговой почты. В исходящий поток необходимо внедрить два необработанных почтовых заголовка:

List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Когда клиенты вроде Gmail или Yahoo анализируют эти заголовки, они отображают заметную кнопку «Отписаться» рядом с именем отправителя в интерфейсе почтового ящика. Нажатие на неё отправляет автоматический POST-запрос на сервер, немедленно удаляя подписчика без открытия окна браузера.

5. Проверьте прямую и обратную DNS

Принимающие серверы проверяют, что IP-адрес отправки соответствует домену в DNS. IP должен разрешаться в корректное имя хоста через PTR-запись, а это имя должно разрешаться обратно в тот же IP через стандартную DNS A-запись. Операторы выделенных почтовых серверов или облачных инстансов могут изменить настройки обратного DNS в консоли провайдера или открыть тикет поддержки, чтобы сопоставить IP с полным доменным именем (FQDN) почтового сервера.

6. Отслеживайте метрики в Postmaster Tools и отчётах DMARC

Создайте аккаунт в Google Postmaster Tools и подтвердите владение доменом через DNS TXT-запись. Панель управления даёт прямую видимость репутации домена, уровня жалоб на спам и доли успешной аутентификации. Держите уровень жалоб ниже 0,1%; достижение 0,3% приведёт к тому, что Google направит почту в папку спама независимо от статуса SPF и DKIM. Для мониторинга сбоев аутентификации у всех принимающих провайдеров и выявления посторонних отправляющих IP настройте автоматизированную отчётность DMARC.

За пределами соответствия: использование правил для улучшения доставляемости

Политика p=none сама по себе оставляет домен беззащитным перед подделкой — она лишь предписывает принимающим серверам записывать данные аутентификации, но не мешает злоумышленникам выдавать себя за домен в фишинговых атаках.

Когда все легитимные потоки почты проходят выравнивание SPF и DKIM, повысьте политику DMARC до p=quarantine или p=reject. p=quarantine направляет неаутентифицированную почту прямо в спам, а p=reject отбрасывает поддельные сообщения на принимающем шлюзе.

После перехода к принудительному DMARC отправители могут опубликовать Brand Indicators for Message Identification (BIMI) — технологию, отображающую проверенный логотип бренда рядом с сообщениями во входящих получателей, что повышает узнаваемость и доверие.

Часто задаваемые вопросы о требованиях к массовым отправителям

Каков порог массового отправителя для Google и Yahoo?

Google и Yahoo определяют массовых отправителей как домены, отправляющие ~5 000 и более сообщений в день на личные аккаунты. Объём рассчитывается по всему основному домену со всеми отправляющими сервисами вместе.

Распространяются ли эти правила на транзакционные письма?

Да. Транзакционные письма, такие как сброс пароля, обновления заказов и системные оповещения, должны проходить проверки SPF, DKIM, DMARC и DNS, однако для них не требуются заголовки однокоординатной отписки.

Достаточно ли политики DMARC p=none для соответствия?

Да, p=none соответствует базовым требованиям Google и Yahoo. Однако она лишь отслеживает трафик, не блокируя подделку, поэтому рекомендуется перейти на p=quarantine или p=reject.

Что произойдёт с моей почтой при несоблюдении требований?

Провайдеры будут ограничивать SMTP-соединения кодами 4xx, направлять письма напрямую в папку спама или выдавать жёсткие отказы 5xx с полным отклонением почты.

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

После исправления гигиены списков и возврата уровня жалоб ниже 0,1% обычно требуется от 7 до 14 дней чистой отправки, чтобы Google Postmaster Tools восстановил репутацию домена.

Как проверить, превышает ли моя SPF-запись лимит в 10 запросов?

Изучите SPF TXT-запись и подсчитайте каждый механизм, вызывающий DNS-запрос. Если общее число DNS-запросов по основной и вложенным записям превышает 10, SPF-запись завершится ошибкой PermError.

Источник: FinTechZoom