Почему письма компании попадают в спам: SPF, DKIM и DMARC простыми словами

Ключевой факт о электронной почте: сам протокол не проверяет отправителя. Кто угодно может отправить письмо, где в поле «От» стоит ваш домен, - так устроена технология с 1980-х. Всю защиту почтовые сервисы надстроили сверху: получая письмо «от вашего домена», они сверяются с DNS-записями этого домена - SPF, DKIM и DMARC - и решают, верить ли письму.

С 2024 года крупнейшие почтовые провайдеры - Gmail, Яндекс и другие - перевели эти проверки из рекомендаций в требования: без корректных записей письма массовых отправителей отклоняются или уходят в спам независимо от содержания. Поэтому «у нас маленькая компания, нам не надо» больше не работает: правила общие для всех, кто шлёт почту с собственного домена.

SPF - это текстовая запись в DNS вашего домена, в которой перечислены серверы, имеющие право отправлять почту от этого домена: ваш почтовый провайдер, сервис рассылок, CRM. Получатель сверяет: письмо пришло с сервера из списка - проверка пройдена; с постороннего - это повод для подозрений.

Типовые ошибки: записи нет вообще; в неё забыли добавить сервис рассылок или платформу уведомлений - и их письма стали «нелегитимными»; в домене случайно живут две SPF-записи (это ломает проверку целиком); стоит разрешающее «+all», которое обнуляет смысл записи. Отдельная классика - сервисы, которые когда-то подключили, отключили, а из SPF не убрали: разрешение слать от вашего имени осталось у чужой инфраструктуры.

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

На практике DKIM включается на стороне почтового сервиса (Яндекс 360, VK WorkSpace, сервисы рассылок - у всех есть инструкция), а в вашу DNS добавляется запись с ключом. Ошибка здесь обычно одна: подпись включили у основного провайдера, но забыли у транзакционных отправителей - уведомлений сайта, CRM, платёжных писем. В итоге самые важные письма - про заказы и оплаты - идут без подписи.

SPF и DKIM отвечают на вопрос «настоящее ли письмо», но не говорят получателю, что делать с ненастоящим. Это работа DMARC - записи-политики: «письма от нашего домена, не прошедшие проверки, - пропускать (none), в спам (quarantine) или отклонять (reject)». Без DMARC даже идеальные SPF и DKIM не защищают от подделки: почтовый сервис видит подозрительное письмо, но инструкции на этот случай у него нет.

Второй дар DMARC - отчёты: почтовые сервисы присылают сводки, кто и откуда шлёт письма от вашего домена. Именно из них компании узнают, что от их имени идёт рассылка из неожиданных стран - или что легитимный сервис выпал из SPF. Правильная траектория: включить DMARC с политикой none и отчётами, две-четыре недели наблюдать, починить легитимных отправителей - и только потом ужесточать до quarantine и reject. Сразу ставить reject опасно: вместе с мошенниками отсечёте собственные письма.

Проверка занимает минуту: все три записи публичны, их видит любой инструмент проверки DNS - в том числе бесплатный экспресс-скан на нашей странице аудита, который заодно смотрит TLS и security-заголовки сайта. Дальше порядок простой: сначала SPF с полным списком реальных отправителей, затем DKIM у каждого из них, затем DMARC с none и отчётами - и постепенное ужесточение политики.

Бонус-запись из той же серии - CAA: она ограничивает, какие центры сертификации могут выпускать TLS-сертификаты для вашего домена. К почте она отношения не имеет, но проверяется теми же инструментами и закрывает соседний риск - выпуск сертификата для вашего домена посторонними. Всё вместе - это гигиена домена: один раз навести порядок, дальше только поддерживать при подключении новых сервисов.