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

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

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

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

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

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

Количество получателей

Ограничение

В одном письме, отправленном через сайт или мобильное приложение

1000

В одном письме, отправленном через почтовую программу или по протоколу SMTP

300

Внимание

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

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

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

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

Внимание

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

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

Написать в службу поддержки