Почтовые серверы электронной почты: сбои доставки и их решение

В моей практике такой момент хотя бы раз переживал каждый, кто администрирует корпоративную почту или ведёт рассылки, — и первая реакция почти всегда одна и та же: растерянность. Кажется, что письмо просто пропало, а сервер «не работает». На самом деле каждый такой код — не каприз системы, а вполне читаемый диагностический сигнал. Если научиться его понимать, большинство сбоев доставки превращаются из тревожной загадки в спокойный порядок действий на пару минут.

Почтовая доставка ломается не в одной точке. Отправляющий сервер должен корректно установить SMTP-соединение, представить себя принимающей стороне, пройти проверки IP-адреса и домена, подписать письмо, а затем не вызвать подозрений содержимым и поведением отправителя. Ошибка на любом из этих этапов может выглядеть для пользователя одинаково: «письмо не дошло». Для администратора разница принципиальна — повторять отправку, исправлять DNS, проверять адрес получателя или разбираться с репутацией нужно в совершенно разных случаях.

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

Анатомия SMTP-ошибок: как читать коды 4xx и 5xx

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

Для первичной диагностики достаточно разделить ответы на два больших семейства.

Семейство 4xx означает временную ошибку. Сервер-получатель сообщает: «сейчас я не могу принять письмо, попробуй позже». Причина может быть на его стороне, на стороне отправителя или в сработавшем ограничении скорости. Обычно отправляющий сервер не считает такую попытку окончательной неудачей и ставит сообщение в очередь.

Самые частые варианты:

• 421 — сервис временно недоступен. Такое бывает при технических работах, перегрузке, временном ограничении соединений или принудительном закрытии SMTP-сессии.
• 450 — почтовый ящик или операция временно недоступны. Причиной может быть переполнение ящика, временная блокировка или политика ограничения частоты доставки.
• 451 — локальная ошибка при обработке. Формулировка довольно широкая: она может указывать на сбой внутри принимающего сервера, проблемы с проверкой или временную ошибку фильтра.
• 452 — недостаточно системных ресурсов либо временно превышен допустимый объём операций.

Важен не только сам код, но и текст после него. Например, 421 4.7.0 и 421 4.4.2 относятся к временным сбоям, но первая формулировка может указывать на ограничение политики или подозрительную активность, а вторая — на техническую проблему соединения. Текст ответа и логи отправляющего сервера здесь полезнее, чем попытка угадать причину по одной первой цифре.

Временные ошибки — это не повод паниковать, а сигнал, что отправляющему серверу стоит повторить попытку. Именно поэтому почтовые системы автоматически делают несколько повторов в течение нескольких часов.

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

Семейство 5xx означает постоянную ошибку. Сервер прямо говорит: «эту попытку принимать не буду». Простая повторная отправка обычно ничего не меняет, потому что причина не исчезнет сама собой.

• 550 — запрошенное действие не выполнено. Это может быть несуществующий ящик, отказ в доступе, блокировка по политике или отклонение письма как подозрительного.
• 551 — адрес получателя не обслуживается этим сервером; иногда ответ содержит указание на другой адрес или маршрут.
• 552 — превышен допустимый размер сообщения, ящика или другого ресурса.
• 553 — проблема с адресом или синтаксисом команды. Часто встречается при ошибке в адресе, но точную причину нужно смотреть в расширенном тексте ответа.
• 554 — транзакция отклонена. Это может быть результатом фильтрации спама, антивирусной проверки, нарушения политики или общего отказа принять сообщение.

Расширенный статус уточняет класс ошибки. В записи 550 5.7.1 число 5 после пробела указывает на постоянный отказ, 7 — на проблему политики или безопасности, а последняя цифра уточняет конкретную реализацию. У разных провайдеров текст и дополнительные коды отличаются, поэтому один и тот же 5.7.1 не всегда означает абсолютно одинаковое действие. Но это уже достаточный сигнал проверить аутентификацию, репутацию IP и домена, содержимое письма и политику получателя.

Есть и практическая граница между ошибкой доставки конкретному адресу и проблемой всей инфраструктуры. Если 550 получает одно письмо на один ящик, сначала проверяют адрес и локальную политику получателя. Если одинаковые отказы приходят по десяткам доменов, а в тексте встречаются слова spam, blocked, authentication или reputation, вероятнее всего, проблема системная.

PTR-запись и обратный DNS: фундамент репутации сервера

Прежде чем разбирать SPF, DKIM и DMARC, стоит задержаться на менее заметной, но критически важной детали — PTR-записи. Это обратная DNS-запись, которая связывает IP-адрес сервера с его доменным именем. Если A-запись говорит: «домен example.ru живёт по адресу 203.0.113.10», то PTR делает обратное: «адрес 203.0.113.10 представляет домен example.ru».

При SMTP-соединении принимающая сторона видит IP-адрес отправителя. Если у него нет понятного обратного имени, имя выглядит случайным или используется домен, никак не связанный с сервером, это снижает уровень доверия. Само наличие PTR не гарантирует попадание во «Входящие», но её отсутствие или очевидная ошибка способны стать причиной отказа ещё до анализа текста письма.

Крупные провайдеры — Gmail, Outlook и Yahoo — проверяют не только наличие обратной записи, но и согласованность прямого и обратного DNS. Этот принцип называют FCRDNS, или Forward-Confirmed Reverse DNS. Имя, указанное в PTR, должно разрешаться обратно в тот же IP-адрес через A- или AAAA-запись. Иными словами, проверка должна пройти в обе стороны:

1. IP-адрес ведёт через PTR к имени сервера.

2. Это имя через прямую DNS-запись возвращает тот же IP-адрес.

3. Имя сервера используется последовательно в SMTP-приветствии и конфигурации почтового узла.

PTR-запись — это, по сути, «рекомендательное письмо» от вашего IP-адреса: если обратное имя ведёт к рабочему домену с честной историей, доверие к письму выше.

На практике PTR редко редактируется в панели регистратора домена. Её настраивает владелец IP-адреса — хостинг-провайдер или оператор связи, у которого вы арендуете сервер. Если вы используете выделенный сервер или VPS, нужно уточнить у поддержки, можно ли самостоятельно изменить обратное имя и соответствует ли оно вашему hostname.

Проверять стоит не только саму запись, но и окружение:

• совпадает ли имя в PTR с именем, которое сервер передаёт в команде EHLO;
• есть ли у этого имени прямая A- или AAAA-запись;
• не используется ли один IP сразу для большого числа несвязанных доменов;
• не числится ли адрес в публичных списках блокировок;
• настроена ли корректная обратная запись для IPv6, если сервер отправляет почту по IPv6.

Отдельный риск — динамические и дешёвые адресные пулы. Даже если технически SMTP на таком IP работает, провайдер может относиться к нему настороженно из-за истории предыдущих пользователей. В такой ситуации настройка SPF и DKIM не отменяет проблемы репутации самого адреса.

SPF, DKIM и лимит в 10 DNS-запросов

SPF, DKIM и DMARC часто называют тремя китами доменной аутентификации. Это удобная формула, но у каждого механизма своя роль. SPF отвечает за право IP-адреса отправлять почту, DKIM подтверждает целостность и происхождение сообщения, а DMARC связывает эти проверки с доменом в видимом поле From: и задаёт политику для провайдера-получателя.

SPF (Sender Policy Framework) — TXT-запись в DNS, в которой перечислены IP-адреса и серверы, имеющие право отправлять почту от имени домена. Получающий сервер сравнивает IP отправителя с опубликованными правилами. Если адрес разрешён, SPF проходит; если нет, результат может быть fail, softfail, neutral или none — в зависимости от правил записи и наличия совпадения.

У SPF есть технический предел, о который спотыкаются даже опытные администраторы. Согласно RFC 7208, во время проверки разрешено не более 10 DNS-запросов определённых типов. Это не простое количество слов include: в строке. Один include: может привести к дополнительным обращениям к DNS, а вложенные записи способны неожиданно увеличить итоговый счётчик. В результате длинная SPF-запись с правилами Microsoft, Google, сервисов рассылок, CRM и собственных серверов может завершиться ошибкой PermError.

Что помогает удержать конфигурацию в рабочем состоянии:

• минимизировать количество внешних include:, оставляя только реально используемые сервисы;
• применять ip4: и ip6: для стабильных адресов, когда это оправдано и не усложняет поддержку;
• удалять из SPF старые сервисы, которыми компания уже не пользуется;
• не создавать несколько SPF-записей для одного домена — принимающий сервер не должен выбирать между ними;
• проверять не только исходную TXT-запись, но и всю цепочку включений специальным валидатором;
• заранее учитывать, что смена платформы рассылок потребует обновления SPF, DKIM и DMARC одновременно.

SPF проверяет путь доставки, но не защищает содержимое письма от изменения после отправки. За это отвечает DKIM (DomainKeys Identified Mail). Отправляющий сервер добавляет к письму криптографическую подпись, сформированную на основе выбранных заголовков и тела сообщения. Получающий сервер находит открытый ключ в DNS и проверяет, соответствует ли подпись письму.

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

Для новых конфигураций разумно использовать ключ длиной 2048 бит. Более короткие ключи всё ещё могут встречаться в старых системах, но они хуже соответствуют современным ожиданиям безопасности и постепенно становятся источником дополнительных ограничений. Не стоит забывать и о селекторе: он входит в имя DNS-записи, а при ротации ключа новый селектор позволяет некоторое время поддерживать старую и новую подписи параллельно.

DMARC: выравнивание доменов и три уровня политики

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

Политика публикуется в TXT-записи _dmarc и может принимать три основных значения:

• p=none — режим наблюдения. Провайдеры не обязаны отправлять письмо в спам или отклонять его только из-за этой политики, а владелец домена получает отчётность о происходящем.
• p=quarantine — сообщение, не прошедшее необходимые проверки, рекомендуется поместить в спам или обработать как подозрительное.
• p=reject — принимающей стороне рекомендуется отклонить письмо на SMTP-этапе.

Эти значения не являются приказом, который каждый провайдер обязан исполнять одинаково. DMARC задаёт политику домена, но окончательное решение может учитывать собственные фильтры, репутацию, содержание и историю взаимодействия с отправителем.

Самая частая ошибка — считать, что отдельного успешного SPF или DKIM достаточно. Для DMARC важен alignment, то есть выравнивание доменов. Домен в видимом заголовке From: должен совпадать или быть согласован с доменом, который прошёл SPF либо DKIM. При строгой настройке требуется точное совпадение, при расслабленной допускается согласование организационного домена.

Например, обратный адрес конверта может указывать на bounce.example-mail.com, а в видимом поле From: при этом стоит newsletter@example.com. SPF в такой схеме может пройти для технического домена, но DMARC не засчитает его как выровненный с example.com. Если DKIM подписывает письмо доменом example.com, проблема исчезает. Если же DKIM отсутствует или подписывает письмо чужим доменом платформы, сообщение может не пройти DMARC несмотря на формально корректный SPF.

DMARC с политикой p=none — это не защита, а диагностика. Реальная защита от подделки начинается с p=quarantine и полноценно работает на p=reject.

Начинать обычно разумно с p=none. В течение нескольких недель отчёты показывают, какие системы действительно отправляют почту от имени домена: основной сервер, CRM, формы на сайте, сервисы поддержки, бухгалтерская система и платформа рассылок. После инвентаризации отправителей можно постепенно усиливать политику.

Переход к reject без наблюдения опасен. Владелец домена может не помнить о старом сервисе, который отправляет письма клиентам, или не учесть отдельный поток уведомлений. В результате защита от подделки начнёт блокировать легитимные сообщения. Поэтому сначала нужно собрать источники отправки, настроить DKIM для каждого разрешённого сервиса, проверить выравнивание и только потом ужесточать политику.

Новые правила Google, Yahoo и Microsoft: что изменилось в 2024–2025 годах

В 2024–2025 годах требования крупных почтовых платформ к массовым отправителям стали заметно строже. При этом слово «массовый» нельзя понимать как универсальный порог для всех провайдеров. Для Gmail ориентир в 5000 сообщений в сутки относится к отправителям, которые передают такой объём на адреса Gmail. У Yahoo действуют сопоставимые требования к массовой почте, а Microsoft ввела аналогичные правила для Outlook.com, Hotmail.com и Live.com в мае 2025 года.

Иными словами, отправитель, который пересылает более 5000 писем в день на адреса Gmail, попадает в категорию массового отправителя Google. Для Yahoo и Microsoft нельзя механически переносить этот порог без учёта их собственных правил и трактовок, но требования к аутентификации, жалобам и отписке нужно воспринимать как общую инфраструктурную норму, а не как формальность только для одного сервиса.

Ключевые изменения выглядели так:

• Февраль 2024 года. Google и Yahoo начали применять более строгие требования к массовой почте. В их основе — корректная аутентификация домена, низкий уровень жалоб на спам, понятный процесс отписки и соблюдение базовых технических правил доставки.
• Май 2025 года. Microsoft ввела аналогичные требования для массовых отправителей, направляющих сообщения на домены Outlook.com, Hotmail.com и Live.com. В поле внимания оказались SPF, DKIM, DMARC, репутация и возможность быстро отказаться от рассылки.
• В 2024–2025 годах провайдеры стали активнее применять не только мягкие ограничения, но и отказы на SMTP-этапе к потокам, которые систематически не соответствуют требованиям или имеют плохую репутацию.

Для Google и Yahoo важен не сам факт наличия трёх записей в DNS, а их работа в реальной доставке. SPF может быть опубликован, но завершаться PermError. DKIM может быть включён в панели сервиса, но не проходить после изменения заголовков. DMARC может иметь политику p=none, но не давать положительного результата из-за отсутствия выравнивания. В каждом случае формальная настройка есть, а доверия к отправителю всё равно не возникает.

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

Меньший объём не означает полное освобождение от требований. Если компания отправляет несколько сотен или несколько тысяч сообщений в день, это не даёт права игнорировать SPF, DKIM и DMARC. Провайдер оценивает совокупность сигналов: историю домена, поведение IP, долю отказов, содержание, вовлечённость получателей и соответствие адреса отправителя ожиданиям пользователя.

Механизмы отписки и управление репутацией отправителя

Последний кусок пазла, без которого даже идеально настроенный сервер может однажды потерять доставляемость, — удобная отписка. Для массовых рассылок в 2024–2025 годах стандартным ожиданием стали заголовки List-Unsubscribe и List-Unsubscribe-Post, связанные с механизмом однокликовой отписки из RFC 8058. Получатель должен иметь возможность отказаться от маркетинговых писем без поиска ссылки в длинном подвале, а отправитель — обработать запрос без дополнительных подтверждений и задержек.

На практике цепочка выглядит так:

1. В письме присутствует заголовок List-Unsubscribe с адресом или URL обработчика отписки.

2. Заголовок List-Unsubscribe-Post сообщает почтовому клиенту, что поддерживается однокликовая отписка.

3. Клиент показывает пользователю кнопку или ссылку рядом с данными отправителя.

4. Запрос на отписку попадает в систему управления подписками и быстро исключает адрес из соответствующего маркетингового потока.

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

Если игнорировать заголовок List-Unsubscribe, получатели, которые не нашли удобной кнопки в вашем письме, просто нажимают «Спам» — и вы теряете репутацию гораздо быстрее, чем от обычной отписки.

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

Есть несколько правил, которые действительно помогают держать доставляемость под контролем:

• Следите за жалобами. Ориентир ниже 0,1% обычно рассматривается как более безопасный уровень для попадания во входящие, но важна динамика и политика конкретного провайдера. Рост жалоб даже с низкой базы — повод остановить кампанию и проверить сегмент.
• Не покупайте базы подписчиков. В таких списках много неактуальных, ошибочных и незаинтересованных адресов. Среди них могут оказаться спам-ловушки, используемые провайдерами для выявления сомнительных методов сбора.
• Проверяйте bounce-отчёты. Жёсткие отказы с кодами 5xx часто говорят о несуществующих ящиках, давно не обновлявшейся базе или сборе адресов с ошибками. Такие адреса нужно удалять, а не бесконечно повторять отправку.
• Разделяйте потоки. Транзакционные уведомления, письма поддержки и рекламные кампании лучше не смешивать без необходимости. Проблемы одного потока не должны автоматически ухудшать доставку другого.
• Разогревайте новые домены и IP. При запуске с нового адреса не стоит сразу отправлять весь накопленный объём. Постепенное увеличение нагрузки даёт провайдерам возможность увидеть нормальное поведение отправителя.
• Не меняйте одновременно всё. Если в один день сменить домен, IP, шаблон, частоту и платформу, будет трудно понять, что именно стало причиной отказов. Изменения лучше проводить поэтапно и фиксировать результаты.
• Следите за согласиями и ожиданиями получателей. Адрес, оставленный для получения чека, не всегда означает согласие на рекламные предложения. Нерелевантные письма быстро превращаются в жалобы, даже если база собрана легально.

Отдельно стоит смотреть на технические логи. Отчёт о недоставке от вашего приложения может быть слишком общим, тогда как SMTP-лог содержит ответ удалённого сервера, время повтора, IP-адрес, имя узла и этап, на котором произошёл отказ. Без этой информации диагностика превращается в догадки. При массовой отправке полезно группировать ошибки по доменам, кодам и причинам, а не считать все недоставленные письма одной категорией.

Как выстроить диагностику, когда письма не доходят

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

1. Проверить конкретный адрес. Ошибка может быть банальной: опечатка, удалённый ящик, переполненный mailbox или запрет на приём внешней почты.

2. Сопоставить время и код. Единичный 421 требует другой реакции, чем устойчивый 550 5.7.1 на один и тот же домен.

3. Посмотреть полную формулировку ответа. Слова authentication, blocked, rate limit, spam и mailbox full ведут к разным веткам проверки.

4. Проверить очередь отправляющего сервера. Если сообщения застряли до установления соединения, причина может быть в DNS, маршрутизации, TLS или локальном ограничении.

5. Проверить PTR и FCRDNS. Ошибка обратного DNS особенно вероятна после переезда на новый VPS, смены IP или перехода на IPv6.

6. Проверить SPF целиком. Важны единичная запись, корректный синтаксис, актуальные отправляющие сервисы и отсутствие превышения лимита DNS-запросов.

7. Проверить DKIM в полученном письме. Не достаточно увидеть галочку «включено» в панели сервиса — нужна фактическая подпись и результат её проверки.

8. Проверить DMARC и выравнивание. Сравниваются домен в From:, домен SPF и домен DKIM, а не просто наличие соответствующих TXT-записей.

9. Оценить репутационные факторы. Смотрят на жалобы, жёсткие отказы, резкие изменения объёма и историю IP или домена.

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

Полезно тестировать несколько сценариев: письмо с обычным текстом, письмо с HTML, письмо с вложением, транзакционное уведомление и маркетинговую рассылку. Иногда фильтр отклоняет не весь домен, а конкретный тип сообщения. Аналогично, проблема может проявляться только при отправке через один из сервисов, если он использует отдельный envelope sender или не подписывает письма вашим доменом.

Спокойный порядок действий для администратора

Если что-то «сломалось», я бы двигался от самой дешёвой проверки к самой глубокой:

1. Прочитать SMTP-код и полный текст ответа. 4xx — проверить очередь и дать серверу повторить попытку; 5xx — искать причину отказа.

2. Убедиться, что адрес получателя существует и не заблокирован локальной политикой.

3. Проверить PTR-запись IP и соответствие прямого и обратного DNS.

4. Проверить SMTP-приветствие, TLS и корректность имени отправляющего узла.

5. Прогнать SPF через валидатор, проверить единственность записи и число DNS-запросов.

6. Убедиться, что DKIM-ключ опубликован, подпись добавляется, а ключ имеет современную длину.

7. Проверить DMARC, домены SPF и DKIM, а также их выравнивание с From:.

8. Для массового потока проверить List-Unsubscribe, обработку однокликовой отписки, жалобы и bounce-отчёты.

9. Сопоставить изменения в инфраструктуре с началом проблемы: новый IP, новый сервис, смена домена, рост объёма или обновление шаблона.

10. После исправления постепенно вернуть отправку, а не повторять проблемную кампанию в полном объёме.

Звучит как много шагов, но в моей практике большую часть из них достаточно один раз настроить правильно, а затем поддерживать в рабочем состоянии. Почтовый сервер нельзя «настроить навсегда»: меняются сервисы, IP-адреса, политики провайдеров и состав рассылок. Зато диагностика становится предсказуемой, если в логах есть полные ответы, DNS-записи документированы, а источники отправки не размножаются бесконтрольно.

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