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

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

Документ основан на сложившейся практике крупнейших провайдеров и почтовых служб, соответствует нормам и рекомендациям 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 и другие потенциально опасные объекты.

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

Источник: https://yandex.ru/support/mail/web/spam/honest-mailers.html