Выбирать между DKIM, SPF и DMARC не нужно: эти три стандарта отвечают на разные вопросы и работают только вместе. SPF перечисляет серверы, которым разрешено отправлять почту от имени домена отправителя конверта; DKIM добавляет к письму подпись, созданную ключом, который опубликован в DNS домена; DMARC требует, чтобы хотя бы одна из этих проверок прошла для домена, совпадающего с видимым адресом From:, и публикует политику владельца домена и адреса для отчётов.
Коротко о главном
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Спецификация | RFC 7208 (2014) | RFC 6376 (2011), RFC 8301, RFC 8463 | RFC 9989, 9990, 9991 (май 2026 года) вместо RFC 7489 |
| На какой вопрос отвечает | Может ли этот IP-адрес отправлять почту от имени домена отправителя конверта? | Подписал ли этот домен именно это содержимое без изменений? | Совпадает ли аутентифицированный домен с доменом из From: и что делать, если нет? |
| Проверяемый идентификатор | MAIL FROM (Return-Path) и HELO | Домен d= в DKIM-Signature | Домен из заголовка From: |
| Где публикуется | TXT-запись самого домена | TXT-запись с именем selector._domainkey.domain | TXT-запись с именем _dmarc.domain |
| Выдерживает простую пересылку | Нет (IP-адреса пересылающего сервера нет в записи) | Да, если письмо не изменено | Да, благодаря DKIM |
| Выдерживает списки рассылки, которые изменяют письма | Нет | Нет (меняется тело или подписанные заголовки) | Только если список переписывает From: или принимающий сервер доверяет ARC |
| Жёсткие ограничения | 10 механизмов и модификаторов с DNS-запросами на одну проверку, 2 запроса с пустым ответом | RSA не менее 1024 бит (рекомендуется 2048); rsa-sha1 запрещён | Обход дерева DNS не более чем из 8 запросов |
| Что даёт сам по себе | Только результат; решает принимающий сервер | Только результат; решает принимающий сервер | Политика владельца домена: none, quarantine, reject |
| Отчёты | Нет | Нет | Агрегированные отчёты в XML (rua), отчёты о сбоях (ruf) |
Как работает каждый из них
SPF проверяется во время SMTP-сессии: принимающий сервер берёт домен отправителя конверта (или домен из HELO для уведомлений о недоставке), получает его TXT-запись и сверяет IP-адрес подключившегося сервера с перечисленными в ней механизмами ip4, ip6, a, mx и include. Результат — pass, fail (-all), softfail (~all), neutral, none или ошибка. Каждый include, a, mx, ptr, exists и redirect расходует один DNS-запрос, а если их больше 10, результатом становится permerror (RFC 7208, § 4.6.4), и SPF перестаёт работать для всей почты домена.
DKIM вычисляет хеш канонизированного тела письма (bh=) и перечисленных заголовков (h=) и подписывает их закрытым ключом домена. Принимающий сервер получает открытый ключ из TXT-записи, имя которой составлено из селектора s= и домена d= (например, google._domainkey.github.com), и проверяет подпись. RFC 8301 запрещает rsa-sha1 и требует ключей длиной не менее 1024 бит; RFC 8463 добавляет ed25519-sha256, но такую подпись обычно ставят вместе с подписью RSA, потому что поддерживают её ещё не все проверяющие стороны.
DMARC выполняется после них обоих: проверка проходит, если SPF прошёл для домена, выровненного с From:, или подпись DKIM верна для домена, выровненного с From:. По умолчанию выравнивание мягкое (relaxed: достаточно общего организационного домена, поэтому mail.example.com выровнен с example.com), а с aspf=s и adkim=s — строгое.
Скрипт ниже читает реальные записи (20 октября 2026 года, dig 9.10.6 и OpenSSL 3.6.5).
echo "== SPF: google.com and its include"
dig +short TXT google.com | grep "v=spf1"
dig +short TXT _spf.google.com
echo "== DMARC: google.com and github.com"
dig +short TXT _dmarc.google.com
dig +short TXT _dmarc.github.com
echo "== DKIM: key size behind two github.com selectors"
for sel in google pf2023; do
printf '%s: ' "$sel"
dig +short TXT "$sel._domainkey.github.com" | tr -d '" \n' | sed 's/.*p=//' \
| openssl base64 -d -A | openssl pkey -pubin -inform DER -noout -text | head -1
done
== SPF: google.com and its include
"v=spf1 include:_spf.google.com ~all"
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
== DMARC: google.com and github.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
== DKIM: key size behind two github.com selectors
google: Public-Key: (2048 bit)
pf2023: Public-Key: (1024 bit)
Стоит обратить внимание на три детали. Запись SPF у Google заканчивается на ~all (softfail), а политика DMARC — reject: когда политика DMARC применяется, решает результат DMARC, так что квалификатор SPF почти ничего не значит. GitHub по-прежнему публикует pct=100 — тег, который RFC 9989 удалил; принимающие серверы игнорируют неизвестные теги, а 100 и так было значением по умолчанию, поэтому вреда от него нет. Наконец, один из селекторов GitHub всё ещё использует 1024-битный ключ — минимум, который допускает RFC 8301. Анализатор аутентификации почты выполняет те же проверки для любого домена.
Исход решает выравнивание
В таблице — типичные сценарии для письма с From: news@example.com.
| Сценарий | SPF | DKIM | DMARC |
|---|---|---|---|
Собственный сервер, подписывает от имени example.com | pass, с выравниванием | pass, с выравниванием | pass |
Сервис рассылок со своим доменом возврата (Return-Path), подписывает от имени example.com | pass для домена сервиса, без выравнивания | pass, с выравниванием | pass (DKIM) |
| Сервис, который подписывает письма только своим доменом | pass, без выравнивания | pass, без выравнивания | fail |
| Пересылка без изменений по правилу почтового ящика | fail (IP-адрес пересылающего сервера) | pass, с выравниванием | pass (DKIM) |
| Список рассылки добавляет приписку в конце письма или метку в теме | fail или без выравнивания | fail (хеш тела) | fail, если From: не переписан и принимающий сервер не доверяет ARC |
Подделанный From: с чужого сервера | fail или none | none | fail, применяется политика |
Третья строка — самая частая ошибка внедрения: отправитель проходит SPF и DKIM, но не проходит DMARC, потому что ни один из аутентифицированных доменов не ваш. Настройте каждый сервис рассылок так, чтобы он подписывал письма ключом в вашем домене (обычно это CNAME-запись, указывающая на ключ сервиса), а если хотите, чтобы выровнен был и SPF, используйте собственный домен возврата.
Пересылка, списки рассылки и ARC
SPF аутентифицирует последний узел на пути письма, поэтому любая пересылка ломает SPF; схемы перезаписи отправителя (Sender Rewriting Scheme, SRS) восстанавливают SPF для собственного домена пересылающего сервера, но выравнивания не дают никогда. DKIM аутентифицирует содержимое, поэтому выдерживает передачу через промежуточные серверы, которые не изменяют письмо, и ломается, когда списки рассылки добавляют приписки или метки. ARC (RFC 8617, статус Experimental) позволяет посреднику заверить своей печатью результаты аутентификации, которые он видел, и принимающие серверы, которые доверяют этому посреднику, могут принять письмо, несмотря на непройденный DMARC; цепочку можно посмотреть в инструменте просмотра цепочки ARC. Остаётся одна слабость — повторное использование подписи DKIM (DKIM replay): письмо с действительной подписью можно заново разослать новым получателям. Рабочая группа IETF устраняет эту проблему в черновиках DKIM2.
Что требуют почтовые провайдеры
С 1 февраля 2024 года Gmail требует, чтобы каждый отправитель использовал SPF или DKIM, имел корректные прямую и обратную записи DNS, поддерживал TLS, а доля его писем, которые пользователи отметили как спам, была ниже 0,3 %. Тем, кто отправляет 5 000 и более писем в день на личные аккаунты Gmail, нужны также SPF и DKIM, запись DMARC (достаточно p=none), From:, выровненный с SPF или DKIM, и отписка в один клик (RFC 8058) для маркетинговых рассылок. Одновременно с Gmail такие же правила появились у Yahoo. Microsoft с 5 мая 2025 года применяет те же пороги к Outlook.com и отклоняет несоответствующие требованиям письма с кодом 550 5.7.515. Для логотипов BIMI дополнительно нужен DMARC с политикой quarantine или reject.
RFC 9989 (май 2026 года) перевёл DMARC в разряд стандартов (Standards Track) и изменил формат записи: теги pct, rf и ri удалены, для тестирования вместо pct=0 используется t=y, np задаёт политику для несуществующих поддоменов, psd отмечает домены публичных суффиксов, а для поиска организационного домена вместо Public Suffix List теперь используется обход дерева DNS.
Для чего нужен каждый
- SPF: разрешите отправку своим исходящим серверам и тем сервисам рассылок, которые используют ваш домен в адресе возврата; опубликуйте
v=spf1 -allна доменах и поддоменах, которые никогда не отправляют почту. - DKIM: подписывайте всю исходящую почту своим доменом, в том числе почту, которая уходит через сервисы рассылок; проводите ротацию селекторов не реже раза в год и замените 1024-битные ключи 2048-битными.
- DMARC: сначала соберите отчёты, затем переходите к применению политики; добавьте
np=reject(илиsp=reject), чтобы злоумышленники не могли использовать выдуманные поддомены. - Припаркованные домены:
v=spf1 -all,v=DMARC1; p=reject;и никаких селекторов DKIM. - Защита канала и защита содержимого — разные задачи: для TLS между серверами используйте MTA-STS, а для сквозной подписи — S/MIME или OpenPGP.
Заметки о миграции
- Проведите инвентаризацию отправителей по агрегированным отчётам DMARC при
p=noneв течение 2–4 недель; у каждого легитимного источника должен быть выровненный DKIM, выровненный SPF или и то и другое. - Сначала исправьте DKIM: включите у каждого сервиса рассылок подпись собственным доменом, опубликуйте 2048-битные ключи (генератор записей DKIM разбивает их на строки по 255 символов) и проверьте результат в отладчике DKIM.
- Сократите SPF: удалите неиспользуемые механизмы include, чтобы DNS-запросов было меньше 10; заменяйте include диапазонами IP-адресов, только если сможете автоматически поддерживать эти диапазоны в актуальном состоянии.
- Ужесточайте политику постепенно: сначала
p=quarantineсt=yдля наблюдения, затемp=quarantine, затемp=reject; не прекращайте получать отчётыrua. - Защитите поддомены с помощью
spилиnpи опубликуйте нулевые записи (null records) на каждом домене, который не должен отправлять почту.
Источники
- RFC 7208: SPF (§ 4.6.4: лимиты DNS-запросов)
- RFC 6376: DKIM, RFC 8301: обновление криптографии DKIM, RFC 8463: Ed25519 для DKIM
- RFC 9989: DMARC, RFC 9990: агрегированные отчёты, RFC 9991: отчёты о сбоях
- RFC 8617: ARC
- RFC 8058: отписка в один клик
- Google: рекомендации для отправителей электронной почты
- Microsoft: укрепление почтовой экосистемы и требования к массовым отправителям