В мае 2026 года IETF выпустила RFC 9989, новую основную спецификацию DMARC, и вместе с ней RFC 9990 про сводные отчёты и RFC 9991 про отчёты о сбоях. Старый RFC 7489 от 2015 года теперь устарел. Записи по-прежнему начинаются с v=DMARC1, так что рабочие настройки не ломаются, но часть тегов и советов поменялась. Хороший повод пересобрать заметку о том, как настроить SPF, DKIM и DMARC для домена.
Зачем это всё: без SPF, DKIM и DMARC письма с вашего домена легко подделать, спамеры шлют «от имени» support@ваш-домен, а почтовые сервисы относятся к такой почте с недоверием. Три механизма в DNS закрывают разные слои проверки. Ниже что это, как собрать записи и в каком порядке их вводить, чтобы не уронить доставку.
SPF, DKIM и DMARC: кто за что отвечает
- SPF (Sender Policy Framework): TXT-запись у домена со списком серверов, которым можно слать почту от его имени. Получатель сверяет IP отправителя с этим списком.
- DKIM (DomainKeys Identified Mail): цифровая подпись тела письма и выбранных заголовков. Открытый ключ лежит в DNS, закрытый на почтовом сервере (Postfix, Exim, сервис рассылок). Если письмо по пути не меняли, подпись сходится.
- DMARC: политика поверх SPF и DKIM. Говорит получателю, что делать с письмами, которые не прошли проверку, и куда слать отчёты. Главное требование здесь выравнивание (alignment): домен в From должен совпадать с доменом, который прошёл SPF или DKIM.
По отдельности механизмы слабые: SPF ломается на пересылке, а DKIM без DMARC не говорит, как поступать с поддельными письмами. Вместе они дают и техническую проверку, и понятную политику для получателя.
Что требуют Gmail и Яндекс
Это давно не пожелания. По руководству Gmail для отправителей, с 1 февраля 2024 года всем, кто шлёт письма на адреса Gmail, нужен SPF или DKIM, а тем, кто отправляет больше 5000 писем в день, SPF, DKIM и DMARC сразу, причём домен в From должен совпадать с доменом SPF или DKIM. Ключ DKIM должен быть не короче 1024 бит, Google советует 2048. Письма без проверки подлинности Gmail может отклонить с ошибкой 5.7.26.
У Яндекса в требованиях к честным рассылкам DKIM на всех письмах и SPF для домена обязательны, DMARC рекомендован. Если почта уходит медленно или в спам, полезно ещё проверить PTR и DNS сервера, это разобрано в заметке про медленную отправку через Sendmail.
Порядок внедрения
Разумная схема такая: сначала собрать всех, кто шлёт почту от домена (свой SMTP, Яндекс 360, Google Workspace, сервис рассылок, CRM, тикет-система), потом SPF, затем DKIM на каждом легальном источнике и в конце DMARC с мягкой политикой, которую постепенно ужесточают.
Шаг 1. SPF: одна запись и не больше 10 DNS-запросов
На одно имя домена (или поддомена, с которого реально шлёте) публикуется одна TXT-запись SPF. Если записей две, проверка заканчивается ошибкой permerror, и SPF фактически не работает.
v=spf1 include:_spf.yandex.net include:_spf.google.com ip4:203.0.113.10 -all
include:подключает серверы чужих сервисов, точное значение берите из документации провайдера;ip4:иip6:это ваши собственные серверы;~all(softfail) на время отладки,-all(fail), когда список полный;- не больше 10 механизмов, которые требуют DNS-запроса, считая вложенные include.
Лимит в 10 запросов прописан в RFC 7208: include, a, mx, ptr, exists и redirect считаются, а ip4, ip6 и all нет. Если лимит превышен, результат снова permerror. Ещё RFC советует ограничивать «пустые» запросы, на которые DNS ничего не вернул, двумя.
Шаг 2. DKIM: ключ 2048 бит и selector
На почтовом сервере или в сервисе рассылок создаётся пара ключей. По RFC 8301, RSA-ключ должен быть не короче 1024 бит, а лучше от 2048, подпись rsa-sha1 больше не принимается, только rsa-sha256. Есть и подпись Ed25519 из RFC 8463, но её проверяют не все, поэтому её ставят второй подписью рядом с RSA. Открытый ключ публикуется TXT-записью:
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
selector это любое имя: mail, s1, yandex. В заголовке DKIM-Signature письма стоит тот же selector. Ключ 2048 бит не влезает в одну строку TXT длиной 255 символов, поэтому его разбивают на несколько строк в кавычках, большинство панелей DNS делают это сами. Для смены ключа заводят новый selector, ждут, пока запись разойдётся по DNS, переключают подпись и только потом убирают старый ключ.
Шаг 3. DMARC: от p=none к quarantine
Запись TXT на имени _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
p=none: только наблюдение, с этого начинают;p=quarantine: не прошедшие проверку письма уходят в спам;p=reject: такие письма отклоняются;rua: адрес для сводных XML-отчётов, крупные почтовые сервисы шлют их раз в сутки;rufиfo: отчёты по отдельным письмам, теперь они описаны в RFC 9991, и шлют их немногие;adkimиaspf:rмягкое выравнивание (совпадает основной домен),sстрогое (совпадает имя целиком).
Что поменял RFC 9989. Тег pct (доля писем, к которым применять политику) убран, его частично заменяет t=y: тестовый режим, когда получатель применяет политику на уровень мягче. Убраны rf и ri. Добавлены np (политика для несуществующих поддоменов) и psd (для доменов публичных суффиксов). Вместо списка публичных суффиксов организационный домен теперь ищется обходом дерева DNS. Старые записи с pct=100 работать не перестанут, но этот тег можно убрать.
Про p=reject новый стандарт стал осторожнее. Для доменов с обычными ящиками сотрудников, которые пишут в рассылки и списки, ставить reject не рекомендуется: пересылка через списки рассылок ломает проверку, и легальные письма режутся. Если reject всё же нужен, RFC советует сначала месяц прожить на p=none, потом столько же на p=quarantine и сравнить отчёты. Для доменов, с которых шлют только транзакционные письма и рассылки, reject по-прежнему нормальный финал.
Поддомены наследуют политику основного домена, если у них нет своей записи. Для них есть тег sp, а для несуществующих поддоменов теперь np.
Проверка
dig +short TXT example.com dig +short TXT selector._domainkey.example.com dig +short TXT _dmarc.example.com
Онлайн записи удобно смотреть в MXToolbox и Check MX из набора Google Admin Toolbox, итоговое письмо целиком проверяет mail-tester.com. Надёжнее всего отправить тестовое письмо в Gmail и Яндекс и посмотреть в исходнике письма заголовок Authentication-Results: там должно быть spf=pass, dkim=pass и dmarc=pass.
Частые ошибки
- две и больше записи SPF на одном имени;
- больше 10 DNS-запросов в SPF из-за цепочки include;
- забыли include сервиса рассылок, и маркетинговые письма валят DMARC;
- ключ DKIM обрезан в DNS, потому что не разбили на строки;
- сразу
p=rejectбез отчётов, и режутся легальные письма; - From на одном домене, а SPF и DKIM только на другом, без выравнивания.
Сопровождение
Раз в квартал сверяйте список include с реальными отправителями. При смене сервиса рассылок сначала добавьте его в SPF и включите DKIM, потом переключайте отправку. Отчёты DMARC удобно складывать в отдельный ящик и разбирать парсером или готовым сервисом. В дополнение к тройке стоит включить TLS для почты (MTA-STS и TLS-RPT) и двухфакторную авторизацию на ящиках.
Краткий чеклист
- Собрать все IP и сервисы, которые шлют от домена.
- Опубликовать одну правильную запись SPF, уложиться в 10 запросов, закончить на
~allили-all. - Включить DKIM с ключом 2048 бит на каждом источнике и проверить selector в DNS.
- Поставить DMARC
p=noneсruaи читать отчёты. - Через месяц перейти на
quarantine, а reject только там, где он не мешает людям.
В итоге SPF, DKIM и DMARC сейчас обязательный минимум для любого домена, с которого уходит почта: без них Gmail и Яндекс режут письма или отправляют их в спам. Новый стандарт DMARC (RFC 9989) старые записи не ломает, но убрал pct, добавил np и t и советует не спешить с p=reject для обычных почтовых доменов.
