Gmail і Yahoo: що оновити масовим відправникам

Коротке визначення: що означає ця фраза на практиці

Люди зазвичай запитують: «що нещодавно змінилося у вимогах Gmail і Yahoo до масових відправників і що мені оновити перш за все», бо їм потрібна швидка відповідь, а не історична довідка. Ця фраза — це операційне запитання: якщо ви надсилаєте великі обсяги, що змінилося, що зламається першим і що потрібно виправити ще до наступної кампанії? Ось у чому суть. Не в огляді політики.

Для більшості команд «масовий відправник» — це той, хто надсилає пошту у великих обсягах з однієї або кількох платформ, а не разову розсилку раз на місяць. Практична проблема проста: поштові провайдери тепер очікують чистішої, стабільнішої конфігурації відправника, і очікують цього швидко. Якщо ваша система досі працює як у 2022 році, вона може й надсилати листи. Але може й потрапляти куди не слід.

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

Пріоритетний список «що оновлювати першим»

Почніть із узгодження автентифікації відправника. Не просто «SPF є», не просто «DKIM увімкнено», а чи збігаються домен, який бачить користувач, домен підпису та домен конверта так, щоб поштовий провайдер міг це прочитати без плутанини. Якщо ці частини суперечать одна одній, повідомлення може виглядати так, ніби його надіслали з трьох різних місць. Це не найкраще враження.

Далі перевірте обробку відписки в один клік. Gmail і Yahoo підняли це з приємного бонусу до базового очікування для багатьох масових відправників, а це прямо пов’язано з вимоги Gmail і Yahoo для масових відправників. Якщо посилання для відписки заховане, не працює або веде шляхом із шістьма кліками та запитом на вхід, відправник фактично створює роботу для отримувача. А таку роботу добре запам’ятовують.

Третім кроком наведіть лад у видимій узгодженості ідентичності відправника. Якщо в полі From написано «Acme Billing», шлях для відповіді — «[email protected]», а в футері стоїть ще третій бренд, люди це помічають. Іноді навмисно. Іноді просто тому, що лист виглядає трохи «не так» уже з першої секунди.

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

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

Що саме змінилося на рівні поштових провайдерів

Недавні зміни — це не одна драматична норма, а радше жорсткіший набір очікувань. Поштові провайдери підняли планку автентифікації, стали менш поблажливими до скарг і сильніше тиснуть на узгодженість відправника. Разом це змінює те, як лист оцінюється, навіть якщо сам контент не змінився.

Один із зсувів — вищі очікування до автентифікації для листів із великим обсягом відправки. Вже недостатньо, щоб SPF-запис просто лежав у DNS, мов забутий чек. Gmail і Yahoo хочуть, щоб автентифікована пошта була автентифікована так, щоб це можна було прив’язати до видимого бренду й домену. Саме тому важлива автентифікація SPF DKIM DMARC для email; якщо ланцюжок рветься, повідомлення виглядає менш надійним.

Ще один зсув — те, як поведінка відправника читається через кілька сигналів одночасно. Скарги, реакція на відписку та повторні зміни ідентичності тепер важать більше разом, ніж окремо. Список може бути «дозволеним» і водночас працювати погано, якщо отримувачі постійно сигналізують, що не хочуть цієї пошти. Саме це багато хто не враховує.

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

Якщо вам потрібен ширший контекст щодо цих сигналів для доставлюваності, корисною базою буде стаття про кращі практики доставлюваності електронної пошти. Але ця публікація вужча: що змінилося і що оновити для масових email-розсилок. Без великої теорії.

Які зміни, видимі для вхідних, треба перевірити швидко

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

Потім перевірте домен From і видиму ідентичність відправника. Якщо ваша компанія володіє трьома доменами, а кампанія використовує четвертий, лист, можливо, і відобразиться, але історія відправника стане розмитою. Люди часто просять технічне виправлення, коли проблема в тому, що лист виглядає так, ніби його надіслали з іншого відділу. І справді так виглядає.

Розміщення посилання для відписки — ще одна перевірка, яку видно одразу. Посилання має бути легко знайти у футері, а шлях має працювати без зайвих сюрпризів. Приховане або зламане посилання для відписки не робить список сильнішим. Воно лише скорочує шлях до скарги.

Подивіться, чи повідомлення виглядають так, ніби вони надходять з однієї стабільної ідентичності у всіх кампаніях. Якщо одна кампанія відправляється з «[email protected]», наступна — з «[email protected]», а відповіді підтримки йдуть ще кудись, поштові провайдери бачать розбіжність. Її бачать і отримувачі. Розбіжність коштує дорого.

Якщо проблема неочевидна для людей, але все одно впливає на потрапляння у вхідні, порівняйте налаштування з налаштуванням автентифікації електронної пошти для транзакційних листів. Механіка досить схожа, щоб виявити базові помилки: узгодження доменів, автентифіковані заголовки та ідентичність відправника, яка не змінює форму між інструментами.

Перші налаштування, які варто перевірити у вашому інструменті для email

Відкрийте налаштування ESP або MTA й знайдіть сторінку налаштування домену. Саме там починається перша справжня робота. Переконайтеся, який домен підписує лист, який домен відображається в From і який домен обробляє bounce-повідомлення. Якщо це задають три різні людини в трьох різних вкладках, перше оновлення — це координація.

Далі перевірте записи автентифікації. SPF має містити сервіс, який ви справді використовуєте для відправки, DKIM має підписуватися правильним доменом, а DMARC не повинен просто лежати як декоративний запис без реального політичного наміру. Запис, який існує, але не покриває живий шлях відправки, — це не рішення. Це паперова формальність.

Потім відкрийте конфігурацію відписки. Переконайтеся, що механізм one-click увімкнено там, де ваш інструмент це підтримує, і що він прив’язаний до правильного сегмента аудиторії. Якщо відписки з маркетингу все ще потрапляють у чергу підтримки, система імітує відповідність, додаючи затримку. А затримка дратує людей.

Перевірте також поведінку заголовків за замовчуванням. Деякі платформи автоматично додають футери, list IDs, адреси reply-to або мітки кампанії. Це корисно, доки стандартні налаштування не почнуть вказувати на неправильну ідентичність відправника. Чистий шаблон усе ще може надсилати неохайну пошту, якщо платформа додає неправильні заголовки в бекенді. За інструментом — останнє слово.

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

Типові ситуації «я змінив одну річ, а проблеми залишилися»

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

Ще одна поширена проблема — відписка технічно доступна, але не враховується всюди. Можливо, платформа розсилки обробляє її правильно, а сестринський інструмент надсилає оновлення для клієнтів і ігнорує ту саму перевагу. Тоді підписник думає, що відписався, але система все ще надсилає листи через інші двері. Саме так і починаються скарги.

Коли кілька інструментів надсилають листи під різними ідентичностями, це створює власний хаос. CRM, продуктова система та маркетингова платформа можуть кожна відправляти листи «від» одного бренду, але з різними доменами, різними адресами reply-to та різними шляхами відписки. У результаті одна компанія звучить як три різні. І поштові провайдери, і отримувачі це бачать.

Ще один сценарій — коли очищення відбувається лише в маркетинговому інструменті, а DNS не чіпають. Кампанія виглядає виправленою в інтерфейсі, але записи в DNS усе ще відповідають старому налаштуванню. Така невідповідність може тягнутися днями. І довше, якщо за DNS ніхто не відповідає.

Якщо плутанина пов’язана з bounce та скаргами, порівняйте ваш процес із кращими практиками обробки bounce-повідомлень. Відправник, який правильно обробляє відписки, але неправильно працює з bounce, усе ще подає змішані сигнали. Платформа ці сигнали помічає.

Мінімальний чекліст для оновлення в той самий день

1. Переконайтеся, що видиме ім’я в From відповідає бренду, який очікує отримувач.

2. Перевірте SPF, DKIM і DMARC на активному домені відправки.

3. Увімкніть відписку в один клік, якщо ваш ESP це підтримує, і протестуйте її один раз.

4. Переконайтеся, що посилання для відписки видно у футері та воно працює на мобільному.

5. Перевірте, що домен відправки, домен reply-to та домен bounce не суперечать один одному.

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

7. Надішліть тестовий лист, щоб побачити, що реально бачить отримувач, а не те, що показує панель.

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

Це той чекліст, який команда може закрити до обіду. Він не гламурний. Він працює. Якщо вам потрібно нагадування про те, як уподобання відправника пов’язані зі здоров’ям списку, стаття чому важливі кращі практики відписки від email показує сторону користувача тієї самої проблеми без зайвого шуму.

Коли варто ескалювати до DNS, ESP або юридичної перевірки

Залучайте власника DNS, коли потрібна зміна стосується SPF, DKIM, DMARC, піддоменів або будь-якого запису, який ви не можете безпечно редагувати всередині email-інструменту. Ці зміни невеликі в тексті, але великі за наслідками. Неправильне редагування DNS може зупинити пошту, а це швидкий спосіб зіпсувати запуск.

Залучайте адміністратора ESP або MTA, коли проблема криється в дефолтних налаштуваннях платформи, поведінці заголовків або механіці відписки. Маркетолог може помітити симптом, але змінювати параметр зазвичай має власник платформи. Якщо інструмент надсилає з черги, яку ви не контролюєте, просіть допомоги заздалегідь. Не після кампанії.

Залучайте юристів або фахівців із комплаєнсу, коли у зміні бере участь мова про згоду, логіка suppression або регіональні правила відписки. Це особливо важливо, якщо одна система обробляє розсилки, інша — повідомлення про продукт, а третя — акаунтні сповіщення. Одна аудиторія може мати три різні правові режими. Це звучить хаотично, бо так і є.

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

Для команд, яким потрібна видимість на рівні подій після цих змін, події email webhook для транзакційних листів можуть допомогти пов’язати відправки, bounce і відкриття з реальною поведінкою системи. Це корисно, коли одна платформа каже «надіслано», а інша — «призупинено», що трапляється напрочуд часто.

І останнє практичне правило: якщо для виправлення потрібно торкнутися двох систем або більше, запишіть власника кожного кроку до того, як щось змінювати. Сама кількість незначна, але помилки зазвичай трапляються на передачі. Чисте оновлення рідко буває наслідком одного кліка.