Как письма попадают в спам: разбор пути письма

MAATRIX

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

Путь письма целиком: карта проверок принимающей стороны

Когда ваш сервер (Postfix, Exim, iRedMail, Mailcow — неважно) отправляет письмо, принимающий MTA получателя (условно gmail-smtp-in, outlook.com, yandex.ru) проходит примерно такую последовательность:

1. Проверка репутации IP-адреса, с которого пришло соединение — ещё до чтения содержимого письма.
2. Проверка аутентификации — SPF, DKIM, DMARC, а также согласованность (alignment) между ними.
3. Анализ содержимого письма — текст, вложения, ссылки, HTML-разметка, заголовки.
4. Учёт поведения получателей — как реагировали на письма с этого отправителя раньше (жалобы на спам, открытия, удаления не читая).

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

Дальше — детально по каждому этапу, а в конце — как диагностировать, где именно у вас проблема.

Этап 1. Репутация IP-адреса отправителя

Это первое, что видит принимающий сервер — ещё на этапе TCP-соединения и SMTP-диалога, до какого-либо анализа текста письма. Проверяется:

• Исторический «послужной список» IP: как долго с этого адреса отправляется почта, сколько жалоб на спам поступало, попадал ли IP в чёрные списки (Spamhaus, SORBS, Barracuda и десятки других).
• PTR-запись (обратная DNS-зона): соответствует ли обратное разрешение IP → hostname прямому разрешению hostname → IP, и выглядит ли hostname как легитимный почтовый сервер, а не как динамический IP провайдера (123-45-67-89.dynamic.isp.ru — почти гарантированный повод для подозрения). Подробно про настройку и типичные ошибки PTR — отдельная тема, если у вас ещё нет корректной PTR-записи на арендованном сервере, это первое, что стоит проверить.
• «Возраст» и репутацию диапазона IP: новый или «холодный» IP по умолчанию не имеет доверия — принимающие серверы попросту не знают, чего от него ожидать, и применяют более строгие лимиты и фильтры. Это касается и IP, которые раньше принадлежали спамерам (типично для дешёвых VPS-провайдеров, где IP переиспользуются) — в таком случае вы наследуете чужую плохую репутацию.
• Скорость и объём отправки: резкий скачок исходящей почты с ранее «тихого» IP сам по себе выглядит подозрительно, даже если письма легитимны.

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

Этап 2. Аутентификация: SPF, DKIM, DMARC

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

• SPF (Sender Policy Framework) — DNS-запись у домена-отправителя перечисляет, каким IP-адресам разрешено слать почту от его имени. Принимающий сервер сверяет IP отправителя со списком.
• DKIM (DomainKeys Identified Mail) — криптографическая подпись письма закрытым ключом, которую принимающая сторона проверяет открытым ключом из DNS. Подтверждает, что письмо не подделано и не изменено в пути.
• DMARC (Domain-based Message Authentication) — политика поверх SPF и DKIM: что делать, если проверки не прошли (ничего не делать, пометить как подозрительное, отклонить), плюс требование «согласованности» (alignment) домена в заголовке From с доменом, прошедшим SPF/DKIM.

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

Здесь важно зафиксировать главное: даже безупречно настроенные SPF, DKIM и DMARC — это подтверждение того, что письмо не подделано, а не гарантия, что оно не спам. Аутентификация отвечает на вопрос «кто отправил письмо», а не «хорошее ли это письмо». Спамер тоже может настроить SPF/DKIM/DMARC для своего домена — и пройти этот этап без проблем, провалившись на следующих.

Этап 3. Анализ содержимого письма

Если отправитель прошёл проверку репутации IP и аутентификации, спам-фильтр принимающей стороны (у Gmail, Яндекса, Mail.ru и корпоративных серверов — свои алгоритмы, часто на базе машинного обучения) анализирует само содержимое:

• Текст письма: характерные спам-слова и обороты («бесплатно», «срочно», избыточные восклицательные знаки, ALL CAPS в теме), соотношение текста и изображений, скрытый текст белым по белому фону.
• Ссылки: домены, на которые ведут ссылки в письме — их репутация, использование сервисов сокращения ссылок, несоответствие видимого текста ссылки и реального URL.
• HTML-разметка: неаккуратный или сгенерированный автоматически HTML, отсутствие текстовой версии письма (только HTML, без plain-text альтернативы), подозрительные скрипты или трекеры.
• Заголовки письма: несоответствия между заявленным отправителем, обратным адресом (Reply-To) и доменом в подписи DKIM, отсутствие корректного Message-ID, аномалии в служебных заголовках, которые добавляет ваш почтовый сервер (Postfix/Exim) при отправке.
• Вложения: типы файлов, наличие макросов, соответствие содержимого заявленному типу.

Если вы используете фильтр Rspamd на собственном сервере для входящей почты, тот же принцип работает и у получателя — только там уже не вы контролируете правила. На своей стороне полезно прогонять исходящие письма через тестовые сервисы (например, mail-tester.com), которые показывают, как реагируют на письмо основные спам-фильтры, до того как проблема проявится на реальных получателях.

Этап 4. Поведение получателей и накопление репутации

Это, пожалуй, наименее очевидный этап — и он же со временем становится самым весомым для крупных провайдеров вроде Gmail. Принимающая сторона следит за тем, как реальные получатели реагируют на письма от конкретного отправителя (связка домен + IP + иногда конкретный поддомен рассылки):

• Жалобы на спам: если заметная доля получателей нажимает «Это спам» на письма с вашего домена, будущие письма от этого отправителя всё активнее фильтруются — независимо от того, что писать в теме или как настроен DKIM.
• Открытия и переходы по ссылкам: аномально низкий процент открытий по сравнению с типичным поведением для такого объёма рассылки — сигнал, что письма либо неинтересны получателям, либо вообще не доходят до глаз человека (уже осели в спаме, что усугубляет проблему по кругу).
• Удаление без открытия: массовое удаление писем не читая — тоже негативный сигнал вовлечённости.
• Добавление в адресную книгу / «Не спам»: обратный, положительный сигнал — если получатели явно отмечают отправителя как надёжного.

Эти сигналы накапливаются со временем и формируют репутацию домена и IP у конкретного провайдера — то, что у Gmail видно через Google Postmaster Tools (если вы отправляете достаточный объём почты, чтобы туда попасть). Именно поэтому резкий разовый успех («один раз настроили — и всё заработало») в email-доставляемости не работает: репутация строится и портится постепенно, на горизонте недель и месяцев, а не одним технически правильным письмом.

Почему нет одной «волшебной настройки»

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

Это значит:

• Правильно настроенные SPF, DKIM и DMARC — необходимое, но не достаточное условие. Они закрывают только этап 2. Если у вас плохая репутация IP (этап 1) или письма выглядят как спам-рассылка (этап 3), безупречная аутентификация не спасёт.
• Прогретый, чистый IP с хорошей историей (этап 1) не гарантирует доставляемость, если письма технически не аутентифицированы (этап 2) или содержимое триггерит спам-фильтры (этап 3).
• Даже идеальные технические настройки и хороший IP могут не помочь, если получатели массово жалуются на письма (этап 4) — например, если рассылка идёт по устаревшей базе адресов, которые давно не открывают почту.

Таблица ниже — сжатая карта того, какой этап за что отвечает и где искать причину, если что-то не так:

Как диагностировать проблему с доставляемостью

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

1. Проверьте репутацию IP отдельно от всего остального. Пробейте IP по основным чёрным спискам (например, через mxtoolbox.com/blacklists), проверьте, что PTR-запись настроена и соответствует прямой зоне: dig -x ВАШ_IP +short должен вернуть hostname, а dig ВОЗВРАЩЁННЫЙ_HOSTNAME +short — обратно тот же IP. Если IP новый — не делайте выводов по одному тестовому письму, отправка с холодного IP объективно хуже доходит первые дни-недели вне зависимости от остальных настроек.
2. Проверьте аутентификацию отдельно. Отправьте тестовое письмо на свой ящик в Gmail и откройте «Показать оригинал» — там явно видны результаты SPF, DKIM и DMARC (spf=pass, dkim=pass, dmarc=pass или соответствующие fail). Если тут fail — проблема локализована точно, дальше смотрим DNS-записи и конфиг Postfix/OpenDKIM. Если тут pass — переходите к следующему этапу, аутентификация не виновата.
3. Проверьте содержимое отдельно от инфраструктуры. Прогоните конкретное письмо (не абстрактный шаблон, а именно то, что реально уходит в спам) через тестовый сервис оценки спамности. Если оценка низкая при pass на всех проверках аутентификации и чистом IP — смотрите текст, ссылки и HTML-разметку письма.
4. Проверьте историю поведения получателей отдельно. Если первые три пункта в порядке, а доставляемость всё равно плохая — вероятно, дело в накопленной репутации у конкретного провайдера из-за старых рассылок или в качестве базы адресов (устаревшие, несуществующие ящики, много неактивных получателей).

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

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