SPF, DKIM и DMARC: зачем письму три протокола аутентификации

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

Почему провайдеры перестали верить письмам на слово

Протокол электронной почты SMTP создавался в эпоху, когда сети доверяли друг другу: в поле «От кого» можно написать любой адрес, и технически письмо уйдёт. Этим десятилетиями пользовались спамеры и фишеры — слали письма «от банков» и «от коллег», не имея к ним никакого отношения. Ответом индустрии стали протоколы аутентификации: SPF, DKIM и DMARC. Их совместная задача — дать получающему серверу способ проверить, что письмо с адреса ivan@company.ru действительно отправлено инфраструктурой company.ru.

Для отправителя деловых писем это означает простую вещь: почтовые провайдеры по умолчанию не доверяют никому. Письмо без аутентификации — аноним без документов: его либо не пустят вовсе, либо посадят в папку «Спам» до выяснения. Gmail с 2024 года прямо требует SPF и DKIM от всех отправителей, а для заметных объёмов — ещё и DMARC; Яндекс и Mail.ru движутся в том же направлении.

Важно понимать роль аутентификации правильно: это пропуск на фильтрацию, а не в инбокс. Письмо с идеальными SPF, DKIM и DMARC всё равно оценивается по репутации домена, жалобам и содержанию. Но без пропуска до этой оценки оно просто не доходит.

SPF: список серверов, которым разрешено слать от вашего имени

SPF (Sender Policy Framework) — самый старый и простой из трёх протоколов. Это TXT-запись в DNS вашего домена, в которой перечислено: «почту с моего домена имеют право отправлять вот эти серверы». Получающий сервер смотрит, с какого IP-адреса фактически пришло письмо, сверяет его со списком в SPF-записи домена отправителя и получает вердикт: pass (сервер в списке), fail (не в списке) или мягкие промежуточные варианты.

Пример записи: v=spf1 include:_spf.yandex.net ip4:203.0.113.10 ~all. Читается так: письма от нашего домена легально ходят через серверы Яндекса и через сервер 203.0.113.10, всё остальное — считать подозрительным. У SPF есть важные ограничения: запись должна быть одна на домен, а суммарное число DNS-обращений при её проверке — не больше десяти, поэтому бездумное добавление include для каждого нового сервиса рано или поздно ломает всю запись.

Слабое место SPF — пересылки: когда письмо форвардится через промежуточный сервер, исходный IP теряется и проверка падает, хотя письмо настоящее. Именно поэтому SPF в одиночку недостаточен и его дополняет DKIM.

DKIM: криптографическая подпись содержимого

DKIM (DomainKeys Identified Mail) решает другую задачу: подтвердить, что письмо не изменили по дороге и что его действительно подписал владелец домена. Работает это на паре ключей. Закрытый ключ хранится на отправляющем сервере и ставит невидимую подпись на заголовки и тело каждого письма. Открытый ключ публикуется в DNS домена, и любой получающий сервер может им проверить подпись.

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

На практике DKIM настраивается на стороне почтового сервиса: он генерирует пару ключей и говорит, какую запись с селектором добавить в DNS. От отправителя требуется одно — фактически добавить запись и убедиться, что подпись ставится именно доменом отправки, а не техническим доменом сервиса-посредника.

DMARC: политика на случай провала проверок

SPF и DKIM отвечают на вопрос «настоящее ли письмо», но не говорят получающему серверу, что делать с ненастоящим. Эту роль выполняет DMARC (Domain-based Message Authentication, Reporting and Conformance) — ещё одна TXT-запись в DNS, в которой владелец домена публикует политику: письма, не прошедшие проверку, ничего не делать (p=none), отправлять в спам (p=quarantine) или отклонять (p=reject).

У DMARC есть второй механизм, который часто недооценивают, — выравнивание (alignment). Он требует, чтобы домен в видимом получателю поле «От кого» совпадал с доменом, прошедшим SPF или DKIM. Без этого мошенник мог бы пройти проверки со своим доменом, а в поле From показать ваш. Именно DMARC связывает техническую аутентификацию с тем, что видит человек.

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

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

Проследим путь холодного письма от отправки до инбокса. Ваш сервер отправляет письмо и подписывает его DKIM-ключом. Сервер получателя, например Gmail, принимает соединение и первым делом смотрит SPF: пришло ли письмо с IP, разрешённого доменом отправителя. Затем проверяет DKIM-подпись по открытому ключу из DNS. Потом запрашивает DMARC-политику домена из поля From: сошлись ли проверки с выравниванием и что владелец домена велел делать при провале.

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

Для адресного B2B-аутрича это критично вдвойне. Объёмы малые, каждое письмо адресовано конкретному ЛПР, и потеря даже 10–15% доставки из-за кривой аутентификации означает, что часть тщательно собранного сегмента вы просто не достали. При этом исправляется всё это один раз: три DNS-записи, час работы, проверка — и техническая часть больше не съедает результат.

Типичные ошибки и как проверить себя

Самые частые проблемы, которые мы видим на аудитах доменов перед стартом кампаний: две SPF-записи на одном домене (валидна ни одна), превышение лимита DNS-обращений из-за накопленных include, DKIM-подпись техническим доменом сервиса вместо домена отправки, DMARC отсутствует вовсе или годами висит в p=none без разбора отчётов. Отдельная классика — настроили всё на основном домене, а рассылку ведут с поддомена, у которого своих записей нет.

Проверить себя можно за пять минут без специальных инструментов. Отправьте письмо со своего боевого ящика на Gmail, откройте его и выберите «Показать оригинал»: вверху будет сводка SPF, DKIM и DMARC с вердиктами pass или fail. Тот же приём работает с Яндекс.Почтой через просмотр служебных заголовков. Если хотя бы один вердикт не pass — начинать кампании рано.

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

• Проверьте, что SPF-запись на домене ровно одна и укладывается в 10 DNS-обращений
• Убедитесь, что DKIM подписывает письма доменом отправки, а не доменом сервиса
• Опубликуйте DMARC хотя бы с p=none и адресом для отчётов
• Отдельно проверьте поддомен, с которого реально идёт отправка
• Отправьте тест на Gmail и Яндекс, посмотрите вердикты в оригинале письма
• Раз в месяц заглядывайте в DMARC-отчёты: кто шлёт от имени вашего домена

Что это значит для холодного аутрича

В адресном B2B-аутриче аутентификация — нулевой этап, который выполняется до сборки базы и написания писем. Стандартная схема: под аутрич выделяется отдельный домен или поддомен, на нём настраиваются SPF, DKIM и DMARC, ящики прогреваются 2–4 недели, и только потом начинаются кампании. Так основной корпоративный домен изолирован от рисков, а отправка стартует с чистой технической базы.

В LDM проверка аутентификации встроена в подготовку кампании: платформа проверяет записи домена отправки и не даст спалить сегмент из-за забытой DNS-записи. Но сами протоколы — не про инструменты, а про доверие: провайдеры годами ужесточают требования, и тренд один — письмо без полной аутентификации будет доставляться всё хуже. Настроить три записи один раз дешевле, чем терять ответы ЛПР каждую кампанию.

Вопросы и ответы