EN
ПРОВЕРКА DNS

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

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

Все инструменты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструмент не подходит как единственный критерий готовности к массовому запуску. Если записи проходят, а письма не доходят или уходят в спам, нужен разбор связки домена, ящиков, базы и сценария отправки. Для такого случая подходит аудит аутрича и деливери.

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

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

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

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

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

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

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

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

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

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

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

Проверьте отправляющий контур до первой волны

Оставьте заявку на разбор. Мы сверим DNS, настройки ящиков и фактический маршрут тестовых писем, затем дадим список исправлений по приоритету.

Кейсы
24 часа
столько занимает ответ с расчётом по вашему сегменту