SPF, DKIM и DMARC на примере обычного письма: как работает email-аутентификация
Когда в почтовом ящике появляется письмо с адресом `support@bank.ru` или `security@google.com`, один только видимый адрес ещё ничего не доказывает. Его можно подменить так же легко, как написать на бумажном конверте любое имя отправителя. Поэтому принимающий почтовый сервер должен проверить: действительно ли сообщение отправлено от имени указанного домена и не было ли изменено по дороге.
Для этого используются три взаимосвязанных механизма: SPF, DKIM и DMARC. Каждый отвечает за свою часть проверки, а вместе они помогают снизить риск спуфинга, фишинга и доставки поддельных писем от имени компании.
Что происходит с письмом после отправки
Рассмотрим обычное сообщение:
```text
From: promo@romashka.ru
To: ivan@gmail.com
```
После нажатия кнопки "Отправить" письмо передаётся через SMTP-серверы. Однако сервер получателя не обязан сразу помещать его во "Входящие". Сначала он анализирует:
- с какого IP-адреса установлено соединение;
- какой технический адрес указан во время SMTP-диалога;
- разрешён ли этому серверу исходящий трафик от имени домена;
- присутствует ли цифровая подпись;
- совпадает ли содержимое письма с подписанными данными;
- связаны ли результаты проверок с адресом в поле `From`.
Затем принимающая сторона выбирает дальнейшее действие: принять сообщение, отправить его в спам или отклонить ещё до доставки.
Важно различать видимый адрес отправителя и технический адрес, используемый при передаче. Поле `From` показывается пользователю, но само по себе не является доказательством подлинности. Именно эту проблему и решают SPF, DKIM и DMARC.
SPF: какие серверы имеют право отправлять почту
SPF расшифровывается как Sender Policy Framework. Это правило, опубликованное в DNS-зоне домена. В нём владелец домена перечисляет серверы и сервисы, которым разрешено отправлять письма от его имени.
Упрощённо SPF можно представить как список доверенных курьеров. Компания "Ромашка" заранее сообщает: "Наши письма могут доставлять серверы с такими-то IP-адресами и почтовые платформы, указанные в записи".
Когда письмо поступает на сервер получателя, тот сопоставляет IP отправителя с SPF-записью домена, указанного в техническом адресе отправки - `Mail From`, или envelope sender. Если адрес входит в разрешённый список, проверка SPF завершается успешно. Если нет, сервер получает результат `fail`, `softfail`, `neutral` или другой статус в зависимости от настроек.
Пример SPF-записи может выглядеть так:
```text
v=spf1 ip4:203.0.113.10 include:mailer.example -all
```
Она означает, что отправку разрешают конкретный IP-адрес и почтовая платформа, подключённая через `include`. Остальные источники запрещены благодаря параметру `-all`.
Где размещается SPF
SPF хранится в DNS домена как TXT-запись. Получающий сервер запрашивает её самостоятельно и сравнивает сведения с фактическим IP-адресом отправителя.
При настройке SPF важно учитывать все системы, которые отправляют письма от имени домена:
- корпоративную почту;
- CRM;
- сервисы рассылок;
- системы чеков и уведомлений;
- платформы поддержки клиентов;
- серверы транзакционных сообщений.
Для одного домена должна существовать одна итоговая SPF-запись. Добавление нескольких независимых записей часто приводит к ошибке `permerror`, и проверка перестаёт работать корректно. Кроме того, SPF ограничен десятью DNS-запросами, поэтому слишком сложная цепочка `include` может превысить допустимый лимит.
Почему SPF не подтверждает адрес в поле From
Главное ограничение SPF заключается в том, что он проверяет не обязательно тот адрес, который видит пользователь. Проверка выполняется для технического домена `Mail From`.
Например, в интерфейсе указано:
```text
From: promo@romashka.ru
```
А во время SMTP-сеанса используется:
```text
Mail From: bounce@mailer-service.example
```
SPF может успешно подтвердить право сервера отправлять письма от `mailer-service.example`, но это не означает, что он имеет отношение к `romashka.ru`. Поэтому одного SPF недостаточно: злоумышленник способен отправить письмо через разрешённый сервис, сохранив в видимом поле чужой адрес.
DKIM: цифровая подпись сообщения
DKIM - DomainKeys Identified Mail - добавляет к письму криптографическую подпись. Отправляющий сервер формирует подпись на основе выбранных заголовков и содержимого сообщения, после чего помещает её в специальный заголовок `DKIM-Signature`.
Получатель извлекает из подписи имя домена и селектор, а затем ищет соответствующий открытый ключ в DNS. Закрытый ключ хранится только у отправляющей стороны, открытый публикуется для проверки.
Если подпись корректна, это подтверждает два обстоятельства:
1. письмо действительно прошло через систему, располагающую закрытым ключом домена;
2. подписанные части сообщения не были изменены после отправки.
DKIM не шифрует письмо и не скрывает его содержимое. Его задача - подтвердить целостность и происхождение сообщения.
Что такое селектор
Селектор позволяет использовать несколько DKIM-ключей одновременно. Например, разные ключи могут применяться для корпоративной почты, маркетинговой платформы и транзакционных уведомлений.
В DNS ключ размещается по адресу вида:
```text
selector1._domainkey.romashka.ru
```
Это упрощает замену ключей: новый ключ можно опубликовать заранее, переключить отправку на него, а старый удалить после завершения переходного периода.
Почему одного DKIM тоже недостаточно
Злоумышленник может подписать письмо собственным доменом. В результате DKIM будет технически успешным, но подпись окажется связана, например, с `mailer-attacker.example`, тогда как пользователь увидит `romashka.ru` в поле `From`.
Кроме того, письмо может пройти DKIM-проверку, но содержать поддельный видимый адрес. Значит, принимающему серверу нужно не просто проверить наличие SPF или DKIM, а понять, соответствуют ли результаты домену, который указан пользователю.
DMARC связывает проверки с видимым отправителем
DMARC расшифровывается как Domain-based Message Authentication, Reporting and Conformance. Этот механизм связывает SPF и DKIM с доменом из поля `From`, а также сообщает принимающему серверу, что делать при провале проверок.
DMARC считается пройденным, если выполняется хотя бы одно условие:
- SPF успешен, а домен технического отправителя совпадает с доменом в `From`;
- DKIM успешен, а домен, указанный в подписи, совпадает с доменом в `From`.
Такое соответствие называют alignment - выравниванием доменов. Оно может быть строгим или ослабленным. При строгом режиме домены должны совпадать полностью, при ослабленном допускается использование поддомена.
Пример DMARC-записи:
```text
v=DMARC1; p=quarantine; rua=mailto:dmarc@romashka.ru
```
Политики DMARC
Параметр `p` определяет реакцию на сообщения, не прошедшие проверку.
`p=none`
Почтовый сервер не обязан блокировать письмо. Сообщение может попасть во "Входящие" или в спам, а владелец домена получает отчёты. Такой режим используют на начальном этапе внедрения, чтобы выявить легитимные источники отправки и не нарушить существующие рассылки.
`p=quarantine`
Письма с проваленной аутентификацией рекомендуется помещать в спам или карантин. Это промежуточная мера: сообщения не обязательно отклоняются, но их доверие снижается.
`p=reject`
Получателю рекомендуется отклонять неподтверждённые письма. Это наиболее строгий режим, который затрудняет подделку домена, но требует аккуратной подготовки. Если забыть добавить в SPF или DKIM легитимный сервис, его сообщения также могут перестать доставляться.
Зачем нужны отчёты DMARC
DMARC поддерживает агрегированные отчёты, позволяющие увидеть, кто отправляет письма от имени домена и проходят ли они проверки. В отчётах обычно отражаются:
- IP-адреса отправляющих серверов;
- количество сообщений;
- результаты SPF и DKIM;
- домены, обнаруженные в письмах;
- применённая политика.
Это помогает обнаружить неизвестные платформы, ошибки в настройках и попытки массовой подмены домена. Отчёты не всегда содержат полный текст писем - обычно они предназначены именно для статистического анализа.
Почему письмо с успешными SPF, DKIM и DMARC может попасть в спам
Аутентификация не гарантирует доставку во "Входящие". Она только доказывает, что сообщение связано с заявленным доменом и прошло технические проверки.
На решение почтового сервиса также влияют:
- репутация IP-адреса;
- история домена;
- жалобы пользователей на спам;
- процент недоставленных писем;
- качество базы получателей;
- частота отправок;
- содержание сообщения;
- наличие подозрительных ссылок и вложений;
- поведение получателей;
- корректность обратного DNS;
- соблюдение требований к отписке.
Даже идеально настроенный домен может столкнуться с фильтрацией, если его письма массово игнорируют или помечают как нежелательные.
Зачем выделяют отдельный поддомен для рассылок
Для маркетинговых и транзакционных сообщений часто используют отдельный поддомен, например:
```text
news.romashka.ru
mail.romashka.ru
notify.romashka.ru
```
Это позволяет отделить репутацию рассылок от основной корпоративной почты. Если рекламная кампания получит много жалоб, риски для адресов сотрудников и важных служебных писем будут ниже.
Поддомен также удобен для раздельных SPF-записей, DKIM-ключей и DMARC-политик. Например, для корпоративной почты можно применить строгие правила, а для нового маркетингового канала сначала использовать режим наблюдения.
Что означает делегирование поддомена
Делегирование поддомена не означает передачу всей зоны или основного домена стороннему сервису. Владелец может делегировать только часть DNS-пространства, например `mail.romashka.ru`.
После этого сервис получает возможность управлять DNS-записями внутри выделенного поддомена: размещать DKIM-ключи, настраивать SPF и технические адреса возврата. Основной домен `romashka.ru`, его корпоративная почта и остальные записи при этом остаются под контролем компании.
Иногда вместо полного делегирования используют отдельные CNAME-записи. Такой вариант позволяет сохранить управление DNS у владельца домена, но предоставить платформе нужные технические указатели.
Как внедрять email-аутентификацию без риска
Настройку лучше проводить поэтапно:
1. составить список всех сервисов, которые отправляют письма;
2. привести в порядок SPF и удалить дублирующие записи;
3. включить DKIM для каждого легитимного источника;
4. добавить DMARC с политикой `none`;
5. проанализировать отчёты и найти неизвестные источники;
6. устранить ошибки выравнивания доменов;
7. перейти к `quarantine`;
8. после тестирования установить `reject`.
Также важно регулярно проверять срок действия и актуальность DKIM-ключей, контролировать лимит DNS-запросов SPF и не использовать общий домен для несвязанных рассылок.
Итог
SPF отвечает на вопрос: "Имеет ли этот сервер право отправлять письма от имени домена?". DKIM проверяет: "Подписано ли сообщение доверенной системой и не изменилось ли оно?". DMARC уточняет: "Соответствуют ли эти подтверждения адресу, который видит получатель, и что делать при нарушении?".
Ни один механизм не является абсолютной защитой от спама, однако совместная настройка SPF, DKIM и DMARC значительно усложняет подмену отправителя, улучшает контроль над почтовыми потоками и помогает поддерживать репутацию домена.