Что такое SPF, DKIM и DMARC

Когда письма компании попадают в спам или клиенты получают поддельные письма «от вашего имени», почти всегда причина в трёх DNS-записях: SPF, DKIM и DMARC. Объясним, что они делают, без лишней теории.

Зачем это нужно

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

Все три записи публикуются в DNS вашего домена.

SPF — кто может отправлять письма

SPF (Sender Policy Framework) — список серверов, которым разрешено отправлять почту от имени домена.

Пример записи:

company.ru.  TXT  "v=spf1 include:_spf.mail-provider.example ip4:203.0.113.10 -all"

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

Получатель смотрит, с какого сервера пришло письмо, и сверяет его со списком.

Ограничения SPF: при пересылке письма проверка может не пройти, а у записи есть лимит в 10 DNS-запросов — слишком много include ломают проверку.

DKIM — подпись письма

DKIM (DomainKeys Identified Mail) — цифровая подпись. Сервер-отправитель подписывает письмо закрытым ключом, а открытый ключ публикуется в DNS:

mail._domainkey.company.ru.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Получатель проверяет подпись и убеждается, что письмо отправлено сервером, у которого есть ключ домена, и не изменялось по дороге. В отличие от SPF, подпись переживает пересылку.

Ключ и имя записи (селектор, в примере — mail) выдаёт почтовый сервис или генерирует ваш почтовый сервер.

DMARC — правила и отчёты

DMARC (Domain-based Message Authentication, Reporting and Conformance) связывает SPF и DKIM с адресом в поле «От кого» и говорит получателю, что делать с письмами, не прошедшими проверку:

_dmarc.company.ru.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@company.ru"

• p=none — только собирать отчёты, ничего не блокировать;
• p=quarantine — отправлять подозрительные письма в спам;
• p=reject — отклонять их;
• rua= — адрес для сводных отчётов: кто и сколько писем отправлял от имени домена.

Как внедрять без риска

1. Составить список всех, кто отправляет письма от имени домена: почтовый сервис, сайт, CRM, 1С, сервисы рассылок, сканеры и принтеры.
2. Настроить SPF, включив все эти источники.
3. Включить DKIM в почтовом сервисе и там, где это поддерживают остальные системы.
4. Опубликовать DMARC с p=none и несколько недель изучать отчёты.
5. Исправить найденные источники, которые не проходят проверку.
6. Ужесточить политику до quarantine, а затем, если всё в порядке, до reject.

Сразу ставить p=reject без анализа опасно: письма из забытой CRM или 1С перестанут доходить.

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

• открыть заголовки полученного письма (в почтовой программе — «Показать оригинал» или «Свойства») и найти строки с результатами spf=pass, dkim=pass, dmarc=pass;
• проверить DNS-записи командой nslookup -type=TXT company.ru или онлайн-сервисами проверки почтовых записей;
• анализировать отчёты DMARC.

Частые ошибки

• Две SPF-записи на домене. Запись должна быть одна, иначе проверка ломается.
• Забыли про сайт или 1С. Уведомления и счета уходят в спам.
• Больше 10 DNS-запросов в SPF. Слишком много include — проверка не проходит.
• DKIM включён только в DNS, но не активирован в почтовом сервисе.
• DMARC не настроен вовсе — никто не знает, кто рассылает письма от имени компании.
• Сразу p=reject без анализа отчётов.

Как организовать почту целиком — в статье «Как организовать корпоративную почту».