Как настроить SPF, DKIM и DMARC для домена интернет‑магазина — пошаговое руководство

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

Перед началом важно собрать доступы и информацию, чтобы не тормозить процесс в середине. Нужны права на управление DNS домена (панель регистратора или DNS‑провайдера), доступ к почтовому серверу или сервису рассылок, и логин в панели хостинга магазина. Если есть внешние почтовые провайдеры (SMTP, транзакционные сервисы), подготовьте их названия и данные интеграции.

Полезно заранее получить: 1) список систем, которые отправляют письма с домена (CMS, CRM, платёжные системы, сервисы доставки), 2) контактный email для получения отчетов DMARC (aggregate/forensic), 3) понимание, где генерируются DKIM‑ключи — на стороне почтового сервера или в панели почтового провайдера. Это предотвращает пропуск источников при настройке SPF.

Если у вас несколько субдоменов (например, shop.example.ru, payments.example.ru), решите, будете ли вы применять правила централизованно через основной домен или настраивать каждую зону отдельно. Принятие этого решения до начала позволяет прописать корректные селекторы DKIM и единый DMARC‑политик для домена.

• Доступ к DNS (регистратор или DNS‑панель)
• Доступ к почтовому серверу/провайдеру
• Перечень всех систем, отправляющих почту
• Email для получения DMARC‑отчетов

Коротко о том, зачем нужны SPF, DKIM и DMARC

SPF (Sender Policy Framework) — это способ указать, какие сервера имеют право отправлять почту от имени домена. SPF помогает почтовым серверам проверять, не подделан ли источник письма. Корректный SPF снижает риск того, что легитимные письма интернет‑магазина окажутся в спаме.

DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к исходящим письмам. Почтовые системы получают публичный ключ из DNS и сверяют подпись, подтверждая целостность и авторство письма. DKIM особенно полезен для транзакционных писем и массовых рассылок, где важно доказать, что письмо не изменено.

DMARC (Domain-based Message Authentication, Reporting & Conformance) связывает результаты SPF и DKIM с политикой домена: что делать с письмами, не прошедшими проверку. DMARC также позволяет получать отчёты о доставке и попытках подделки — это ключевой инструмент мониторинга безопасности почты магазина.

Шаг 1 — настройка SPF: конкретные действия

1) Соберите список всех IP, хостов и внешних сервисов, которые отправляют почту с домена. 2) В панели DNS создайте или отредактируйте TXT‑запись для домена с содержимым SPF. Типичная структура: v=spf1 <механизмы> -all. Используйте include для внешних сервисов и ip4/ip6 для собственных серверов.

При формировании записи избегайте дублирования include и следите за ограничением 10 DNS‑запросов в механизмах include/redirect. Если список длинный, объедините отправку через доверенный транзитный сервер или используйте синхронизацию с почтовым провайдером, чтобы уменьшить количество include.

После записи в DNS проверьте её синтаксис и распространение. Для проверки используйте nslookup/dig и онлайн‑проверки SPF. Отправьте тестовое письмо на внешние почтовые сервисы и изучите заголовки сообщения, чтобы убедиться, что проверка SPF проходит и что указанные источники действительно аутентифицируются.

Шаг 2 — настройка DKIM: генерация, публикация и проверка

DKIM требует двух частей: пары ключей и публикации публичного ключа в DNS. Сначала сгенерируйте RSA‑ключ (часто 2048 бит) или используйте рекомендации вашего почтового провайдера. При генерации определите selector — метку, которая будет частью имени TXT‑записи в DNS (например, mail2026._domainkey).

Публикуйте публичный ключ в TXT‑записи вида selector._domainkey.example.ru с содержимым v=DKIM1; k=rsa; p=<public_key>. Затем настройте почтовый сервер или сервис рассылок так, чтобы он подписывал исходящую почту этим селектором и закрытым ключом. Убедитесь, что для каждого отправляющего сервиса настроен свой селектор при необходимости.

Проверьте подпись, отправив тестовое письмо на аккаунт, где видны заголовки, или воспользуйтесь онлайн‑валидаторами DKIM. В заголовках ищите строку DKIM‑Signature и убедитесь, что проверка прошла успешно. Если подпись не проходит, проверьте совпадение selector, корректность публичного ключа в DNS и конфигурацию кодировки/перехода строк на сервере отправки.

Шаг 3 — настройка DMARC: политика и отчёты

DMARC задаётся в виде TXT‑записи _dmarc.example.ru и содержит политику (p=none/quarantine/reject) и адреса для отправки отчетов (rua, ruf). Начинайте с p=none, чтобы собирать отчёты и увидеть реальные случаи несовпадений SPF/DKIM без риска блокировки писем. Пример базовой записи: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.ru.

После периода мониторинга (несколько недель) анализируйте агрегированные отчёты, выявляйте легитимные источники, которые не проходят проверки, и корректируйте SPF/DKIM. Когда доля корректно подписанных писем стабилизируется, переходите к усилению политики: сначала quarantine, затем — при уверенности — reject.

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

Контрольные точки — что обязательно проверить перед переводом политики в reject

1) Все источники отправки перечислены в SPF и/или подписывают письма DKIM. Перед усилением политики убедитесь, что 95–99% транзакционной почты проходит хотя бы одну из проверок (SPF или DKIM). 2) Наличие и корректность DMARC‑отчётов — вы должны получать агрегированные L2‑отчёты на адрес, указанный в rua.

3) Тесты доставки: отправьте письма с каждого источника на разные почтовые провайдеры (gmail, yandex, mail.ru) и проверьте заголовки. 4) Проверьте SPF на превышение лимита DNS‑запросов и отсутствие синтаксических ошибок. 5) Убедитесь, что DKIM‑ключи не истекают и хранятся безопасно.

Выполнение этих контрольных точек снижает вероятность случайной блокировки важных писем — уведомлений о заказах, платёжных чеков и служебных сообщений. Только после прохождения всех пунктов можно безопасно ужесточать DMARC‑политику.

• Наличие TXT‑записей SPF и DMARC
• Рабочий DKIM‑подписанный поток писем
• Получаемые DMARC‑отчёты
• Тестовые отправки на основные почтовые провайдеры

Тестирование: инструменты и практики проверки

Для первичной проверки используйте локальные утилиты: dig и nslookup позволяют убедиться, что записи опубликованы и видны извне. Проверьте SPF‑TXT, selector._domainkey и _dmarc записи. Для долговременного мониторинга полезны онлайн‑сканеры и сервисы анализа DMARC‑отчётов, которые упрощают чтение агрегированных XML‑файлов.

Отправляйте тестовые письма с каждого отправляющего источника и изучайте заголовки у получателя. В заголовках ищите строки Authentication‑Results, SPF, DKIM‑Signature и DMARC. Это даст ясную картину, какие проверки проходят, а какие — нет. Для развёрнутого тестирования используйте аккаунты у нескольких провайдеров, чтобы увидеть возможные различия в обработке.

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

Запуск и наблюдение после перехода к строгой политике

После перевода DMARC в политику quarantine или reject начните активный мониторинг: проверяйте агрегированные отчёты ежедневно в первые недели и оперативно реагируйте на резкий рост отказов. Обратите внимание на ключевые транзакционные письма, чтобы они по‑прежнему доставлялись корректно, и будьте готовы временно ослабить политику в случае критических проблем.

Поддерживайте процедуру обработки отчётов: назначьте ответственного за анализ, настройте фильтрацию и хранение отчётов. Учитывайте нагрузку на почтовые провайдеры и требование к обработке большого объёма XML‑отчётов — в ряде случаев удобнее подключить специализированный сервис для парсинга DMARC.

Наконец, планируйте регулярные ревизии: пересмотрите SPF и DKIM при добавлении новых интеграций, меняйте DKIM‑ключи по политике безопасности и документируйте все изменения. Это уменьшит вероятность регресса и упростит восстановление при возникновении инцидентов.

Типичные ошибки и способы их избежать

Частая ошибка — пропуск источников отправки при составлении SPF. Результат — легитимные письма не проходят проверку. Регулярно актуализируйте список отправителей и при добавлении новых сервисов проверяйте их включение в SPF или наличие DKIM‑подписей.

Другой распространённый просчёт — превышение лимита DNS‑запросов в SPF. Чтобы избежать этого, минимизируйте число include, сжмите список IP‑адресов и при необходимости используйте сервисы, которые агрегируют отправку. Ошибка в синтаксисе TXT‑записей тоже приводит к полному провалу проверок — всегда проверяйте записи через dig/nslookup и валидаторы.

Наконец, многие игнорируют DMARC‑отчёты, считая их шумом. Это лишает вас информации о попытках подделки и проблемах доставки. Настройте автоматическую обработку и выделите ответственного за анализ, чтобы своевременно реагировать и корректировать конфигурацию.

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