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

Что делает каждая запись

Протокол почты сам по себе не проверяет, кто указан в поле «От». Любой сервер может отправить письмо от director@ваша-компания.uz. Три DNS-записи решают эту проблему вместе:

Ключевое понятие DMARC — выравнивание (alignment). Мало того, чтобы SPF или DKIM прошли, — домен, который они проверили, должен совпадать с доменом в адресе «От». Письмо проходит DMARC, если хотя бы одна из проверок прошла и выровнена.

Пример DNS-записей

Допустим, корпоративная почта на Google Workspace, а рассылки идут через сервис email-маркетинга.

SPF — одна TXT-запись на корне домена:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.newsletter-service.example ~all"

• include: добавляет серверы провайдера;
• ~all — «остальные, скорее всего, не наши» (softfail), -all — строгий запрет. С DMARC обычно достаточно ~all.

DKIM — публичный ключ, который выдаёт ваш почтовый сервис. Имя записи состоит из селектора и _domainkey:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

У каждого сервиса свой селектор, поэтому записей DKIM может быть несколько, и это нормально.

DMARC — запись на поддомене _dmarc:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Как перевести DMARC с none на reject

Сразу ставить p=reject опасно: вы заблокируете собственные легитимные письма, о которых забыли. Двигайтесь по шагам:

1. p=none — ничего не блокируется, но вы начинаете получать отчёты. Соберите данные за несколько недель и найдите всех, кто шлёт почту от вашего имени.
2. Настройте SPF и DKIM для каждого найденного легитимного отправителя.
3. p=quarantine; pct=25 — часть непрошедших писем отправляется в спам. Постепенно увеличивайте pct до 100, следя за отчётами.
4. p=reject — письма, не прошедшие DMARC, отклоняются. Это цель.

Для поддоменов действует тег sp=. Для доменов, с которых почта не отправляется вообще, сразу публикуйте строгую политику:

parked.example.     TXT  "v=spf1 -all"
_dmarc.parked.example.  TXT  "v=DMARC1; p=reject"

Как читать агрегированные отчёты

Отчёты по адресу из rua приходят от почтовых провайдеров, обычно раз в сутки, в виде XML в архиве. Читать их вручную неудобно, поэтому используют сервисы-анализаторы или скрипты. В каждом отчёте важно:

• IP-адрес источника и количество писем с него;
• результат SPF и DKIM и выровнены ли они;
• применённое действие: доставлено, в спам, отклонено.

Как интерпретировать:

• Неизвестный IP, всё проваливается — скорее всего, подделка. Именно от этого защищает DMARC.
• Знакомый сервис (CRM, рассылка, хелпдеск) проваливает выравнивание — нужно донастроить его DKIM на ваш домен.
• Пересылка (forwarding) часто ломает SPF, но сохраняет DKIM. Поэтому DKIM критически важен.

Типичные ошибки при нескольких отправителях

• Две SPF-записи на одном домене. Это ошибка, проверка вернёт permerror. Все include объединяются в одну запись.
• Больше 10 DNS-запросов в SPF. Каждый include, a, mx считается, вложенные тоже. При превышении SPF ломается — уберите лишнее или вынесите рассылки на поддомен.
• SPF прошёл, но не выровнен. Сервис рассылок отправляет с собственным доменом в Return-Path. Решение — DKIM-подпись с вашим доменом или собственный домен возврата.
• Забытые отправители: сайт, отправляющий уведомления через mail() хостинга, 1С, биллинг, системы тикетов.
• +all в SPF — разрешает отправку кому угодно.
• Отчёты на чужой домен без подтверждения: если rua указывает на домен другой компании, ему нужна специальная запись-разрешение.
• Слишком длинный DKIM-ключ одной строкой. Строки в TXT ограничены 255 символами; длинный ключ разбивается на несколько строк в кавычках, большинство панелей DNS делают это сами.