Пошта

Вимоги Яндекса до чесних розсилок

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

Документ основано на практиці найбільших провайдерів і поштових служб, відповідає нормам і рекомендаціям ASTA, а також «Нормам користування мережею». Алгоритм розділення розсилок і спаму є ноу-хау компанії, не публікується і не обговорюється.

Що має бути у чесної розсилки:

  1. Процес підписки:

    • (Обов'язк.) Розсилка повинна здійснюватися лише на явну вимогу або за згодою одержувача.
    • (Обов'язк.) Адресу одержувача розсилки має бути явним чином підтверджено самим одержувачем.
    • У разі додавання в лист розсилки адреси одержувачів повинні пройти валідацію.

  2. Процес відмови від підписки:
    • (Обов'язк.) У кожному листі мають бути чіткі інструкції про те, як відписатися від розсилки. При цьому процес відписування не повинен вимагати від одержувача складних дій, таких, як відновлення пароля, реєстрація або авторизація. Одержувач повинен мати можливість відписатися від розсилки впродовж 10 хвилин.
    • У тілі листа має бути явно зазначено адресу підписника.
    • (Обов'язк.) У листі має бути використано заголовок list-unsubscribe, оформлений за стандартом RFC. У разі переходу за посиланням із цього заголовка користувач має бути негайно відписаний від розсилки.
    • (Обов'язк.) Для відписки необхідно зазначати лише дійсні посилання.
  3. Заголовок листа:

    • Тема повідомлення має бути зрозумілою користувачеві та не повинна вводити його в оману.
    • Тема повідомлення має бути однаковою для усіх листів однієї розсилки.
    • (Обов'язк.) У полі Від кого має бути зазначено реально існуючу електронну адресу, що асоціюється з джерелом розсилки. Якщо повідомлення, що надходять на цю адресу, обробляються роботом, то у відповідь мають надходити ясні та чіткі інструкції, що дозволяють зв'язатися з вашою службою підтримки.

  4. Коректність мережевої ідентифікації:

    • (Обов'язк.) Програмне забезпечення, що здійснює розсилку, має перевіряти отримані відповіді. Якщо приймаючий сервер відповідає, що зазначеного користувача не існує, то розсилку за цією адресою має бути призупинено.
    • (Обов'язк.) Хост, що здійснює розсилку, повинен мати постійну IP-адресу із коректно налаштованим зворотним DNS-запитом. При цьому реєстраційні дані власника домену мають бути актуальними і доступними публічно за протоколом WHOIS.
    • Для коректної ідентифікації доменне ім'я має бути змістовним, а не бути автоматичною адресою на зразок x.y.z.w-in-addr-arpa або dsl-4-3-2-1.provider.net.
    • Хост, що здійснює розсилку, повинен відрізнятися від хоста, що надсилає звичайну кореспонденцію.
    • (Якщо попередню вимогу виконати неможливо). Доменне ім'я в полі From повинне відрізнятися від доменного імені, використовуваного для регулярного листування, і вказувати на джерело кореспонденції. Наприклад, для домену example.ua сповіщення про нові повідомлення на форумі повинні надсилатися з домену forum.example.ua, а підписка на новини сайту — з домену news.example.ua тощо.
    • (Обов'язк.) Усі повідомлення мають бути підписані за допомогою ключа DKIM чи DMARC (або має бути налаштовано SPF-запис домену).

  5. Інші вимоги:

    • Не можна змінювати інформацію про відправника або про цільову сторінку для будь-яких посилань у листах.
    • Не рекомендовано використовувати скорочені посилання.
    • Усі посилання в тексті повинні бути зазначені у вигляді повного доменного імені: не можна використовувати як посилання IP-адреси або перекодовані імена доменів (URL Encoded).
    • (Обов'язк.) У листі мають бути стандартні заголовки, використовувані у разі масових або автоматичних розсилок, — наприклад, Precedence: bulk (junk, list, list-unsubscribe тощо). Усі посилання в них повинні дозволяти відписатися від розсилки автоматично.
    • Заголовки і формат повідомлення повинні відповідати вимогам RFC 5322 і стандарту MIME. Крім того, у повідомленні мають бути коректні заголовки Date і Message-ID.
    • Для кожної частини повідомлення має бути зазначено реально використовуване кодування. Повідомлення з текстами у двох кодуваннях одночасно недопустимі.
    • Якщо розсилка здійснюється у форматі HTML, у листі неприпустимо використовувати елементи JavaScript, ActiveX та інші потенційно небезпечні об'єкти.

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

Також ви можете ознайомитися з Принципами взаємодії Яндекса з іншими мережами.

моя розсилка потрапляє у спам
розсилка потрапляє у спам
правила розсилок
розсилка листів