Загрузка...
Загрузка...
Подробное руководство по настройке SPF, DKIM и DMARC записей. Защита от спуфинга, улучшение доставляемости писем. Примеры DNS-записей и пошаговая настройка.
Практическое руководство по настройке DNS для email: MX-записи, синтаксис SPF, генерация ключей DKIM, политики DMARC. Примеры конфигураций для популярных провайдеров.
БезопасностьПолное руководство по доставляемости email: репутация отправителя, аутентификация SPF/DKIM/DMARC, контент, чёрные списки, мониторинг. Практические советы для маркетологов и администраторов.
БезопасностьАктуальные практики защиты аккаунтов в 2026. Менеджеры паролей, двухфакторная аутентификация, passkeys. Миграция и рекомендации.
БезопасностьПравила создания надёжных паролей. Длина, сложность, генерация. Как избежать слабых паролей и защититься от перебора и утечек.
Поделитесь с коллегами или изучите другие материалы блога
Каждый день почтовые серверы по всему миру обрабатывают миллиарды писем, и значительная часть из них — мошеннические. Злоумышленник отправляет письмо якобы от имени вашего банка, вашего работодателя или вашего домена — и получатель видит знакомый адрес в поле «От». Протокол SMTP, разработанный в 1982 году, не предусматривал никакой проверки отправителя. Любой сервер мог отправить письмо с любым обратным адресом — и долгие годы это было нормой.
Три технологии — SPF, DKIM и DMARC — были созданы, чтобы закрыть эту брешь. Вместе они формируют систему email-аутентификации, которая позволяет принимающему серверу определить, действительно ли письмо отправлено с авторизованного сервера и не было ли оно изменено в пути. Если вы администрируете почтовый домен и до сих пор не настроили все три записи — эта статья для вас.
Email-спуфинг — это подделка адреса отправителя. Злоумышленник отправляет письмо с адресом ceo@yourcompany.ru сотруднику бухгалтерии с просьбой срочно перевести деньги. Письмо выглядит легитимно, потому что SMTP не проверяет, имеет ли отправляющий сервер право использовать этот домен.
Фишинг работает по схожему принципу, но нацелен на клиентов: письмо якобы от support@yourbank.ru с ссылкой на поддельную страницу авторизации. По данным отчёта Verizon DBIR, фишинг остаётся вектором начального доступа в 36% успешных кибератак. И в большинстве случаев атака начинается именно с поддельного email-адреса.
Даже если вы не беспокоитесь о мошенниках, email-аутентификация напрямую влияет на доставляемость ваших собственных писем. Google, Yahoo, Mail.ru и Яндекс открыто заявляют: домены без корректных SPF, DKIM и DMARC записей получают пониженный рейтинг доверия. Ваши маркетинговые рассылки, транзакционные уведомления и даже обычная деловая переписка могут оказаться в папке «Спам» или быть отклонены полностью.
С февраля 2024 года Google и Yahoo ввели обязательные требования для массовых отправителей (более 5000 писем в день): наличие SPF и DKIM, корректная DMARC-запись и возможность отписки в один клик. Отправители, не выполняющие эти требования, получают отказ в доставке.
Каждый почтовый провайдер ведёт скоринг репутации домена. Эта репутация формируется годами и разрушается за часы. Достаточно одной фишинговой кампании с вашего домена (даже если вы к ней непричастны), чтобы попасть в чёрные списки. Восстановление занимает недели и требует взаимодействия с каждым провайдером отдельно. Правильно настроенная email-аутентификация — это страховка от такого сценария.
SPF позволяет владельцу домена указать в DNS-записи, какие серверы имеют право отправлять почту от имени этого домена. Когда принимающий сервер получает письмо с адресом user@example.com, он делает DNS-запрос к домену example.com и получает SPF-запись. Затем сверяет IP-адрес отправляющего сервера со списком разрешённых — и принимает решение.
Технически SPF-запись — это TXT-запись в DNS. Принимающий сервер проверяет адрес из конверта письма (MAIL FROM), а не из заголовка From:, который видит пользователь. Это важный нюанс, к которому мы вернёмся при обсуждении DMARC.
Каждая SPF-запись начинается с v=spf1 и заканчивается механизмом по умолчанию. Между ними перечисляются разрешённые источники:
v=spf1 [механизмы] [модификатор_по_умолчанию]
Основные механизмы:
| Механизм | Описание | Пример |
|---|---|---|
ip4 | Разрешить конкретный IPv4-адрес или подсеть | ip4:192.168.1.1 или ip4:10.0.0.0/24 |
ip6 | Разрешить IPv6-адрес или подсеть | ip6:2001:db8::/32 |
a | Разрешить IP-адреса из A-записи домена | a:mail.example.com |
mx | Разрешить IP-адреса из MX-записей домена | mx |
include | Включить SPF-запись другого домена | include:_spf.google.com |
redirect | Перенаправить проверку на другой домен | redirect=_spf.example.com |
Модификаторы по умолчанию определяют, что делать с серверами, не попавшими в список:
| Модификатор | Значение | Когда использовать |
|---|---|---|
+all | Разрешить всё | Никогда. Бессмысленная запись |
~all | Мягкий отказ (softfail) | На этапе тестирования |
-all | Жёсткий отказ (fail) | В продакшене |
?all | Нейтрально | Редко, эквивалент отсутствия записи |
Google Workspace:
v=spf1 include:_spf.google.com -all
Яндекс 360 для бизнеса:
v=spf1 include:_spf.yandex.net -all
Mail.ru для бизнеса:
v=spf1 include:_spf.mail.ru -all
Комбинированная запись — Google Workspace + собственный почтовый сервер + сервис рассылок SendPulse:
v=spf1 include:_spf.google.com ip4:185.100.50.25 include:spf.sendpulse.com -all
Домен, который не отправляет почту вообще:
v=spf1 -all
Эта запись особенно важна для паркованных доменов и поддоменов, не использующих email. Без неё злоумышленники могут безнаказанно отправлять письма от имени таких доменов.
SPF имеет жёсткое ограничение: при обработке записи допускается не более 10 DNS-запросов. Каждый механизм include, a, mx и redirect генерирует как минимум один запрос. А include может ссылаться на записи, содержащие свои include — и все они суммируются.
Проверим на примере. Запись include:_spf.google.com выполняет 1 запрос. Но внутри _spf.google.com содержатся ещё 3 include — итого 4 запроса только для Google. Добавляем include:_spf.mail.ru (ещё 2-3 запроса), сервис рассылок (ещё 1-2) — и вот вы уже вплотную к лимиту.
Превышение лимита приводит к ошибке permerror, и вся SPF-проверка считается проваленной. Писма могут уходить в спам или отклоняться.
Способы уложиться в лимит:
include на конкретные ip4/ip6 адреса, где это возможно. Механизмы ip4 и ip6 не генерируют DNS-запросов.redirect вместо множественных include, вынеся всю логику в отдельный поддомен.include в списки IP-адресов, но требуют регулярного обновления.Пример оптимизированной записи через поддомен:
; Основная запись
v=spf1 redirect=_spf.example.com
; _spf.example.com
v=spf1 ip4:142.250.0.0/16 ip4:172.217.0.0/16 ip4:185.100.50.25 include:spf.sendpulse.com -all
Если SPF проверяет, с какого сервера отправлено письмо, то DKIM проверяет целостность самого письма. Механизм основан на асимметричной криптографии: отправляющий сервер подписывает заголовки и тело письма приватным ключом, а принимающий сервер проверяет подпись публичным ключом, опубликованным в DNS.
При отправке почтовый сервер вычисляет хэш от заголовков и тела письма, шифрует его приватным ключом и добавляет подпись в заголовок DKIM-Signature. Принимающий сервер извлекает из заголовка домен и селектор, получает публичный ключ из DNS, расшифровывает подпись и сравнивает хэши. Совпадение означает, что письмо подлинное и не было изменено в пути.
Публичный ключ размещается в TXT-записи DNS по адресу [селектор]._domainkey.[домен]. Селектор — это произвольная метка, позволяющая использовать несколько ключей одновременно.
Пример DNS-записи:
; Имя записи: google._domainkey.example.com
; Тип: TXT
; Значение:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSm...публичный_ключ...QAB
Разберём параметры:
| Параметр | Описание |
|---|---|
v=DKIM1 | Версия протокола |
k=rsa | Алгоритм ключа (rsa или ed25519) |
p=... | Публичный ключ в формате Base64 |
t=s | Строгий режим (опционально, запрещает поддомены) |
t=y | Тестовый режим (опционально) |
Google Workspace:
Google генерирует ключ в панели администратора (Admin Console → Apps → Google Workspace → Gmail → Authenticate email). По умолчанию используется селектор google и 2048-битный ключ. Google предоставит значение TXT-записи — вам нужно создать её в DNS.
; Имя: google._domainkey.example.com
; Тип: TXT
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Важно: 2048-битный ключ не помещается в одну строку DNS TXT-записи (лимит 255 символов на строку). Большинство DNS-провайдеров автоматически разбивают длинные записи, но некоторые требуют ручного разделения кавычками:
v=DKIM1; k=rsa; p="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...продолжение_ключа..."
Яндекс 360:
Яндекс автоматически включает DKIM для доменов, подключённых к Яндекс 360. Селектор — mail. Запись создаётся автоматически, если DNS управляется Яндексом. Для внешнего DNS значение берётся из панели администратора.
; Имя: mail._domainkey.example.com
; Тип: TXT
v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNAD...
Собственный почтовый сервер (Postfix):
Для Postfix используется OpenDKIM. Генерация ключей:
opendkim-genkey -s mail -d example.com -b 2048
Команда создаст два файла: mail.private (приватный ключ) и mail.txt (DNS-запись). Приватный ключ помещается в /etc/opendkim/keys/example.com/mail.private, а содержимое mail.txt публикуется в DNS.
Конфигурация OpenDKIM (/etc/opendkim.conf):
Domain example.com
KeyFile /etc/opendkim/keys/example.com/mail.private
Selector mail
Socket inet:8891@localhost
Canonicalization relaxed/simple
Ключи DKIM не имеют встроенного срока годности, но их рекомендуется менять каждые 6–12 месяцев. Причина — если приватный ключ будет скомпрометирован, злоумышленник сможет подписывать письма от имени вашего домена, и DKIM-проверка будет проходить.
Процедура ротации без простоя:
mail202603).Использование дат в имени селектора упрощает управление:
; Текущий ключ
mail202603._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
; Следующий ключ (подготовлен заранее, но ещё не используется сервером)
mail202609._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
Традиционно DKIM использует RSA-ключи длиной 1024 или 2048 бит. Алгоритм Ed25519 — более современная альтернатива с компактными ключами (44 символа в Base64) и сопоставимой криптографической стойкостью:
v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=
Ed25519 пока не поддерживается всеми провайдерами. Разумная стратегия — публиковать оба ключа с разными селекторами и настроить сервер на подпись обоими.
SPF и DKIM по отдельности решают частные задачи, но не дают владельцу домена контроля над тем, что происходит, когда проверка провалена. SPF прошёл, а DKIM нет? Или наоборот? Что делать с таким письмом — принять, отклонить, отправить в спам? Каждый почтовый провайдер решал это по-своему.
DMARC унифицирует поведение: владелец домена публикует политику, явно указывающую, как поступать с письмами, не прошедшими аутентификацию. Кроме того, DMARC решает проблему выравнивания (alignment): он проверяет, что домен в заголовке From: (который видит пользователь) совпадает с доменом, прошедшим SPF или DKIM проверку.
Без DMARC злоумышленник мог отправить письмо с MAIL FROM: hacker@evil.com (SPF пройдёт для evil.com) и заголовком From: ceo@yourcompany.ru (это увидит получатель). DMARC это пресекает.
DMARC-запись — это TXT-запись в DNS с именем _dmarc.[домен]:
; Имя: _dmarc.example.com
; Тип: TXT
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; pct=100
Параметры:
| Параметр | Значения | Описание |
|---|---|---|
v | DMARC1 | Версия (обязательный) |
p | none, quarantine, reject | Политика для основного домена (обязательный) |
sp | none, quarantine, reject | Политика для поддоменов (необязательный, наследует p) |
rua | mailto:адрес | Куда отправлять агрегированные отчёты |
ruf | mailto:адрес | Куда отправлять forensic-отчёты |
adkim | r (relaxed), s (strict) | Выравнивание для DKIM |
aspf | r (relaxed), s (strict) | Выравнивание для SPF |
pct | 1–100 | Процент писем, к которым применяется политика |
fo | 0, 1, d, s | Условия генерации forensic-отчётов |
p=none — режим наблюдения. Письма доставляются как обычно, но вы получаете отчёты. Это стартовая точка для любого внедрения.
v=DMARC1; p=none; rua=mailto:dmarc@example.com
p=quarantine — подозрительные письма отправляются в спам. Получатель всё ещё может их увидеть, но они не попадут во входящие.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
p=reject — почтовый сервер получателя отклоняет письмо на уровне SMTP. Оно не доставляется вообще — ни во входящие, ни в спам. Максимальная защита.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s
Одна из самых ценных функций DMARC — отчётность. Без отчётов вы работаете вслепую, не зная, кто отправляет почту от имени вашего домена.
Агрегированные отчёты (rua) приходят в формате XML один раз в сутки от каждого крупного провайдера. Они содержат статистику: сколько писем прошло SPF/DKIM, сколько не прошло, с каких IP-адресов отправлялись. Объём может быть значительным — для домена со средним почтовым трафиком ожидайте десятки отчётов в день.
Forensic-отчёты (ruf) содержат данные о конкретных письмах, не прошедших проверку. Они полезны для расследования инцидентов, но не все провайдеры их отправляют (Google, например, не отправляет ruf). Кроме того, forensic-отчёты могут содержать персональные данные получателей, что создаёт вопросы с точки зрения GDPR.
Для анализа отчётов используйте специализированные сервисы или open-source решения вроде parsedmarc. Читать XML-файлы вручную бессмысленно при любом заметном объёме почты.
Переход сразу на p=reject — верный способ заблокировать легитимную почту. Рассылочные сервисы, CRM-системы, тикет-системы, мониторинг — всё, что отправляет письма от имени вашего домена, должно быть учтено в SPF и подписано DKIM. DMARC внедряется постепенно.
Этап 1: Аудит (2–4 недели)
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Собираете отчёты, анализируете источники почты. Составляете полный список серверов и сервисов, отправляющих письма от вашего домена.
Этап 2: Мягкий карантин (2–4 недели)
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com
Применяете карантин к 10% писем. Наблюдаете за отчётами и обратной связью от получателей. Если проблем нет — увеличиваете pct до 25%, 50%, 100%.
Этап 3: Карантин 100% (2–4 недели)
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com
Все неаутентифицированные письма уходят в спам. На этом этапе все легитимные источники должны быть настроены корректно.
Этап 4: Отклонение
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com
Финальная политика. Поддельные письма отклоняются полностью. Продолжайте мониторить отчёты — новые сервисы, подключаемые компанией, потребуют обновления SPF/DKIM.
Ниже — последовательность действий для домена, на котором email-аутентификация настраивается с нуля.
Прежде чем трогать DNS, составьте список всего, что отправляет почту от имени вашего домена:
Пропущенный источник = заблокированные письма после включения строгой политики.
Создайте TXT-запись, включающую все источники из шага 1:
v=spf1 include:_spf.google.com include:amazonses.com ip4:185.100.50.25 -all
Проверьте, что количество DNS-запросов не превышает 10. Используйте DNS Lookup на reChecker для просмотра текущих DNS-записей домена и валидации конфигурации.
Для каждого сервиса, отправляющего почту, настройте DKIM-подпись:
Каждый сервис использует собственный селектор, поэтому конфликтов не возникает:
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
sendpulse._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
mail._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Проверьте агрегированные отчёты. Определите:
Последовательно переходите от p=none к p=quarantine (начиная с pct=10) и далее к p=reject. На каждом этапе выдерживайте паузу и анализируйте отчёты.
Если ваши поддомены не отправляют почту, явно запретите это:
_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
Параметр sp=reject распространяет жёсткую политику на все поддомены.
После настройки необходимо убедиться, что всё работает корректно. Ошибка в синтаксисе DNS-записи или пропущенный сервис могут привести к потере писем.
Убедитесь, что записи опубликованы и доступны. Используйте Проверка email-аутентификации на reChecker — сервис покажет текущие SPF, DKIM и DMARC записи домена, проверит их синтаксис и выявит типичные ошибки конфигурации.
Проверку можно выполнить и через командную строку:
# SPF
dig TXT example.com | grep spf
# DKIM (замените селектор)
dig TXT google._domainkey.example.com
# DMARC
dig TXT _dmarc.example.com
Отправьте письмо на ящик Gmail или Яндекс, откройте полные заголовки и найдите результаты проверки:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=google header.b=abc12345;
spf=pass (google.com: domain of user@example.com designates 142.250.150.26 as permitted sender) smtp.mailfrom=user@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Все три проверки должны показывать pass. Если хотя бы одна показывает fail или softfail — ищите причину.
Email-аутентификация — не разовая настройка. Новые сервисы, смена IP-адресов, ротация DKIM-ключей — всё это требует обновления DNS-записей. Настройте регулярную проверку:
За годы практики некоторые ошибки встречаются с завидной регулярностью. Разберём самые распространённые.
У домена может быть только одна SPF TXT-запись. Если вы добавите вторую (например, забыв объединить записи при подключении нового сервиса), обе записи будут считаться невалидными:
; НЕПРАВИЛЬНО — две отдельные SPF-записи
v=spf1 include:_spf.google.com -all
v=spf1 include:_spf.yandex.net -all
; ПРАВИЛЬНО — одна объединённая запись
v=spf1 include:_spf.google.com include:_spf.yandex.net -all
Добавление каждого нового сервиса через include приближает к лимиту в 10 запросов. При этом разработчик обычно не считает вложенные includes. Вы добавили include:spf.protection.outlook.com — это выглядит как 1 запрос, но внутри Outlook SPF-запись содержит ещё 2 include, итого 3.
Контролируйте общее количество запросов при каждом изменении. Если лимит превышен — оптимизируйте запись, используя ip4/ip6 вместо include для стабильных адресов.
SPF настроен, DMARC включён, но рассылочный сервис отправляет письма без DKIM-подписи вашего домена. Результат: SPF может пройти (IP сервиса в списке), но DMARC alignment не работает, потому что домен в MAIL FROM отличается от домена в From. Письма уходят в спам.
Решение: настройте DKIM-подпись для каждого стороннего сервиса, отправляющего почту от вашего имени. У всех крупных ESP (email service provider) есть инструкции по настройке custom DKIM.
~all (тильда) означает softfail — принимающий сервер не должен отклонять письмо, а лишь отметить его как подозрительное. Многие администраторы ставят ~all «на время тестирования» и забывают переключить на -all. В сочетании с p=none в DMARC это полностью обесценивает защиту.
Вы настроили идеальную аутентификацию для example.com, но забыли про staging.example.com, dev.example.com и old.example.com. Злоумышленники это знают и целенаправленно ищут незащищённые поддомены для спуфинга.
Решение: добавьте sp=reject в DMARC основного домена и создайте SPF-записи v=spf1 -all для каждого поддомена, который не отправляет почту.
DMARC с p=none и без rua — это запись, которая ничего не делает. Она не защищает домен и не даёт данных для анализа. Если вы уже публикуете DMARC — всегда указывайте адрес для отчётов.
Включение p=reject без предварительного аудита через p=none гарантированно заблокирует часть легитимной почты. Особенно страдают пересылки: когда получатель настроил пересылку на другой ящик, письмо доставляется с оригинального сервера пересылки, а не с вашего — SPF ломается. Без DKIM такое письмо не пройдёт и DMARC.
Три технологии работают как единая система. Полезно понимать их взаимосвязь:
Входящее письмо
│
▼
┌─────────────────┐
│ Проверка SPF │ ← IP отправителя в списке?
│ (MAIL FROM) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Проверка DKIM │ ← Подпись валидна?
│ (заголовок) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Проверка DMARC │ ← SPF или DKIM прошли
│ (alignment + │ И домен совпадает с From?
│ политика) │
└────────┬────────┘
│
┌────┴────┐
│ pass │ fail
▼ ▼
Доставка Применение политики
(none/quarantine/reject)
DMARC считается пройденным, если выполнено хотя бы одно из условий:
Именно поэтому рекомендуется настраивать и SPF, и DKIM. Даже если SPF ломается при пересылке, DKIM-подпись остаётся валидной, и письмо проходит DMARC.
Email-аутентификация — это не опциональная рекомендация, а необходимый минимум для любого домена, отправляющего почту. SPF указывает, кто имеет право отправлять, DKIM подтверждает целостность письма, DMARC связывает всё вместе и даёт контроль над политикой.
Настройка занимает несколько часов, но защищает домен на годы. Ключевые принципы:
none → quarantine (с нарастающим pct) → reject.sp=reject.Если вы откладывали настройку email-аутентификации — начните сегодня. Каждый день без SPF, DKIM и DMARC — это день, когда кто-то может отправить письмо от имени вашего домена, и вы об этом даже не узнаете.