Что обновить в Gmail и Yahoo для массовых рассылок

Короткое определение: что эта фраза значит на практике

Обычно люди спрашивают: «Что недавно изменилось в требованиях Gmail и Yahoo к массовым отправителям и что мне нужно обновить в первую очередь?» — потому что им нужен быстрый ответ, а не лекция по истории. Эта фраза — про работу в реальных условиях: если вы отправляете письма большими объёмами, что изменилось, что ломается первым и что нужно исправить до следующей кампании? В этом и есть суть. Не пересказ политики.

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

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

Приоритетный список того, что нужно обновить в первую очередь

Начните с согласованности аутентификации отправителя. Не просто «SPF есть» и не просто «DKIM включён», а соответствует ли видимый домен отправителя, домен подписи и домен envelope так, чтобы почтовый провайдер мог прочитать это без путаницы. Если эти части расходятся, письмо может выглядеть так, будто пришло сразу из трёх разных мест. Это не лучший вид.

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

Третьим шагом наведите порядок в видимой идентичности отправителя. Если в поле From указано «Acme Billing», обратный путь — «[email protected]», а в футере ещё один бренд, это бросается в глаза. Иногда специально. Иногда просто потому, что письмо выглядит не так, как надо, даже если на долю секунды.

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

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

Что именно изменилось на уровне почтовых провайдеров

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

Один из сдвигов — более строгие ожидания по аутентификации для писем с большим объёмом. Уже недостаточно, чтобы SPF просто лежал в DNS как забытый чек. Gmail и Yahoo хотят, чтобы аутентифицированная почта была аутентифицирована так, чтобы её можно было связать с видимым брендом и доменом. Если цепочка рвётся, письмо выглядит менее надёжным.

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

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

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

Какие изменения, заметные пользователю во входящих, нужно проверить срочно

Сначала проверьте имя в поле From. Соответствует ли оно бренду, который ожидает подписчик? Напоминание об оплате от «Team Updates» и запуск продукта от «Client Services» могут работать, но не должны выглядеть как случайная почта от посторонних отделов. Последовательность даёт узнаваемость за секунду или меньше.

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

Размещение ссылки на отписку — ещё одна видимая проверка. Ссылку должно быть легко найти в футере, и она должна работать без неожиданного трения. Скрытая или сломанная ссылка на отписку не делает список сильнее. Она лишь сокращает путь к жалобам.

Посмотрите, выглядят ли сообщения так, будто они приходят от одной стабильной идентичности в разных кампаниях. Если одна кампания идёт с «[email protected]», следующая — с «[email protected]», а ответы поддержки снова уходят куда-то ещё, почтовые провайдеры видят дрейф. Получатели тоже его видят. Дрейф стоит дорого.

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

Первые настройки, которые стоит проверить в вашем email-инструменте

Откройте настройки ESP или MTA и найдите страницу настройки домена. Именно там начинается первая реальная работа. Проверьте, какой домен подписывает письмо, какой домен указан в From и какой домен обрабатывает возвраты. Если это настраивали три разных человека в трёх разных вкладках, первое обновление — это координация.

Дальше проверьте записи аутентификации. SPF должен включать реально используемый сервис отправки, DKIM должен подписывать письма правильным доменом, а DMARC не должен просто лежать как декоративная запись без намерения применяться. Запись, которая существует, но не покрывает живой путь отправки, — это не исправление. Это бумажная работа.

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

Проверьте и поведение заголовков по умолчанию. Некоторые платформы автоматически добавляют футеры, list ID, адреса reply-to или метки кампаний. Это полезно, пока значения по умолчанию не начинают указывать на неправильную идентичность отправителя. Чистый шаблон всё равно может отправлять неаккуратную почту, если платформа подставляет не те заголовки в фоне. Последнее слово остаётся за инструментом.

Для операторов, которым нужен более широкий набор проверок перед изменением живых настроек, руководство по инструментам тестирования email deliverability · YourTrend поможет заметить пробелы в конфигурации до отправки кампании. Тестирование дешевле, чем исправлять последствия неудачной рассылки. Обычно намного дешевле.

Частые ситуации «я поменял одну вещь, а проблемы остались»

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

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

Несколько инструментов, отправляющих письма под разными идентичностями, создают свой собственный хаос. CRM, продуктовая система и маркетинговая платформа могут отправлять письма «от» одного бренда, но с разными доменами, разными адресами reply-to и разными путями отписки. В результате одна компания звучит как три. Это видят и провайдеры, и получатели.

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

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

Минимальный чек-лист для обновления в тот же день

1. Проверьте, что видимое имя From совпадает с брендом, который ожидает получатель.

2. Проверьте SPF, DKIM и DMARC для активного домена отправки.

3. Включите отписку в один клик, если ваш ESP это поддерживает, и один раз протестируйте её.

4. Убедитесь, что ссылка на отписку видна в футере и работает на мобильных устройствах.

5. Проверьте, что домен отправки, домен reply-to и домен возвратов не противоречат друг другу.

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

7. Отправьте тестовое письмо и посмотрите, что реально видит получатель, а не что утверждает панель управления.

8. Поставьте кампанию на паузу, если для любого из пунктов нужно изменение DNS, которое ещё не успело распространиться. Подождать 20 минут дешевле, чем объяснять неудачную рассылку.

Такой чек-лист команда может закрыть до обеда. Он не гламурный. Но он работает. Если нужен ещё один ориентир о том, как предпочтения отправителя связаны со здоровьем списка, статья почему важны best practices для отписки по email даёт пользовательский взгляд на ту же проблему без лишнего шума.

Когда стоит эскалировать к DNS, ESP или юристам

Поднимайте вопрос к владельцам DNS, если нужное изменение затрагивает SPF, DKIM, DMARC, поддомены или любую запись, которую нельзя безопасно править внутри email-инструмента. Эти изменения маленькие по тексту и большие по последствиям. Ошибочное изменение DNS может остановить почту — это быстрый способ испортить запуск.

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

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

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

Для команд, которым нужна видимость на уровне событий после таких изменений, email webhook events для transactional emails помогут связать отправки, возвраты и открытия с реальным поведением системы. Это полезно, когда одна платформа говорит «отправлено», а другая — «подавлено», что, как ни странно, встречается очень часто.

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