# Проверка SPF, DKIM и DMARC домена

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

## Что именно сверяет проверка домена для рассылки

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

| Проверка | Что ищем | Что означает сбой |
|---|---|---|
| SPF | Одна TXT-запись с разрешёнными сервисами | Сервер-отправитель не указан или запись конфликтует |
| DKIM | Публичный ключ по селектору | Подпись письма нельзя подтвердить |
| DMARC | Политика и адрес для отчётов при необходимости | Домен не сообщает, как обрабатывать неподтверждённое письмо |

Проверка читает опубликованные данные, а не настройки внутри почтового кабинета. Поэтому запись может выглядеть верно, но письмо всё равно не подписываться: например, в почтовом сервисе DKIM ещё не активировали для конкретного ящика. Порядок настройки и сверки собран в [гайде по SPF, DKIM и DMARC](/gaydy/spf-dkim-dmarc-nastroyka/).

## Как читать результат SPF без ложного спокойствия

SPF отвечает на один вопрос: разрешил ли владелец домена этому почтовому сервису отправлять письма. Рабочая запись обычно начинается с `v=spf1`, перечисляет разрешённые механизмы и заканчивается политикой, часто `-all` или `~all`. Две отдельные SPF TXT-записи для одного домена — ошибка: получающий сервер может вернуть неопределённый результат.

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

> Слишком длинная SPF-цепочка с множеством вложенных `include` тоже рискованна: сервер ограничивает число DNS-запросов при проверке. Инструмент укажет на сложную запись, но решить её можно только после инвентаризации сервисов.

## Зачем DKIM нужен, если SPF уже проходит

DKIM добавляет к письму криптографическую подпись. Получатель берёт публичный ключ из DNS и сверяет, что существенные части письма не были изменены после отправки. Это отдельная проверка: SPF привязан к источнику отправки, а DKIM — к подписи и домену, указанному в ней.

В результате важны селектор и ключ. Если селектор в заголовке письма не совпадает с поддоменом DNS или ключ опубликован с ошибкой, подпись не пройдёт. После публикации записи отправьте контрольное письмо на внешний адрес и посмотрите технические заголовки: там должна быть строка `dkim=pass`, а не только наличие записи в DNS.

Если нужна отдельная проверка инфраструктуры до кампании, её проводят вместе с [валидацией и очисткой базы](/uslugi/validaciya-bazy/): чистый список адресов не компенсирует неверную подпись домена, но снижает число лишних отказов.

## Как DMARC связывает домен в поле «От» и проверки

DMARC смотрит не просто на прохождение SPF или DKIM. Он сопоставляет домен из видимого получателю поля «От» с доменом, который прошёл SPF либо DKIM. Это называется выравниванием. Письмо может иметь `spf=pass`, но не пройти DMARC, если проверенный домен не связан с адресом отправителя.

1. Начните с записи DMARC в режиме наблюдения: она собирает сведения, не требуя отклонять письма.
2. Проверьте контрольные отправки со всех используемых сервисов и найдите источники, которые не выровнены.
3. Только после исправлений ужесточайте политику, если это требуется вашей схеме почты.

Пример ошибки: в поле «От» стоит `name@company.ru`, а сервис подписывает письмо доменом собственной платформы. ЛПР видит ваше имя, однако сервер получателя не может связать подпись с `company.ru`. Разбор терминов есть в статьях [SPF](/slovar/spf/), [DKIM](/slovar/dkim/) и [DMARC](/slovar/dmarc/).

## Где проверка записей не сработает

Проверка DNS не измеряет репутацию домена и IP, содержимое письма, жалобы получателей, качество списка или реальное попадание во «Входящие». Она также не увидит закрытые настройки сервиса: включена ли подпись для конкретного ящика, какой адрес использован в Return-Path и что меняет платформа при отправке.

Инструмент не подходит как единственный критерий готовности к массовому запуску. Если записи проходят, а письма не доходят или уходят в спам, нужен разбор связки домена, ящиков, базы и сценария отправки. Для такого случая подходит [аудит аутрича и деливери](/uslugi/audit-autricha/).

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

**Можно ли отправлять письма без DMARC?**

Технически письмо может быть доставлено и без DMARC. Но домен не публикует правило обработки неподтверждённых сообщений, а вы не получаете полноценной связки проверок SPF и DKIM.

**Почему SPF найден, но результат всё равно с ошибкой?**

Частая причина — несколько SPF-записей, неверный синтаксис или неучтённый сервис отправки. Ещё один вариант — превышение допустимого числа DNS-запросов через цепочки include.

**Нужно ли создавать DKIM самостоятельно?**

Обычно ключ генерирует почтовый провайдер, а вы публикуете выданную TXT-запись в DNS. Затем важно включить подпись в самом сервисе и проверить заголовки тестового письма.

**Когда изменения DNS станут видны?**

Это зависит от TTL записи и обновления DNS-кэшей. Не считайте настройку завершённой, пока публичная проверка не видит новую запись, а тестовое письмо не показывает успешные проверки.

**Достаточно ли настроить записи на основном сайте компании?**

Записи на основном домене не заменяют настройку домена, с которого реально идут письма. Проверять нужно именно домен в адресе отправителя и схему подписи используемого почтового сервиса.

---
Источник: https://ot9.ru/instrumenty/proverka-dns/ · Отряд 9 (КАП Групп) · обновлено 2026-08-09