DMARC, DKIM и SPF: как защитить домен от подмены

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

1. Сначала найдите всех отправителей
Составьте закрытый реестр почтовых серверов, CRM, рассыльщиков, helpdesk, биллинга, устройств и SaaS. Для каждого потока запишите домен в From, SMTP MAIL FROM, IP-адреса, DKIM-домен d=, селектор, владельца и способ отключения.
DMARC проходит, когда успешно проверен и выровнен с From хотя бы один механизм: SPF или DKIM. Для штатной почты полезно настроить оба. SPF нередко перестаёт проходить после пересылки, поэтому устойчивая DKIM-подпись особенно важна.
Не включайте p=reject, пока отчёты показывают неизвестные легитимные источники. Данные об инфраструктуре и ответственных сотрудниках не публикуйте.
2. SPF: разрешите только нужные источники
Для одного DNS-имени публикуйте одну SPF-запись, например:
v=spf1 ip4:192.0.2.10 include:_spf.provider.example -all
• оставляйте только действующие IP и сервисы;
• после инвентаризации применяйте -all;
• не используйте +all, а ~all оставляйте лишь на время проверки;
• удаляйте include после отключения поставщика.
Во время одной проверки SPF допускается не более десяти терминов, вызывающих DNS-запросы; превышение приводит к permerror. Учитывайте всю цепочку include и redirect.
Для DMARC домен MAIL FROM должен быть выровнен с видимым From. SPF-проверка технического домена провайдера сама по себе ваш домен не защищает. Если домен вообще не отправляет почту, опубликуйте v=spf1 -all.
3. DKIM: подпись, выравнивание и ротация
Каждый сервис должен подписывать письма доменом d=, выровненным с From. Пример DNS-записи:
selector2026._domainkey.example.com TXT "v=DKIM1; k=rsa; p="
Используйте rsa-sha256 и RSA-ключи не короче 2048 бит. Выдавайте отдельный селектор каждому сервису и каждой ротации. Закрытый ключ хранится только в системе подписи, а в DNS размещается открытый.
Включайте From в h=, подписывайте значимые заголовки и всё тело без l=. Каноникализация relaxed/relaxed обычно практична, но её нужно проверить на реальной доставке через ваши шлюзы.
Для ротации сначала опубликуйте новый ключ, дождитесь обновления DNS, переключите подпись и проверьте полученное письмо. Старый ключ удаляйте лишь после завершения доставки ранее подписанных сообщений. При отключении сервиса уберите его DKIM-ключ и разрешения SPF.
4. DMARC: переходите к блокировке поэтапно
Начните со сбора агрегированных отчётов:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r
Исправьте отказы легитимной почты, затем включите p=quarantine и наблюдайте не меньше полного делового цикла. Когда все нужные потоки проходят проверку, переходите к политике:
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r
p=reject запрашивает отклонение подделок основного домена, а sp=reject распространяет политику на поддомены. Relaxed alignment подходит большинству организаций; strict выбирайте только при намеренной изоляции поддоменов.
Проверяйте заголовок Authentication-Results: ожидаются dmarc=pass и хотя бы один выровненный результат — spf=pass или dkim=pass. Ограничьте доступ к отчётам и срок их хранения.
DMARC мешает подделывать домен в From, но не спасает от похожих доменов, подмены отображаемого имени, захвата аккаунта и вредоносной почты от уже разрешённого сервиса.
Что почитать и попробовать
• RFC 8301: безопасная криптография DKIM
— Используйте при выборе алгоритма, длины ключа и правил ротации DKIM.
• RFC 9990: агрегированные отчёты DMARC
— Нужен команде, которая принимает rua-отчёты и контролирует почтовые потоки.
Я в соцсетях
TG · TikTok · Сетка · MAX