SPF, DKIM и DMARC на примере обычного письма: как работает email-аутентификация
Когда в почтовом ящике появляется письмо от `support@bank.ru` или `security@google.com`, один только адрес отправителя ещё ничего не доказывает. Его можно подделать так же легко, как надпись на бумажном конверте. Отправитель может указать любой домен - в том числе принадлежащий банку, интернет-магазину или государственному сервису.
Такая подмена называется email spoofing. Её часто используют в фишинговых атаках: злоумышленник маскирует письмо под сообщение от знакомой организации и пытается заставить получателя перейти по вредоносной ссылке, открыть файл или передать конфиденциальные данные.
Почему SMTP сам по себе не защищает от подмены
Электронная почта работает на базе SMTP - протокола передачи сообщений, созданного ещё в 1980-х годах. В момент его появления интернет был гораздо меньше, а массового фишинга практически не существовало. Поэтому в протокол изначально не заложили надёжный способ проверить, действительно ли письмо отправлено владельцем указанного домена.
Сегодня почтовые серверы обрабатывают миллиарды сообщений. Среди них есть деловая переписка, чеки, уведомления, сервисные письма и рекламные рассылки, но вместе с ними поступают спам и мошеннические сообщения. Для автоматической проверки отправителей появились три основных механизма:
- SPF определяет, какие серверы вправе отправлять письма от имени домена;
- DKIM подтверждает подлинность содержимого письма;
- DMARC проверяет, соответствует ли результат этих механизмов адресу, который видит получатель, и определяет дальнейшие действия с подозрительными сообщениями.
Чтобы понять их назначение, разберём путь обычного письма.
Что происходит после нажатия кнопки "Отправить"
Представим, что компания "Ромашка" отправляет клиенту сообщение:
```text
From: promo@romashka.ru
To: ivan@gmail.com
```
Упрощённо письмо проходит несколько этапов:
1. почтовая система отправителя устанавливает соединение с сервером получателя;
2. сервер принимает технические данные о сообщении;
3. проверяет IP-адрес отправляющего сервера;
4. анализирует домен конверта и видимый адрес отправителя;
5. проверяет SPF и DKIM;
6. сопоставляет результаты с политикой DMARC;
7. принимает письмо, помещает его в спам или отклоняет.
Адрес в поле `From` - это лишь видимая часть сообщения. До проведения проверок он представляет собой заявление: "Это письмо отправлено с домена romashka.ru". Но такое заявление может сделать кто угодно.
SPF: каким серверам разрешено отправлять почту
SPF расшифровывается как Sender Policy Framework. Это механизм, с помощью которого владелец домена публикует список разрешённых отправляющих серверов.
Представим бумажное письмо от компании "Ромашка". На конверте указано имя организации, но доставляет его неизвестный человек. Получатель может спросить: действительно ли эта служба работает с "Ромашкой"? Если компания заранее сообщила, какие курьерские службы ей доверены, проверить это несложно.
В электронной почте такую роль выполняет SPF-запись. Она хранится в DNS домена и может содержать:
- разрешённые IP-адреса;
- почтовые серверы определённых провайдеров;
- дополнительные домены, которым разрешена отправка;
- правило обработки для всех остальных серверов.
При подключении к серверу получателя отправляющая система передаёт технический адрес отправителя - IP-адрес. Получатель находит SPF-запись домена и проверяет, входит ли этот IP в разрешённый список.
Если сервер указан в SPF, проверка обычно завершается успешно. Если нет, сообщение получает статус ошибки или подозрения.
Что такое Mail From
SPF проверяет не тот адрес, который пользователь видит в почтовом клиенте, а так называемый envelope sender - технический адрес конверта. Его часто называют `Mail From` или `Return-Path`.
Он нужен для служебных целей, прежде всего для обработки сообщений об ошибках доставки. Поэтому адрес `Mail From` может отличаться от адреса в поле `From`.
Например:
```text
From: promo@romashka.ru
Mail From: bounce@mailer.romashka.ru
```
SPF подтвердит право сервера отправлять почту от имени `mailer.romashka.ru`, но само по себе это ещё не доказывает связь с доменом `romashka.ru`, который видит получатель.
Именно здесь проявляется главное ограничение SPF: он проверяет технический домен, а не обязательно видимый адрес отправителя.
DKIM: цифровая подпись сообщения
DKIM расшифровывается как DomainKeys Identified Mail. Этот механизм добавляет к письму криптографическую подпись.
Перед отправкой специальный сервер формирует подпись на основе содержимого сообщения. Обычно в расчёт включаются заголовки и тело письма. Закрытый ключ хранится у отправляющей стороны, поэтому создать корректную подпись может только система, имеющая доступ к этому ключу.
В письмо добавляется заголовок `DKIM-Signature`. В нём указываются, среди прочего:
- домен, от имени которого сделана подпись;
- селектор - имя ключа;
- перечень подписанных заголовков;
- криптографическое значение подписи.
Открытый ключ публикуется в DNS. Получающий сервер видит селектор и домен, находит соответствующую DNS-запись, получает открытый ключ и проверяет подпись.
Успешная DKIM-проверка означает две вещи:
1. письмо действительно подписано системой, располагающей закрытым ключом;
2. подписанные части сообщения не изменились после формирования подписи.
Если злоумышленник поменяет ссылку, текст, тему или другой подписанный элемент, вычисленная подпись перестанет совпадать.
Почему одной DKIM-подписи недостаточно
Положительный результат DKIM ещё не гарантирует, что письмо отправила именно та организация, которую видит получатель. Подписать сообщение может сторонний сервис, а домен подписи не обязан совпадать с адресом в поле `From`.
Например:
```text
From: bank.ru
DKIM-подпись: marketing-platform.example
```
Письмо технически подписано, но подпись не подтверждает право отправлять сообщения от имени банка. Поэтому важно не только наличие DKIM, но и совпадение доменов.
DMARC: связь проверок с видимым отправителем
DMARC расшифровывается как Domain-based Message Authentication, Reporting and Conformance. Этот стандарт объединяет SPF и DKIM и отвечает на ключевой вопрос: подтверждают ли технические проверки именно тот домен, который указан в поле `From`?
DMARC использует принцип выравнивания доменов. Для успешного результата достаточно, чтобы с доменом из `From` совпал:
- домен, проверенный через SPF;
- или домен, указанный в DKIM-подписи.
Например, если письмо выглядит так:
```text
From: promo@romashka.ru
Mail From: bounce@romashka.ru
DKIM: d=romashka.ru
```
SPF и DKIM не только могут пройти проверку, но и согласуются с видимым доменом. Это значительно сильнее, чем отдельный положительный результат одной из проверок.
Допускаются и поддомены, если это предусмотрено настройками режима выравнивания. Однако домены от совершенно разных организаций связать в рамках DMARC нельзя.
Что происходит при провале DMARC
В DNS публикуется DMARC-запись с политикой для писем, которые не прошли проверку. Основные варианты такие:
- none - только наблюдать и собирать статистику, не меняя доставку;
- quarantine - считать письмо подозрительным и отправлять его в спам или карантин;
- reject - отклонять сообщение ещё на этапе приёма.
Обычно внедрение начинают с политики `none`. Это позволяет выяснить, какие сервисы отправляют письма от имени домена, не рискуя случайно заблокировать легитимные сообщения.
После инвентаризации отправителей и исправления настроек можно перейти к `quarantine`, а затем - к `reject`. Такая последовательность снижает вероятность проблем с доставкой рабочих писем, уведомлений и транзакционных сообщений.
Отчёты DMARC
DMARC может использоваться не только для блокировки подделок, но и для мониторинга. Владелец домена указывает адрес, на который почтовые системы будут отправлять агрегированные отчёты.
В них обычно содержится информация:
- с каких IP-адресов отправлялась почта;
- сколько сообщений было принято;
- сколько писем не прошло SPF или DKIM;
- какая политика применялась;
- какие домены участвовали в проверках.
Такие отчёты помогают обнаружить забытые сервисы, неправильно настроенные рассылки и попытки массовой подмены домена.
Почему письмо с положительными проверками всё равно может попасть в спам
SPF, DKIM и DMARC подтверждают техническую подлинность отправителя, но не гарантируют попадание во "Входящие". Антиспам-системы учитывают множество дополнительных факторов:
- репутацию IP-адреса;
- историю домена;
- жалобы получателей;
- долю недоставленных писем;
- содержание сообщения;
- подозрительные ссылки и вложения;
- частоту и объём отправки;
- качество базы адресатов;
- наличие отписки и корректных заголовков;
- поведение получателей.
Иными словами, аутентификация отвечает на вопрос "кто отправил письмо", но не всегда отвечает на вопрос "стоит ли доверять его содержанию".
Зачем выделяют поддомен для рассылок
Для массовых рассылок часто создают отдельный поддомен, например `mail.romashka.ru` или `news.romashka.ru`. Это помогает разделить разные потоки почты:
- корпоративную переписку;
- письма от сайта;
- маркетинговые кампании;
- сервисные уведомления;
- сообщения о сбоях доставки.
Если у рассылки возникнут проблемы с репутацией, они не обязательно повлияют на основную деловую переписку домена. Кроме того, для поддомена можно отдельно настроить SPF, DKIM и DMARC.
Иногда сервис рассылок просит делегировать поддомен. Это не означает передачу всего домена или регистрацию его на стороне провайдера. Делегируется только выделенная DNS-зона, которую можно использовать для технических записей и подписей рассылочного сервиса.
Как работает делегирование поддомена
Владелец основного домена создаёт DNS-запись, указывающую, что управление конкретным поддоменом передаётся определённым DNS-серверам. Основной домен при этом остаётся под контролем компании.
Почтовая платформа получает возможность публиковать необходимые записи только в пределах выделенной зоны:
- SPF для разрешённых серверов;
- DKIM-ключи;
- DMARC-политику;
- записи отслеживания переходов;
- технические записи для обработки возвратов.
Такой подход удобен, когда рассылочный сервис часто меняет инфраструктуру: владельцу домена не приходится вручную обновлять десятки записей после каждого изменения.
Практический порядок настройки
Перед запуском рассылок стоит составить список всех систем, которые отправляют почту от имени домена. В него могут входить сайт, CRM, система поддержки, бухгалтерский сервис, платформа маркетинга и облачные уведомления.
Затем необходимо:
1. определить домен в поле `From`;
2. выбрать технический домен `Mail From`;
3. настроить SPF без лишних разрешений;
4. включить DKIM и проверить публикацию открытого ключа;
5. убедиться в выравнивании доменов;
6. создать DMARC с политикой `none`;
7. проанализировать отчёты;
8. постепенно ужесточить политику.
Важно избегать слишком длинных и сложных SPF-записей: у DNS есть ограничения на количество обращений при проверке. Также нельзя создавать несколько независимых SPF-записей для одного домена - их нужно объединять в одну корректную запись.
Главное
SPF показывает, имеет ли конкретный сервер право отправлять почту от имени домена. DKIM подтверждает, что сообщение подписано доверенной системой и не изменялось. DMARC связывает эти проверки с адресом, который видит получатель, и задаёт правила для писем, не прошедших аутентификацию.
Ни один механизм не заменяет остальные:
- SPF без DMARC не доказывает соответствие видимого отправителя;
- DKIM без проверки домена может быть формально корректным, но бесполезным против подмены;
- DMARC без правильного SPF и DKIM приведёт к проблемам с легитимными письмами.
Вместе эти технологии образуют базовый уровень защиты домена от spoofing и фишинга. А грамотное разделение корпоративной почты и массовых рассылок помогает сохранить управляемость, репутацию и стабильную доставку сообщений.
