Почему письма агрокомпании попадают в спам: SPF, DKIM, DMARC и качество базы
КП по семенам отправлено, CRM показывает успешное действие, а покупатель не видит письмо. Это ещё не диагноз «сломался SPF». Сообщение могло остаться в очереди, получить отказ принимающего сервера, пройти аутентификацию и оказаться в спаме либо попасть в ящик, который никто не проверяет. Исправление зависит от наблюдаемого этапа.
Полезный результат расследования — конкретная причина с журналом, исходными заголовками и проверкой повторного случая. Ниже разобраны требования провайдеров на 10 октября 2026 года, безопасный локальный пример и план проверки реальной среды. Учебный пример выполнен; отправка в реальные ящики и измерение доставляемости здесь не проводились.
Показать данные текстом
| Шаг | Что сохраняется | Куда уходит сбой |
|---|---|---|
| Сайт, CRM, почта | Задание отправки и Message-ID | — |
| Передача SMTP | Ответ сервера и очередь | Временный или постоянный отказ и его причина |
| Проверка домена | SPF, DKIM, DMARC и выравнивание | — |
| Решение фильтра | Репутация, база, содержание | «Входящие», «Спам» или другая обработка |
Принятие сервером, аутентификация, папка и ответ человека — разные результаты. Для каждого нужны свои свидетельства.
Показать картинку
Путь письма: отправка, аутентификация и решение принимающего сервиса
Найти место, где прервался путь
Сначала берут одно проблемное сообщение: время, адрес получателя, Message-ID, отправляющую систему и номер КП. Затем запрашивают журнал именно этого маршрута. Письмо менеджера, уведомление сайта, робот CRM и сервис рассылки могут использовать разные серверы, домены возвратов и DKIM-подписи.
| Наблюдение | Что проверить | Чего оно не подтверждает |
|---|---|---|
| CRM выполнила действие отправки | Создание сообщения и передачу почтовому сервису | Принятие сервером покупателя |
| SMTP вернул временный отказ 4xx | Код, текст, очередь и повторные попытки | Окончательный отказ или успешную доставку |
| Получен постоянный отказ 5xx | Причину, адрес, политику и аутентификацию | Что получатель просто не читает почту |
| Принимающий сервер принял сообщение | Дальнейший возврат и состояние в контрольном ящике | Папку «Входящие» и прочтение человеком |
SMTP различает временные и постоянные отрицательные ответы: повтор неизменённого запроса после постоянного отказа не является штатным решением. Конкретный код читают вместе с текстом ответа. .
Если получатель может предоставить исходник письма из спама, сохраняют его целиком. Скриншот темы не заменяет Authentication-Results, Received, DKIM-Signature и адрес возврата. При пересылке обычной кнопкой часть диагностической информации может относиться уже к новой отправке.
Сверить требования конкретного принимающего сервиса
Справочные страницы не дают одинакового минимального набора для всех отправителей. Область применения нужно сохранить вместе с настройкой.
| Провайдер | Аутентификация и существенные условия |
|---|---|
| Gmail, личные аккаунты | Для всех отправителей — SPF или DKIM, корректные прямые и обратные DNS, TLS. Для массовых — SPF и DKIM, DMARC хотя бы p=none, выравнивание домена; рекламным и подписным сообщениям нужна отписка одним действием |
| Яндекс, требования к честным рассылкам | DKIM и SPF обязательны; DMARC рекомендован. Нужны подтверждённый адрес, согласие, работающая отписка и обработка несуществующих адресов |
| Mail, правила рассылок | Требуются SPF/DKIM/DMARC, корректные PTR и обработка возвратов. Рассылка основана на явном запросе или согласии; отказ должен быть простым |
Источники таблицы: , , . У Mail показана дата обновления 6 декабря 2023 года; страницы доступны в исследуемом срезе. Даты редакции остальных страниц не указаны.
В FAQ Gmail массовый отправитель определяется объёмом около 5000 сообщений и более личным Gmail-аккаунтам за 24 часа. Сообщения основного домена и его поддоменов суммируются; однажды присвоенный статус сохраняется. Эти требования не следует механически переносить на входящую почту Google Workspace. .
Разделение отправки по поддоменам помогает описать источники и политики. Оно не гарантирует независимую репутацию и не отменяет правила провайдера о суммировании объёма. Согласие на рекламу и техническая аутентификация тоже проверяются отдельно: запись DNS не создаёт разрешение на рассылку.
SPF: одна запись на домен, все разрешённые источники
SPF проверяет право отправляющего узла использовать домен SMTP MAIL FROM, а не просто видимый адрес в поле From. Поэтому в инвентаризации нужны оба значения. Для нескольких систем отправки политика должна учитывать каждый легитимный источник соответствующего домена.
У домена не должно быть двух выбираемых SPF-записей. При этом несколько строк внутри одной TXT-записи допустимы: они соединяются без добавления пробелов. Лимит SPF — десять DNS-зависимых терминов при вычислении, включая вложенные include и redirect; это не лимит на количество всех TXT-записей домена. Превышение даёт permerror. .
В локальном примере одна запись представлена двумя строками:
example.com TXT "v=spf1 ip4:192.0.2.10 " "-all"Это искусственные домен и адрес для документации, не инструкция для рабочего DNS. В действующую запись вносят только подтверждённые источники своей среды. Добавлять второй v=spf1 для нового сервиса или без проверки расширять список include нельзя: такая правка может ухудшить обработку всех сообщений домена.
DKIM: проверить подпись сообщения, а не наличие слова в DNS
DKIM использует домен d= и селектор s= из подписи. Для d=example.com и s=demo2026 ключ ищут по имени demo2026._domainkey.example.com. Проверка должна подтвердить подпись конкретного сообщения, а не только существование записи. .
У корпоративной почты и рассыльщика могут быть разные селекторы. В карте отправителей фиксируют владельца каждого ключа, фактический домен подписи и процедуру смены. При ротации проверяют новое подписание, публикацию ключа и сообщения, которые ещё находятся в пути. Удаление старого селектора до завершения перехода создаёт отдельный отрицательный сценарий.
Если подпись перестала проходить после промежуточной обработки, сравнивают исходник на входе и выходе: тело, подписанные заголовки, кодировки и добавленные подписи организации. «Ключ опубликован» недостаточно, чтобы исключить изменение сообщения после подписания.
DMARC: результат pass требует выравнивания
DMARC связывает видимый домен From с доменом успешно прошедшего SPF или DKIM. В строгом режиме домены совпадают точно; в мягком проверяется общий организационный домен. Успешная проверка чужого сервисного домена сама по себе не даёт нужного выравнивания. Достаточен один успешно прошедший и выровненный механизм, но отдельные требования провайдера к обоим механизмам сохраняются. .
В мае 2026 года RFC 9989 заменил RFC 7489 и 9091. Среди изменений — удаление pct, который раньше предлагали использовать для процентного ужесточения политики. Новая спецификация вводит тестовый тег t; наличие стандарта не подтверждает его поддержку конкретным получателем. .
Переход начинают с учёта всех отправителей и наблюдения отчётов, затем исправляют легитимные маршруты. Решение о quarantine или reject принимают после проверки прямой отправки, пересылок и списков. Это проект процедуры; произвольное «увеличивать процент каждую неделю» здесь не используется. p=none не отключает антиспам принимающей стороны, а прохождение DMARC не гарантирует попадание во «Входящие».
Что действительно исполнено локально
Подготовлены 12 файлов .eml, набор заданных условий и проверяющий скрипт на стандартной библиотеке Python. Все адреса используют example.com, example.net и example.org; подписи намеренно искусственные. Скрипт разбирает контролируемые заголовки, проверяет точное выравнивание, количество SPF-записей, заданную трассу терминов и элементы отписки.
| Отрицательный сценарий | Полученный результат модели |
|---|---|
SPF и DKIM прошли для sender.example.net, From — example.com | DMARC fail: выравнивания нет |
| Две SPF-записи, но корректный выровненный DKIM задан входом | DMARC pass; ошибка SPF сохранена |
| В заданной трассе 11 DNS-зависимых терминов | Лимит SPF превышен; успешный DKIM не скрывает ошибку |
Поддомены отличаются при aspf=s; adkim=s | DMARC fail |
| Authentication-Results вне доверенного контура | Результат unknown, не pass |
| Нет POST-заголовка, подписи нужных заголовков или поддержки POST | Отдельные ошибки отписки |
Все 12 ожидаемых результатов совпали с полученными: девять модельных pass, два fail и один unknown. Это проверка логики искусственных входов. Она не проверяет ключи, криптографию, полный алгоритм SPF, поиск организационного домена, DNS-кеши или настоящие HTTP-обработчики. Ни одно письмо не отправлено. Протокол и воспроизведение.
Само наличие Authentication-Results не доказывает достоверность результатов: нужен доверенный источник в инфраструктуре получателя. Разрешённый идентификатор сервера в учебном файле не заменяет эту проверку происхождения. .
Отписка и база требуют собственного контроля
Для технической отписки RFC 8058 нужны HTTPS-адрес в List-Unsubscribe, List-Unsubscribe-Post: List-Unsubscribe=One-Click и действительная DKIM-подпись, покрывающая оба заголовка. Обработчик принимает POST; обычная ссылка в теле не заменяет весь механизм. .
В реальной среде отдельно проверяют, что отказ отменяет будущие задания во всех системах. Несуществующий адрес исключают из дальнейшей рассылки после подтверждённого возврата; временные ошибки разбирают по причине. Жалобы, устаревшие контакты и неподтверждённое происхождение базы остаются проблемами даже при корректной аутентификации. Массовую «реактивацию» нельзя считать способом задним числом получить основание для уже отправленной рекламы.
Проверить новый источник до первой массовой отправки
Подключение нового сервиса рассылки или смена домена меняют карту источников. Для нового маршрута отдельно подтверждают домены отправителя, подпись и выравнивание, обработку возвратов и отказов. Успешная проверка прежней CRM не распространяется на новый сервис. Снимок настроек сохраняют с датой, чтобы после изменения можно было объяснить различие результатов.
Протокол проверки настоящей среды
Для инженерного испытания сначала сохраняют карту источников, версии настроек и DNS-снимок с временем, TTL и ответами авторитетных серверов. Затем при разрешённой контрольной отправке сопоставляют Message-ID, SMTP-ответ, исходник у получателя, аутентификацию и наблюдаемую папку. Для каждого маршрута повторяют отрицательные случаи: неправильный домен подписи, отсутствующий селектор, возврат и отказ от подписки.
Отдельный журнал содержит результаты настоящей отправки и пределы наблюдения. Принятие сервером, размещение в ящике и ответ человека — разные события. Открытие по пикселю не подходит для единственного доказательства: Apple может загружать удалённый контент в фоне. .
Измерять реальную доставку следует после такой подготовки, с определёнными получателями и периодом. Проценты попадания в спам, роста открытий или продаж из локального разбора файлов получить нельзя. Зато он позволяет заранее выявить ошибки регламента проверки и не перепутать модельный pass с наблюдаемым результатом отправки. Починка SPF и DMARC нужна не ради галочки. Сценарии писем после коммерческого предложения — как раз те отправки, которые иначе не дойдут до агронома и закупщика.
7 мин
24 октября 2026 
