Требования Gmail и Yahoo к отправителям в 2024

Что изменилось в требованиях Gmail и Yahoo к отправителям в 2024 году

В 2024 году Gmail и Yahoo ужесточили правила для отправителей, потому что почтовые ящики захлестнули поддельные письма, низкокачественные массовые рассылки и неряшливые практики работы со списками. Эти изменения касались не только крупных брендов. Обычные отправители тоже ощутили их на себе — особенно те, кто ежемесячно отправляет письма тысячам получателей или ведёт и транзакционные, и маркетинговые рассылки с одного домена. Одна проблемная настройка теперь может навредить сильнее, чем раньше.

Коротко говоря, письма должны быть проще для проверки, проще для отписки и проще для отслеживания до реального отправителя. На словах это звучит просто. На практике — совсем нет. Многие команды поняли это на собственном опыте, когда письма начали попадать в спам или отклоняться, хотя для человека они выглядели вполне нормально. Если вам нужен технический контекст, статья о настройке аутентификации email для транзакционных писем подробнее разбирает базовые элементы.

Эти правила в первую очередь затрагивают массовых отправителей, но не только их. Малому бизнесу, который отправляет чеки заказов, напоминания о встречах и еженедельную рассылку с одного домена, тоже нужно быть внимательным. Если идентичность отправителя выглядит неаккуратно, Gmail и Yahoo могут считать весь поток менее надёжным. В этом и заключается неприятный момент.

Теперь для отправки писем ожидается аутентификация

SPF, DKIM и DMARC — именно эти названия чаще всего звучали в 2024 году, и не зря. Gmail и Yahoo ожидают аутентифицированную почту, потому что аутентификация подтверждает, что отправитель имеет право отправлять письма от имени домена или, как минимум, предпринял серьёзную попытку обозначить, кто за это отвечает. Проще говоря, неаутентифицированная почта очень быстро выглядит подозрительно. Именно поэтому требования Gmail и Yahoo к отправителям 2024 года так часто сводятся к базовой, но строгой проверке источника письма.

SPF проверяет, разрешён ли отправляющий сервер для данного домена. DKIM подписывает сообщение, чтобы получатель мог понять, не менялось ли содержимое после отправки. DMARC связывает эти две вещи и сообщает получателям, что делать, если выравнивание не прошло. Если какого-то из этих элементов нет, письма всё ещё иногда могут приниматься, но риск возрастает. В практическом смысле это и есть SPF DKIM DMARC для email — не абстрактный набор букв, а основа доверия к отправке.

Не считайте аутентификацию одноразовой галочкой. DNS-записи устаревают. Настройки ESP меняются. Команда переносит платформу и забывает старый домен отправки. И тогда система, которая вроде бы «работает», начинает тихо сбоить. Тихие сбои — самые неприятные.

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

Ещё один важный нюанс: Gmail и Yahoo обращают внимание не только на сам факт успешной аутентификации, но и на постоянство идентичности. Сообщение, которое проходит SPF, но отправляется с необычного поддомена, а DKIM подписывается другим доменом, всё равно может выглядеть неряшливо. А неряшливая почта вызывает меньше доверия. Почтовые ящики терпеливы, но не настолько.

Требования к отписке в один клик и чистоте списков

Правила 2024 года серьёзно усилили значение простой отписки. Если получатель хочет выйти из рассылки, процесс должен быть очевидным и быстрым. Не спрятанным в крошечном футере. Не скрытым за входом в аккаунт. Не сломанным из-за тяжёлой JavaScript-страницы, которая не работает на мобильных устройствах. Отписка в один клик больше не просто приятное дополнение; именно отписка в один клик Gmail Yahoo рассматривают как обязательный элемент корректной работы рассылки.

Управление списками с учётом удобства для почтовых сервисов важно по той же причине. Если люди продолжают получать письма, которые им не нужны, они скорее нажмут «это спам», чем будут искать ссылку для отписки. Такая жалоба быстро наносит ущерб. Вовлечённые списки помогают, потому что открытия, клики, ответы и долгосрочное взаимодействие показывают Gmail и Yahoo, что отправитель релевантен. Мёртвый список рассказывает противоположную историю.

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

Именно поэтому многие команды объединяют работу над отпиской с лучшими практиками обработки bounce-ошибок email и процессами подавления адресов. Bounce, отписка и жалоба должны вести к одному базовому результату: перестать отправлять письма на этот адрес, если только получатель не подпишется снова.

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

Правила для поля From, выравнивания доменов и идентичности отправителя

Идентичность отправителя в 2024 году стала заметнее. Отображаемое имя, адрес From, домен подписи и обратный путь должны логично сочетаться друг с другом. Если клиент получает счёт с одного домена, а сообщение подписано другим доменом и ответ уходит ещё куда-то, письмо вызывает сомнения. То же самое делают и фильтры.

Выравнивание доменов важно, потому что оно связывает видимый бренд с техническим отправителем. Фирменные домены отправки обычно работают лучше, чем случайные общие схемы, но только если брендинг выдержан последовательно. Компания, которая отправляет письма как «Биллинг команда» с billing@brand.com и подписывает их DKIM с того же домена бренда, выглядит организованно. Компания, которая шлёт письма с маркетингового алиаса на одном домене, а bounce-адрес ведёт на другой домен, выглядит фрагментированно.

Вот момент, на котором команды часто спотыкаются при ребрендинге. Изменить отображаемое имя легко. А вот менять домен отправки, селекторы DKIM, обработку ответов и почтовые ящики поддержки — дольше. Если эти четыре элемента не меняются вместе, доставляемость может пострадать. Не сразу, иногда. А потом, и это уже сложнее.

Одна практичная проверка — отправить письмо на аккаунт Gmail и посмотреть заголовки. Если видимый отправитель и аутентифицированный отправитель не совпадают, исправьте это до следующей кампании. Это займёт 10 минут. И может сэкономить неделю жалоб.

Команды, которые дорабатывают более общие правила идентичности отправителя, часто сравнивают их с лучшими практиками deliverability email, потому что выравнивание — это не просто одна запись в DNS. Это весь путь от шаблона до входящих.

Порог жалоб на спам и влияние на репутацию

Gmail и Yahoo смотрят на жалобы, bounce-ошибки и сигналы репутации. Это не новость 2024 года, но контроль стал строже. Числовые пороги легко повторять, но им трудно доверять, если не сверяться с актуальными рекомендациями провайдера. Тем не менее направление понятно: уровень жалоб должен оставаться низким, а согласие — чистым.

Репутация формируется со временем. Отправитель, который годами был надёжным, всё равно может столкнуться с проблемами, если начнёт массово слать письма по неактивным контактам или покупать списки. Отправитель с высокой вовлечённостью иногда переживает неудачную кампанию, но только до определённого момента. Фильтры помнят шаблоны поведения.

Самая большая ошибка — считать, что проблему вызвала одна кампания. Часто виновата десятая подряд, которая была слишком агрессивной. Иногда это тихая куча bounce-ошибок с прошлого квартала. Иногда — список, импортированный с выставки без реального согласия на подписку. Один плохой источник списка может испортить несколько рассылок.

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

Какие технические настройки отправителям стоит пересмотреть

В 2024 году многим командам пришлось снова погружаться в DNS, и это не так уж плохо. Начните с записей SPF, DKIM и DMARC. Затем проверьте, опубликованы ли они на правильном домене и использует ли сервис отправки тот же домен, который видит получатель. Одна отсутствующая TXT-запись может запустить цепочку сбоев.

Reverse DNS тоже важен, особенно для команд, которые используют собственную инфраструктуру. Если IP-адрес не указывает на понятный hostname, некоторые фильтры будут считать письмо менее качественным. TLS тоже важен, потому что шифрование при передаче помогает защитить письма в пути и сигнализирует о более современной, менее небрежной настройке. Всё это не выглядит эффектно. Но всё это имеет значение.

Если в вашем стеке есть пользовательская прикладная почта, настройки SMTP relay тоже стоит пересмотреть. Статья о том, что означает SMTP relay для node.js, простым языком объясняет сторону ретрансляции, что помогает, когда часть почтового пути контролируют разработчики, а другую часть — маркетинг.

Есть и мелкие, но важные детали помимо DNS. Проверьте имя HELO, репутацию отправляющего IP, заголовок «From», envelope sender и то, разделены ли почтовые потоки по назначению. Транзакционную почту лучше не смешивать с рекламными массовыми рассылками, если этого можно избежать. Сброс пароля должен идти по более чистому пути, чем пятничная распродажа.

Ещё одна техническая деталь, которую слишком часто игнорируют: протестируйте endpoint отписки и на мобильном, и на десктопе, а также при медленном соединении. Ссылка, которая работает во внутрикорпоративной идеальной сети, всё равно может не сработать у реального клиента. А такая ошибка превращается в жалобу в один клик.

Что бизнесу и маркетологам нужно сделать сейчас

Начните с аудита всех доменов и поддоменов, с которых отправляются письма. Составьте список типов писем, используемого ESP или сервера и настроек аутентификации. Затем сравните этот список с тем, что получатели действительно видят в своих входящих. Если одна и та же компания использует три разных адреса From для одной цели, сначала приведите это к единому виду.

Далее пересмотрите шаблоны и футеры. Сделайте путь отписки очевидным. Уберите старые адреса. Проверьте, помогают ли центры предпочтений или, наоборот, запутывают людей. Центр предпочтений может быть полезен, но только если он снижает трение, а не создаёт его. Если человеку нужно сделать пять кликов, чтобы покинуть список, это уже слишком много.

Потом согласуйте действия с ESP или ИТ-командой. Узнайте, кто управляет SPF, кто отвечает за ключи DKIM и кто обновляет политику DMARC. Узнайте, кто отслеживает bounce-ошибки и кто получает жалобы на злоупотребления. Если никто не отвечает за эти задачи, назначьте ответственных уже сегодня. Программа отправки без владельцев обычно начинает «плыть».

Команды, которым нужен более чистый процесс, часто объединяют эту работу с email webhook events для транзакционных писем, потому что и события доставки, и события отписки должны куда-то поступать. Данные полезны только тогда, когда их кто-то читает.

Не пропускайте тестирование. Отправьте письма в Gmail, Yahoo и ещё в один-два почтовых сервиса. Проверьте попадание во входящие. Посмотрите заголовки. Нажмите на ссылку отписки. Сгенерируйте bounce в безопасной тестовой среде, если ваша конфигурация это позволяет. Затем исправьте то, что ломается, до следующей реальной отправки. Такой порядок экономит неловкость.

Распространённые ошибки и как их избежать

Отсутствие аутентификации всё ещё остаётся самой очевидной ошибкой и одной из самых простых для устранения. Корректно настройте SPF, DKIM и DMARC, а затем убедитесь, что они совпадают с фактическим доменом отправки. Запись в DNS сама по себе не помогает, если приложение отправляет письма по другому пути.

Сломанные ссылки отписки — ещё одна частая проблема. Иногда ссылка ведёт на staging-сайт. Иногда endpoint не отвечает вовремя. Иногда страница открывается, но запрос так и не попадает в список подавления. Это плохой день для отправителя и ещё худший для получателя.

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

Плохие практики сбора адресов создают долгосрочный ущерб. Купленные списки, собранные парсингом списки и расплывчатые конкурсы с «подпиской» могут привести к жалобам, которые будут тянуться долго. Лучший путь медленнее, но чище: явное согласие, понятные ожидания и документированный источник для каждого адреса. Всё меньшее создаёт работу позже.

Некоторые команды также забывают управлять suppression-списками после отписок или hard bounce. В итоге письма снова уходят тем, кто уже отказался от рассылки, а это и рискованно, и легко избежать. Если ваш текущий процесс по-прежнему живёт в таблицах и в памяти людей, стоит посмотреть руководство по управлению suppression-списками email · YourTrend.

И наконец, ещё одна ошибка — считать, что правила 2024 года являются разовым событием. Это не так. Gmail и Yahoo подняли планку и могут продолжать её корректировать. Любой, кто спрашивает, что изменилось в требованиях Gmail и Yahoo к отправителям в 2024 году, должен воспринимать ответ как отправную точку, а не как финиш, потому что настоящая задача — поддерживать чистоту программы отправки неделя за неделей.