SPF/DKIM/DMARC в 2026: практическая настройка, alignment и политика без потери доставляемости

Инструкции
04 фев, 2026
Время на чтение: ~16 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Что изменилось к 2026 году и почему «просто SPF» уже не работает

В 2026 году базовая тройка SPF/DKIM/DMARC всё ещё фундамент для доставляемости, но требования почтовых провайдеров стали заметно жёстче: сам факт «SPF pass» больше не гарантирует, что письмо окажется во входящих.

Сейчас важны три вещи: совпадение доменов (alignment), контроль всех источников отправки и предсказуемая политика DMARC, которая не ломает легитимные потоки. На практике проблемы всплывают не на вашем MTA, а на стыке сервисов: ESP/CRM, helpdesk, SaaS-уведомления, формы сайта, мониторинг, пересылки.

Цель этой инструкции — собрать конфигурацию так, чтобы письма проходили проверки, домены совпадали по alignment, а переход к строгой политике DMARC был управляемым и без всплеска bounce.

Карта понятий: SPF, DKIM, DMARC и alignment простыми словами

SPF: кто имеет право отправлять от домена

SPF публикуется как DNS TXT-запись и описывает, какие сервера и сервисы имеют право отправлять почту для домена в части MAIL FROM (Return-Path). Получатель сравнивает IP отправителя с тем, что разрешено SPF-политикой домена.

Ограничение SPF в том, что он завязан на IP и на домен Return-Path, который часто отличается от домена в видимом заголовке From. Поэтому одного SPF для защиты бренда и борьбы с подменой From недостаточно.

DKIM: криптоподпись письма

DKIM добавляет в письмо заголовок DKIM-Signature. Получатель проверяет подпись по публичному ключу из DNS (TXT-запись для конкретного селектора). DKIM чаще «переживает» пересылку, чем SPF: пересылка меняет IP, но не обязана менять подпись, если письмо не модифицировали.

Важно: DKIM — это не «разрешённые IP», а подтверждение, что письмо подписано ключом домена d=.

DMARC: правило действий и отчётность

DMARC связывает всё вместе: он проверяет, что письмо прошло SPF и/или DKIM, и что домены совпадают по alignment с доменом в заголовке From. Также DMARC задаёт политику (p=none/quarantine/reject) и каналы отчётности (rua/ruf).

Alignment: главный «тонкий момент»

Alignment — это сравнение домена в From с доменом, который прошёл SPF (домен Return-Path), и/или доменом подписи DKIM (значение d=). Именно alignment делает подмену From существенно сложнее.

У DMARC два режима alignment:

relaxed (по умолчанию): совпадает организационный домен (например, mail.example.com и example.com считаются совпадающими).
strict: должен совпасть домен целиком (например, example.com должно совпасть только с example.com).

Схема проверки SPF, DKIM и DMARC и принципа alignment между From и доменами аутентификации

Стратегия внедрения: как не получить всплеск bounce при включении DMARC

Самая частая ошибка — включить DMARC сразу с p=reject и получить отказы по части транзакционных писем или «тихую» потерю доставки в отдельные домены. Правильный подход — идти ступенями и опираться на отчёты.

Соберите инвентаризацию источников отправки: собственные MTA, сайт (формы), CRM/ESP, helpdesk, мониторинг, SaaS-уведомления.
Включите DKIM везде, где возможно (и проверьте, что d= совпадает с вашим доменом/поддоменом).
Соберите SPF так, чтобы он соответствовал реальности и не упирался в DNS-лимиты.
Включите DMARC в режиме p=none и начните собирать агрегированные отчёты rua.
Закройте «дыры»: неизвестные отправители, несовпадение alignment, сломанные пересылки и модификации письма.
Поднимите политику до p=quarantine с постепенным процентом (pct).
Доведите до p=reject, когда отчёты стабилизировались.

Если вы не уверены, что все системы подписывают DKIM и/или проходят SPF с правильным alignment, начинайте с p=none и собирайте статистику хотя бы 7–14 дней.

Отдельная практическая тема — разбор агрегированных отчётов и поиск «невидимых» источников отправки. Если нужно углубиться, посмотрите материал про разбор DMARC rua-отчётов и влияние на доставляемость.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

SPF в 2026: минимализм, лимит DNS и типовые ошибки

Базовый SPF-шаблон

SPF — это DNS TXT. Для домена обычно нужна одна запись. Пример базовой политики (разрешаем отправку только с A и MX):

example.com. 3600 IN TXT "v=spf1 a mx -all"

Если часть отправки идёт через сторонний сервис, добавляют include::

example.com. 3600 IN TXT "v=spf1 a mx include:_spf.mailvendor.example -all"

Почему SPF ломается: include-цепочки и лимит 10 DNS-проверок

При проверке SPF делаются DNS-запросы (например, для a, mx, include, redirect, exists). По стандарту допускается максимум 10 «DNS-запросных» механизмов. Если лимит превышен, получатель может вернуть permerror, что ухудшает доставляемость и увеличивает bounce при строгих проверках.

Типовые симптомы превышения лимита:

в заголовках/логах встречается spf=permerror;
часть провайдеров принимает письма, часть отклоняет;
после добавления очередного include: резко растёт bounce.

Практика: как держать SPF «коротким»

Удаляйте неиспользуемые источники (старые ESP, тестовые сервисы, временные интеграции).
Не плодите несколько SPF TXT на одном имени: это частая ошибка после миграции DNS и почти всегда даёт неверную интерпретацию.
Делайте DKIM основным «паспортом» там, где SPF неизбежно ломается (пересылки, сложные цепочки посредников).
Если используете поддомены для отправки, следите, чтобы DMARC-политика и alignment были понятны (relaxed/strict).

DKIM: селекторы, ротация ключей и что ломает подпись

Как выглядит DKIM в DNS

Публичный ключ публикуется в TXT вида selector._domainkey.example.com. Пример (сокращённо):

selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

В письме будет d=example.com и s=selector1. Получатель соберёт DNS-имя и проверит подпись.

Селекторы: держите два

Для безболезненной ротации ключей держите минимум два селектора: активный и следующий.

Публикуете новый ключ как selector2.
Переключаете отправку на selector2.
Держите старый selector1 ещё 7–14 дней (письма могут «доезжать» очередями, а у получателей бывают задержки кэширования DNS).
Удаляете старый ключ.

Про ротацию, TTL и типовые ловушки (кэш DNS, параллельная подпись, несколько селекторов у разных систем) подробно разобрано в статье ротация DKIM: селекторы и TTL без простоя.

Что чаще всего портит DKIM-подпись

Промежуточные системы, которые меняют тело письма (добавляют баннеры/приписки, переупаковывают MIME).
Некорректная перекодировка заголовков (особенно при «самописных» интеграциях).
Отправка через сервис, который подписывает d= своим доменом, а не вашим: SPF/DKIM могут быть pass, но DMARC не пройдёт по alignment.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

DMARC: политика, rua/ruf и настройки, которые реально влияют на доставляемость

Минимальный DMARC для старта наблюдения

Стартовая DMARC TXT-запись для сбора агрегированных отчётов (rua) обычно выглядит так:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; fo=1"

Ключевые теги:

p — политика для домена: none, quarantine, reject.
rua — куда слать агрегированные отчёты (XML). Это основной рабочий инструмент для инвентаризации источников.
ruf — форензик-отчёты. В 2026 многие провайдеры не отправляют ruf или сильно ограничивают содержимое из-за приватности, поэтому не делайте на него ставку как на единственный источник правды.
fo=1 — запросить отчёт при любом отказе SPF или DKIM (фактическое поведение зависит от получателя).

Как читать отчёты и находить «невидимые» источники отправки

В rua-отчётах вас интересуют три блока: откуда отправляют (IP/ASN), результаты SPF/DKIM и итог DMARC (прошёл ли alignment и почему нет).

Частый кейс: письма идут через сторонний сервис, DKIM у него с d=vendor.example, SPF проходит по его Return-Path, а From у вас example.com. Итог: SPF pass и DKIM pass по отдельности, но DMARC fail из-за отсутствия alignment.

Настройка alignment: adkim/aspf

DMARC позволяет управлять строгостью совпадения доменов:

adkim=r или adkim=s — relaxed/strict для DKIM.
aspf=r или aspf=s — relaxed/strict для SPF.

Для большинства доменов разумно начинать с relaxed и переходить к strict только когда вы точно контролируете поддомены и все схемы отправки.

Переход к quarantine/reject без шока

Когда вы почистили источники и добились стабильного прохождения на реальных потоках, включайте принудительные политики поэтапно:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r"

Дальше поднимайте pct до 50/100 и затем переключайтесь на p=reject. Это снижает риск массового bounce из-за забытых систем и редких сценариев.

Политика для поддоменов: sp=

Если у вас активно используются поддомены (например, news.example.com, billing.example.com), заранее определитесь, как их защищать. Тег sp задаёт политику для поддоменов:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-rua@example.com"

Это удобно, если основной домен уже готов к reject, а поддомены ещё в переходном периоде.

Фрагмент DNS-зоны с TXT-записями SPF, DKIM и DMARC для домена

Диагностика: что проверить, если доставляемость упала

Быстрый чек-лист по DNS TXT

На домене ровно одна SPF TXT-запись (начинается с v=spf1).
DKIM TXT существует для нужного селектора; запись целая, без «сломанных» кавычек и лишних пробелов.
DMARC TXT опубликован на _dmarc и корректно парсится.
TTL разумный (например, 300–3600) на время внедрения; после стабилизации можно увеличить.

Разница bounce из-за DMARC и bounce из-за SPF/DKIM

В отказах и логах полезно различать:

SPF fail/permerror: обычно проблема в IP, цепочке include или нескольких SPF.
DKIM fail: неверный селектор/ключ, письмо модифицировали, ошибки MIME/перекодировки.
DMARC fail: SPF и DKIM могут быть pass, но не пройти alignment с From; либо оба fail.

Если bounce вырос после ужесточения p в DMARC, почти всегда виноват непройденный alignment у одного из легитимных источников, а не «капризный получатель».

Типовые сценарии и как их «вылечить»

1) SaaS отправляет с вашим From, но подпись чужая

Включите у SaaS custom DKIM (подпись вашим доменом) или меняйте From на домен, который контролирует SaaS, если процесс это допускает. Для deliverability обычно лучше custom DKIM: бренд сохраняется, DMARC проходит по DKIM alignment.

2) Пересылка (forward) ломает SPF

Это нормальная ситуация: при пересылке письмо приходит с другого IP, а Return-Path остаётся прежним. Здесь ставка на DKIM: пусть DMARC проходит по DKIM, даже если SPF стал fail. Важно, чтобы исходящий поток стабильно подписывался DKIM, а downstream-системы не модифицировали письмо.

Если у вас Postfix/Rspamd и много пересылок, может помочь ARC: он не заменяет DMARC, но иногда спасает доставку при легитимном форвардинге. По теме есть отдельный разбор: ARC для Postfix/Rspamd при пересылках.

3) Много сервисов — SPF упёрся в лимит

Если у вас десяток отправителей, SPF почти гарантированно придёт к permerror. Практическая тактика: оставить SPF минимальным для ваших реальных MTA, а идентичность переносить в DKIM/DMARC, заставив внешние сервисы подписывать вашим доменом. Альтернатива — выстроить SPF alignment через корректный Return-Path домен, который соответствует From (с учётом relaxed/strict).

Мини-FAQ: частые вопросы админов

Нужны ли rua и ruf одновременно?

Для практической работы почти всегда достаточно rua. ruf может быть полезен, но многие получатели его не отправляют или урезают. Если включаете ruf, заведите отдельный ящик и учитывайте требования к обработке персональных данных.

Можно ли жить без DKIM, если SPF настроен идеально?

Иногда — да, но для устойчивой доставляемости в 2026 DKIM почти обязателен. Он закрывает пересылки и даёт вам «якорь» для DMARC alignment.

Что важнее: strict alignment или p=reject?

Обычно важнее стабильно проходить DMARC на реальных потоках. Сначала добейтесь уверенного pass на relaxed alignment и строгой политики (p=reject), и только затем включайте strict, если есть конкретная причина.

Итоги: рабочий план на 2 недели

Соберите список всех отправителей и доменов From/Return-Path.
Включите DKIM у всех систем, где это возможно, и держите два селектора.
Приведите SPF к одной записи и проверьте лимит DNS-запросов.
Опубликуйте DMARC с p=none и rua, собирайте отчёты 7–14 дней.
Исправьте alignment у внешних сервисов (custom DKIM и/или правильный Return-Path).
Поднимайте p до quarantine с pct, затем до reject.

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

Поделиться статьей