Отправить много писем

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

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

Если вы хотите массово рассылать письма вашим партнерам или клиентам, подключите Яндекс 360 для бизнеса и пользуйтесь Яндекс Рассылками.

Ограничения на отправку писем

Ограничения действуют на количество отправленных писем в сутки. При этом одно письмо, например, с 10 получателями, считается за 10 писем. Учитываются получатели, указанные не только в поле Кому, но и в полях Копия и Скрытая копия.

При достижении лимита блокируется отправка писем — входить в Почту и получать письма вы по-прежнему сможете. Блокировка закончится автоматически через 24 часа, если вы не попытаетесь отправить письмо в течение этого времени, — иначе блокировка продлится еще на сутки.

Письма не доставляются

Если вы отправили рассылку на почтовые ящики на Яндексе и письма отклонились почтовым сервером Яндекса, вы получите автоматический отчет от сервиса Mailer-Daemon. В нем будут указаны причины недоставки и имя сервера, который заблокировал письмо.

Письма попадают в папку «Спам»

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

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

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

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

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

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

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