SPF, DKIM и DMARC: как проверить защиту корпоративной почты
Проверяем доменную аутентификацию почты: инвентаризация отправителей, SPF, DKIM, DMARC, отчёты и безопасное ужесточение политики.
Подмена домена в письмах подрывает доверие к компании. SPF, DKIM и DMARC помогают принимающим серверам оценивать происхождение сообщений, но неправильная настройка способна отклонять легитимные письма. Начните не с запрета, а с реестра отправляющих сервисов.
01. Найдите все источники исходящей почты
Карта потоков нужна до любой правки DNS.
- Перечислите основной почтовый сервер, CRM, сервис рассылок, сайт, тикет-систему и облачные интеграции, отправляющие письма с домена.
- Для каждого канала запишите From, envelope sender, DKIM d=, IP и ответственного; проведите тестовую отправку с сохранением технических заголовков.
- Отдельно выявите пересылки и сервисы, которые подписывают письма собственным доменом, но показывают адрес вашей организации.
- Результат этапа: проверенный список отправителей и каналы, которые ещё требуют настройки или миграции.
02. Приведите SPF к фактическим отправителям
SPF проверяет разрешённость источника для домена envelope sender.
- Соберите действующий TXT SPF, уберите неизвестные старые include после подтверждения владельцем сервиса.
- Учтите ограничения на DNS-поиски SPF; не складывайте бесконечную цепочку include без технического аудита.
- Убедитесь, что на одном домене не опубликованы несколько конфликтующих SPF-политик.
- Результат: легитимные исходящие каналы проходят SPF, а неподтверждённые адреса не добавляются «на всякий случай».
03. Настройте DKIM-подпись каждого канала
Подписываемый домен и ключ должны управляться вами или доверенным поставщиком.
- Проверьте DKIM-подпись на реальных письмах от почтового сервера и внешних сервисов.
- Запишите селектор, домен d=, порядок ротации ключей и ответственную сторону, не публикуя приватные ключи.
- При смене провайдера продумайте период параллельного существования старых и новых подписей для писем в очереди.
- Результат: подписи валидны после обычной отправки, пересылки и изменения шаблона там, где это технически возможно.
04. Вводите DMARC через наблюдение
DMARC оценивает согласованность идентификаторов с видимым доменом From.
- Начните с режима наблюдения p=none и адреса для агрегированных отчётов, если обеспечены их приём и обработка.
- Сопоставьте отчёты с реестром отправителей и выясните причины провалов выравнивания SPF/DKIM.
- Повышайте политику поэтапно только после устранения легитимных ошибок; контролируйте долю доставленных писем.
- Результат: домен защищён от части подделок без массовой потери клиентской переписки.
05. Проверьте реальные сценарии доставки
DNS-валидатор без проверки писем недостаточен.
- Отправьте письма в несколько независимых принимающих систем: Gmail, корпоративные почтовики и службу поддержки.
- Проверьте Authentication-Results, попадание в папки, жалобы пользователей и задержки пересылки.
- Отдельно испытайте подтверждения с сайта, счета, заявки и уведомления о сбросе пароля.
- Результат: есть протокол «отправлено → прошло аутентификацию → получено», включая отклонения.
06. Назначьте контроль после изменений
Почтовый контур постоянно меняется.
- Закрепите владельцев SPF, DKIM и DMARC и правила обновления записей при подключении новых сервисов.
- Периодически проверяйте отчёты DMARC и аномальные домены/источники, не воспринимая каждый отказ как атаку.
- Документируйте изменение DNS, причину, время, предварительные проверки и способ возврата.
- Результат: новый сервис не отправляет почту от имени компании без проверки аутентификации.
Редакционный материал, октябрь 2026 года. Проверяйте применимость методов к вашей конфигурации и действующим требованиям.