SPF, DKIM и DMARC: базовая защита домена от подделки писем
SPF, DKIM и DMARC — три DNS-записи, которые вместе закрывают подделку отправителя (спуфинг) в вашем домене. По отдельности они дырявы: SPF проверяет, с какого сервера разрешено слать почту; DKIM подписывает письмо криптоподписью, которую нельзя подделать; DMARC связывает их с адресом From, говорит почтовым системам, что делать с непрошедшими письмами, и присылает отчёты. Без всех трёх ваш домен можно использовать для фишинга от вашего имени. **Если коротко:** настройка идёт строго по порядку — сначала SPF и DKIM, затем DMARC в режиме мониторинга `p=none` с отчётами, и только после того как отчёты подтвердят, что вся легитимная рассылка проходит проверку, политику ужесточают до `quarantine` и затем `reject`. Спешка с `reject` гарантированно теряет письма. Ниже — что делает каждый механизм, какие DNS-записи нужны, пошаговый план внедрения и типичные ошибки. Сравнить поставщиков защиты почты по подтверждённым сигналам можно в [рейтинге защиты почты и антифишинга](/rating/email-security-antiphishing).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Зачем нужны SPF, DKIM и DMARC
Протокол SMTP создавался без аутентификации отправителя: в поле From можно вписать любой адрес, и письмо «от вашего банка» технически отправит кто угодно. На этом построены фишинг, компрометация деловой переписки (BEC) и рассылки вредоносов от имени доверенных доменов. SPF, DKIM и DMARC — это надстройка над DNS, которая возвращает в почту проверяемое доверие.
Важно понимать, что три механизма решают разные части задачи и работают только вместе: SPF и DKIM по отдельности проверяют технические заголовки, но не защищают видимый адрес From — именно его подделывает фишер. Связывает проверки с видимым отправителем и задаёт реакцию на провал только DMARC. Поэтому цель — не «включить что-то одно», а выстроить все три и довести DMARC до политики отклонения.
Механизм → что проверяет → запись DNS
| Механизм | Что проверяет | Запись DNS | Где живёт |
|---|---|---|---|
| SPF | С какого IP/сервера разрешено отправлять почту домена | TXT в корне домена: `v=spf1 include:... -all` | `example.ru` |
| DKIM | Криптоподпись письма (не изменено, отправлено владельцем ключа) | TXT с публичным ключом по селектору: `selector._domainkey` | `sel._domainkey.example.ru` |
| DMARC | Совпадение домена From с SPF/DKIM (alignment) + политика и отчёты | TXT: `v=DMARC1; p=...; rua=mailto:...` | `_dmarc.example.ru` |
SPF: кто имеет право слать почту
SPF (Sender Policy Framework) — это TXT-запись в корне домена, перечисляющая серверы, которым разрешено отправлять почту от его имени. Принимающий сервер берёт домен из конверта (envelope-from) и сверяет IP отправителя со списком в записи.
Ключевые элементы записи:
- **`include:`** — подключает SPF чужого сервиса (почта на корпоративном хостинге, рассыльщик, CRM). Например `include:_spf.mail.ru`. - **`ip4:` / `ip6:`** — прямое указание собственных адресов отправки. - **`-all`** (hard fail) — всё, что не в списке, считать подделкой. Это целевое состояние. `~all` (soft fail) — мягче, помечает как подозрительное; годится на этапе внедрения. - **Лимит 10 DNS-запросов.** Сумма всех `include`/`a`/`mx` не должна порождать больше 10 обращений к DNS, иначе SPF ломается (`permerror`). Частая причина — много вложенных `include`.
Главное ограничение SPF: при пересылке письма (forwarding) меняется отправляющий сервер и SPF «рвётся». Поэтому SPF нельзя использовать в одиночку — его подстраховывает DKIM.
DKIM: криптоподпись письма
DKIM (DomainKeys Identified Mail) добавляет к письму цифровую подпись заголовком `DKIM-Signature`. Закрытый ключ хранится на отправляющем сервере, а публичный публикуется в DNS по адресу `селектор._domainkey.домен`. Принимающий сервер берёт селектор из подписи, достаёт публичный ключ из DNS и проверяет, что письмо не изменено в пути и подписано владельцем ключа.
Что важно на практике:
- **Селекторы** позволяют держать несколько ключей одновременно (свой у каждого сервиса рассылки, удобно для ротации). - **Длина ключа** — рекомендуется 2048 бит; 1024 считается устаревшим минимумом. - **Ротация ключей** — периодически меняйте ключи; для этого и нужны селекторы. - В отличие от SPF, DKIM-подпись **переживает пересылку**, пока тело и подписанные заголовки не меняются — поэтому DKIM закрывает слабое место SPF.
DMARC: политика и отчёты
DMARC (Domain-based Message Authentication, Reporting and Conformance) — связующее звено. Он проверяет так называемый alignment: совпадает ли домен из видимого поля From с доменом, который прошёл SPF и/или DKIM. Если совпадает хотя бы по одному — письмо аутентифицировано. Если нет — применяется заданная вами политика.
Параметры записи `_dmarc`:
- **`p=`** — политика для домена: `none` (только мониторинг), `quarantine` (в спам), `reject` (отклонять на этапе SMTP). Целевое состояние — `reject`. - **`sp=`** — отдельная политика для поддоменов. - **`pct=`** — процент писем, к которым применяется политика (для постепенного раскатывания, например `pct=25`). - **`rua=`** — адрес для агрегированных (сводных) XML-отчётов: статистика по источникам и результатам проверки. - **`ruf=`** — адрес для форензик-отчётов по отдельным письмам (поддерживается не всеми и несёт данные о приватности — используйте осторожно). - **`adkim=` / `aspf=`** — режим выравнивания: `s` (строгий, точное совпадение домена) или `r` (мягкий, допускает поддомены).
Агрегированные отчёты `rua` — главный инструмент: именно по ним видно, какие серверы шлют от вашего имени и проходят ли они проверки, прежде чем переключать политику на жёсткую.
Что закрывает каждый механизм (покрытие защиты)
Редакционная оценка вклада каждого механизма в защиту от спуфинга по открытым данным (0–100). Это не бенчмарк продуктов; реальное покрытие зависит от корректной настройки.
Поэтапное внедрение до p=reject
-
01
Инвентаризация отправителей
Соберите все сервисы, шлющие почту от домена: основной почтовый сервис, рассыльщики, CRM, мониторинг, биллинг. Пропущенный источник — будущая потеря писем.
-
02
Настройка SPF
Опубликуйте TXT-запись со всеми легитимными `include`/`ip4`. На старте допустим `~all`, целитесь в `-all`. Уложитесь в лимит 10 DNS-запросов.
-
03
Настройка DKIM
Включите подпись на каждом отправляющем сервисе, опубликуйте публичные ключи по селекторам, ключ 2048 бит. Проверьте, что письма реально подписываются.
-
04
DMARC в режиме мониторинга
Опубликуйте `_dmarc` с `p=none` и адресом `rua=`. Писем это пока не блокирует, но запускает сбор агрегированных отчётов.
-
05
Анализ отчётов
2–4 недели читайте `rua`: найдите все легитимные источники, которые не проходят SPF/DKIM или alignment, и дочините их. Это самый важный этап.
-
06
Ужесточение до quarantine
Когда отчёты показывают, что легитимная почта проходит, переключите на `p=quarantine`, при желании через `pct=` (например 25 → 50 → 100).
-
07
Переход на reject
Убедившись, что в карантин не падает «своё», установите `p=reject`. Теперь подделки отклоняются на входе, а домен защищён.
Типичные ошибки
- **Сразу `p=reject`.** Без фазы мониторинга вы гарантированно потеряете часть легитимной почты, о которой не знали. Всегда начинайте с `p=none`. - **Забытый источник отправки.** Рассыльщик или CRM, не внесённый в SPF и без DKIM, начнёт попадать в спам или отклоняться после ужесточения политики. - **Превышение 10 DNS-запросов в SPF.** Цепочка вложенных `include` ломает SPF целиком (`permerror`) — почта перестаёт проходить проверку. - **Две SPF-записи на домене.** Допускается ровно одна TXT-запись SPF; вторая делает результат невалидным. Объединяйте. - **DMARC без `rua`.** Политика без отчётов лишает вас единственного способа увидеть, что происходит, — внедрение становится «вслепую». - **Игнорирование alignment.** Письмо может пройти SPF/DKIM по техническому домену, но провалить DMARC, если он не совпадает с видимым From. Проверяйте именно alignment. - **Устаревший ключ DKIM 1024 бит** без ротации — слабое место, которое стоит закрыть переходом на 2048 бит.
Чек-лист настройки и проверки
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики защиты почты и антифишинга сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы клиентов, внешняя репутация, специализация и прозрачность данных. SPF, DKIM и DMARC можно настроить самостоятельно, но контроль доставляемости, разбор DMARC-отчётов и защита от BEC часто требуют отдельного решения. Для сверки статуса отечественных продуктов опирайтесь на проверяемые первоисточники — [реестр отечественного ПО](https://reestr.digital.gov.ru/) и [реестр сертифицированных СЗИ ФСТЭК](https://reestr.fstec.ru/), — а сравнение компаний смотрите в [рейтинге категории](/rating/email-security-antiphishing).
Следующий шаг
Настроили SPF, DKIM и DMARC — выберите решение для контроля доставляемости, разбора отчётов и защиты от фишинга и BEC: **[рейтинг защиты почты и антифишинга →](/rating/email-security-antiphishing)**. Полезно прочитать рядом: [рейтинг российских систем защиты почты 2026](/research/reyting-email-security-rossiya-2026), [чем заменить Proofpoint и Mimecast](/research/zamena-proofpoint-mimecast) и [защита почты от BEC, фишинга и спуфинга](/research/zashchita-pochty-bec-fishing).
Частые вопросы
Нужны ли все три записи или хватит одной?
Нужны все три. SPF и DKIM по отдельности не защищают видимый адрес From — именно его подделывает фишер. SPF рвётся при пересылке, DKIM не покрывает выбор отправляющего сервера. Связывает проверки с From и задаёт реакцию только DMARC, поэтому цель — все три плюс политика `reject`.
С чего начинать настройку?
С инвентаризации всех сервисов, которые шлют почту от вашего домена. Затем SPF и DKIM, потом DMARC в режиме `p=none` с отчётами. Только убедившись по отчётам, что легитимная почта проходит, ужесточают политику. Порядок критичен.
Чем отличаются политики none, quarantine и reject?
`none` — только мониторинг, письма не трогаются, но идут отчёты. `quarantine` — непрошедшие письма уходят в спам. `reject` — отклоняются на этапе приёма. Целевое состояние — `reject`, но переходить к нему нужно поэтапно, иначе теряется легитимная почта.
Почему нельзя сразу включить p=reject?
Почти всегда есть отправители, о которых вы не знаете (старая CRM, биллинг, сервис рассылок). При мгновенном `reject` их письма начнут отклоняться. Фаза `p=none` с разбором `rua`-отчётов выявляет такие источники до того, как политика начнёт что-то блокировать.
Что такое DMARC-отчёты и зачем их читать?
Агрегированные XML-отчёты (`rua`) показывают, какие серверы шлют почту от вашего имени и проходят ли они SPF/DKIM и alignment. Это единственный способ увидеть реальную картину рассылки и безопасно довести политику до `reject`, ничего не потеряв.
Где сравнить решения для защиты почты?
В рейтинге защиты почты и антифишинга — там поставщики ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
SPF, DKIM и DMARC — три DNS-записи, которые вместе закрывают подделку отправителя (спуфинг) в вашем домене. По отдельности они дырявы: SPF проверяет, с какого сервера разрешено слать почту; DKIM подписывает письмо криптоподписью, которую нельзя подделать; DMARC связывает их с адресом From, говорит почтовым системам, что делать с непрошедшими письмами, и присылает отчёты. Без всех трёх ваш домен можно использовать для фишинга от вашего имени. **Если коротко:** настройка идёт строго по порядку — сначала SPF и DKIM, затем DMARC в режиме мониторинга `p=none` с отчётами, и только после того как отчёты подтвердят, что вся легитимная рассылка проходит проверку, политику ужесточают до `quarantine` и затем `reject`. Спешка с `reject` гарантированно теряет письма. Ниже — что делает каждый механизм, какие DNS-записи нужны, пошаговый план внедрения и типичные ошибки. Сравнить поставщиков защиты почты по подтверждённым сигналам можно в [рейтинге защиты почты и антифишинга](/rating/email-security-antiphishing).