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

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

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

Сначала определите, что именно произошло

Если удалённый сервер не принял письмо, исходящая система обычно получает SMTP-код и текст причины. Код 5xx означает постоянный отказ для конкретной попытки, 4xx — временную проблему, после которой сервер может повторить доставку. Уведомление о недоставке, журнал очереди или ответ SMTP гораздо информативнее пересказа «не дошло».

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

Для первичного разбора зафиксируйте:

• точное время отправки и адрес получателя;
• Message-ID и адрес envelope-from, если они доступны;
• полный SMTP-ответ или текст уведомления о недоставке;
• заголовки Authentication-Results и Received у принятого письма;
• домен и IP фактического исходящего сервера;
• повторяется ли результат у одного получателя, одного провайдера или у всех.

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

Проверьте SPF, DKIM и DMARC по реальному письму

DNS-проверка показывает, что записи существуют, но не доказывает, что конкретное сообщение использовало ожидаемые домены и подпись. Откройте Authentication-Results на стороне получателя. SPF должен оцениваться для фактического envelope-from и IP; DKIM — для домена d= и селектора из подписи; DMARC — для домена видимого заголовка From.

DMARC проходит, если успешен и выровнен хотя бы один путь: SPF или DKIM. Поэтому простой результат spf=pass ещё не гарантирует dmarc=pass: технический домен конверта может не совпадать с видимым From. Аналогично dkim=pass не помогает DMARC, если подпись сделана несвязанным доменом сервиса.

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

• spf=fail, softfail или permerror из-за неизвестного IP, нескольких SPF-политик или слишком сложной цепочки include;
• dkim=fail из-за неверного селектора, отсутствующего ключа или изменения подписанного содержимого;
• dmarc=fail при отсутствии выравнивания с заголовком From;
• none, когда механизм не был настроен или сообщение не подписано ожидаемым доменом.

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

Сверьте техническую идентичность сервера

Принимающие системы смотрят не только на TXT-записи домена. Для исходящего IP обычно важны корректная обратная DNS-запись, осмысленное имя в SMTP-команде EHLO/HELO, прямое разрешение этого имени и стабильное TLS-соединение. Конкретные требования различаются, поэтому ориентироваться нужно на опубликованные правила крупных получателей и на фактический текст отказа.

Обратную запись PTR устанавливает владелец IP-диапазона, а не обычная DNS-панель домена. Имя из PTR желательно согласовать с именем почтового узла и его прямой A/AAAA-записью. Случайное динамическое имя, несоответствие EHLO или отсутствие обратного разрешения не всегда автоматически блокируют письмо, но затрудняют проверку идентичности и часто встречаются в диагностике отказов.

MX здесь играет другую роль: он задаёт маршрут входящей почты для домена. Его наличие не авторизует исходящий IP и не заменяет PTR, SPF или DKIM. Если проблема возникла после миграции приёма, отдельно проверьте MX-запись для почты и безопасное переключение маршрута.

Репутация строится поведением, а не одной записью

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

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

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

Проверьте список получателей и согласие

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

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

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

Содержание важно, но нет списка «запрещённых слов»

Фильтры оценивают сочетание сигналов. Одно слово, цвет кнопки или количество картинок редко объясняют результат сами по себе. Гораздо полезнее проверить, соответствует ли тема реальному содержанию, понятно ли назван отправитель, не маскируются ли ссылки и есть ли у сообщения нормальная текстовая версия наряду с HTML.

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

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

Диагностируйте по слоям

Последовательная проверка экономит время:

Меняйте по одному контролируемому фактору и сохраняйте пример до и после. Одновременная замена IP, домена, темы и DNS лишает вас возможности понять, что помогло. Для редкой проблемы полезнее один полный заголовок и точный SMTP-ответ, чем десяток скриншотов разных интерфейсов.

Как Mailcore помогает с доставляемостью

При подключении специалист Mailcore готовит и проверяет MX, SPF, DKIM и DMARC под фактическую схему отправки. Для настроенных ящиков доступны веб‑почта, IMAP и SMTP, а входящий поток проходит антиспам‑проверку. Контрольные письма во внешние системы помогают проверить реальный маршрут и аутентификацию.

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

Перед первым рабочим потоком полезно пройти весь путь подключения домена и провести контрольные отправки. Порядок описан в материале Как Mailcore подключает домен: от заявки до первого письма.

Короткий план действий

Начните с точного статуса: отказ, временная задержка или спам после принятия. Получите SMTP-ответ либо полные заголовки. Проверьте реальные результаты SPF, DKIM и DMARC, затем IP, PTR и EHLO. После технического слоя изучите жалобы, отказы, источник адресов и динамику объёма. Только потом экспериментируйте с содержанием.

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

Источники

• Google: Email sender guidelines
• Microsoft Learn: Troubleshooting mail sent to Microsoft 365
• RFC 5321: Simple Mail Transfer Protocol
• RFC 9989: DMARC