Приложение «Рассылки» поддерживает технологию DKIM (DomainKeys Identified Mail).
Получатели email-рассылки не всегда могут быть уверены в том, что полученное ими письмо было отправлено с благонадежного адреса. Нередко злоумышленники с целью получения ценных данных отправляют мошеннические или спам-сообщения, указывая в качестве отправителя email-адрес какой-либо компании с положительной репутацией, например, ваш! Если от вашего имени будут рассылаться подобные сообщения, то ваше доменное имя может попасть в черные списки почтовых сервисов. Для того чтобы повысить свою репутацию отправителя, рекомендуем подписывать отправляемые сообщения с помощью технологии DKIM.
Инструкция по использованию DKIM в приложении «Рассылки»
Честные рассылки
С внедрением этой важной функции «Рассылки» теперь полностью удовлетворяют требованиям Яндекса к честным email-рассылкам. Покажем соответствие приложения этим требованиям в виде таблицы.
| Требования «Яндекса» | Поддержка «Рассылками» |
| Процесс подписки | |
| Рассылка должна осуществляться только по явному требованию или согласию получателя. | Поддерживается в виде форм подписки для публикации на сайте. |
| Адрес получателя рассылки должен быть явным образом подтвержден самим получателем. | В настройках форм подписки есть функция подтверждения подписки с помощью индивидуальной ссылки, отправляемой на электронный адрес потенциального подписчика. |
| При добавлении в рассылочный лист адреса получателей должны пройти валидацию. | Поддерживается. |
| Процесс отказа от подписки | |
| В каждом письме должны быть даны четкие инструкции о том, как отписаться от рассылки. При этом процесс отписки не должен требовать от получателя сложных действий, таких как восстановление пароля, регистрация или авторизация. Получатель должен иметь возможность отписаться от рассылки в течение 10 минут. | Инструкции об отписке должен указывать в письме автор сообщения. Ссылка для отписки вставляется в виде переменной, доступной в визуальном редакторе сообщения. При переходе по ссылке отписки отказ от получения дальнейших рассылок фиксируется сразу же — без необходимости дополнительного подтверждения. Срок действия ссылки для отписки не ограничен. |
| В теле письма должен быть явно указан адрес подписчика. | Поддерживается. Для вставки адреса подписчика в текст письма необходимо использовать переменную персонализации, доступную в визуальном редакторе сообщения. |
| В письме должен быть использован заголовок List-unsubscribe, оформленный по стандарту RFC. При переходе по ссылке из этого заголовка пользователь должен быть моментально отписан от рассылки. | Поддерживается. Заголовок добавляется автоматически. |
| Для отписки необходимо указывать только работающие ссылки. | Поддерживается. Для вставки корректной ссылки для отписки необходимо использовать переменную, доступную в визуальном редакторе сообщения. |
| Заголовок письма | |
| Тема сообщения должна быть понятна пользователю и не должна вводить его в заблуждение. | Обеспечивается автором рассылки. |
| Тема сообщения должна быть одинаковой для всех писем одной рассылки. | Поддерживается. |
| В поле От кого должен быть указан реально существующий электронный адрес, ассоциированный с источником рассылки. Если сообщения, поступающие на этот адрес, обрабатываются роботом, то в ответ должны приходить ясные и четкие инструкции, позволяющие связаться с вашей службой поддержки. | Обеспечивается автором рассылки. |
| Корректность сетевой идентификации | |
| Программное обеспечение, осуществляющее рассылку, должно проверять полученные ответы. Если принимающий сервер отвечает, что указанного пользователя не существует, то рассылка по этому адресу должна быть приостановлена. | Поддерживается в виде возможности настройки адресов Return-Path для автоматического сбора уведомлений от почтовых серверов получателей об ошибках доставках. Адреса получателей, при попытке доставки на которые были получены уведомления о критичных ошибках (например, «почтовый ящик не существует»), автоматически игнорируются при отправке дальнейших рассылок. |
| Хост, осуществляющий рассылку, должен иметь постоянный 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-запись домена). | Поддерживается в виде опции «DKIM» в свойствах отправителя. |
| Другие требования | |
| Нельзя изменять информацию об отправителе или о целевой странице для любых ссылок в письмах. | Обеспечивается автором рассылки. |
| Не рекомендуется использовать сокращенные ссылки. | Обеспечивается автором рассылки. |
| Все ссылки в тексте должны указываться в виде полного доменного имени: нельзя использовать в качестве ссылок IP-адреса или перекодированные имена доменов (URL Encoded). | Обеспечивается автором рассылки. |
| В письме должны присутствовать стандартные заголовки, используемые при массовых или автоматических рассылках — например, Precedence: bulk (junk, list, list-unsubscribe и т. п.). Все ссылки в них должны позволять отписаться от рассылки автоматически. | Поддерживается. В каждое сообщение автоматически добавляются заголовки Precedence: bulk и List-unsubscribe. |
| Заголовки и формат сообщения должны соответствовать требованиям RFC 5322 и стандарту MIME. Кроме того, в сообщении должны присутствовать корректные заголовки Date и Message-ID. | Поддерживается. Заголовки Date и Message-ID добавляются автоматически. |
| Для каждой части сообщения должна быть указана реально используемая кодировка. Сообщения с текстами в двух кодировках одновременно недопустимы. | Всегда используется только одна кодировка: UTF-8. |
| Если рассылка осуществляется в формате HTML, в письме недопустимо использовать элементы JavaScript, ActiveX и другие потенциально опасные объекты. | Обеспечивается автором рассылки. |
0 комментариев
No comments yet.