Вимоги Gmail і Yahoo до відправників у 2024

Що змінилося в вимогах Gmail і Yahoo до відправників у 2024 році

У 2024 році Gmail і Yahoo посилили правила для відправників, бо скриньки переповнювалися підробленими листами, неякісною масовою розсилкою та недбалою роботою зі списками. Саме тому запит на кшталт "вимоги Gmail і Yahoo до відправників 2024" став таким частим: зміни стосувалися не лише великих брендів. Їх відчули й звичайні відправники, особливо ті, хто надсилає листи тисячам отримувачів щомісяця або веде змішані транзакційні та маркетингові розсилки з одного домену. Одна зламана схема тепер може нашкодити сильніше, ніж раніше.

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

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

Тепер для відправлення листів очікується автентифікація

SPF, DKIM і DMARC — саме ці назви найчастіше звучали у 2024 році, і недаремно. Поширена автентифікація email SPF DKIM DMARC стала базовою вимогою, бо Gmail і Yahoo очікують автентифіковану пошту, а автентифікація доводить, що відправник має право надсилати листи від імені домену або принаймні зробив серйозну спробу чітко вказати, хто керує розсилкою. Простими словами, неавтентифіковані листи швидко виглядають підозріло.

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

Не сприймайте автентифікацію як разову галочку в чеклісті. DNS-записи змінюються. Налаштування ESP оновлюються. Команда мігрує на нову платформу і забуває про старий домен відправлення. А потім «робоча» система починає тихо давати збій. Саме тихі збої найгірші.

Якщо вашій команді потрібна структурована відправна точка, матеріал про налаштування DKIM SPF DMARC для транзакційних листів стане корисним доповненням, коли ви розкладаєте по поличках усі складові маркетингових і транзакційних потоків.

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

Очікування щодо one-click unsubscribe і гігієни списків

Правила 2024 року зробили реальним пріоритетом просте відписування. Саме тому вимога one-click unsubscribe Gmail Yahoo стала одним із найпомітніших нових орієнтирів: якщо отримувач хоче вийти зі списку, процес має бути очевидним і швидким. Не захованим у дрібному футері. Не схованим за логіном. Не зламаним через сторінку з купою JavaScript, яка не працює на мобільному. One-click unsubscribe більше не є приємним бонусом.

Керування списками з позиції поштових сервісів важливе з тієї самої причини. Якщо люди й надалі отримують листи, які їм не потрібні, вони частіше натиснуть «спам», замість того щоб шукати посилання для відписки. Така скарга швидко завдає шкоди. Активні списки допомагають, бо відкриття, кліки, відповіді та довгострокова взаємодія показують Gmail і Yahoo, що відправник доречний. Мертвий список розповідає протилежну історію.

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

Саме тому багато команд поєднують роботу з відпискою з кращими практиками обробки email-bounce та процесами блокування адрес. Bounce, відписка й скарга мають приводити до одного базового результату: не надсилати на цю адресу листи, якщо отримувач знову не погодиться на розсилку.

Деякі команди досі питають, чи не шкодить видиме посилання для відписки залученню. Ні, не шкодить. Якщо приховати вихід, люди частіше натиснуть кнопку «спам», а це гірший результат для всіх.

Правила щодо поля From, вирівнювання доменів і ідентичності відправника

У 2024 році ідентичність відправника стала помітнішою. Ім’я в полі «From», адреса From, домен підпису та return path мають логічно збігатися між собою. Якщо клієнт отримує рахунок з одного домену, але лист підписано іншим доменом, а відповідь іде ще кудись окремо, повідомлення виглядає підозріло. Так само й фільтри.

Вирівнювання доменів важливе, бо воно поєднує видимий бренд із технічним відправником. Брендовані домени для відправки зазвичай працюють краще, ніж випадкові спільні схеми, але лише за умови, що брендинг послідовний. Компанія, яка надсилає листи як «Billing Team» з billing@brand.com і підписує їх DKIM тим самим брендовим доменом, виглядає організованою. Компанія, яка надсилає розсилку з маркетингового псевдоніма на одному домені, а bounce спрямовує на інший, виглядає роздробленою.

Ось момент, на якому команди часто спотикаються під час ребрендингу. Змінити назву в полі відображення легко. А ось змінити домен відправлення, DKIM-селектори, обробку відповідей і поштові скриньки підтримки — це вже довше. Якщо ці чотири елементи не рухаються разом, deliverability може постраждати. Не одразу, іноді. Пізніше, а це вже складніше.

Одна практична перевірка — надіслати лист на акаунт Gmail і переглянути заголовки. Якщо видимий відправник і автентифікований відправник не збігаються, виправте це ще до наступної кампанії. Це займе 10 хвилин. І може зекономити тиждень скарг.

Команди, які вдосконалюють ширші правила ідентичності відправника, часто порівнюють їх із кращими практиками email deliverability, адже вирівнювання — це не лише один запис у 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 name, репутацію IP відправлення, заголовок «From», envelope sender і те, чи розділений потік листів за призначенням. Транзакційні листи не варто змішувати з промо-розсилками, якщо цього можна уникнути. Скидання пароля потребує чистішого шляху, ніж п’ятничний розпродаж.

Одна технічна деталь, яку занадто часто ігнорують: протестуйте endpoint відписки з мобільного й десктопа, а також на повільному з’єднанні. Посилання, яке ідеально працює у внутрішній мережі, може не спрацювати для реального клієнта. А ця помилка перетворюється на скаргу одним кліком.

Що бізнесу та маркетологам варто зробити зараз

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

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

Потім узгодьте дії з ESP або IT-командою. Запитайте, хто відповідає за SPF, хто керує DKIM-ключами і хто оновлює політику DMARC. Запитайте, хто моніторить bounce і хто отримує скарги на зловживання. Якщо ніхто не відповідає за ці завдання, призначте відповідальних сьогодні. Програма розсилок без власників має властивість поступово роз’їжджатися.

Команди, які хочуть вибудувати чистіший процес, часто поєднують цю роботу з подіями email webhook для транзакційних листів, бо і події доставки, і події відписки мають кудись потрапляти. Дані корисні лише тоді, коли їх хтось читає.

Не пропускайте тестування. Надішліть листи на Gmail, Yahoo та ще один-два поштові провайдери. Перевірте, куди потрапило повідомлення — в inbox чи ні. Перегляньте заголовки. Натисніть посилання для відписки. Спробуйте згенерувати bounce, якщо ваша схема дозволяє це зробити в безпечному тестовому середовищі. Потім виправте те, що зламалося, ще до наступного реального відправлення. Така послідовність рятує від незручностей.

Поширені помилки та як їх уникнути

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

Зламані посилання для відписки — ще одна поширена проблема. Іноді посилання веде на staging-сайт. Іноді endpoint перевищує тайм-аут. Іноді сторінка працює, але запит так і не потрапляє до списку блокування. Для відправника це поганий день, а для отримувача — ще гірший.

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

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

Деякі команди також забувають керувати блокуваннями після відписок або жорстких bounce. Це призводить до повторного надсилання людям, які вже відмовилися від розсилки, а це і ризиковано, і легко уникнути. Якщо ваш поточний процес досі живе в таблицях і пам’яті, варто переглянути гайд про керування suppression list для email · YourTrend.

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