SPF, DKIM, DMARC: как проверить почту домена

Зачем домену почтовые записи

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

Почему без этих записей нельзя:

MX — без неё домен физически не принимает почту. Ошибка «адрес не найден» при отправке — почти всегда отсутствующая или неверная MX.
SPF — список серверов, которым вы разрешили отправлять письма от вашего домена. Без него любой может подделать обратный адрес.
DKIM — криптографическая подпись письма. Получатель сверяет её с публичным ключом в DNS и убеждается, что письмо не подменили по дороге.
DMARC — политика: что делать с письмами, которые не прошли проверки, и куда присылать отчёты.

Вместе они образуют контур доверия. Проверка MX, SPF, DKIM и DMARC занимает несколько минут и делается из терминала — а настройка почты домена без этих четырёх записей считается неполной, даже если сама почта уже работает. Ниже — все команды пошагово и с разбором вывода.

Как три записи работают вместе

Порядок проверки на стороне получателя выглядит так:

Отправитель соединяется с вашим почтовым сервером, определённым по MX (для входящих писем) или отправляет письмо со своего сервера (для ваших исходящих).
Получатель смотрит на домен в адресе From: и запрашивает TXT-запись с v=spf1 — сверяет IP отправителя со списком разрешённых.
Получатель находит в заголовках письма DKIM-Signature, вычисляет хеш и проверяет подпись публичным ключом из <selector>._domainkey.<домен>.
Затем запрашивает политику по адресу _dmarc.<домен> и применяет её: пропустить, пометить или отклонить письмо.

Ключевое понятие на этом этапе — выравнивание (alignment). DMARC проверяет не просто наличие SPF и DKIM, а совпадение доменов: домен из From: должен совпасть с доменом, который прошёл SPF (Return-Path), либо с доменом d= в DKIM-подписи. Отсюда два режима в записи DMARC: aspf/adkim со значением r (relaxed, поддомены считаются совпадающими) и s (strict, нужно точное совпадение).

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

Точки проверки письма: SPF, DKIM, DMARC

Проверка через dig: MX, SPF, DKIM, DMARC

dig показывает, что реально лежит в DNS, — в отличие от панели управления, где записи могут быть сохранены, но не применены. Ниже — все четыре запроса по порядку. Для наглядности считается, что домен — example.com.

Шаг 1. Куда приходит почта: dig MX

dig +short MX example.com

Ключ +short убирает служебную часть ответа и оставляет только значения.

Типичный рабочий вывод:

10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.

Как читать:

Число перед именем — приоритет. Чем меньше, тем раньше сервер будет использован. Приоритеты 10 и 20 означают: сначала пытаться доставить на сервер с 10, и только если он недоступен — на 20.
Точки в конце (aspmx.l.google.com.) — это полные имена (FQDN), так и должно быть. Если точки нет, DNS всё равно может достроить её, но лучше приводить запись к каноническому виду.
Все записи должны иметь разные приоритеты. Одинаковые значения — распространённая ошибка, при которой балансировка работает непредсказуемо.

Пустой вывод означает, что MX-записей нет: домен не принимает почту. Ситуация «нет MX» иногда бывает осознанной — например, домен отправительский. В таком случае принято ставить «нулевой MX», явно сообщающий, что почту принимать не нужно:

0 .

Точка — это корень DNS, служебное обозначение, означающее «не принимать почту».

Шаг 2. Разрешения отправителей: dig TXT с SPF

dig +short TXT example.com

В выводе ищите строку, начинающуюся с v=spf1:

"v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all"

Если записей несколько, они выводятся списком — помимо SPF, в домене обычно лежит ещё пара служебных TXT (например, верификационные токены сервисов). SPF — та, что начинается с v=spf1.

Разбор:

v=spf1 — версия и обязательный первый элемент. Только одна TXT-запись в домене может начинаться с v=spf1.
include:_spf.google.com — «разреши серверы, перечисленные в SPF этого домена». Каждый include: требует отдельного DNS-запроса — это важно, про лимит ниже.
ip4:203.0.113.10 — разрешение конкретного IPv4-адреса. Есть аналоги ip6: и диапазоны вида ip4:203.0.113.0/24.
a, mx — разрешить IP текущей A-записи домена или серверов из MX.
~all — квалификатор для всех, кто не попал в список:
- -all — fail, письмо считается не разрешённым (жёстко, но корректно, когда список полный);
- ~all — softfail, письмо принимается, но помечается как подозрительное;
- ?all — neutral, нейтрально: политику не навязываем;
- +all — разрешить всё. Это фактически отключённый SPF, и его стоит найти и убрать при первой же проверке.

Отдельно стоит проверить, не разрослась ли запись за пределы лимита. По спецификации SPF на обработку разрешено не более 10 DNS-запросов (include, a, mx, ptr, exists, redirect). При превышении получатель вернёт permerror, и все ваши письма разом потеряют защиту.

dig +short TXT example.com | tr -d '"' | tr ' ' '\n' | grep -Ec '^(include:|a|a:|mx|mx:|ptr|ptr:|exists:|exists:|redirect=)'

Команда разбивает строку по пробелам и считает механизмы, требующие обращения к DNS. Если результат близок к 10 или превышает его — часть include: нужно объединить или заменить на ip4:.

Шаг 3. Политика: dig TXT _dmarc.example.com

DMARC хранится по строго фиксированному имени — к домену добавляется префикс _dmarc:

dig +short TXT _dmarc.example.com

Рабочий вывод:

"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Разбор по тегам:

Тег	Что задаёт	Возможные значения
`v=DMARC1`	Версия. Обязательный первый тег, регистр важен	только `DMARC1`
`p`	Политику для писем, не прошедших проверку	`none`, `quarantine`, `reject`
`sp`	Отдельная политика для поддоменов	те же значения
`rua`	Адреса для сводных отчётов	`mailto:` через запятую
`ruf`	Адреса для отчётов о сбоях отдельных писем	`mailto:`
`pct`	Какую долю писем подчинять политике	1–100
`adkim`, `aspf`	Строгость выравнивания для DKIM и SPF	`r` (relaxed) или `s` (strict)
`fo`	Условия отправки отчётов о сбоях	`0`, `1`, `d`, `s`

Что здесь важно на практике:

p=none — режим наблюдения. Ничего не блокируется, но приходят отчёты. С него правильно начинать: он показывает, какие сервисы реально отправляют письма от вашего домена.
p=quarantine — подозрительные письма идут в спам.
p=reject — письма отклоняются. Это целевое состояние, но переходить к нему стоит только после того, как отчёты перестали показывать легитимные источники, не попавшие в SPF или DKIM.
Тег rua без указания адреса — бессмысленен: без отчётов вы не увидите, что настраивать.
По умолчанию sp наследует значение p, поэтому жёсткий p=reject автоматически распространяется и на поддомены — а это частая причина пропавших писем с адресов вида mail.example.com.

Если dig возвращает NXDOMAIN или пустоту — записи DMARC нет вообще, и получатели применяют собственные эвристики. Это не «нейтрально»: у крупных почтовых провайдеров такие письма чаще попадают в спам.

Шаг 4. Подпись: `dig TXT <selector>._domainkey.example.com`

DKIM-ключ лежит по адресу <селектор>._domainkey.<домен>. Селектор — это произвольное имя, которое выбирает почтовый провайдер или сервис рассылок; он виден в заголовке DKIM-Signature письма в поле s=.

Часто используемые селекторы по умолчанию — default, mail, dkim, selector1, s1, google. Приведённые ниже команды — не «магические»: если вы не знаете селектор, посмотрите его в панели провайдера или в исходнике любого полученного письма.

dig +short TXT default._domainkey.example.com

Если записи нет, dig вернёт пустой ответ или NXDOMAIN. Проверьте второй типичный селектор:

dig +short TXT mail._domainkey.example.com

Корректный ответ:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Разбор:

v=DKIM1 — версия записи.
k=rsa — тип ключа. Также встречаются k=ed25519.
p= — публичный ключ в base64. Это самая длинная часть записи.
p= без значения (пустой) — служебный способ отозвать ключ. Такой селектор считается недействительным, и подписи по нему не пройдут.

Две частые технические проблемы, которые видно прямо здесь:

Запись разрезана на несколько строк. TXT-запись ограничена 255 символами в одной строке, а RSA-ключ на 2048 бит длиннее. У некоторых провайдеров DNS вы видите результат как несколько кавычках подряд — при проверке их нужно мысленно склеить:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A" "MIIBCgKCAQEA..."

Если провайдер сохранил это как две отдельные TXT-записи вместо одной с несколькими строками, почтовые серверы прочитают только первую — и подпись не пройдёт никогда. Симптом: DKIM не проходит, а визуально запись «есть».

Ключ слишком короткий. Длину можно оценить по DER-представлению публичного ключа:

dig +short TXT default._domainkey.example.com | sed 's/.*p=//; s/".*//' | base64 -d 2>/dev/null | wc -c

RSA-ключ на 2048 бит даёт около 294 байта, на 1024 бита — около 162. Значение в районе 160 означает ключ 1024 бита: формально работает, но многие получатели такие подписи усиливают в фильтрации. Правильно перевыпустить ключ на 2048 бит и обновить публикацию с новым селектором.

Таблица: запись → что проверяет → типичная ошибка

Запись	Что проверяет	Типичная ошибка
`MX`	Куда доставлять входящую почту	Отсутствует или указывает на старый хост; одинаковые приоритеты; запись есть, но хост не резолвится
`TXT` с `v=spf1`	Какие серверы вправе отправлять письма от домена	Две и более SPF-записи в одном домене (гарантированный `permerror`); `+all` в конце; превышен лимит 10 DNS-запросов; не указан сторонний сервис рассылок
`<селектор>._domainkey` (`TXT`)	Подлинность подписи DKIM	Неверный или несуществующий селектор; ключ склеен в две отдельные `TXT`-записи вместо многострочной; селектор сменили у провайдера, а в DNS остался старый
`_dmarc` (`TXT`)	Политику для писем, не прошедших SPF/DKIM	Запись лежит не на `_dmarc.<домен>`, а в корне; сразу `p=reject` без периода наблюдения; `p=none` без `rua` — отчёты никуда не приходят; `sp` не задан, из-за чего политика накрывает поддомены
`TXT` с токеном верификации	Владение доменом для сторонних сервисов	Конфликтует с SPF при попытке «склеить всё в одну запись»
`PTR` / обратная зона	Соответствие IP и имени для отправляющего сервера	Не настроена у провайдера — часть получателей отклоняет соединение сразу

Диагностика: если почта уходит в спам или не доходит

Здесь пригодится не только DNS, но и общая проверка окружения домена. Порядок действий:

Проверьте MX извне. Если письма вам не приходят, а раньше приходили, — сравните текущий вывод dig MX с ожидаемым. Смена хостинга почты почти всегда означает, что . в конце записи забыли или указали новый хост с опечаткой.
Убедитесь, что SPF ровно один. Две записи v=spf1 в одном домене — фатальная ошибка: результат — permerror, и защита не работает вовсе. Часто возникает при переносе: старый провайдер оставил свою запись, новый добавил свою.
Пройдитесь по всем селекторам DKIM. Сервис рассылок и корпоративная почта обычно используют разные селекторы. Настроенный один не защищает письма, отправленные другим источником.
Сверьте выравнивание. Если DMARC в reject, а рассылка идёт с домена сервиса в Return-Path и без DKIM на вашем домене, письма будут отклонены. Решение — либо include: нужного сервиса в SPF, либо DKIM-ключ на своём домене.
Проверьте репутацию IP. Подписи и политики могут быть настроены идеально, но если IP отправляющего сервера в чёрном списке, часть получателей отклонит письмо ещё до проверки DKIM. Хорошая практика — периодически смотреть IP в проверке blacklist.
Смотрите заголовки полученного письма. Строки Authentication-Results, Received-SPF и dkim= в исходнике письма показывают, как именно получатель оценил ваше письмо, и это самый честный источник правды.

Быстрый способ пройти все пункты без терминала — проверка почтовых записей домена: она одним прогоном показывает состояние MX, SPF, DKIM и DMARC. Для контекста рядом стоит посмотреть полный набор записей домена через проверку DNS — так видно, нет ли дублирующихся TXT и не осталось ли записей старого провайдера.

Результат проверки почтовых записей

Пошаговая настройка: с чего начинать

Если записи только предстоит настроить, порядок имеет значение — он позволяет не потерять письма.

Шаг 1. MX

Возьмите у почтового провайдера список серверов и добавьте их как MX с разными приоритетами. Проверьте результат через dig +short MX <домен>: вывод должен совпасть с тем, что выдал провайдер.

Шаг 2. SPF

Соберите все источники, от имени которых уходят письма: корпоративная почта, рассылки, CRM, сервис транзакционных писем. Каждый добавляется либо как include:, либо как ip4:.

dig +short TXT example.com | grep spf1

Подпись ~all — нормальное стартовое значение. Переходить на -all стоит, когда вы уверены, что список источников полный и тестовые отправки проходят.

Шаг 3. DKIM

Провайдер выдаёт селектор и значение p= — их публикуют как одну TXT-запись на <селектор>._domainkey.<домен>. Здесь почти все ошибки связаны с копированием длинного значения: лишний пробел, обрезанный хвост, потерянные кавычки. После публикации подождите истечения TTL и проверьте dig — это единственный способ убедиться, что ключ виден снаружи, а не «сохранён в панели».

Шаг 4. DMARC

Начинайте с мягкой политики:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Адрес в rua должен реально принимать письма — на него придёт XML со сводками. Раз в неделю проверяйте отчёты и добавляйте пропущенные источники в SPF или DKIM.

Шаг 5. Ужесточение

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

Четыре шага настройки почтовых записей

Частые ошибки и их последствия

Симптом	Причина	Решение
Письма не приходят вообще	Нет `MX` или запись указывает на выключенный хост	Восстановить `MX`, сверить с данными провайдера
`SPF permerror` в заголовках	Две и более `v=spf1`-записи в домене	Оставить одну, объединив механизмы
Письма от рассылки уходят в спам, остальные проходят	Домена сервиса нет в SPF и нет DKIM на вашем домене	Добавить `include:` или опубликовать DKIM-запись сервиса
DKIM «настроен», но не проходит	Селектор неверный; ключ разрезан на две отдельные записи	Сверить `s=` из заголовка письма, перепубликовать одной многострочной `TXT`
DMARC-отчёты не приходят	В `rua` указан несуществующий или не принимающий ящик	Проверить ящик, указать рабочий адрес
После `p=reject` пропали письма с поддоменов	`sp` не задан, поэтому поддомены унаследовали жёсткую политику	Задать `sp=none` или настроить SPF/DKIM для поддоменов отдельно
Часть писем пропала после смены провайдера рассылок	В DNS остался старый селектор, а новый не опубликован	Опубликовать новый селектор, старый удалить после проверки
Всё настроено, но письма всё равно в спаме	Репутация IP, содержимое письма, отсутствие обратной зоны	Проверить IP в blacklist, настроить `PTR`, пересмотреть контент

Что проверять регулярно

DNS-записи не статичны: провайдер рассылок меняет селектор DKIM, при смене хостинга пропадают MX, а добрый коллега «оптимизирует» SPF, склеив его с верификационным токеном. Каждая такая правка тихо ломает доставку, а узнаёте вы об этом из жалоб клиентов через несколько дней.

Практичный набор для регулярной проверки:

MX — раз в месяц и обязательно после любых работ с почтой или доменом.
SPF — после каждой смены сервиса рассылок; отдельно держать в голове лимит 10 DNS-запросов, который со временем исчерпывается сам.
DKIM — перед крупными рассылками: подпись должна проходить, а селектор существовать.
DMARC — раз в месяц просматривать сводные отчёты, а после смены политики — еженедельно.
Blacklist — периодически, особенно если рассылки идут с собственного IP.

Если домен обслуживает несколько сервисов, удобнее ориентироваться на автоматическую проверку, а не на ручной прогон dig по каждому домену. UptimeChecker проверяет почтовые записи домена и DNS-конфигурацию по расписанию, так что расхождение видно раньше, чем о нём напишут получатели: начать можно с проверки MX, SPF, DKIM и DMARC, а рядом держать под наблюдением DNS-записи и репутацию IP — три проверки вместе покрывают и доставляемость, и корректность зоны.