# Настройка SPF, DKIM и DMARC: пошагово

Настройка SPF, DKIM и DMARC — это согласованная проверка права отправлять письма от домена, подписи сообщения и правила действий для получателя при ошибке проверки. Работу нельзя сводить к добавлению трёх записей: нужно связать домены, адреса отправки и политику контроля, затем проверить результат на реальных письмах.

## Зачем домену сразу три механизма проверки?

SPF отвечает на вопрос, имеет ли отправляющая почтовая система право говорить от имени домена. DKIM добавляет к письму криптографическую подпись: получатель проверяет, что содержимое не было изменено после отправки. DMARC связывает эти проверки с доменом в поле отправителя и задаёт порядок обработки несоответствий. По отдельности они создают лишь видимость контроля; вместе дают получателю понятный сигнал, кому можно доверять.

| Механизм | Что подтверждает | Что проверяют при приёмке |
|---|---|---|
| SPF | Право инфраструктуры отправлять письма | У отправляющего контура есть разрешение домена |
| DKIM | Подлинность и целостность сообщения | Подпись присутствует и проходит проверку |
| DMARC | Связь проверки с адресом отправителя и политика домена | Выравнивание доменов и получение отчётов работают |

> Запись в DNS ещё не означает, что защита работает. Критерий — корректный результат проверки письма, отправленного от каждого согласованного адреса.

## Как выглядит работа до публикации записей?

Сначала составляют карту почтового контура. В неё входят домены, поддомены, адреса, с которых уходят деловые письма, и все системы, способные отправить сообщение от имени компании. Цель — не допустить двух крайностей: забыть легитимный источник и оборвать важную переписку либо разрешить слишком широкий круг отправителей.

1. Инвентаризировать домены и сценарии исходящей почты: продажи, поддержка, уведомления и личная переписка сотрудников.
2. Проверить действующие DNS-записи и найти дубли, устаревшие разрешения и конфликтующие правила.
3. Согласовать, какой домен видит получатель в поле «От кого» и какие подписи допустимы для каждого потока.
4. Опубликовать изменения в согласованном порядке и дождаться их применения в DNS.
5. Провести контрольную отправку и разобрать результаты аутентификации, а не только факт доставки.

Здесь часто возникает дорогая ошибка. Компания настраивает защиту только под новые письма отдела продаж, но забывает о системных уведомлениях. После ужесточения политики часть служебных сообщений начинает отклоняться или помечаться как подозрительная. Поэтому настройка — задача на стыке DNS, почты и бизнес-процессов, а не отдельная строка в панели управления.

Если исходящий контур готовят под холодные касания, его имеет смысл проверять вместе с [доставляемостью писем](/uslugi/dostavlyaemost/) и состоянием [доменов и почтовых ящиков](/uslugi/progrev-domenov/). Аутентификация не заменяет содержание письма или качество контакта, но без неё получателю сложнее отличить легитимное сообщение от подмены.

## Что именно смотреть при проверке DMARC?

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

### Сводка, которую стоит запросить у исполнителя

Удачный отчёт не ограничивается фразой «DMARC настроен». В нём видно, какой поток проверяли и почему он прошёл. Неудачный вариант — скриншот записи без перечня отправителей: он не отвечает на главный риск, а именно не пострадает ли обычная деловая почта после изменения политики.

Для первичной диагностики можно использовать [проверку SPF, DKIM и DMARC домена](/instrumenty/proverka-dns/), но результат инструмента — повод для разбора, а не окончательный вердикт. Он не знает, какие из ваших отправителей предусмотрены бизнес-процессом.

## Какие ошибки ломают защиту и доставку?

Первая ошибка — менять DNS без инвентаризации. Вторая — считать, что одна общая настройка покрывает все поддомены и адреса. Третья — вводить строгую реакцию на ошибки до проверки всех легитимных потоков. Последняя особенно опасна: письмо может быть технически корректным для отправителя, но не пройти выравнивание у получателя.

Типовой диалог выглядит так: руководитель видит, что письмо дошло, и спрашивает, зачем разбирать заголовки. Ответ прост: доставленное письмо может оказаться в нежелательной папке или сопровождаться предупреждением. Проверка заголовков показывает не впечатление от одного ящика, а факт прохождения SPF, DKIM и DMARC.

- Список всех доменов и почтовых потоков согласован с ответственным сотрудником.
- Нет устаревших или неизвестных разрешений на отправку.
- Подписи DKIM проверены на контрольных письмах.
- DMARC выровнен с доменом, который видит получатель.
- Есть понятный порядок разбора отчётов и изменений в почтовом контуре.

Проблемы аутентификации нередко маскируются под «плохой текст письма». Разделить эти причины помогает [аудит аутрича и деливери](/uslugi/audit-autricha/): сначала фиксируют технический статус отправки, затем оценивают адресата, оффер и реакцию на сообщение.

## Кому SPF, DKIM и DMARC не решат задачу?

Эти механизмы не создают спрос, не исправляют нерелевантную базу и не превращают предложение без повода в предметный разговор. Они также не гарантируют папку «Входящие»: решение получает почтовая система адресата, учитывая множество сигналов. Если письмо отправлено не тому человеку или выглядит как массовая реклама, корректная аутентификация не сделает его нужным.

Не стоит начинать с жёсткой политики, если компания не знает, какие системы и подразделения отправляют почту от её доменов. Сначала нужна разведка контура и контрольные проверки. Для холодного канала это часть более широкой задачи [email-аутрича под ключ](/uslugi/email-autrich/), где техническая готовность связана с базой, письмом и обработкой ответов.

Мы проводим инвентаризацию отправителей, настраиваем SPF, DKIM и DMARC без раскрытия лишних прав, проверяем выравнивание и передаём сводку для приёмки. После этого команда понимает, какие письма подтверждены доменом, а какие требуют отдельного разбора.

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

**Можно ли настроить SPF, DKIM и DMARC один раз и больше не возвращаться к ним?**

Нет. При появлении нового почтового потока, смене подрядчика или запуске нового домена настройки нужно пересматривать. Иначе легитимные письма могут не пройти проверку, а старые разрешения останутся без контроля.

**Как понять, что DKIM работает?**

Нужно отправить контрольное письмо и проверить его технические заголовки: подпись должна присутствовать и успешно подтверждаться получателем. Наличие записи в DNS без такой проверки недостаточно.

**Что делать, если проверка DMARC показывает ошибку?**

Сначала определяют источник письма и домены, участвующие в SPF или DKIM. Затем исправляют причину несоответствия и повторяют проверку; не стоит просто ослаблять политику, не разобрав поток.

**Защищают ли эти записи от попадания в спам?**

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

**Нужна ли настройка, если писем немного?**

Да, объём не отменяет риск подмены домена и технических ошибок. Тем более важно заранее понимать, какие письма действительно отправляются от имени компании.

---
Источник: https://ot9.ru/gaydy/spf-dkim-dmarc-nastroyka/ · Отряд 9 (КАП Групп) · обновлено 2026-08-10