SPF, DKIM и DMARC: проверка почтового домена

SPF, DKIM и DMARC решают связанные, но разные задачи. SPF перечисляет системы, которым разрешено отправлять почту для технического домена конверта. DKIM добавляет криптографическую подпись к выбранным заголовкам и содержимому. DMARC связывает результаты этих проверок с доменом, который человек видит в поле From, и публикует политику обработки сообщений, не прошедших аутентификацию.

Ни один из механизмов в одиночку не доказывает, что письмо полезно или желанно. Успешная аутентификация означает, что принимающая система смогла проверить заявленную связь сообщения с доменом. Решение о папке «Входящие», «Спам» или отказе остаётся за получателем и учитывает репутацию, жалобы, объём, содержание и локальные правила.

SPF проверяет путь отправки

SPF публикуется TXT-записью в DNS. Она описывает, какие IP-адреса или внешние сервисы могут отправлять сообщения с определённым доменом в SMTP-команде MAIL FROM. Этот адрес ещё называют envelope-from или обратным путём. Он может отличаться от видимого адреса From в почтовом клиенте — отсюда возникает много неверных интерпретаций результата SPF.

Упрощённый пример:

example.uz.  IN  TXT  "v=spf1 ip4:192.0.2.10 -all"

Такая запись разрешает указанный IPv4-адрес, а для остальных источников даёт результат SPF fail. Что делать с этим результатом, решает принимающая система. Это только пример синтаксиса, не шаблон для копирования: реальная запись должна учитывать все законные отправители домена — основной SMTP-сервер, CRM, сервис уведомлений, рассылки и другие системы.

Для одного имени домена должна существовать одна SPF-политика. Две отдельные TXT-записи, начинающиеся с v=spf1, не складываются и приводят к ошибке проверки. Если источников несколько, их объединяют в одну политику. При этом стандарт ограничивает число DNS-запросов, возникающих при оценке механизмов вроде include, a, mx, exists и redirect. Слишком длинная цепочка внешних включений может завершиться permerror, даже если каждый сервис по отдельности указан правильно.

SPF чувствителен к обычной пересылке. Пересылающий сервер может сохранить исходный envelope-from, но отправить сообщение уже со своего IP, которого нет в политике первоначального домена. Поэтому SPF не заменяет DKIM, а инфраструктуре пересылки иногда требуется Sender Rewriting Scheme. Главное — оценивать итоговый заголовок Authentication-Results, а не предполагать результат по одному адресу From.

DKIM подтверждает подпись сообщения

При DKIM исходящий сервер вычисляет хэш выбранных заголовков и тела письма, подписывает его закрытым ключом и добавляет заголовок DKIM-Signature. Принимающая сторона находит в нём домен d= и селектор s=, затем запрашивает публичный ключ по имени вида:

selector1._domainkey.example.uz

Закрытый ключ остаётся у отправляющей системы. В DNS публикуется только открытая часть. Если проверка сходится, получатель понимает, что подписанные фрагменты не были незаметно изменены после подписания и что отправитель обладал соответствующим закрытым ключом.

Селекторы позволяют менять ключи без одновременной остановки всей отправки. Новый ключ публикуют под новым селектором, переключают подпись на него, проверяют реальный поток и только после переходного периода удаляют старую запись. Это безопаснее, чем бессрочно использовать один ключ или заменять значение под тем же именем без учёта DNS-кэшей.

DKIM тоже не является печатью «не спам». Подпись может успешно проверяться у законной массовой рассылки, нежелательного письма или скомпрометированной учётной записи. Кроме того, системы пересылки и почтовые шлюзы иногда изменяют тему, тело или вложения. Если изменена подписанная часть, проверка может не пройти. Именно поэтому в DMARC достаточно согласованного успеха хотя бы одного из двух путей — SPF или DKIM.

DMARC связывает проверку с видимым From

Пользователь обычно доверяет домену в поле From. DMARC проверяет, согласован ли этот домен с доменом, успешно прошедшим SPF, либо с доменом действительной DKIM-подписи. Это называется alignment, или выравнивание доменов.

При relaxed-режиме допустимы организационно связанные поддомены. При strict-режиме домены должны совпадать точнее. DMARC считается пройденным, когда проходит и выравнивается хотя бы один механизм: SPF или DKIM. Значит, сообщение может пройти DMARC при неудаче SPF, если сохранилась согласованная DKIM-подпись, и наоборот.

Политика публикуется в TXT-записи _dmarc.example.uz:

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

p=none не запрашивает карантин или отказ из-за одной только DMARC-политики. Адрес агрегированных отчётов задаёт отдельный параметр rua. p=quarantine просит относиться к провалившим проверку сообщениям как к подозрительным, а p=reject — отклонять их. Формулировка «просит» важна: конечное решение принимает принимающая почтовая система в рамках своей локальной политики.

Адрес rua используется для агрегированных отчётов. Они помогают увидеть источники, которые отправляют от имени домена, результаты SPF/DKIM и причины несогласованности. Для отчётного адреса нужно подготовить ящик или специализированный обработчик: XML-файлы неудобны для ручного чтения, их объём бывает заметным, а сами отчёты содержат технические метаданные о потоке почты.

Почему нужны все три механизма

SPF без DMARC проверяет технический адрес конверта, который пользователь может не видеть. DKIM без DMARC подтверждает домен подписи, но он не обязан совпадать с видимым From. DMARC устанавливает эту связь, однако опирается на результаты SPF и DKIM и не создаёт их сам.

Практическую модель удобно представить так:

Эти записи относятся к исходящей аутентификации. MX решает другую задачу — указывает сервер для входящей доставки. Если вы как раз меняете маршрут приёма, начните со статьи MX-запись для почты: как направить письма на нужный сервер.

Безопасный порядок внедрения

Сначала составьте карту отправителей. В неё входят не только сотрудники, но и сайт, система восстановления паролей, счета, CRM, поддержка, мониторинг и сервис рассылок. Для каждого источника выясните, какой envelope-from он использует, каким доменом подписывает DKIM и можно ли настроить собственный домен вместо общего домена провайдера.

Затем полезно идти по этапам:

1. Соберите одну SPF-политику для всех подтверждённых источников и проверьте число DNS-запросов.
2. Включите DKIM у каждого сервиса, сохраняя закрытые ключи вне DNS и публичного репозитория.
3. Проверьте несколько реальных сообщений в разных внешних почтовых системах по Authentication-Results.
4. Опубликуйте DMARC с наблюдательной политикой и рабочим адресом агрегированных отчётов.
5. Найдите забытые легитимные источники, исправьте выравнивание и прекратите несанкционированную отправку.
6. Только после достаточного периода наблюдения обсуждайте переход к quarantine или reject.
7. После каждого изменения снова проверяйте реальные письма, а не только наличие TXT в DNS.

Переход сразу к строгой политике может заблокировать законные уведомления, если инвентаризация неполна. Обратная крайность — годами оставлять p=none и считать домен защищённым. Наблюдательная политика даёт данные; защита от подделки усиливается после исправления источников и осознанного включения более строгого режима.

Специалист Mailcore готовит и проверяет MX, SPF, DKIM и DMARC под фактическую схему отправки. Клиент сообщает сайт, CRM и другие источники, а Mailcore учитывает их до переключения и ужесточения политики. Пошаговый контекст подключения есть в статье Как Mailcore подключает домен: от заявки до первого письма.

Что смотреть в заголовках письма

Отправьте тестовое сообщение на внешний ящик и откройте оригинал или технические заголовки. Найдите Authentication-Results и отдельно проверьте:

• результат SPF и домен, к которому он относится;
• результат DKIM, домен d= и использованный селектор;
• результат DMARC и домен заголовка From;
• совпадает ли фактический исходящий сервер с ожидаемым;
• нет ли промежуточного шлюза, изменившего письмо.

Результат pass у всех трёх механизмов создаёт важную техническую основу для доставляемости. Если письмо отклоняется или дополнительно фильтруется получателем, для диагностики нужны SMTP‑код ответа, репутация источника, характер потока и содержание. Разбор последовательности дан в статье Почему письма попадают в спам и что проверять.

Частые ошибки конфигурации

Самая заметная ошибка SPF — несколько политик для одного имени. Следом идут устаревшие IP, забытые include и превышение лимита DNS-проверок. У DKIM часто путают селектор, обрезают длинное TXT-значение при переносе между панелями или публикуют ключ в одном домене, а подписывают другим. В DMARC типичны неработающий адрес отчётов, преждевременный reject и отсутствие выравнивания у сторонних сервисов.

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

Источники

• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
• Google: Email sender guidelines
• Microsoft Learn: Email authentication in Microsoft 365
• Cloudflare: Email security DNS records