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

Проверить это на практике можно бесплатным тестом попадания письма во «Входящие» на check.live-direct-marketing.online.

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