Почему письма с домена не доходят или попадают в спам

Как проходит письмо от отправителя до ящика

Удобнее искать проблему как разрыв цепочки. На каждом этапе остаются разные следы: ошибка приложения, журнал отправляющего сервера, SMTP-ответ получателя, результаты SPF/DKIM/DMARC или уже готовые заголовки доставленного сообщения.

Симптом → где искать причину → что проверить первым

1. Сначала выясните, письмо не отправилось, было отклонено или отфильтровано

Это три разные задачи. Если сайт не смог авторизоваться на SMTP-сервере, никакая правка DMARC не поможет: письмо ещё не дошло до внешнего получателя. Если получатель вернул 550, нужно изучать его отказ. Если сервер получателя принял сообщение, а пользователь нашёл его в папке «Спам», транспорт уже сработал и диагностика смещается к аутентификации, репутации и фильтрации.

Есть ли запись об отправке на вашем сервере

Для сайта, CRM или приложения ищите журнал именно почтовой отправки. Полезны время, адрес получателя, Message-ID, имя SMTP-сервера и его ответ. Сообщение интерфейса «успешно» иногда означает только то, что приложение передало данные своей библиотеке, а не то, что письмо дошло до удалённого домена.

Есть ли bounce — письмо о недоставке

Возврат обычно содержит больше информации, чем короткая фраза «не доставлено»: адрес проблемного получателя, трёхзначный SMTP-код, расширенный код вида 5.7.26 или 5.1.1 и текст политики. Сохраняйте сообщение целиком.

Если возврата нет

Отсутствие bounce не доказывает попадание во входящие. Письмо могло быть принято удалённой системой, а затем попасть в спам, карантин, правило сортировки или внутреннюю пересылку. Для корпоративного получателя полезен message trace или аналогичный журнал на его стороне.

2. Как читать SMTP-коды 421, 450, 451, 550, 552 и 554

В SMTP первая цифра особенно важна. Ответы 4xx относятся к временным ошибкам: отправляющий сервер обычно может повторить доставку позже. Ответы 5xx означают постоянный отказ для текущей попытки, и бессмысленно просто повторять то же письмо без изучения причины.

3. MX: куда приходит почта вашего домена

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

Что проверить

• MX указывает на действующие почтовые серверы вашего провайдера;
• в DNS не остались старые MX после миграции почты;
• приоритеты MX соответствуют схеме провайдера;
• почтовые ящики и маршрутизация реально существуют на указанной стороне.

4. SPF: имеет ли этот сервер право отправлять от имени домена

SPF может проверять SMTP-идентичности HELO/EHLO и MAIL FROM. При обычной диагностике исходящей почты часто смотрят MAIL FROM; именно результат SPF для MAIL FROM используется DMARC при проверке alignment. Это не просто «галочка, что SPF существует». Запись должна включать все реальные сервисы, которые отправляют вашу почту: основной почтовый хостинг, CRM, сервис рассылок, сайт или транзакционный провайдер, если они используют ваш домен в соответствующей SMTP-идентичности.

Типичные ошибки SPF

• новый сервис начал отправлять письма, но его источник не добавили в SPF;
• для одного имени опубликовано несколько SPF-записей вместо одной корректной политики;
• цепочка include, a, mx и других DNS-запросов стала слишком сложной;
• после миграции в SPF остались старые источники, а новые не добавлены;
• письмо проходит SPF для технического домена сервиса, но этот домен не согласован с видимым From для DMARC.

Стандарт SPF ограничивает число терминов, вызывающих DNS-запросы при проверке, десятью. Превышение лимита приводит к permerror. Поэтому бесконечно добавлять include тоже нельзя.

5. DKIM: действительно ли письмо подписано вашим доменом

DKIM добавляет к письму криптографическую подпись. Получатель берёт домен подписи и selector из заголовка DKIM-Signature, получает открытый ключ через DNS и проверяет, что подписанные части сообщения соответствуют подписи.

Почему одного доменного имени недостаточно для проверки DKIM

Ключ ищется по имени вида selector._domainkey.example.com. Selector выбирает отправляющая система, и у одного домена их может быть несколько. Поэтому универсальная «проверка DKIM только по example.com» не знает, какой selector использовать.

Как найти selector

Откройте исходные заголовки реально отправленного письма и найдите DKIM-Signature. Параметр s= содержит selector, а d= — домен подписи. После этого можно проверить соответствующее DNS-имя. У некоторых почтовых провайдеров по этому DNS-имени опубликована TXT-запись с ключом, у других имя является CNAME на инфраструктуру провайдера.

6. DMARC: совпадает ли аутентифицированный домен с тем, что видит получатель

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

Политики p=none, quarantine и reject

Запись DMARC также выражает предпочтение владельца домена по обработке сообщений, не прошедших проверку. Режим p=none используется для мониторинга без запроса карантина или отклонения, а более строгие политики требуют особенно аккуратного внедрения: сначала нужно убедиться, что легитимные источники действительно аутентифицируются и выровнены.

7. Обратный DNS, отправляющий IP и репутация

Если вы отправляете с собственного SMTP-сервера или выделенного IP, получатель видит реальный IP соединения и может учитывать его имя, историю и репутацию. Для таких серверов особенно важно, чтобы PTR (reverse DNS) был настроен владельцем IP, а имя сервера корректно разрешалось обратно. Если вы используете крупного почтового провайдера, эту часть инфраструктуры обычно обслуживает он.

Почему правильный SPF не исправляет плохую репутацию

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

Проверьте, с какого IP письмо реально ушло

Не ориентируйтесь только на IP сайта. Веб-сервер и почтовый сервер могут быть разными системами. Реальный исходящий IP лучше брать из логов SMTP-провайдера или заголовков уже доставленного письма.

8. Почему письмо попадает в спам, хотя SPF, DKIM и DMARC проходят

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

Репутация домена и IP

На неё влияет история отправки. После взлома сайта, резкого всплеска трафика или длительного периода нежелательных рассылок технически корректно подписанное письмо всё равно может оцениваться осторожно.

Жалобы получателей и согласие на рассылку

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

Резкие изменения объёма и смешивание разных типов писем

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

Требования крупных почтовых сервисов меняются

На момент обновления этого руководства крупные провайдеры отдельно публикуют требования для отправителей и ужесточают их для массовых потоков: аутентификация, согласование доменов, низкий уровень жалоб, корректная DNS-инфраструктура и удобная отписка. Не переносите старую памятку из интернета на новый проект — перед массовой отправкой сверяйтесь с актуальными официальными sender guidelines конкретного получателя.

9. Что можно узнать из заголовков доставленного письма

Если хотя бы одно тестовое письмо дошло, его исходные заголовки часто дают больше информации, чем просмотр DNS отдельно. Ищите блок Authentication-Results и DKIM-Signature. Если Authentication-Results несколько, ориентируйтесь на результат, добавленный принимающим почтовым сервисом или другой доверенной системой: одноимённый заголовок может присутствовать и во входящем сообщении.

Заголовки особенно полезны, когда «в DNS всё есть», но письмо всё равно фильтруется. Они показывают результат проверки именно конкретного сообщения, а не предполагаемую конфигурацию домена.

10. Если письма отправляет сайт, форма или CRM

У веб-приложения может быть собственный почтовый поток, отличный от обычной корпоративной почты. Например, сотрудники пишут через один сервис, а форма сайта отправляет через хостинг, отдельный SMTP или транзакционного провайдера. Тогда «у нас SPF настроен для почты» ещё не означает, что источник сайта разрешён и подписывает письма правильно.

Проверьте реальный способ отправки

• какой SMTP-сервер использует приложение;
• какой MAIL FROM / Return-Path формируется;
• какой адрес стоит в видимом From;
• подписывает ли этот поток письма DKIM;
• входит ли реальный источник в SPF;
• проходит ли DMARC alignment;
• какие ответы SMTP сохраняются в логах.

Что передать почтовому провайдеру или администратору

Хороший запрос в поддержку должен позволить найти конкретную SMTP-транзакцию, а не начинать расследование со слов «иногда письма не доходят».

• полный адрес отправителя и домен;
• полный адрес получателя или хотя бы домен получателя, если адрес нельзя раскрывать;
• точное время отправки и часовой пояс;
• Message-ID, если он известен;
• полный bounce / SMTP-ответ без обрезания строки;
• исходящий IP и имя SMTP-сервера, если они известны;
• происходит ли проблема у всех получателей или только у одного провайдера;
• попадает ли письмо в спам, если всё-таки доставляется;
• что менялось перед появлением проблемы: DNS, почтовый сервис, сайт, CRM, IP, объём отправки.

Чего эта диагностика не может гарантировать

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

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

Наконец, не обещайте фиксированный срок «восстановления доставки» после исправления записи. DNS зависит от TTL и кэшей, а антиспам- и репутационные системы работают по собственным правилам.