Предел почтовой отправки: сколько писем в час выдержит сервер и почтовые провайдеры

MAATRIX

Вопрос «сколько писем в час выдержит мой сервер» на самом деле распадается на два разных вопроса, и их путаница — причина половины проблем с доставляемостью. Один предел — чисто технический: сколько сообщений физически способен обработать и отправить Postfix или Exim на вашем железе. Второй — репутационный: сколько писем с одного IP готовы принять без подозрений Gmail, Outlook и Яндекс, и он почти всегда наступает намного раньше первого. Разберём оба, а заодно — как разгонять новый сервер, чтобы не сжечь репутацию в первый же день.

Два разных предела — и почему их путают

Технический предел определяется вашим сервером: сколько ядер CPU и памяти под очередь, сколько одновременных TLS-сессий держит сеть, насколько быстро отвечает DNS при резолве MX получателей. Это ресурс, который вы контролируете напрямую — добавили ядро, увеличили smtp_destination_concurrency_limit, получили больше параллельных соединений.

Репутационный предел определяется чужой инфраструктурой — антиспам-системами Gmail, Outlook (Microsoft 365 / Exchange Online Protection) и Яндекса. Они видят не «сколько вы можете отправить», а «сколько писем внезапно пришло с IP, у которого нет истории». Скорость отправки для них — один из сигналов вместе с содержимым, репутацией домена, аутентификацией и поведением получателей (открывают, отвечают, жалуются на спам).

Ключевая ошибка новичков: настроить Postfix так, чтобы он «летел» на пределе технической мощности — тысячи писем в час одним потоком — и удивляться, почему через два часа весь трафик уходит в спам. Сервер отработал штатно. Репутационный лимит был превышен на порядок раньше, чем технический дал о себе знать.

«Сколько писем в час» — вопрос не только про MTA. Ресурсы под саму рассылку (очередь, база подписчиков, шаблонизатор) считаются отдельно — этому посвящён материал о том, сколько ресурсов реально нужно VPS для почтовой рассылки. Здесь же речь именно про предел отправки в единицу времени.

Технический предел: сколько писем в час физически потянет Postfix или Exim

У Postfix и Exim нет жёсткого «потолка писем в секунду» как у SaaS с тарифными планами — предел складывается из нескольких параметров и ресурсов сервера:

• Concurrency (параллелизм) — сколько одновременных SMTP-соединений к разным получателям MTA готов держать одновременно. В Postfix это default_destination_concurrency_limit и отдельные лимиты по конкретным доменам через transport_maps или main.cf для конкретного relay.
• Rate delay — искусственная пауза между письмами к одному домену получателя: default_destination_rate_delay в Postfix, аналог в Exim через ratelimit-условия в ACL. Это не про мощность сервера, а про намеренное сдерживание — throttling, о котором дальше отдельный раздел.
• DNS-резолв MX — при большом объёме резолвер становится узким местом раньше CPU: медленный или лимитированный DNS тормозит каждую новую связь с доменом получателя. Локальный кэширующий резолвер (unbound, systemd-resolved с кэшем) снимает эту проблему почти полностью.
• TLS-хендшейк — на каждое новое соединение MTA обычно устанавливает TLS (STARTTLS). На слабом CPU при массе параллельных соединений именно хендшейки, а не передача письма, съедают процессор.
• Очередь на диске — при стандартной дисковой очереди Postfix число IOPS ограничивает скорость постановки и удаления писем. На VPS с сетевым диском это может стать неожиданным узким местом при всплеске объёма.

Практический вывод: на современном небольшом VPS (несколько ядер, SSD, нормальный канал) технический потолок Postfix обычно измеряется тысячами писем в час при открытых лимитах параллелизма — но точную цифру для своей связки железо+сеть+получатели никто не назовёт без замера на месте, она зависит от смеси доменов получателей и среднего размера письма. Проверяйте эмпирически на тестовой рассылке, прежде чем полагаться на предполагаемые цифры.

Посмотреть текущую загрузку очереди и скорость её разбора:

postqueue -p | tail -1
mailq | grep -c '^[A-F0-9]'
tail -f /var/log/mail.log | grep 'status=sent'

Если очередь стабильно растёт быстрее, чем разбирается — вы упёрлись именно в технический предел (или искусственно выставленный rate delay). Если очередь разбирается штатно, а письма всё равно не долетают или уходят в спам — предел не технический, а репутационный, и добавление ресурсов серверу здесь не поможет.

Репутационный предел: сколько готовы принять Gmail, Outlook и Яндекс с одного IP

У каждого крупного почтового провайдера есть собственные внутренние лимиты на приём с одного отправляющего IP или домена, и они не публикуются как фиксированные цифры — потому что адаптивны и зависят от репутации конкретного отправителя, а не единой планки для всех. То, что выдержит IP с многолетней историей чистой отправки, для свежего IP из дата-центра может оказаться избыточным уже на первой сотне писем в час.

Общий принцип у всех крупных провайдеров одинаковый, хотя конкретная реализация закрыта:

• Новый IP без истории оценивается заведомо строже: первые письма проходят через более агрессивную фильтрацию, часть может попадать в спам или временно отклоняться, даже если содержимое и аутентификация в порядке — это часть проверки самой репутации.
• Резкий скачок объёма — даже у прогретого IP — воспринимается как аномалия. Пятикратный рост объёма за сутки без предупреждения выглядит как компрометация аккаунта или начало спам-рассылки, даже если это легитимный рост вашего бизнеса.
• Соотношение хороших и плохих сигналов — открытия, ответы, добавление в адресную книгу считаются в плюс; жалобы на спам (Feedback Loop), высокий bounce rate — в минус, и скорость отправки тут вторична по отношению к тому, что получатели делают с письмами.
• IP-адреса дата-центров (VPS, cloud) по умолчанию несут более настороженное отношение антиспам-систем, чем адреса известных ESP — это не значит, что со своего VPS нельзя доставлять почту, но запас доверия у вас меньше с самого старта.

Практический ориентир, а не гарантированная цифра: для совсем нового IP без репутации разумная стартовая скорость на один провайдер — низкие десятки писем в час, с постепенным ростом по мере накопления положительной статистики. У вашего конкретного случая цифра может отличаться в разы в любую сторону — единственный надёжный способ узнать свой реальный предел — постепенно поднимать объём и следить за метриками bounce/жалоб/доставляемости.

Если репутация уже испорчена резким стартом, восстановление — отдельная и небыстрая работа: как выбраться из чёрных списков и вернуть доверие описано в материале про восстановление репутации IP после попадания в чёрные списки.

Warm-up: как разгонять отправку с нового сервера, не сжигая репутацию

Warm-up (прогрев) — это намеренное, постепенное наращивание объёма отправки с нового IP или домена по расписанию, а не попытка сразу выйти на целевую скорость. Логика простая: вы даёте антиспам-системам получателей накопить положительную статистику о вашем IP маленькими порциями, прежде чем доверить ему большой объём.

Общая схема прогрева, которую стоит адаптировать под свой объём, а не копировать буквально:

1. Начните с самых лояльных получателей. Первые письма прогрева должны идти туда, где высокая вероятность открытия и низкая — жалобы: собственные тестовые ящики на разных провайдерах, активные клиенты. Не начинайте с холодной базы или неактивных контактов — это сразу портит статистику открытий.
2. Растягивайте объём во времени, а не режьте залпом. Равномерно раскидывайте письма в течение дня через default_destination_rate_delay в Postfix или аналогичный throttling в вашей рассылочной системе. Резкий залп даже небольшого объёма выглядит подозрительнее, чем тот же объём, растянутый на часы.
3. Увеличивайте объём постепенно день за днём, ориентируясь на метрики: пока bounce rate и жалобы остаются низкими, а открываемость — на ожидаемом уровне, можно наращивать; как только показатель ухудшается — держите объём на месте или откатывайтесь на шаг назад.
4. Разделяйте типы трафика по субдоменам. Транзакционные письма (подтверждение регистрации, сброс пароля) и маркетинговые рассылки лучше отправлять с разных субдоменов (mail.example.com и news.example.com) — так репутация одного потока не тянет за собой другой. И не переезжайте резко на новый IP без причины: каждая смена отправляющего адреса — это новый прогрев с нуля, обнуляющий накопленное доверие.

Подробный пошаговый план настройки именно нового VPS под почтовую рассылку с нуля, включая последовательность действий по DNS, PTR и первым тестовым отправкам, разобран в материале про настройку VPS под почтовую рассылку с нуля — warm-up там встроен в общую последовательность запуска, а не рассматривается изолированно.

Throttling на уровне Postfix для равномерного распределения нагрузки в течение прогрева:

# в main.cf: пауза между письмами к одному домену получателя
default_destination_rate_delay = 5s

# ограничить число одновременных соединений к одному домену
default_destination_concurrency_limit = 2

# общий потолок одновременных исходящих соединений
default_process_limit = 10

Значения выше — иллюстрация синтаксиса, а не рекомендуемые цифры: подбирайте их под свой этап прогрева и меняйте по мере роста объёма.

SPF, DKIM, DMARC — фундамент, без которого прогрев бессмысленен

Скорость отправки и аутентификация — независимые оси, но репутационные фильтры смотрят на обе сразу. Можно прогревать IP сколь угодно аккуратно, но если письма технически не проходят проверку подлинности, часть провайдеров будет резать их в спам вне зависимости от скорости и репутации отправителя.

• SPF (Sender Policy Framework) — TXT-запись в DNS домена, перечисляющая, каким серверам разрешено отправлять почту от его имени. Без корректного SPF получатель не может подтвердить, что письмо отправлено с авторизованного IP.
• DKIM (DomainKeys Identified Mail) — криптографическая подпись письма закрытым ключом, публичная часть которого публикуется в DNS. Подтверждает, что письмо не изменено по пути и действительно отправлено владельцем домена.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — политика поверх SPF и DKIM: что делать получателю, если проверки не прошли (none — ничего, только отчёт; quarantine — в спам; reject — отклонить), плюс отчёты о том, кто отправляет почту от имени вашего домена.

Все три вместе — не формальность для галочки, а прямой сигнал репутации: Gmail и Outlook отдельно учитывают выравнивание (alignment) домена в заголовке From с доменом, прошедшим SPF/DKIM. Несовпадение снижает доверие к письму сильнее, чем полное отсутствие DKIM.

Пошаговая настройка всех трёх механизмов разобрана в материале как установить и настроить SPF, DKIM и DMARC на VPS — там же показано, как проверить, что записи применились, прежде чем запускать прогрев. Начинать прогрев без работающей аутентификации не имеет смысла: часть накопленной репутации всё равно будет списываться на проверках, которые вы не прошли.

Признаки, что вы упёрлись в лимит принимающей стороны

Отличить «сервер не справляется технически» от «получатель ограничивает приём» можно по логам.

Soft bounce (временный код ошибки, обычно из серии 4xx) — это не «письмо потеряно навсегда», а явный сигнал «попробуйте позже и помедленнее». MTA сам поставит такое письмо на повторную отправку по расписанию (bounce_queue_lifetime / maximal_queue_lifetime в Postfix), но если soft bounce приходит массово — это системный сигнал, что скорость превышает то, что получатель готов принимать с вашего IP прямо сейчас.

Greylisting стоит отдельно: это не про репутацию как таковую, а стандартный приём отсеивания примитивных спам-ботов, которые не умеют повторять отправку. Легитимный MTA сам справится — при временном отказе он поставит письмо в очередь и повторит попытку позже. Если greylisting массово тормозит доставку, а не единичные случаи — стоит разобрать конкретный обмен подробнее, как это делается в материале про разбор пути письма до попадания в спам.

Общий диагностический принцип: если очередь Postfix растёт и не разбирается — это технический предел сервера или сети. Если письма уходят штатно (status=sent), но получатели сообщают о задержках или недоставке — предел не ваш, а принимающей стороны, и решение здесь не в ресурсах сервера, а в снижении темпа и работе над репутацией.

Частые вопросы