SPF, DKIM, DMARC простыми словами и по шагам

MAATRIX

Три буквы подряд — SPF, DKIM, DMARC — пугают, потому что везде объясняются через RFC и таблицы флагов проверки. На деле смысл у каждой записи простой, если не лезть сразу в синтаксис, а спросить: какую конкретно проблему она решает. Ниже — разбор без канцелярита, с примерами реальных DNS-записей и порядком действий, в котором эти три записи стоит настраивать, чтобы не сломать почту по пути.

Зачем вообще эти три записи

Электронная почта устроена на честном слове. Протокол SMTP, на котором она работает, изначально не проверял, кто на самом деле отправитель — в поле «От» можно вписать любой адрес, включая чужой домен. Это как конверт без штампа отправителя: получатель верит тому, что написано, потому что проверить нечем. Годами этим пользовались для фишинга и спама: письмо якобы от bank.ru, а на самом деле с случайного сервера.

SPF, DKIM и DMARC — это три независимые проверки, закрывающие эту дыру каждая со своей стороны:

• SPF отвечает на вопрос «этому серверу разрешено слать почту от имени домена?»
• DKIM отвечает на вопрос «письмо точно не подделано и не изменено в пути?»
• DMARC отвечает на вопрос «что делать с письмом, если проверки выше не прошли, и как сообщить об этом владельцу домена?»

Три вопроса разные, поэтому и записи разные. Настроить одну без других — как поставить замок на дверь, у которой нет стен. Дальше — про каждую по отдельности, простыми словами и с примером записи.

SPF: список серверов, которым можно говорить от вашего имени

SPF расшифровывается как Sender Policy Framework — «схема политики отправителя». По сути это одна TXT-запись в DNS вашего домена, в которой вы прямо перечисляете: вот эти IP-адреса и вот эти сервисы имеют право отправлять почту от имени вашдомен.ru. Всё, что не в списке, — не должно проходить проверку.

Аналогия: представьте, что на входе в офис висит список «эти курьеры имеют право доставлять почту от компании». Охранник (принимающий почтовый сервер) сверяет курьера со списком. Нет в списке — письмо помечается как подозрительное.

Пример базовой SPF-записи для домена, который отправляет почту с одного сервера и по-другому не рассылает:

v=spf1 ip4:203.0.113.10 -all

Разбор по частям:

• v=spf1 — версия стандарта, обязательное начало любой SPF-записи.
• ip4:203.0.113.10 — механизм: «этому конкретному IPv4-адресу можно». Для IPv6 аналогично, ip6:2001:db8::1.
• -all — что делать со всеми остальными источниками, не попавшими в список выше. -all значит «жёстко отклонить», это самый строгий вариант.

Если почта дополнительно уходит через внешний сервис (например, транзакционные письма через сервис рассылок), в запись добавляют механизм include, который подключает чужую SPF-запись целиком:

v=spf1 ip4:203.0.113.10 include:_spf.mailerservice.com -all

Это значит: «можно с моего IP, и ещё можно всем, кого разрешает провайдер рассылок в своей собственной SPF-записи». Именно так include и работает — не копирует список вручную, а ссылается на чужую запись, и она может меняться на стороне провайдера без вашего участия.

Насчёт хвоста записи — ~all вместо -all часто рекомендуют новичкам. ~all значит «мягкий провал» (softfail): письма от не перечисленных источников не отклоняются автоматически, а помечаются как подозрительные, окончательное решение — на усмотрение принимающей стороны (часто просто уходят в спам). -all — «жёсткий провал»: явное указание отклонять. Пока вы не уверены, что перечислили вообще все свои источники отправки, ~all безопаснее — не потеряете легитимную почту из-за забытого IP.

Важная деталь: у домена может быть только одна SPF-запись. Если добавить вторую (например, при подключении нового сервиса кто-то создаёт новую TXT-запись вместо правки существующей), проверка ломается целиком с ошибкой permerror — и это отдельная частая грабля, которая заслуживает отдельного разговора.

DKIM: цифровая подпись, которую нельзя подделать

DKIM (DomainKeys Identified Mail) работает совершенно иначе, чем SPF, — не через список разрешённых адресов, а через криптографию. Идея простая: почтовый сервер, отправляющий письмо, подписывает его своим закрытым (приватным) ключом. Получатель проверяет эту подпись публичным ключом, который заранее опубликован в DNS домена отправителя. Если подпись сходится — значит, письмо действительно отправлено владельцем этого домена и его содержимое не менялось в пути.

Аналогия: сургучная печать на конверте. Печать делается уникальной формой, которая есть только у отправителя (закрытый ключ), а проверить подлинность оттиска может кто угодно, кто знает, как должна выглядеть настоящая печать (публичный ключ). Подделать оттиск без формы невозможно, а вот убедиться в подлинности — легко, если знаешь эталон.

Принцип генерации ключей простой: на почтовом сервере создаётся пара ключей — закрытый и публичный. Закрытый остаётся на сервере и никогда никуда не публикуется, им подписываются исходящие письма. Публичный публикуется в DNS в виде TXT-записи по специальному имени, включающему «селектор» — произвольную метку, которую вы сами придумываете при генерации (например, mail или дату генерации ключа):

mail._domainkey.вашдомен.ru

Содержимое такой записи выглядит примерно так (ключ обрезан для примера, реальный публичный ключ 2048 бит — это несколько сотен символов):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7v...

Разбор: v=DKIM1 — версия, k=rsa — тип алгоритма (RSA — стандарт по умолчанию), p= — сам публичный ключ в закодированном виде. Селектор mail в имени записи важен: он позволяет иметь несколько DKIM-ключей одновременно (например, при плановой смене ключа) — сервер указывает в заголовке письма, каким селектором он подписал, и получатель ищет именно ту запись.

Практическая деталь, которая портит настройку чаще всего: длинный публичный ключ при вставке в панель DNS-провайдера легко ломается — переносы строк или лишние пробелы делают запись нерабочей, и проверка выдаёт dkim=fail, хотя на первый взгляд всё настроено. Сверяйте содержимое DNS-записи с исходным файлом ключа на сервере посимвольно (не считая разбиения на кавычки, которое DNS сам склеивает обратно).

DMARC: политика поверх SPF и DKIM плюс отчёты

DMARC (Domain-based Message Authentication, Reporting and Conformance) — третий уровень, и он принципиально не проверяет письмо сам. DMARC ничего не знает про IP-адреса и подписи напрямую — он опирается на РЕЗУЛЬТАТЫ проверок SPF и DKIM, которые уже прошли до него, и говорит получателю: «если оба (или хотя бы один — в зависимости от настройки) провалились, вот что с письмом делать».

Это ключевое отличие DMARC от первых двух механизмов: SPF и DKIM — это сами проверки, а DMARC — это политика реагирования на их результат плюс канал обратной связи. Без DMARC получатель, увидев провал SPF или DKIM, решает сам, по своим внутренним правилам (часто просто отправляет в спам без уведомления кого-либо). С DMARC вы сами явно говорите, что делать, и получаете отчёт о том, как проходят проверки в реальности.

Пример базовой DMARC-записи, размещаемой по адресу _dmarc.вашдомен.ru:

v=DMARC1; p=none; rua=mailto:dmarc-reports@вашдомен.ru

Разбор:

• v=DMARC1 — версия, обязательна.
• p=none — политика: «ничего не делать со сбойными письмами, только наблюдать». Это самая мягкая политика, о ней подробнее ниже.
• rua=mailto:... — адрес, куда присылать агрегированные отчёты о прохождении проверок (rua — reporting URI for aggregate reports). Именно сюда крупные почтовые системы вроде Google и Microsoft будут раз в сутки присылать сводку: сколько писем от вашего домена они видели, сколько прошло SPF и DKIM, сколько нет и с каких IP.

Политика p= может принимать три значения:

Для строгости можно добавить pct= (какой процент писем подвергать политике — полезно для постепенного перехода) и ruf= (адрес для детальных forensic-отчётов по отдельным письмам, но их поддерживает меньше провайдеров, чем агрегированные rua).

Важно понимать связь трёх механизмов ещё раз, другими словами: DMARC не проверяет письмо сам и не заменяет SPF или DKIM — он их использует как исходные данные. Без хотя бы одной настроенной проверки (SPF или DKIM) DMARC бессмысленен, ему не на что опираться. Поэтому порядок настройки, о котором ниже, не случаен.

Порядок настройки: почему именно так

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

Шаг 1. SPF — самый простой и быстрый. Одна TXT-запись, никаких ключей генерировать не нужно, только перечислить реальные источники отправки. Проверяется сразу после распространения DNS:

dig TXT вашдомен.ru +short

В выводе должна быть строка, начинающаяся с v=spf1. Убедитесь, что она ровно одна.

Шаг 2. DKIM — требует генерации пары ключей на самом почтовом сервере и настройки почтового ПО на подпись исходящих писем. Как именно это делается, зависит от вашего сервера — у Postfix с OpenDKIM это одни команды, у готовых решений вроде iRedMail или Mailcow ключ генерируется через встроенный интерфейс. Общий принцип везде тот же: генерируете пару ключей → публикуете публичный ключ в DNS по адресу селектор._domainkey.вашдомен.ru → включаете подпись на сервере → ждёте распространения DNS → проверяете:

dig TXT mail._domainkey.вашдомен.ru +short

Отправьте себе тестовое письмо на ящик, который показывает технические заголовки (Gmail подходит — «Показать оригинал»), и убедитесь, что там стоит dkim=pass.

Шаг 3. DMARC с мягкой политики. Только после того, как SPF и DKIM оба стабильно проходят проверку хотя бы несколько дней, добавляйте DMARC — и обязательно начинайте с p=none. Это принципиальный момент: p=none не защищает домен от подделки сама по себе, но даёт вам данные — реальную картину, сколько писем от вашего домена проходят проверки, а сколько нет, и с каких IP приходят несовпадения. Часто на этом этапе обнаруживается забытый источник отправки (например, форма обратной связи на сайте отправляет через другой сервис, о котором все забыли) — без периода наблюдения это грозило бы попаданием легитимных писем под жёсткую блокировку.

Через одну-две недели наблюдения по отчётам, когда видно, что все легитимные источники проходят проверки, политику ужесточают до p=quarantine, а затем, при полной уверенности, до p=reject. Каждый шаг — это отдельная правка одной DNS-записи, никакой сложности, кроме терпения дождаться данных.

Как читать первые отчёты DMARC

Агрегированные отчёты (rua) приходят в виде XML-файлов раз в сутки от каждого крупного получателя (Google, Microsoft, Yahoo и другие), обычно заархивированных. Открывать их вручную неудобно — XML не предназначен для чтения глазами, там построчно указаны IP-адреса, с которых пришла почта, и результат по каждому: spf=pass/fail, dkim=pass/fail, итоговое disposition (что было бы сделано по текущей политике).

На практике для чтения отчётов используют бесплатные онлайн-парсеры или скрипты, превращающие XML в читаемую таблицу — искать в первую очередь строки, где оба spf и dkim стоят fail, и смотреть, чей это IP. Если IP ваш собственный (второй сервер, забытая интеграция) — это источник, который нужно добавить в SPF или настроить на нём DKIM. Если IP незнакомый — это, вероятно, действительно попытка подделать домен, и наличие DMARC уже не даёт этому письму дойти как легитимному.

Проверка всей связки одним запросом

После настройки всех трёх записей удобно проверять их не по одной, а комплексным сервисом (в интернете есть бесплатные проверки SPF/DKIM/DMARC по домену — введите домен, сервис покажет статус каждой записи и синтаксические ошибки). Для ручной проверки из терминала пригодятся три команды подряд:

dig TXT вашдомен.ru +short | grep spf
dig TXT mail._domainkey.вашдомен.ru +short
dig TXT _dmarc.вашдомен.ru +short

Если все три возвращают непустой и синтаксически верный результат — база готова. Финальная проверка — отправить письмо на ящик с видимыми техническими заголовками и убедиться, что все три проверки в заголовке Authentication-Results показывают pass.

Частые вопросы