SMTP 421 и 451: временные ограничения при отправке рассылок

1. Что означают коды 421 и 451

В SMTP первая цифра кода ответа определяет его класс. Цифра 4 в начале означает временный отказ (transient negative completion): операция не выполнена, но отправитель может повторить попытку позже. В отличие от кодов класса 5xx, это не окончательный отказ, и корректно настроенный почтовый сервер отправителя должен поставить письмо в очередь и пробовать снова.

Код 421 по RFC 5321 означает, что служба временно недоступна и сервер закрывает канал передачи: "Service not available, closing transmission channel". На практике так отвечают при перегрузке сервера, технических работах или, чаще всего, при срабатывании ограничения скорости по IP или домену отправителя.

Код 451 по RFC 5321 означает, что запрошенное действие прервано из-за локальной ошибки обработки: "Requested action aborted: local error in processing". Так отвечают при внутренних сбоях фильтрации, а также при грейлистинге, когда сервер намеренно откладывает первое письмо от незнакомого отправителя.

Расширенный код после основного (например, 4.7.0) уточняет причину. По RFC 3463 все расширенные коды, начинающиеся с 4, описывают временные состояния. Текстовая часть ответа часто важнее цифр: именно там провайдер пишет, чей именно лимит сработал (IP, домен, получатель) и иногда указывает ссылку на справку.

2. Почему почтовый сервер откладывает письма

Главная причина ответов 421 и 451 в массовых рассылках: ограничение скорости приема. Каждый почтовый провайдер держит внутренние лимиты на количество соединений, писем в единицу времени и получателей с одного IP или домена. Пороги зависят от репутации отправителя: у нового домена они низкие, у старого с хорошей историей выше.

Типичные триггеры временной блокировки рассылки:

резкий рост объема: вчера отправляли 5 000 писем в день, сегодня 100 000; почтовик читает это как аномалию;

новый IP или домен без истории отправок, на который сразу подали большой поток;

рост жалоб на спам: у Gmail порог 0,1% считается нормой, а уровень 0,3% и выше в Google Postmaster Tools трактуется как проблемный; у Mail.ru допустимая доля жалоб зависит от месячного объема (от 1,1% при объеме до 10 000 писем до 0,3% при объеме свыше 50 000 000);

много недействительных адресов в базе: почтовик видит поток отказов на RCPT TO и прикрывает прием;

грейлистинг на стороне получателя: первое письмо от неизвестной тройки "IP отправителя, адрес отправителя, адрес получателя" откладывается с ответом 4xx, повторная попытка принимается.

Отдельный случай: временные сбои на стороне самого почтовика. Они выглядят так же (421, 451), но затрагивают многих отправителей одновременно и проходят без ваших действий. Отличить их от собственного rate limit можно по массовости: если deferred только у вас, причина на вашей стороне.

3. Как это выглядит в логах: пример сессии

В логах вашего почтового сервера или ESP временное ограничение видно как ответ 4xx на команду RCPT TO или DATA. Вот типичный фрагмент сессии с Gmail:

S: 220 mx.google.com ESMTP ... C: MAIL FROM:<news@example.com> S: 250 2.1.0 OK C: RCPT TO:<user@gmail.com> S: 421-4.7.28 Gmail has detected an unusual rate of unsolicited email originating S: 421 4.7.28 from your IP address 203.0.113.10.

Разбор этого ответа: код 421 говорит, что соединение будет закрыто; расширенный код 4.7.28 относится именно к превышению лимита по объему или скорости отправки (не к общей репутации или контенту - у них свои коды, например 4.7.0 или 4.7.24); в тексте указан ваш IP. Это сигнал снизить темп и проверить репутацию, а не признак постоянного бана.

Для сравнения, ответ при грейлистинге обычно короче: "451 4.7.1 Greylisting in action, please come back later" или похожий текст со словом greylisting. Здесь нет проблемы с репутацией: достаточно, чтобы ваш сервер корректно повторил отправку через несколько минут.

В SMTP нет стандартного заголовка Retry-After, как в HTTP: RFC 5321 не задает механизм, которым сервер сообщал бы точное время повтора. Некоторые провайдеры пишут рекомендуемую паузу прямо в тексте ответа, поэтому читайте текст, а не только код. Если времени нет, опирайтесь на экспоненциальную задержку повторов в очереди вашего MTA.

4. Дерево диагностики: что проверять и в каком порядке

Шаг 1. Определите масштаб. Посмотрите в логах, у каких провайдеров deferred: только Gmail, только Mail.ru, только Яндекс или все сразу. Ограничение у одного провайдера почти всегда означает вашу репутацию именно у него. Отказ у всех одновременно указывает на проблему в инфраструктуре (недоступность вашего релея, ошибка конфигурации) или на глобальный сбой.

Шаг 2. Прочитайте текст ответа. Слова rate limited, too many connections, unusual rate указывают на скорость и объем. Greylisting или please retry later указывают на временную задержку без санкций. Упоминание reputation или spam означает, что лимит ужесточен из-за жалоб.

Шаг 3. Сопоставьте с объемом. Сравните сегодняшний объем и темп отправки с обычным за последние 2-4 недели. Рост в разы за один день сам по себе объясняет 421 у Gmail и Mail.ru, даже если репутация была хорошей.

Шаг 4. Проверьте репутацию и жалобы. В Google Postmaster Tools смотрите долю жалоб на спам и соответствие требованиям отправителей; в Mail.ru Postmaster смотрите показатель "Репутация, %" (средний процент жалоб за 30 дней, меньше лучше). Рост жалоб перед появлением 421 подтверждает репутационную причину.

Шаг 5. Проверьте аутентификацию и инфраструктуру. Убедитесь, что SPF, DKIM и DMARC проходят: ослабление аутентификации снижает доверие и ужесточает лимиты. Заодно проверьте PTR-запись IP и черные списки.

5. Что делать, когда письма уходят в deferred

Снизьте темп. Уменьшите количество одновременных соединений и писем в минуту на проблемный домен получателя. Если отправляете через ESP, попросите настроить троттлинг по домену; если через свой MTA, настройте ограничения в конфигурации транспорта.

Проверьте логику повторов. Очередь должна повторять отправку с растущими интервалами (например, 5, 15, 30, 60 минут) и отбрасывать письмо только после нескольких часов или дней попыток. Мгновенные ретраи в цикле усиливают ограничение.

Остановите рост объема. Верните дневной объем к уровню, который почтовик принимал без отказов, и наращивайте его постепенно: принцип тот же, что при прогреве домена, равномерное увеличение без скачков.

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

Разделите потоки. Транзакционные письма и маркетинговые рассылки лучше отправлять с разных поддоменов: тогда временное ограничение маркетингового потока не заденет подтверждения заказов и пароли.

6. Как проверить, что ограничение снято

Главный индикатор: доля ответов 4xx в логах возвращается к обычному уровню, очередь исходящих писем перестает расти, письма доставляются без многочасовых задержек.

Дальше смотрите панели репутации. В Google Postmaster Tools проверьте, что доля жалоб вернулась ниже 0,1% и нет нарушений требований отправителей. В Mail.ru Postmaster отследите динамику показателя "Репутация, %" по дням: он должен стабилизироваться ниже порога для вашего объема.

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

Если вы ведете рассылки постоянно, удобно следить за этими метриками в мониторинге: PostmastersTool собирает данные Google Postmaster Tools и Mail.ru Postmaster, показывает историю по дням и присылает уведомление при пересечении порогов, чтобы рост deferred и жалоб не остался незамеченным.

7. Ограничения и когда нужен аудит

Временные ограничения почти всегда снимаются сами после нормализации темпа и репутации, но точные пороги провайдеры не раскрывают: у Gmail, Mail.ru, Яндекса и Outlook лимиты динамические и зависят от истории отправителя. Поэтому любые инструкции вида "отправляйте ровно N писем в час" следует считать приближением.

Если после снижения темпа и чистки базы ответы 421 и 451 держатся дольше нескольких дней, репутация в Postmaster не восстанавливается, а доля жалоб не падает, причина обычно глубже: качество базы, контент, архитектура поддоменов, ошибки аутентификации. В этой ситуации разумнее провести комплексный аудит доставляемости, чем продолжать подбирать скорость отправки вслепую.