Почта (старый интерфейс)
Дополнительные возможности

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

Настоящий документ отражает представление компании «Яндекс» о честных рассылках. Он не является офертой и не влечет за собой никаких обязательств со стороны компании и ее почтовой службы перед сервисами, осуществляющими массовые рассылки.

Документ основан на сложившейся практике крупнейших провайдеров и почтовых служб, соответствует нормам и рекомендациям 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.ru уведомления о новых сообщениях на форуме должны отправляться из домена forum.example.ru, а подписка на новости сайта — из домена news.example.ru и т. п.
    • (Обяз.) Все сообщения должны быть подписаны с помощью ключа DKIM или DMARC (либо должна быть настроена SPF-запись домена).

  5. Другие требования:

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

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

Также вы можете ознакомиться с Принципами взаимодействия Яндекса с другими сетями.