Настройка SPF, DKIM и DMARC

Если вы отправляете email-рассылки, транзакционные письма или уведомления со своего домена, необходимо правильно настроить его аутентификацию.

Основные механизмы — SPF, DKIM и DMARC.

В отдельном материале мы подробно разобрали, что такое SPF, DKIM и DMARC и как они работают. Здесь сосредоточимся именно на практике: где взять необходимые записи, как добавить их в DNS, что проверять после настройки и какие ошибки встречаются чаще всего.

Общий процесс выглядит так:

определить источники отправки → проверить текущий DNS → настроить SPF → подключить DKIM → добавить DMARC → отправить тестовое письмо → проверить реальные результаты аутентификации.

Важно: значения DNS-записей в этой инструкции приведены только для объяснения структуры. Для реальной настройки используйте данные вашего почтового сервиса или платформы email-рассылок.

Что нужно подготовить перед настройкой

Не начинайте с копирования SPF или DMARC из случайной инструкции.

Сначала разберитесь, кто вообще отправляет email от имени вашего домена.

Например, компания использует домен:

company.ru

Письма от него могут отправлять:

• корпоративная почта;
• сервис email-рассылок;
• CRM;
• интернет-магазин;
• сайт;
• helpdesk;
• система регистрации;
• SMTP-сервис;
• API для транзакционных сообщений.

Все эти источники необходимо учитывать.

Если забыть хотя бы одну рабочую систему, после ужесточения DMARC часть собственных писем компании может перестать нормально доставляться.

Шаг 1. Определите, где управляется DNS домена

SPF, DKIM и DMARC добавляются в DNS-зону домена.

При этом регистратор, хостинг и DNS-провайдер могут быть разными компаниями.

Например:

• домен куплен у регистратора;
• сайт находится на отдельном хостинге;
• DNS обслуживает Cloudflare или другой сервис.

Редактировать записи нужно там, где находятся авторитетные DNS-серверы домена.

Как понять, где расположен DNS

Посмотрите NS-записи домена.

Они могут выглядеть примерно так:

ns1.provider.ru

ns2.provider.ru

Именно сервис, которому принадлежат эти NS, обычно управляет DNS-зоной.

Если вы добавите SPF в панели регистратора, но DNS фактически обслуживается другим провайдером, новая запись не появится в интернете.

Это одна из самых частых причин сообщения:

DNS-запись не найдена.

Шаг 2. Сделайте инвентаризацию существующих записей

Перед изменениями посмотрите, что уже опубликовано.

Особенно интересуют TXT и CNAME.

Проверьте:

• существует ли SPF;
• есть ли DKIM;
• существует ли _dmarc;
• какие selectors используются DKIM;
• присутствуют ли записи старых сервисов рассылок.

Не удаляйте неизвестную запись только потому, что не знаете её назначения.

Она может принадлежать:

• корпоративной почте;
• CRM;
• предыдущему SMTP;
• сайту;
• службе поддержки.

Сначала выясните её назначение.

Шаг 3. Настройте SPF

SPF указывает, какой инфраструктуре разрешено отправлять почту для домена.

Пример структуры записи:

v=spf1 include:_spf.example-service.ru ~all

Здесь:

• v=spf1 — версия SPF;
• include — разрешённая внешняя инфраструктура;
• ~all — правило для остальных источников.

Это не готовая запись для использования.

Ваш сервис должен предоставить собственное значение.

Если SPF уже существует

Это очень важный случай.

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

v=spf1 include:_spf.mail-provider.ru ~all

После подключения сервиса рассылок он предлагает ещё один источник.

Нельзя просто создать вторую TXT-запись:

v=spf1 include:_spf.email-service.ru ~all

В результате у одного домена окажутся две независимые SPF-политики.

Вместо этого разрешённые источники нужно корректно объединить в одну запись.

Условно:

v=spf1 include:_spf.mail-provider.ru include:_spf.email-service.ru ~all

Конкретная конфигурация зависит от ваших сервисов.

Почему несколько SPF-записей — ошибка

Принимающий сервер ожидает одну SPF-политику.

Если обнаруживается несколько SPF-записей, проверка может завершиться permanent error.

То есть даже если каждая запись сама по себе выглядит корректно, вся конфигурация становится неправильной.

Поэтому первое правило настройки SPF:

Для одного домена должна существовать одна согласованная SPF-политика.

Какие механизмы могут встречаться в SPF

Кроме include, можно увидеть:

ip4

ip6

a

mx

redirect

all

Например:

ip4:192.0.2.10

означает разрешение конкретного IPv4-адреса.

Но не добавляйте IP вручную, если сервис рекомендует использовать include. Инфраструктура платформы может меняться.

Следите за количеством DNS lookup

SPF имеет ограничение на количество определённых DNS-запросов во время проверки.

Если политика разрастается до большого количества вложенных include, a, mx и других механизмов, SPF может начать завершаться ошибкой.

Это особенно характерно для компаний, которые годами подключали новые сервисы и никогда не удаляли старые.

Поэтому периодически полезно пересматривать SPF и удалять действительно неиспользуемые разрешения.

Шаг 4. Сохраните SPF и проверьте DNS

После изменения записи дождитесь её публикации.

Проверьте, что внешний DNS-запрос действительно возвращает ожидаемую SPF-политику.

Обратите внимание:

• запись начинается с v=spf1;
• она одна;
• все используемые сервисы учтены;
• нет лишних кавычек или ошибочно повторённого домена;
• значение опубликовано именно на нужном домене.

Но наличие SPF в DNS ещё не означает, что реальное письмо проходит проверку.

Это проверим позже.

Шаг 5. Настройте DKIM

Следующий этап — DKIM.

В отличие от SPF, здесь сервис отправки обычно предоставляет отдельный selector и DNS-запись.

Например:

qwerty._domainkey.company.ru

Сервис может попросить создать:

• TXT с публичным ключом;
• либо CNAME на свою инфраструктуру.

Используйте именно тот тип записи, который указан в инструкции платформы.

Что такое selector

Selector позволяет одному домену использовать несколько DKIM-ключей.

Например:

corporate._domainkey.company.ru

может относиться к корпоративной почте,

а:

newsletter._domainkey.company.ru

— к сервису email-рассылок.

Поэтому наличие нескольких DKIM-записей для одного домена является нормальной ситуацией.

В отличие от SPF, здесь несколько записей не создают проблему, если у них разные selectors.

Как правильно заполнить имя DKIM-записи

Предположим, сервис показывает:

newsletter._domainkey.company.ru

Но DNS-панель автоматически добавляет .company.ru.

Тогда в поле «Имя» может потребоваться указать только:

newsletter._domainkey

Если написать полный адрес, итоговая запись может превратиться в:

newsletter._domainkey.company.ru.company.ru

Сервис её не найдёт.

Поэтому после сохранения проверяйте итоговое DNS-имя, а не только то, что отображалось в форме.

TXT или CNAME для DKIM

Оба варианта нормальны.

TXT

В DNS непосредственно публикуется открытый DKIM-ключ.

CNAME

Ваш selector указывает на DNS сервиса отправки.

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

Не преобразовывайте CNAME в TXT самостоятельно и наоборот.

Используйте формат, который предоставляет ваш сервис.

Шаг 6. Проверьте DKIM

После публикации DKIM вернитесь в сервис рассылок.

Если есть кнопка:

Проверить

или:

Verify

запустите проверку.

Но, как и со SPF, нам важно убедиться не только в существовании записи.

После настройки сервис должен реально подписывать отправляемые сообщения соответствующим DKIM-ключом.

Это проверяется по заголовкам тестового письма.

Шаг 7. Настройте DMARC

DMARC публикуется на специальном поддомене:

_dmarc.company.ru

Базовая запись может выглядеть условно так:

v=DMARC1; p=none;

где:

• v=DMARC1 — версия;
• p=none — политика мониторинга.

Если DMARC раньше не использовался, начинать обычно разумнее с наблюдения, а не с немедленной блокировки.

Почему не стоит сразу ставить p=reject

Политика:

p=reject

рекомендует принимающим серверам отклонять письма, которые не проходят DMARC.

Это полезная защита, но только после того, как вы уверены в своей инфраструктуре.

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

• Google Workspace или другую корпоративную почту;
• CRM;
• QWERTYMAIL;
• сайт;
• helpdesk.

Три системы настроены правильно, а четвёртая отправляет письма без alignment.

После включения строгой политики именно легитимные письма четвёртой системы могут начать блокироваться.

Поэтому нормальный процесс выглядит так:

none → анализ → исправление → quarantine → анализ → reject

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

Как добавить отчёты DMARC

Для агрегированных отчётов используется параметр rua.

Условный пример:

v=DMARC1; p=none; rua=mailto:dmarc@company.ru

Почтовые провайдеры могут отправлять на этот адрес агрегированную информацию о результатах DMARC.

По ней можно увидеть:

• кто отправляет почту от имени домена;
• какие IP используются;
• где проходит SPF;
• где проходит DKIM;
• где нарушается alignment;
• какие неизвестные источники появляются.

Для крупной инфраструктуры такие отчёты особенно полезны.

Шаг 8. Проверьте DMARC alignment

Это принципиальный этап.

Допустим, письмо имеет:

From: newsletter@company.ru

SPF прошёл успешно для технического домена:

bounce.email-platform.ru

а DKIM подписан:

d=company.ru

В таком случае DMARC может пройти благодаря DKIM alignment.

DMARC не требует одновременно aligned SPF и aligned DKIM.

Достаточно, чтобы хотя бы один из механизмов успешно прошёл проверку и соответствовал домену From.

Подробнее сам принцип мы разобрали в статье «SPF, DKIM и DMARC: что это и зачем нужны для email-рассылок».

Шаг 9. Отправьте реальное тестовое письмо

Это самая важная проверка всей настройки.

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

Например:

• через сервис массовой отправки;
• через SMTP;
• через API;
• через CRM.

Не проверяйте только DNS.

Нам нужен результат реального сообщения.

Что искать в заголовках письма

Откройте исходный код или технические заголовки сообщения.

Ищите результаты аутентификации:

spf=pass

dkim=pass

dmarc=pass

Дополнительно посмотрите:

• домен MAIL FROM;
• DKIM d=;
• selector;
• From;
• Return-Path;
• Authentication-Results.

Цель — не просто получить три слова pass, а убедиться, что аутентификация действительно относится к ожидаемому домену.

SPF pass, но DMARC fail — почему

Это вполне возможно.

Например:

From:

newsletter@company.ru

SPF проходит для:

mailer.external-service.ru

Но эти домены не aligned.

Если DKIM тоже не соответствует company.ru, DMARC получит fail.

Поэтому:

SPF pass ≠ автоматический DMARC pass.

DKIM pass, но DMARC fail

Причина похожая.

DKIM может успешно подтвердить подпись:

d=external-service.ru

но From указывает:

company.ru

DKIM технически исправен, однако alignment отсутствует.

В таком случае для DMARC понадобится либо aligned DKIM, либо aligned SPF.

Шаг 10. Проведите spam test

После настройки аутентификации полезно проверить письмо целиком.

Отдельная инструкция:

Как проверить email-письмо на спам перед рассылкой.

Тест помогает увидеть:

• SPF;
• DKIM;
• DMARC;
• технические заголовки;
• часть репутационных сигналов;
• потенциальные проблемы письма.

Но хороший результат spam-test также не является гарантией попадания каждого сообщения во «Входящие».

Шаг 11. Проверьте репутацию домена и IP

Если техническая аутентификация проходит, но доставка остаётся плохой, переходите к репутации.

Полезные материалы:

• Что такое Postmaster и зачем он нужен отправителю
• Как проверить домен и IP в чёрных списках email
• Почему письма попадают в спам

SPF, DKIM и DMARC — фундамент, но не вся система доставляемости.

Шаг 12. Проверьте качество базы

Даже идеально настроенный домен не спасёт рассылку по плохой базе.

Если значительная часть адресов:

• не существует;
• давно не используется;
• содержит ошибки;
• была собрана много лет назад,

будет расти количество bounce.

Если база давно не использовалась, перед крупной отправкой можно воспользоваться валидатором email-адресов QWERTYMAIL.

А разницу между постоянными и временными ошибками доставки подробно разбираем в статье про hard bounce и soft bounce.

Частые ошибки SPF

Создание второй SPF-записи

Нужно расширять существующую политику, а не создавать новую независимую.

Старые include

Компания больше не пользуется сервисом, но он годами остаётся разрешённым в SPF.

Ошибка в домене include

Одна неправильная буква делает механизм бесполезным.

Слишком сложная политика

Большое количество вложенных DNS lookup может привести к ошибке проверки.

Частые ошибки DKIM

Неправильный selector

Сервис подписывает одним selector, а в DNS опубликован другой.

Домен указан дважды

DNS-панель автоматически дописала основной домен.

TXT скопирован не полностью

Особенно часто это происходит с длинными DKIM-ключами.

DKIM существует в DNS, но сервис не подписывает им письма

Наличие публичного ключа — только половина настройки.

Нужно проверить реальный DKIM-Signature сообщения.

Частые ошибки DMARC

Сразу установлен reject

При этом часть легитимных источников ещё не настроена.

Не проверяется alignment

SPF и DKIM показывают pass, но принадлежат другим техническим доменам.

DMARC добавлен не на _dmarc

Запись опубликована на неправильном имени.

Слишком быстро меняется политика

Не успели накопить и проанализировать данные, но уже включили строгую обработку.

Домен верифицирован — значит всё настроено?

Не обязательно.

Верификация домена отправителя и корректная аутентификация реальных сообщений — связанные, но не полностью одинаковые вещи.

Сервис может показать:

Домен подтверждён

потому что увидел нужную DNS-запись.

Но после этого всё равно стоит проверить реальное письмо:

spf=pass

dkim=pass

dmarc=pass

Это намного надёжнее, чем ориентироваться только на статус в интерфейсе.

Что делать, если пришёл Mailer-Daemon после настройки

Если письмо возвращается с ошибкой доставки, смотрите SMTP-ответ.

Например:

550 5.1.1

может говорить о несуществующем адресе,

а:

554 5.7.1

— о политике безопасности или антиспам-ограничении.

Сам SPF/DKIM/DMARC не объясняет любую ошибку доставки.

Для диагностики используйте материал «Mailer-Daemon: что это за письмо и почему оно приходит».

SPF, DKIM и DMARC при использовании SMTP/API

Если сайт, приложение или CRM отправляет письма автоматически, особенно важно использовать корректно настроенный домен.

Через SMTP/API могут отправляться:

• регистрационные письма;
• коды подтверждения;
• восстановление пароля;
• чеки;
• уведомления;
• статусы заказов.

В QWERTYMAIL для программной отправки можно использовать SMTP и REST API.

Перед запуском продакшн-отправки проверьте реальный Authentication-Results именно у сообщений, отправленных через эту инфраструктуру.

Нужен ли отдельный поддомен

Не обязательно.

Можно использовать основной домен:

company.ru

Но при большом количестве независимых потоков иногда удобно разделять инфраструктуру.

Например:

marketing.company.ru

для маркетинга,

notify.company.ru

для уведомлений.

Это позволяет яснее разделять технические потоки и управлять репутацией.

Но отдельный поддомен не является магическим способом улучшить доставляемость.

Для него всё равно нужны:

• аутентификация;
• качественная база;
• нормальная репутация;
• аккуратный объём отправки.

Нужно ли прогревать новый домен

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

Резкое увеличение активности может выглядеть подозрительно для принимающих систем.

Лучше увеличивать объём постепенно и следить за:

• bounce;
• жалобами;
• Postmaster;
• доставляемостью;
• вовлечённостью получателей.

Аутентификация делает отправителя технически понятным, но репутация формируется со временем.

Чек-лист настройки SPF, DKIM и DMARC

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

• определены все системы отправки;
• вы редактируете правильную DNS-зону;
• SPF существует в одном экземпляре;
• SPF содержит необходимые источники;
• нет лишних старых разрешений;
• DKIM-запись опубликована;
• selector корректный;
• сервис действительно подписывает письма DKIM;
• DMARC опубликован на _dmarc;
• выбран подходящий режим DMARC;
• проверен alignment;
• тестовое сообщение отправлено;
• SPF = pass;
• DKIM = pass;
• DMARC = pass;
• проведён spam-test;
• контролируются bounce;
• проверяется репутация;
• база актуальна.

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

В каком порядке настраивать SPF, DKIM и DMARC?

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

Можно ли настроить только DKIM?

Для полноценной современной инфраструктуры лучше использовать SPF, DKIM и DMARC вместе.

Нужно ли менять MX-записи?

Обычно нет.

MX отвечает за приём входящей почты домена.

Подключение сервиса исходящих рассылок обычно не требует переноса корпоративной входящей почты, если сам сервис прямо не говорит обратного.

Можно ли использовать SPF из чужой инструкции?

Нет.

SPF должен соответствовать именно вашим источникам отправки.

Как быстро обновляется DNS?

Иногда изменения становятся видимыми почти сразу, иногда требуется больше времени. Всё зависит от провайдера, TTL и кеширования.

Что важнее — SPF или DKIM?

Они выполняют разные функции.

Для хорошей инфраструктуры не нужно выбирать один механизм вместо другого.

Нужно ли сразу устанавливать DMARC p=reject?

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

Что делать, если SPF и DKIM pass, а письмо всё равно в спаме?

Переходить к другим факторам: репутации, жалобам, базе, содержанию, истории отправки и поведению аудитории.

Подробнее — в статье «Почему письма попадают в спам и что с этим делать».

Связанные материалы

Для полной настройки инфраструктуры используйте весь кластер:

• SPF, DKIM и DMARC: что это и как они работают
• Как верифицировать домен отправителя
• Почему письма попадают в спам
• Как проверить письмо на спам
• Hard bounce и soft bounce
• Mailer-Daemon: причины ошибок доставки
• Что такое Postmaster
• Проверка домена и IP в чёрных списках
• SMTP и API QWERTYMAIL
• Валидатор email-адресов

Главное

Правильная настройка SPF, DKIM и DMARC начинается не с DNS-записи, а с понимания всей инфраструктуры отправителя.

Надёжный порядок такой:

определить источники → проверить DNS → настроить SPF → подключить DKIM → настроить DMARC → проверить реальное письмо → контролировать репутацию и bounce.

Не ограничивайтесь зелёным статусом «Домен подтверждён» в сервисе.

Главная техническая проверка — это реальное отправленное сообщение, в котором вы видите:

spf=pass

dkim=pass

dmarc=pass

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