SPF, DKIM и DMARC на примере: как защитить домен от подделки писем

Бухгалтер получает письмо «от директора» с адреса director@example.com: срочно оплатить счёт. Письмо написал не директор, но проверить это нечем: протокол SMTP, по которому ходит почта, подлинность отправителя сам не подтверждает (RFC 5321). Поэтому поверх него появились три механизма на основе записей DNS: SPF, DKIM и DMARC. Вместе они позволяют получателю проверить, что письмо с вашего домена действительно отправлено вами, а вам — сказать, что делать с остальными.

В этой статье мы на примере вымышленного домена example.com разберём, где в письме два «адреса отправителя», опубликуем записи SPF, DKIM и DMARC, пройдём безопасный порядок внедрения (от наблюдения p=none к ужесточению) и научимся проверять результат в DNS и в заголовке Authentication-Results.

Что нужно знать заранее

• Сети с нуля 07. DNS: как имя превращается в адрес — записи TXT и MX, TTL и кэширование: всё, что ниже, хранится в DNS.
• Сети с нуля 10. Диагностика сети в Windows: ping, tracert, nslookup и другие — как пользоваться nslookup.

Почтовый сервер (MTA, mail transfer agent) принимает и передаёт письма по SMTP. Чтобы доставить письмо на anna@example.org, сервер отправителя спрашивает DNS о записи MX домена example.org, которая называет сервер, принимающий его почту.

DMARC недавно получил новый стандарт. В мае 2026 года RFC 7489 (категория Informational) признан устаревшим: его заменили три документа категории Standards Track: RFC 9989 (сам протокол), RFC 9990 (агрегатные отчёты) и RFC 9991 (отчёты о сбоях). Многие инструкции, включая страницы Microsoft Learn на 28 октября 2026 года, всё ещё ссылаются на RFC 7489. Записи выглядят почти так же, но есть отличия, и мы их отметим.

Два адреса отправителя

У бумажного письма адрес на конверте может отличаться от подписи на листке. В электронной почте так же: по RFC 5321 письмо состоит из конверта (envelope) и содержимого. Приведём упрощённый разговор двух серверов (ответы сервера опущены):

C: EHLO mail.example.com
C: MAIL FROM:<bounce@example.com>
C: RCPT TO:<anna@example.org>
C: DATA
C: From: "Director" <director@example.com>
C: To: anna@example.org
C: Subject: Urgent payment
C:
C: Please pay the invoice today.
C: .

Адреса отправителя здесь два:

• MAIL FROM (он же RFC5321.MailFrom, Return-Path, адрес конверта) — часть конверта. Сюда сервер получателя присылает отчёты об ошибках доставки. Пользователь его обычно не видит.
• From (RFC5322.From) — заголовок в содержимом письма. Именно его показывает почтовая программа как отправителя.

Эти адреса не обязаны совпадать, и в каждом можно указать что угодно: протокол не сверяет их с владельцем домена. Кроме них, сервер представляется командой EHLO (HELO).

Механизм	Что проверяет	Где публикуется	Как это выглядит у получателя
SPF	с разрешённого ли IP-адреса пришло письмо для домена из MAIL FROM	TXT-запись на самом домене	spf=pass
DKIM	не изменено ли письмо и подписано ли оно ключом домена из подписи	TXT на <селектор>._domainkey.<домен>	dkim=pass
DMARC	совпадает ли (выровнен ли) видимый домен From с доменом, прошедшим SPF или DKIM; и что делать при провале	TXT на _dmarc.<домен>	dmarc=pass

SPF и DKIM проверяют «технические» домены (конверта и подписи), а DMARC связывает их с тем доменом, который видит человек.

SPF: кто может отправлять от имени домена

SPF (Sender Policy Framework, RFC 7208) — список серверов, которым домен разрешает отправлять почту. Это одна TXT-запись на имени домена, которая начинается с v=spf1. Сервер получателя берёт домен из MAIL FROM (при пустом MAIL FROM — из EHLO), читает запись и проверяет, есть ли IP-адрес подключившегося сервера в списке.

Пусть у example.com есть свой почтовый сервер 203.0.113.25 и вымышленный сервис рассылок send.example.org, который просит добавить include:_spf.send.example.org:

example.com.  3600  IN  TXT  ( "v=spf1 ip4:203.0.113.25 "
                               "include:_spf.send.example.org ~all" )

Запись читается слева направо, каждая часть — «директива»:

Часть	Значение
ip4:203.0.113.25, ip6:	разрешить этот адрес или сеть (ip4:203.0.113.0/24); без маски это один адрес
a, mx	разрешить IP-адреса самого домена (a) или его почтовых серверов из записей MX (mx); можно указать другой домен: a:mail.example.com
include:<домен>	подключить SPF-запись другого домена: совпадение есть, только если проверка того домена дала pass; -all внутри неё не завершает вашу проверку
all	совпадает всегда; ставится в самый конец; всё, что после него, игнорируется
redirect=<домен>	модификатор: взять запись другого домена целиком

Перед директивой может стоять квалификатор, он определяет результат при совпадении:

Знак	Результат	Смысл
+ (по умолчанию)	pass	разрешено
-	fail	не разрешено
~	softfail	«скорее всего, не разрешено»
?	neutral	мнения нет

Есть и другие результаты: none (записи SPF нет), temperror (временный сбой DNS) и permerror (запись некорректна). Если ни одна директива не совпала, результат neutral, поэтому запись заканчивают -all или ~all.

Между -all и ~all разница в строгости. Получатель вправе отклонить письмо с fail (ответом 550 5.7.1), но с softfail не должен отклонять его только на этом основании. Microsoft рекомендует -all для доменов с настроенными DKIM и DMARC, а стандарт DMARC предупреждает, что письмо с -all могут отклонить ещё до проверки DMARC, и оно не попадёт в отчёты. Начинать можно с ~all, а -all включить, когда отправители сверены.

Лимит в 10 запросов

Каждая директива include, a, mx, ptr, exists и модификатор redirect заставляют получателя делать DNS-запросы. Всего их не может быть больше 10, включая вложенные include; при превышении проверка даёт permerror. Директивы ip4, ip6 и all запросов не требуют и в лимит не входят. Механизм ptr не используйте: стандарт не советует его публиковать. Проверка идёт слева направо и останавливается при первом совпадении, поэтому ошибка видна не у всех отправителей сразу. Ещё рекомендуется не больше двух «пустых» ответов (имя не существует или записей нет).

Отсюда практика:

• для постоянных адресов пишите ip4:, а не a и mx: дешевле и не зависит от DNS;
• каждый сервис рассылок — минимум один include, а в его записи могут быть вложенные. Если лимит подступает, выносите сторонние сервисы в поддомен (например, news.example.com) с отдельной SPF-записью: так советует и Microsoft;
• для доменов, с которых почту не отправляют, публикуйте v=spf1 -all.

SPF проверяет только MAIL FROM (и EHLO), а не видимый From, поэтому адрес, который видит пользователь, он не защищает: нужен DMARC.

DKIM: цифровая подпись письма

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

Подпись добавляется заголовком DKIM-Signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=mail2026;
 h=from:to:subject:date:message-id;
 bh=<ХЭШ_ТЕЛА>; b=<ПОДПИСЬ>

Тег	Значение
v	версия, всегда 1
a	алгоритм подписи: rsa-sha256 (алгоритм rsa-sha1 использовать нельзя)
c	способ канонизации заголовков и тела: simple почти не допускает изменений, relaxed терпит перенос строк и лишние пробелы; без тега simple/simple
d	домен, взявший ответственность за подпись
s	селектор: имя ключа
h	какие заголовки подписаны; From обязан быть в списке
bh	хэш тела письма
b	сама подпись

Получатель строит имя <s>._domainkey.<d> (здесь mail2026._domainkey.example.com) и запрашивает его TXT-запись:

mail2026._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=<ОТКРЫТЫЙ_КЛЮЧ>" )

В записи: v=DKIM1 (версия, если есть, стоит первой), k=rsa (тип ключа, по умолчанию rsa), p= (открытый ключ в base64; пустое значение означает отзыв ключа), t=y (домен тестирует DKIM: получатель не должен относиться к письму хуже, чем к неподписанному).

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

Длина RSA-ключа должна быть не меньше 1024 бит, рекомендуется не меньше 2048 (RFC 8301). Ключ на 2048 бит длиннее 255 символов, которые допускает одна строка TXT, поэтому запись режут на несколько строк в кавычках внутри одной записи: получатель склеивает их без пробелов.

Подпись включают в самой почтовой системе, по её документации: обычно она создаёт пару ключей и показывает запись для DNS. Внешние сервисы часто подписывают письма своим доменом: такая подпись корректна, но с вашим From не совпадает (см. ниже), поэтому включайте подпись вашим доменом.

DMARC: связь с видимым адресом и политика

DMARC (Domain-based Message Authentication, Reporting, and Conformance) отвечает на два вопроса: совпадает ли домен, прошедший SPF или DKIM, с доменом из From, и что получателю делать, если нет. Запись публикуется как TXT на имени _dmarc.<домен>.

Выравнивание

Письмо проходит DMARC, если выполнено хотя бы одно из двух условий:

• SPF дал pass, и домен из MAIL FROM выровнен (aligned) с доменом из From;
• DKIM дал pass, и домен из подписи (d=) выровнен с доменом из From.

DMARC проверяет SPF только по MAIL FROM, а не по EHLO. Рекомендуется настроить оба механизма. Выравнивание бывает relaxed (по умолчанию: совпадает организационный домен, в простом случае — зарегистрированный домен вроде example.com) и strict (домены совпадают целиком):

Домен из From	Домен SPF или DKIM	Relaxed	Strict
news.example.com	foo.example.com	да	нет
news.example.com	news.example.com	да	да
example.com	send.example.org	нет	нет

Последняя строка — типичный случай со сторонним сервисом: письмо с вашим From прошло SPF и DKIM по домену сервиса, но выравнивания нет, и DMARC не пройден.

Запись DMARC

_dmarc.example.com.  3600  IN  TXT  ( "v=DMARC1; p=none; "
    "rua=mailto:dmarc-reports@example.com" )

Тег	Значение	По умолчанию
v	DMARC1, обязательно первым, иначе запись игнорируется	—
p	политика: none, quarantine или reject	нет p при корректном rua значит p=none
sp	политика для существующих поддоменов	как p
np	политика для несуществующих поддоменов	как sp, а если нет и его, как p
rua	куда присылать агрегатные отчёты (mailto:)	отчёты не присылают
ruf	куда присылать отчёты о сбоях по отдельным письмам	не присылают
adkim, aspf	выравнивание DKIM и SPF: r или s	r
fo	какие отчёты о сбоях запрашивать (только вместе с ruf)	0
t	y — «политику тестирую»: применять её на ступень мягче	n
psd	флаг «это домен публичного суффикса» (y, n, u); обычному домену не нужен	u

Политика p=none ничего не требует от получателя: это режим наблюдения (Monitoring Mode), ради отчётов. p=quarantine просит считать такие письма подозрительными (их, например, кладут в «Спам»), а p=reject — отклонять. Решение остаётся за получателем: стандарт просит не отклонять письмо только из-за p=reject и при отсутствии других данных обращаться с ним как с quarantine (в одном месте мягче, в другом строже). На практике такие письма нередко отклоняют.

Тега pct (применять политику к части писем) в новом стандарте больше нет: на практике он работал неточно, и его частично заменил t, у которого только два значения (без процентов). Документация вендоров ещё описывает pct, но рассчитывать на плавное «10%, 25%, 100%» не стоит. Теги rf и ri тоже удалены. Неизвестные теги получатели игнорируют.

Поддомены. Запись на _dmarc.example.com действует на все поддомены без собственной записи. Чтобы поддомены вели себя иначе, добавляют sp и np либо публикуют отдельную запись на поддомене. Если на одном имени окажутся две записи DMARC, обе будут отброшены.

Что DMARC не закрывает. Он защищает именно ваш домен в From, но не защищает от визуально похожих доменов (с цифрой «1» вместо буквы «l») и от ложного отображаемого имени ("Директор" <someone@example.org>).

Отчёты

Агрегатные отчёты (rua) присылают получатели, как правило, раз в сутки или чаще, вложением: XML, сжатый gzip (*.xml.gz). В отчёте нет персональных данных: нет адресов, IP-адресов отдельных людей и содержимого. Это счётчики по источникам: с какого IP-адреса сколько писем пришло под вашим доменом и как они прошли проверки. Фрагмент отчёта (значения вымышленные):

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>pass</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>example.com</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
</record>

XML вручную читать неудобно: стандарт советует разбирать отчёты программой (своим скриптом или сторонним сервисом). Заведите для них отдельный ящик. Если адрес rua на чужом домене, его владелец должен подтвердить согласие записью example.com._report._dmarc.<домен сервиса> со значением v=DMARC1.

Отчёты о сбоях (ruf) описывают отдельные письма и могут содержать персональные данные, поэтому многие получатели их не отправляют. На старте ruf лучше не включать.

Практика: внедряем по порядку

Все шаги выполняются в панели DNS-хостера; после каждого проверяйте результат (раздел «Проверка» ниже).

Шаг 1. Составьте список отправителей. Выясните, кто пишет письма с вашим доменом в From: почтовый сервер, сервис рассылок, сайт и CRM, бухгалтерия, МФУ, система мониторинга (Zabbix тоже отправляет почту). О забытых отправителях расскажут и отчёты p=none.

Шаг 2. Опубликуйте SPF. Одна запись на домен: ваши серверы через ip4:, внешние сервисы через include: (значение даёт сервис). Концовка ~all на старте, -all позже. Проверьте, что запросов не больше 10.

Шаг 3. Настройте DKIM у каждого отправителя. В каждой системе создайте ключ (2048 бит), опубликуйте запись <селектор>._domainkey и включите подпись вашим доменом (d=example.com).

Шаг 4. Включите наблюдение. Опубликуйте v=DMARC1; p=none; rua=mailto:…. Доставка при этом не меняется. Читайте отчёты не меньше месяца (стандарт отмечает, что до уверенности могут пройти месяцы): найдите источники, которые не проходят SPF или DKIM с выравниванием, и исправьте их.

Шаг 5. Ужесточайте постепенно. Когда все законные источники проходят DMARC, переходите к p=quarantine, затем, если нужно, к p=reject. Стандарт советует доменам, где обычные сотрудники пишут в публичные списки рассылки, не ставить p=reject. Кто всё же хочет, тому стандарт советует сначала держать p=none не меньше месяца, потом p=quarantine не меньше месяца и сравнивать результаты по отчётам. При p=reject одного SPF недостаточно: нужна и подпись DKIM. Microsoft описывает ту же лестницу и называет целью p=reject; выбирайте ступень по своим отчётам. Для доменов, с которых почту не отправляют, Microsoft советует запрещающую DMARC-запись и v=spf1 -all.

Шаг 6. Поддерживайте. Новая система получает SPF и DKIM до начала рассылки; ключи DKIM меняют через новый селектор, а include: отключённых сервисов убирают.

Итоговый набор записей для example.com (кроме DKIM, который создаёт сама почтовая система):

example.com.        3600 IN MX  10 mail.example.com.
example.com.        3600 IN TXT ( "v=spf1 ip4:203.0.113.25 "
                                  "include:_spf.send.example.org ~all" )
mail2026._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
                                  "p=<ОТКРЫТЫЙ_КЛЮЧ>" )
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; "
                                  "rua=mailto:dmarc-reports@example.com" )

В веб-интерфейсе DNS-хостера имя обычно вводят без зоны (_dmarc, mail2026._domainkey): если ввести полное имя, получится _dmarc.example.com.example.com. Кавычки и разбиение на строки поле нередко добавляет само, но у хостеров по-разному: сверяйтесь с результатом проверки.

Проверка

Записи в DNS

C:\Users\admin-lab>nslookup -type=TXT example.com
C:\Users\admin-lab>nslookup -type=TXT mail2026._domainkey.example.com
C:\Users\admin-lab>nslookup -type=TXT _dmarc.example.com

Пример вывода для последней команды:

_dmarc.example.com      text =

        "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

В PowerShell то же: Resolve-DnsName _dmarc.example.com -Type TXT, на Linux: dig +short TXT _dmarc.example.com. Убедитесь, что запись SPF на example.com одна, а в записи DMARC v=DMARC1 стоит первым. Изменения видны не сразу: резолверы держат ответ в кэше до конца TTL.

Заголовок Authentication-Results

Отправьте тестовое письмо с вашего домена на ящик другого домена и откройте полные заголовки письма. В классическом Outlook откройте письмо в отдельном окне и выберите «Файл → Свойства» (поле «Internet headers»), в новом Outlook и Outlook в браузере — «Дополнительные действия (…) → Просмотр → Просмотреть сведения о сообщении».

Принимающий сервер записывает результаты проверок в заголовок Authentication-Results (RFC 8601). Пример (значения вымышленные):

Authentication-Results: mx.example.org;
    spf=pass smtp.mailfrom=example.com;
    dkim=pass header.d=example.com header.s=mail2026;
    dmarc=pass header.from=example.com

Сначала идёт идентификатор сервера, выполнившего проверки (mx.example.org), затем методы и результаты:

• spf=pass smtp.mailfrom=… — результат SPF и проверенный домен из MAIL FROM (при проверке по EHLO вместо него будет smtp.helo);
• dkim=pass header.d=… header.s=… — результат DKIM, домен подписи и селектор;
• dmarc=pass header.from=… — итог DMARC для домена из From (значения: pass, fail, none — записи DMARC нет, temperror, permerror).

У письма, отправленного с чужого сервера, будет, например, spf=softfail (при ~all; при -all — spf=fail), dkim=none и dmarc=fail.

Типичные ошибки и недоразумения

• Две записи SPF или две записи DMARC. SPF даёт permerror, DMARC-записи обе отбрасываются. Объединяйте директивы в одну запись.
• +all или ?all. +all разрешает отправку всем (директива all совпадает всегда), так что запись ничего не защищает. ?all ничего не требует.
• Забытый отправитель при -all или p=reject. Принтер, CRM и мониторинг шлют письма, а вы о них забыли; их письма отклоняют. Поэтому сначала p=none и отчёты.
• Пересылка и списки рассылки. Пересылающего сервера нет в вашей SPF-записи, поэтому SPF обычно ломается (подпись DKIM чаще выживает), а списки, которые меняют письмо (тему, подвал), ломают и DKIM. При p=reject такие письма пропадают.
• Не тот селектор или не то имя. Селектор в s= подписи должен совпадать с именем записи <селектор>._domainkey, а запись DMARC всегда лежит на _dmarc. Пустой p= в ключе означает отзыв ключа.
• Запись разорвана. Строки одной записи TXT склеиваются без пробелов. В ключе DKIM не вставляйте пробелы и переносы; в SPF пробел между директивами должен остаться внутри кавычек (в примере он стоит в конце первой строки); не теряйте ; между тегами DKIM и DMARC.
• Сторонний сервис подписывает своим доменом. SPF и DKIM проходят, а DMARC нет: нет выравнивания.

Проверьте себя

1. Чем MAIL FROM отличается от From и какой из них видит получатель в почтовой программе? MAIL FROM — адрес конверта (для сообщений об ошибках доставки), его пользователь обычно не видит. From — заголовок письма, который показывается как отправитель. Они могут быть разными.
2. В записи SPF 12 директив include. Что произойдёт при проверке? Каждый include требует минимум одного запроса DNS, а предел — 10. Если проверке придётся дойти до 11-го запроса, результат будет permerror и SPF не даст pass. Если отправитель совпал раньше, ошибки не будет, но полагаться на это нельзя: результат зависит от порядка директив и от отправителя. Запись нужно сокращать.
3. Письмо прошло SPF и DKIM по домену сервиса рассылок, но DMARC не пройден. Почему? Домены SPF и DKIM не выровнены с доменом из From. Нужно включить в сервисе подпись вашим доменом или настроить MAIL FROM под вашим доменом.
4. С какой политики DMARC начинают и зачем? С p=none и rua: ничего не блокируется, а отчёты показывают всех отправителей, которых нужно исправить до перехода к quarantine и reject.
5. Что означает dmarc=pass header.from=example.com в Authentication-Results и можно ли верить этому заголовку, если его прислал отправитель? DMARC пройден для домена из From. Верить можно только заголовку, добавленному вашим принимающим сервером: заголовок, пришедший снаружи, мог быть подделан.

Что дальше

• HTTPS и сертификаты: как работает Let's Encrypt и как получить сертификат — ещё одно применение проверки домена через DNS.
• Zabbix с нуля: установка, первые узлы и уведомления — почтовые уведомления системы мониторинга, которые тоже должны проходить проверки домена.

Источники

• RFC 7208: Sender Policy Framework (SPF) — записи SPF, механизмы, квалификаторы, лимит в 10 запросов, пересылка.
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures и RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM — теги подписи и ключа, селекторы, длина ключей, запрет rsa-sha1.
• RFC 9989: DMARC — актуальный стандарт DMARC (май 2026): теги, выравнивание, политики, поэтапное внедрение, приложение с отличиями от RFC 7489.
• RFC 9990: DMARC Aggregate Reporting и RFC 9991: DMARC Failure Reporting — агрегатные отчёты и отчёты о сбоях, проверка внешних адресатов, приватность.
• RFC Editor: сведения об RFC 7489 — статус «obsolete», ссылка на RFC 9989, 9990 и 9991.
• RFC 8601: Authentication-Results — формат заголовка, методы spf, dkim, dmarc и их свойства, удаление чужих заголовков.
• RFC 5321: SMTP и RFC 5322: Internet Message Format — конверт и содержимое письма, заголовок From.
• Microsoft Learn: настройка SPF, DKIM и DMARC для Microsoft 365 — особенности Exchange Online и поэтапное внедрение.
• Microsoft Support: просмотр заголовков в Outlook — как открыть заголовки письма.
• dig(1), Ubuntu Manpages — запрос TXT-записей на Linux.