SPF, DKIM и DMARC: полная настройка аутентификации почты

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

Общая идея: идентичность и доверие

Почта проектировалась в эпоху, когда о себе не врали, поэтому в самом протоколе нет способа доказать, кто отправитель. SPF, DKIM и DMARC — это слои, навешенные позже, чтобы починить это. SPF говорит, какие серверы могут слать от вашего домена. DKIM криптографически подписывает каждое письмо, чтобы его нельзя было подделать или изменить. DMARC связывает эти два, задаёт политику для писем, не прошедших проверку, и присылает отчёты. Вместе они позволяют Gmail с уверенностью сказать «это действительно от вашсайт.ru» — а именно эта уверенность и открывает инбокс.

SPF — кому разрешено отправлять

SPF — это одна TXT-запись со списком сервисов, которым разрешено слать почту от вашего домена:

v=spf1 include:_spf.sendersy.com include:_spf.google.com ~all

Читается слева направо: версия spf1, затем список механизмов include: для каждого сервиса, и в конце ~all (мягкий отказ остальным) или -all (жёсткий). Два правила критичны: не превышайте лимит в 10 DNS-запросов (каждый include может добавлять новые) — иначе SPF вернёт permerror и фактически упадёт; и публикуйте ровно одну SPF-запись — две записи v=spf1 на одном домене недопустимы и ломают SPF целиком. Все include объединяйте в одну запись.

DKIM — подпись каждого письма

DKIM добавляет в заголовок письма криптографическую подпись. Принимающий сервер берёт ваш публичный ключ из DNS и проверяет подпись, доказывая, что письмо не изменили в пути и оно действительно от сервера, владеющего приватным ключом. Провайдер генерирует пару ключей и выдаёт селектор вида postal._domainkey.вашдомен.ru — опубликуйте его как есть. Селектор (postal) должен совпадать с тем, что отправитель ставит на исходящие письма. Если вы шлёте из нескольких сервисов, у каждого свой селектор, и они спокойно сосуществуют.

DMARC — политика и отчёты

DMARC — ключевой элемент. Он требует, чтобы SPF или DKIM не просто прошли, а были выровнены с видимым доменом «от кого», задаёт, что делать с непрошедшими письмами, и присылает сводные отчёты:

_dmarc.вашдомен.ru  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@вашдомен.ru; fo=1"

Тег p= — это политика: none (только мониторинг), quarantine (в спам) или reject (отклонять). Адрес rua получает ежедневные сводные отчёты о том, кто шлёт от вашего домена — бесценно, чтобы найти всех легитимных отправителей до ужесточения политики.

Безопасная последовательность внедрения

Ошибка №1 — сразу поставить p=reject и заблокировать собственную почту. Делайте поэтапно:

1. Опубликуйте SPF и DKIM и убедитесь, что оба проходят на тестовом письме.
2. Включите DMARC на p=none с адресом для отчётов. Доставка пока не меняется.
3. Читайте отчёты 2–4 недели. Найдите все легитимные источники — приложение, ESP, поддержку, биллинг — и добейтесь, чтобы каждый проходил SPF и DKIM с выравниванием.
4. Перейдите на p=quarantine; pct=25, понаблюдайте, поднимите процент к 100.
5. Включите p=reject, когда ничего легитимного не падает. Спуфить вас больше нельзя.

Что содержат отчёты DMARC

Смысл публиковать DMARC даже на p=none — именно в отчётах. Раз в сутки крупные почтовики присылают на вашrua XML-сводку: какие IP слали от вашего домена, сколько писем и прошли ли SPF и DKIM с выравниванием. В сыром виде это неудобно, поэтому отчёты обычно загружают в анализатор, который превращает их в читаемую таблицу. Вы ищете простое: список всех IP, шлющих от вас, разделённый на «легитимные и проходящие» и «всё остальное». Первый столбец — инвентарь отправителей, которых надо сохранить рабочими; второй — либо забытые сервисы, либо прямой спуфинг.

Выравнивание: тонкость, которую все упускают

DMARC требует не просто прохождения SPF или DKIM, а выравнивания (alignment): домен в техническом отправителе (для SPF) или домен подписи (для DKIM) должен совпадать с доменом «от кого», который видит получатель. Письмо может пройти «сырой» SPF на домене провайдера и при этом не пройти DMARC, потому что тот домен не выровнен с вашим «от кого». Поэтому так часто встречается запутанный результат «SPF проходит, а DMARC падает» — и поэтому важно, чтобы сервис подписывал письма вашим доменом.

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

Большинство организаций шлёт из нескольких источников: приложение — транзакционные, ESP — маркетинг, поддержка — ответы, биллинг — счета. Чистая архитектура — дать каждому свой поддомен (notify., mail., help., billing.) со своим include в SPF и своим селектором DKIM. Тогда буря жалоб на маркетинговый поддомен не вредит транзакционному, а политику DMARC можно настраивать отдельно по поддоменам.

Частые ошибки

• Сразу ставят p=reject и блокируют собственную легитимную почту (узнавая об этом от злых клиентов).
• Забывают обновить SPF при смене провайдера — старый include остаётся, новый отправитель падает.
• Публикуют две SPF-записи, чем ломают обе.
• Превышают лимит в 10 DNS-запросов SPF — permerror.
• Публикуют DKIM с неверным селектором — проверка молча падает.
• Настраивают SPF и DKIM, но не добавляют DMARC — оставляя дверь для спуфинга и теряя отчёты, которые его бы выявили.

Проверьте перед запуском

После публикации отправьте тест на Gmail и откройте «Показать оригинал» — нужны три зелёных PASS: SPF, DKIM, DMARC. Повторите для Outlook, Mail.ru и Яндекса. Держите анализатор DMARC-отчётов под рукой: новые сервисы, начавшие слать от вашего домена, проявятся там первыми.

Частые вопросы

Нужен ли DMARC, если SPF и DKIM уже проходят? Да. Без DMARC нет политики и нет отчётов, поэтому спуферы всё ещё могут подделывать ваш домен, а вы об этом не узнаете.

Заблокирует ли p=reject мои рассылки? Только если они не проходят аутентификацию. Корректно настроенная почта проходит и не страдает — в этом и смысл поэтапного внедрения.

Мониторинг DMARC во времени

Аутентификация — не разовая задача «настроил и забыл». Ваш ландшафт отправки меняется: появляется новая CRM, новый хелпдеск, новый сервис рассылок счетов — и каждый из них нужно добавить в SPF и, в идеале, подписывать DKIM вашим доменом. Забудете — и почта этого инструмента начнёт падать по DMARC в момент перехода на enforcement, а реальное бизнес-письмо перестанет доходить. Сводные отчёты DMARC — ваша система раннего предупреждения: новый IP в столбце «не проходит» обычно означает не атаку, а легитимный сервис, который кто-то подключил, не сказав вам. Воспринимайте отчёты как постоянный инвентарь, а не как разовый аудит.

Длина и ротация DKIM-ключей

Стоит периодически ротировать DKIM-ключи и использовать разумную длину: 2048-битный RSA — современный минимум, тогда как 1024 бита всё чаще считаются слабыми. Держите SPF-запись компактной по мере добавления и удаления сервисов: за годы легко незаметно переползти лимит в десять запросов. Ежеквартальная ревизия — проверить, что все отправители всё ещё проходят, убрать include для инструментов, которыми вы больше не пользуетесь, и подтвердить, что DMARC на нужной политике — занимает час и предотвращает медленную тихую деградацию, которая застаёт врасплох многие компании.

BIMI как следующий шаг

Когда DMARC доведён до enforcement, открывается бонус — BIMI: показ вашего проверенного логотипа рядом с письмами в поддерживающих почтовиках. Сам по себе BIMI — небольшой визуальный плюс, но его обязательное условие, DMARC на quarantine или reject, и есть главная ценность: до enforcement кто угодно может подделывать ваш домен в фишинге, после — подделки отбрасываются на стороне получателя. Поэтому порядок такой: сначала SPF, DKIM и DMARC, затем доведение DMARC до enforcement, и только потом BIMI как вишенка на торте, нередко с сертификатом VMC для Gmail.

Порядок приоритетов, если всё сломалось

Когда доставляемость падает, хочется поменять десять вещей сразу — но так невозможно понять, что помогло. Чините строго по порядку влияния. Сначала аутентификация: если SPF, DKIM или DMARC не проходят или не выровнены, остальное не имеет значения, потому что почтовик даже не может подтвердить, что вы — это вы. Затем репутация: IP в блок-листе, всплеск жалоб или холодный домен на полном объёме утопят вас при любой идеальной аутентификации. Потом вовлечённость: рассылка тем, кто не открывает, учит почтовиков считать вас спамом. И только в самом конце — контент.

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

Практический мини-чек-лист перед важной отправкой: SPF одна запись и в пределах 10 запросов; DKIM подписывает верным селектором; DMARC хотя бы на quarantine; жёсткие отказы вычищены, неактивные подрезаны; тестовое письмо на Gmail, Outlook, Mail.ru и Яндекс показывает три PASS. Если все галочки стоят — вы сделали ту работу, которая решает попадание в инбокс.

Сколько времени занимает настройка

Сами записи публикуются за минуты, а распространение DNS обычно занимает от нескольких минут до пары часов, изредка до суток. Если планируете итерации, заранее снизьте TTL у записей, чтобы изменения подхватывались быстрее. Реальное время «проекта» уходит не на публикацию, а на этап мониторинга p=none: пара недель чтения отчётов, чтобы убедиться, что все легитимные отправители найдены и проходят, прежде чем включать enforcement. Не торопите этот этап — именно он защищает вас от блокировки собственной почты.

Пусть записи сгенерирует платформа

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