Почему письма компании попадают в спам: 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-сертификаты для вашего домена. К почте она отношения не имеет, но проверяется теми же инструментами и закрывает соседний риск — выпуск сертификата для вашего домена посторонними. Всё вместе — это гигиена домена: один раз навести порядок, дальше только поддерживать при подключении новых сервисов.