SPF, DKIM и DMARC: три буквенных супа, которые спасают ваши письма от спама

Вы настроили рассылку, написали отличный текст, нажали «Отправить» - а письма падают в спам. Или хуже: кто-то отправляет письма от имени вашего домена, и вы узнаёте об этом от разъярённых клиентов. Обе проблемы решаются тремя DNS-записями. Без них в 2026 году нельзя отправить ни одну массовую рассылку.

Зачем почте аутентификация

Email придумали в 70-х, когда интернетом пользовались несколько сотен учёных. Никто не думал о подделках. Протокол SMTP позволяет указать любой обратный адрес - технически вы можете отправить письмо от putin@kremlin.ru, и сервер его примет. Именно так работает фишинг: мошенник шлёт письмо от имени вашего банка, вы кликаете по ссылке, прощайтесь с деньгами.

SPF, DKIM и DMARC - это заплатки на эту дыру. Три механизма, которые отвечают на один вопрос: «Это письмо действительно отправил тот, кто указан в поле From?»

Каждый работает по-своему. Вместе они перекрывают почти все сценарии подделки.

SPF: список разрешённых серверов

Sender Policy Framework. Звучит сложно, по факту - проще некуда. Вы создаёте TXT-запись в DNS вашего домена, где перечисляете IP-адреса и серверы, которым разрешено отправлять почту от вашего имени. Всё.

Когда Gmail получает письмо от vashdomen.ru, он лезет в DNS, находит SPF-запись и сверяет IP отправителя со списком. Совпало - хорошо. Не совпало - подозрительно.

Типичная SPF-запись выглядит так:

Тут сказано: почту от нашего домена могут слать серверы Google Workspace и SendGrid. Всем остальным - отказ (-all). Если вы пользуетесь ещё и Mailchimp - добавляете ещё один include.

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

• Забыли добавить сервис. Подключили новый ESP, начали слать - а SPF про него не знает. Письма от этого сервиса валятся в спам.
• Слишком много DNS-запросов. SPF допускает максимум 10 DNS lookup-ов. Каждый include - это запрос. А вложенные include тоже считаются. Превысили лимит - SPF ломается.
• Мягкий ~all вместо жёсткого -all. Тильда говорит «ну, может быть, это не мы, а может мы». Дефис - «точно не мы, отклоняйте». Я считаю, что тильда имеет смысл только на время отладки.

SPF - первый рубеж. Но у него есть слабость: он проверяет IP-адрес сервера, а не содержимое письма. Если злоумышленник взломает ваш аккаунт в ESP, SPF его не остановит - ведь письмо идёт с разрешённого IP. Для этого нужен DKIM.

DKIM: цифровая подпись на каждом письме

DomainKeys Identified Mail. Тут идея другая. Каждое исходящее письмо подписывается приватным ключом. А в DNS домена лежит публичный ключ. Получатель берёт подпись из заголовка письма, берёт публичный ключ из DNS - и проверяет, что письмо не менялось в пути и действительно подписано владельцем домена.

По нашему опыту, DKIM - это то, что чаще всего настраивают неправильно. Не потому что сложно, а потому что большинство ESP генерируют ключи автоматически, и люди не понимают, что именно произошло.

Как это выглядит в DNS:

selector1 - это идентификатор ключа. Их может быть несколько: один для Google, другой для SendGrid. Каждый сервис даёт свой selector и публичный ключ. Вы добавляете CNAME или TXT-запись в DNS - готово.

Что DKIM даёт на практике

Защиту от модификации. Если спамер перехватит письмо и поменяет ссылку внутри - подпись сломается. Получатель увидит, что письмо было изменено.

А ещё DKIM накапливает репутацию. Gmail и другие провайдеры ассоциируют DKIM-подпись с поведением ваших писем: открытия, жалобы, bounce-ы. Хорошая репутация DKIM-подписи - прямой билет во «Входящие».

Мы проверяли: домены с корректным DKIM и длиной ключа 2048 бит показывают на 12-18% лучшую доставляемость в Gmail, чем домены с 1024-битным ключом или без DKIM вообще.

Кстати, про длину ключа. 1024 бита - устаревший стандарт. Google рекомендует 2048. Если ваш ESP до сих пор генерирует 1024-битные ключи - это повод задуматься о смене.

DMARC: правила для подделок

Domain-based Message Authentication, Reporting and Conformance. Название длинное, суть простая. DMARC - это инструкция для принимающего сервера: что делать с письмом, если оно не прошло проверку SPF или DKIM.

Три варианта политики:

• p=none - ничего не делать, только присылать отчёты. Режим наблюдения.
• p=quarantine - отправлять подозрительные письма в спам.
• p=reject - отклонять полностью. Письмо не дойдёт вообще.

Минимальная запись:

Поле rua - адрес, на который приходят агрегированные отчёты. XML-файлы, которые показывают: кто отправляет письма от вашего домена, сколько из них прошли SPF и DKIM, а сколько провалились. Золотая информация.

Как читать DMARC-отчёты

Отчёты приходят в формате XML, и читать их глазами - удовольствие сомнительное. Есть бесплатные сервисы: DMARC Analyzer, Postmark DMARC, EasyDMARC. Они парсят XML и показывают красивые графики. Кто отправлял, откуда, прошли ли проверки.

По нашему опыту, 90% людей настраивают p=none и забывают про отчёты навсегда. Это как поставить камеру видеонаблюдения и не подключить монитор. Формально камера есть, толку - ноль.

Как SPF, DKIM и DMARC работают вместе

Каждый по отдельности - полезен, но неполноценен. SPF проверяет сервер, но не содержимое. DKIM подписывает содержимое, но не говорит, что делать с подделками. DMARC собирает всё вместе и добавляет политику.

Вот что происходит, когда Gmail получает ваше письмо:

1. Проверяет SPF: IP отправителя есть в списке разрешённых?
2. Проверяет DKIM: подпись валидна, письмо не изменено?
3. Смотрит DMARC: хотя бы одна проверка пройдена, и домен в From совпадает с доменом SPF или DKIM?
4. Если DMARC пройден - письмо идёт дальше (репутация, контент, engagement). Если провален - применяется политика из DMARC-записи.

Ключевое слово - alignment. DMARC требует, чтобы домен в поле From совпадал с доменом из SPF или DKIM. Без этого совпадения проверка проваливается, даже если SPF и DKIM сами по себе валидны.

Пошаговая настройка: 30 минут на всё

Не нужно быть сисадмином. Нужен доступ к DNS-панели домена и немного терпения.

Шаг 1. SPF

Соберите список всех сервисов, которые отправляют почту от вашего домена. Google Workspace? SendGrid? Bitrix? Собственный сервер? Запишите их все.

Создайте TXT-запись для домена (не для поддомена - для корня). Начните с v=spf1, добавьте include: для каждого сервиса, закончите -all. Проверьте количество DNS-lookup - должно быть не больше 10.

Шаг 2. DKIM

Зайдите в настройки каждого сервиса, который шлёт почту. Найдите раздел «аутентификация» или «DKIM». Сервис выдаст вам CNAME или TXT-запись с публичным ключом. Добавьте её в DNS. Обычно запись выглядит как selector._domainkey.vashdomen.ru. Подождите 10-30 минут, пока DNS обновится, и нажмите «Проверить» в настройках сервиса.

Шаг 3. DMARC

Создайте TXT-запись для _dmarc.vashdomen.ru. Начните с p=none - не хватайтесь сразу за reject. Добавьте rua=mailto:ваш@адрес для получения отчётов. Две-четыре недели наблюдайте. Если всё чисто - переключайте на quarantine. Через месяц, если проблем нет, - на reject.

Торопиться с reject - опасно. Если вы забыли добавить какой-то сервис в SPF или не настроили DKIM для одного из каналов отправки, reject будет блокировать ваши собственные письма. p=none даёт время найти и закрыть все дыры.

Требования почтовых провайдеров в 2026

С февраля 2024 Gmail и Yahoo ввели жёсткие правила для отправителей более 5000 писем в день: SPF или DKIM обязательны, DMARC - обязателен (хотя бы p=none). Без этого письма просто не доходят.

Mail.ru и Яндекс пока мягче, но тренд очевиден. Mail.ru уже учитывает DMARC при фильтрации. И мы ожидаем, что к концу 2026 года аналогичные требования появятся и у российских провайдеров.

Но дело не только в требованиях. Даже если ваш провайдер ещё не блокирует письма без DMARC, отсутствие аутентификации снижает sender reputation. А это значит - «Промоакции» вместо «Входящих», ниже open rate, хуже ROI рассылки.

Типичные грабли и как их обойти

Несколько SPF-записей. Для одного домена может быть только одна SPF TXT-запись. Если вы добавили вторую - обе невалидны. Нужно объединить все include в одну строку.

DKIM без ротации ключей. Один и тот же ключ три года - плохая практика. Если ключ утечёт, злоумышленник сможет подписывать письма от вашего имени. Меняйте ключи раз в 6-12 месяцев. У Google Workspace ротация настраивается в два клика.

Пересылка ломает SPF. Когда подписчик пересылает ваше письмо коллеге, IP пересылающего сервера не совпадает с вашим SPF. Это нормально - именно поэтому DMARC требует пройти хотя бы одну из двух проверок, а не обе. DKIM при пересылке обычно выживает, потому что содержимое не меняется.

Поддомены без собственной политики. DMARC по умолчанию не распространяется на поддомены. Если у вас p=reject для vashdomen.ru, но нет записи для mail.vashdomen.ru - мошенник может слать от mail.vashdomen.ru без ограничений. Используйте sp=reject в DMARC-записи, чтобы закрыть поддомены.

Как проверить, что всё работает

Самый простой способ - отправить письмо на свой Gmail и открыть «Показать оригинал» (три точки → Show original). Там будет строка Authentication-Results. Ищите spf=pass, dkim=pass, dmarc=pass. Три pass - всё на месте.

А ещё есть онлайн-инструменты: MXToolbox, mail-tester.com, Google Postmaster Tools. Последний - обязателен для всех, кто шлёт больше 1000 писем в день. Бесплатно показывает репутацию домена, процент аутентификации, жалобы.

Аутентификация + валидация = доставляемость

SPF, DKIM и DMARC - необходимый фундамент. Но сами по себе они не гарантируют попадание во «Входящие». Вы можете идеально настроить аутентификацию и всё равно попасть в спам - если шлёте на невалидные адреса.

Hard bounce выше 2% - красный флаг для провайдера. Спам-ловушки в базе - ещё хуже. И никакой DMARC с p=reject не спасёт, если ваша база на четверть состоит из мёртвых адресов.

Формула простая: настройте SPF/DKIM/DMARC, потом проверьте базу. Первое занимает полчаса. Второе - ещё меньше.