SPF, DKIM, DMARC: зачем почте три проверки
SMTP проектировали для сети из нескольких сотен университетских и военных компьютеров, где участники знали друг друга. Сервер получателя по умолчанию не сверяет обратный адрес ни с какими списками. Поэтому письмо «от службы безопасности банка» уходит с любого компьютера. Такой трюк называют email spoofing, то есть подделкой отправителя.
Защиту удобно представить на примере посылки из интернет-магазина.
SPF — перечень курьерских служб, с которыми магазин заключил договор.
DKIM похож на фирменную пломбу: сорванную или чужую видно сразу.
DMARC — инструкция для пункта выдачи: как поступить с коробкой, если курьер не из перечня, а пломба не та, и кому сообщить о подозрительной доставке.
Поодиночке каждая мера оставляет обходной путь. В связке три технологии образуют email-аутентификацию, которая отсекает большинство подделок.
Для крупных отправителей эта тройка превратилась в обязательный минимум. Gmail и Yahoo ввели это правило в феврале 2024 года для доменов, которые шлют на их адреса порядка пяти тысяч сообщений в сутки. Outlook.com присоединился 5 мая 2025 года, а в ноябре того же года Google сменил предупреждения на отказы в приеме. От небольших отправителей почта Google ждет хотя бы одну из двух технологий подтверждения.
Sender Policy Framework: кому домен доверяет отправку
SPF расшифровывается как Sender Policy Framework.
Это TXT-строка на корневом домене, где перечислены серверы с правом отправлять письма от его имени. Для чайного магазина с почтой на Яндекс 360 она выглядит так:
kafa-lavka.ru TXT "v=spf1 include:_spf.yandex.net ~all"Принимающая сторона узнает IP-адрес компьютера, который доставил сообщение, запрашивает DNS и ищет этот адрес в перечне. Есть нюанс, о котором часто забывают: SPF сверяет адрес из технического «конверта» (Return-Path), а не тот, что получатель видит в строке «От кого». Окончание записи задает строгость. Механизм ~all помечает посторонние серверы как подозрительные, а -all запрещает их без оговорок.
Ограничений у SPF два, и оба коварные. На домене живет ровно одна SPF-запись: если строк две, проверка завершается ошибкой permerror. Кроме того, на разбор записи отводится не больше десяти DNS-запросов, и каждый новый include съедает часть этого лимита.
Здесь же разведу понятия, которые смешивают особенно охотно. MX-запись указывает сервер для входящей почты и подлинность отправителя не подтверждает. Механизм mx внутри SPF лишь разрешает отправку с тех же компьютеров, которые принимают корреспонденцию.
DKIM-подпись: криптографическая пломба на сообщении
Стандарт DomainKeys Identified Mail вырос в середине 2000-х из двух проектов: DomainKeys компании Yahoo и Identified Internet Mail от Cisco. Актуальная редакция закреплена в RFC 6376 от 2011 года. Механизм опирается на пару ключей. Секретный хранится на сервере отправителя и подписывает каждое письмо. Открытый (англ. public key) лежит в DNS, и по нему любой получатель сверяет подлинность.
Подпись путешествует в служебном заголовке DKIM-Signature (signature по-английски значит «подпись»). Тег d= называет домен-поручитель, s= хранит селектор, то есть имя ключа, а в bh= и b= лежат хеши тела и заголовков. По селектору сервер находит в DNS нужную строку:
lavkame._domainkey.kafa-lavka.ru TXT "v=DKIM1; k=rsa; p=BRIBInSRIgkwh..."Почтовый провайдер, платформа рассылок и CRM выдают каждый свою DKIM-запись, поэтому селекторов у домена со временем набирается несколько. Если в пути поменяется хотя бы одна подписанная буква, например, мошенник подменит ссылку, хеш разойдется с подписью, и сервер зафиксирует dkim=fail. В отличие от SPF, подпись переживает пересылку на другой ящик, поэтому для DMARC она служит более надежной опорой. Ключ я генерирую длиной 2048 бит. Вариант на 1024 бита стандарт пока допускает, однако запас прочности у него скромнее.
Запись DMARC: что делать с письмами без подтверждения
Полное название DMARC — Domain-based Message Authentication, Reporting and Conformance. Строка публикуется на поддомене _dmarc и выполняет две задачи: сверяет домены и сообщает принимающей стороне политику (policy) владельца.
_dmarc.kafa-lavka.ru TXT "v=DMARC1; p=none; rua=mailto:pupupu@kafa-lavka.ru"Первую задачу называют выравниванием (англ. alignment). Она закрывает дыру, которую SPF и DKIM оставляют поодиночке. Злоумышленник проходит обе проверки на собственном домене, а в поле «От кого» подставляет адрес вашей компании. DMARC учитывает результаты обеих технологий, но засчитывает успех, только если хотя бы одна из них подтвердила тот адрес, который видит человек. Мягкий режим принимает и поддомен, а строгий требует полного совпадения имен.
Тег p задает реакцию: none означает только наблюдение, quarantine отправляет письмо в спам, reject отклоняет его еще на входе. В rua указан ящик для ежедневных сводок в формате XML. По ним видно все серверы, которые пишут от имени домена, и долю писем, проваливших проверку.
В мае 2026 года IETF выпустил обновление под рабочим названием DMARCbis: документы RFC 9989, 9990 и 9991 пришли на смену RFC 7489. Привычные записи продолжают работать, префикс v=DMARC1 остался прежним. Зато тег pct, который применял политику к части потока, из стандарта исчез, а его место занял тестовый флаг t=y. Появился и тег np для несуществующих поддоменов, излюбленной лазейки мошенников.
DKIM: как настроить вместе с SPF и DMARC по шагам
Работу я начинаю с инвентаризации и выписываю всех, кто шлет письма от имени домена: корпоративную почту, сервис рассылок, CRM, форму на сайте, службу поддержки, бухгалтерскую программу со счетами. Пропущенный сервис обнаружится позже и неприятным образом: после включения строгой политики его сообщения перестанут доходить.
Дальше идет SPF. В единственную TXT-строку я вношу include каждого провайдера из списка и завершаю ее механизмом ~all. Точное значение каждый сервис приводит в справке.
Третий шаг — настройка DKIM. В кабинете почтового сервиса или платформы рассылок я генерирую ключ. В англоязычных панелях этот раздел обычно подписан «DKIM keys». Выданную строку я копирую в DNS у регистратора, а после публикации включаю подпись в самом сервисе. Обновления DNS расходятся по сети за время от нескольких минут до суток, поэтому проверка сразу после сохранения нередко показывает старую картину.
Завершает цепочку настройка DMARC. Я стартую с p=none и адреса для отчетов и две–четыре недели читаю сводки через сервисы-анализаторы. Потом перевожу домен на quarantine и лишь затем на reject. Промописьма я отправляю с отдельного поддомена вроде novosty.kafa-lavka.ru, чтобы их репутация не касалась рабочей переписки.
Как проверить DKIM и остальные записи
Нагляднее всего отправить письмо на собственный ящик Gmail и выбрать в меню пункт «Показать оригинал».
В шапке страницы появятся вердикты по трем технологиям, и слово PASS означает успех. Яндекс Почта показывает то же самое в свойствах письма, в заголовке Authentication-Results:
Authentication-Results: mx.google.com; dkim=pass header.d=kafa-lavka.ru; spf=pass smtp.mailfrom=kafa-lavka.ru; dmarc=passВместе с вердиктом DKIM-проверка сообщает домен подписи, он записан после header.d. Если там значится адрес платформы рассылок, а не ваш, через DKIM письмо DMARC не пройдет.
Сами строки в DNS я смотрю командой nslookup -type=txt _dmarc.kafa-lavka.ru. Онлайн-валидаторы с названиями вроде «DMARC check» раскладывают запись по тегам и подсвечивают опечатки. Для регулярной проверки DMARC и наблюдения за репутацией подходят кабинеты почтовых служб: Google Postmaster Tools, Postmaster Mail.ru и «Почтовый офис» Яндекса. С конца 2025 года обновленный инструмент Google показывает, соблюдает ли домен требования к массовым отправителям.
Почему письма с DKIM и SPF все равно оседают в спаме
Самый частый промах — вторая SPF-строка.
Новый сервис просит «добавить запись», и вместо правки старой строки появляется еще одна. Итог — permerror и провал проверки для всей почты домена.
Следом идет длинный ключ. Значение на 2048 бит превышает 255 символов, отведенных одной строке TXT, и некоторые регистраторы обрезают его или ломают кавычки. Формально запись существует, а на деле серверы ее не распознают.
Третья ловушка — reject без предварительной разведки. Без отчетов легко упустить, что счета из бухгалтерской программы уходят без подписи, и клиенты перестают их получать. Пересылка и списки рассылок нарушают SPF, а порой и DKIM. Поэтому DMARCbis призывает осторожнее включать строгую политику на доменах, сотрудники которых активно фигурируют в таких списках.
Наконец, безупречные записи бессильны против купленной базы адресов. Google советует держать долю жалоб ниже 0,1% и не приближаться к 0,3%: за этой чертой блокировка наступает при любой подписи.
FAQ
Зачем DKIM и DMARC домену, с которого уходит пара писем в день?
Требование хотя бы одной технологии подтверждения Google распространяет на всех отправителей, а неподписанные письма чаще попадают в спам. DMARC к тому же бережет само имя. Мошенникам безразличен объем ваших рассылок, им интересен узнаваемый домен для фишинга, а политика reject лишает их этой возможности.
Как защитить домен, который вообще не отправляет почту?
Неактивные домены злоумышленники ценят особенно: подмену на них никто не заметит. Для такого адреса я публикую SPF со значением v=spf1 -all, которое запрещает отправку любым серверам, и DMARC с p=reject. Если домен еще и не принимает почту, MX-записи ему ни к чему.
Как часто менять ключи DKIM?
Ротацию проводят раз в 6–12 месяцев, а при подозрении на утечку сразу. Я публикую новый ключ под свежим селектором и переключаю на него подпись. Старую строку удаляю через несколько дней, когда письма со старой подписью наверняка доставлены.
Что такое BIMI и при чем здесь DMARC?
BIMI выводит логотип компании рядом с письмом во входящих Gmail, Yahoo и Apple Mail. Значок появляется только при политике quarantine или reject, а Gmail вдобавок требует сертификат на товарный знак. Получается своеобразная награда за строгую защиту домена.
Почтовый сервер похож на строгого консьержа: незнакомца без пропуска он не пустит, как бы уверенно тот ни звонил в домофон. Три строки в DNS выдают вашему домену такой пропуск, а мягкий старт с p=none и регулярное чтение отчетов уберегут ваши собственные письма от сюрпризов. Выделите вечер на список отправителей, сохраните записи у регистратора и через месяц загляните в сводки: они покажут, сколько писем теперь доходит до адресатов. Почту крупных брендов защищают те же три сочетания букв: DKIM, DMARC, SPF. Что это за сочетания и как они работают, вы теперь знаете, так что пусть ваши письма приходят с пломбой, а подделки получают отказ еще на пороге.
Какой шаг настройки дался вам труднее всего: SPF с лишним include, капризный длинный ключ или решимость включить reject? Расскажите в комментариях, и я с удовольствием помогу разобраться в самых запутанных случаях.
