Настройка почтового сервера: почему SPF, DKIM и DMARC недостаточно

«Электронная почта остаётся критически важным каналом для бизнеса и самым слабым местом с точки зрения протокола. Речь не о крючках для проверяющих из ФСТЭК, а о том, что без SPF, DKIM и DMARC любой может начать рассылать фишинг от имени гендира или бухгалтерии вашей компании. Настройка этих механизмов, это только первый шаг. Настоящая работа начинается с мониторинга, который почти все пропускают, и с понимания, что ваша идеальная конфигурация может быть проигнорирована почтовыми провайдерами, живущими по своим внутренним правилам.»

Как работает подделка почты и почему это ваша проблема

Протокол SMTP был создан в эпоху, когда сеть состояла из взаимно доверяющих узлов. Он не содержит встроенной проверки подлинности отправителя. Это позволяет злоумышленнику указать в поле ‘From’ любой адрес, например, ceo@вашакомпания.ru, и отправить письмо с любого сервера. Эта техника называется спуфингом.

В контексте 152-ФЗ, инцидент с утечкой персональных данных, инициированный фишинг-письмом от имени вашего домена, трактуется как нарушение требований к защите информации. Методики ФСТЭК прямо указывают на необходимость предотвращения несанкционированного доступа, к которым относится и подделка почтовой переписки.

Ключевой момент: механизмы защиты SPF, DKIM и DMARC работают не на вашем сервере отправки, а на стороне сервера-получателя. Вы публикуете политики в DNS своего домена, а получатель, получив письмо, сверяется с ними. Если политик нет, решение о судьбе письма (в inbox, в спам или в корзину) принимает алгоритм получателя, который может быть как консервативным, так и излишне доверчивым.

SPF: объявляем, кто может отправлять от вашего имени

SPF (Sender Policy Framework), это механизм авторизации. Вы публикуете в DNS список IP-адресов и серверов, которым разрешено отправлять почту, используя ваш домен в обратном адресе.

Запись всегда размещается в TXT-записи домена. Простой пример для домена, который отправляет почту только через Яндекса:

v=spf1 include:_spf.yandex.ru ~all

Здесь include:_spf.yandex.ru разрешает все IP-адреса, перечисленные в SPF-записи Яндекса, а ~all указывает, что почта с любых других адресов должна быть помечена как подозрительная.

Основные механизмы, используемые в записи:

ip4:, ip6: — указание конкретного IP-адреса или подсети.
include: — импорт правил из другого домена (используется для почтовых хостингов, рассылочных сервисов).
a, mx — разрешение IP-адресов, на которые указывают A или MX-записи домена.

Как интерпретируются результаты проверки

Каждый механизм может завершаться квалификатором, который подсказывает получателю, как поступить.

Квалификатор	Результат	Рекомендуемое действие
+ (или отсутствует)	PASS	Пропустить, отправитель авторизован
—	FAIL	Жёстко отклонить письмо
~	SOFTFAIL	Поместить в карантин (спам)
?	NEUTRAL	Нет информации, решение за получателем

Главный недостаток SPF — он ломается при пересылке. Если ваше письмо перешлют, сервер пересылки станет новым отправителем с точки зрения SMTP, и его IP не будет в вашем SPF, что приведёт к провалу проверки.

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

DKIM (DomainKeys Identified Mail) решает проблему, которую не закрывает SPF: гарантирует, что содержимое письма не было изменено с момента отправки и что оно действительно связано с вашим доменом. Это асимметричная криптографическая подпись.

Процесс выглядит так:

На вашем исходящем почтовом сервере генерируется пара ключей: приватный и публичный.
Приватный ключ используется для создания цифровой подписи заголовков и тела каждого исходящего письма. Подпись добавляется в заголовок письма.
Публичный ключ публикуется в DNS вашего домена в специальной TXT-записи, привязанной к селектору (например, default._domainkey).
Почтовый сервер получателя, обнаружив подпись DKIM, запрашивает из DNS публичный ключ и проверяет её валидность.

Пример DNS-записи для публичного ключа:

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

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

DMARC: директива, которая всё сводит воедино

DMARC (Domain-based Message Authentication, Reporting & Conformance), это политический слой. Он не заменяет SPF и DKIM, а указывает получателю, как поступать с результатами их проверок, и предоставляет вам обратную связь.

DMARC-политика публикуется в DNS. Пример для начала мониторинга:

v=DMARC1; p=none; rua=mailto:reports@вашдомен.ru

Эта запись говорит: «Я начинаю разбираться (p=none), присылайте сводные отчёты на указанный адрес (rua)».

Ключевые параметры политики:

Параметр	Описание	Распространённые значения
v	Версия протокола	DMARC1
p	Политика для домена	none, quarantine, reject
sp	Политика для поддоменов	Аналогично ‘p’
rua	Адрес для агрегированных отчётов	mailto:адрес
ruf	Адрес для отчётов об отдельных сбоях	mailto:адрес
pct	Процент писем, к которым применяется ‘p’	1-100
aspf, adkim	Строгость выравнивания домена	r (relaxed) или s (strict)

Эволюция политики идёт от p=none (только мониторинг) через p=quarantine (отправка в спам) к p=reject (жёсткий отказ). Переход к reject, это итог анализа, а не стартовая точка.

Практическая настройка: от мониторинга к жёсткому запрету

Настройка защиты почты, это последовательный процесс с обратной связью.

Аудит источников отправки. Составьте полный список всех систем, которые рассылают почту от имени вашего корпоративного домена: корпоративный почтовый сервер, CRM, сервисы рассылок, системы мониторинга, ticketing-системы. Для каждой определите способ авторизации: либо отправка через ваш основной SMTP-сервер (релей), либо добавление её IP-адресов в SPF.
Публикация записей в режиме наблюдения.
- SPF: Включите в запись все легитимные источники с квалификатором ~all.
- DKIM: Настройте подписание на основном почтовом сервере и опубликуйте публичный ключ в DNS.
- DMARC: Установите политику p=none и укажите корректный адрес для отчётов в rua.
Анализ DMARC-отчётов. На указанный адрес начнут поступать агрегированные отчёты в XML. Их анализ отвечает на вопросы:
- Какие IP-адреса и сервисы отправляют письма от вашего имени и успешно проходят проверку.
- Какие легитимные письма не проходят проверку и по какой причине (например, из-за пересылки).
- Откуда и в каких объёмах идут попытки подделки.
Корректировка конфигурации. По итогам анализа:
- Добавьте в SPF пропущенные легитимные источники отправки.
- Настройте DKIM для сервисов, где его не было (например, для рассылочных платформ).
- Решите проблему ложных срабатываний (настройте правильную пересылку через авторизованные релеи).
Ужесточение политики. Когда в отчётах за несколько недель не останется значимого легитимного трафика, не проходящего проверку, можно менять политики.
- Смените квалификатор в SPF с ~all на -all.
- Постепенно измените DMARC-политику с none на quarantine, а затем на reject.

Типичные ошибки и неочевидные подводные камни

Лишние SPF-записи. Для домена разрешена только одна TXT-запись, начинающаяся с v=spf1. Наличие двух или более приведёт к перманентной ошибке (PERMERROR) при проверке.
Слишком длинная цепочка проверок. SPF имеет лимит в 10 DNS-запросов для одной проверки. Каждый механизм include, a, mx вызывает новый запрос. Сложная вложенность include может превысить лимит.
Игнорирование поддоменов в DMARC. Параметр sp задаёт политику для поддоменов. Если вы их не используете, установите sp=reject. Если используете — либо настройте DMARC для каждого, либо явно укажите sp=none.
Резкая ротация DKIM-ключей. Публичный ключ в DNS кэшируется провайдерами. Замена ключа на сервере без предварительной публикации нового ключа в DNS под другим селектором и периода совместной работы приведёт к массовому сбою доставки.
Отчёты без анализа. Публикация DMARC с rua и игнорирование входящих отчётов делает всю систему бессмысленной. Вы не узнаете, что ломаете легитимную рассылку при переходе на reject.

Связь с требованиями регуляторов

Наличие настроенных SPF, DKIM и DMARC всё чаще рассматривается как обязательная минимальная мера технической защиты. Она напрямую ложится на требования ФСТЭК:

Разграничение прав доступа (SPF как список авторизованных отправителей).
Обеспечение целостности информации (DKIM как криптографическое средство контроля).
Регистрация событий безопасности (отчёты DMARC как источник для мониторинга и анализа инцидентов).

При проверке или подготовке к аттестации документация по настройке этих механизмов, а главное — архив отчётов DMARC, служат конкретным доказательством работоспособности и мониторинга средств защиты. Успешная атака фишингом от вашего домена может быть квалифицирована как нарушение требований к защите персональных данных. Наличие политики p=reject существенно снижает этот риск и может быть аргументированно представлено как эффективная контрмера в рамках модели угроз.

Что делать после базовой тройки SPF/DKIM/DMARC

Базовый уровень защиты можно усилить дополнительными протоколами:

MTA-STS (Mail Transfer Agent Strict Transport Security). Принуждает использовать обязательное шифрование TLS при передаче почты между серверами, защищая от downgrade-атак и перехвата трафика.
BIMI (Brand Indicators for Message Identification). Позволяет отображать верифицированный логотип компании в интерфейсе почтового клиента у получателя. Для работы требует DMARC с политикой quarantine или reject и специальный сертификат VMC.
Автоматизация анализа DMARC. Ручной разбор XML-отчётов трудоёмок. Используйте специализированные инструменты или сервисы, которые агрегируют данные, предоставляя дашборды с графиками, источниками отправки и процентом успешных проверок.

Защита почтового домена, это не разовая настройка записей в панели хостинга, а непрерывный цикл: инвентаризация, конфигурация, сбор метрик, анализ, корректировка. Пропуск этапа мониторинга — основная причина, почему компании годами живут с видимостью защиты (p=none), оставаясь фактически уязвимыми для спуфинга.