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

Настройка SPF, DKIM и DMARC помогает почтовому серверу получателя проверить, вправе ли отправитель использовать домен вашей компании. Для бизнеса это касается обычной переписки, уведомлений о заказах, писем из CRM и восстановления доступа. Ошибка в одной записи способна затронуть несколько систем, даже если сотрудники продолжают успешно отправлять письма из веб-почты.

Рабочий результат — не три зелёные отметки в DNS-проверке. Нужно учесть все законные источники, включить подпись там, где создаются письма, проверить реальные сообщения и только затем выбирать политику обработки нарушений. Разберём эту последовательность на понятных примерах. Домены example.com, example.net и адреса в примерах учебные; подставлять их в рабочую конфигурацию нельзя.

SPF, DKIM и DMARC: что проверяет каждый механизм

У письма есть видимый адрес From, технический отправитель в SMTP-конверте и домен подписи. Они могут различаться. Поэтому задача администратора — проверить не только успешность отдельных механизмов, но и их связь с доменом, который видит адресат.

Механизм	Что проверяется	Что настраивает владелец
SPF	Разрешён ли отправляющий сервер для проверяемого домена SMTP-конверта	Единая политика разрешённых источников в DNS
DKIM	Действительна ли подпись сообщения от указанного домена	Подписание у отправителя и публикация публичного ключа
DMARC	Есть ли успешный SPF или DKIM, согласованный с доменом видимого From	Политика домена, режим выравнивания и получение отчётов

Документация Microsoft по DMARC подчёркивает различие MAIL FROM и видимого From: успешная аутентификация технического домена сама по себе не подтверждает домен автора. При этом для DMARC достаточно одного успешно прошедшего и выровненного механизма — SPF или DKIM.

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

Шаг 1. Составьте карту отправителей и сохраните текущие записи

Начните с перечня систем, которые отправляют письма от имени компании. Обычно это не только основной почтовый сервис: сайт, CRM, платформа рассылок, бухгалтерия и служба поддержки могут использовать самостоятельные маршруты. Для каждого источника найдите владельца настройки и пример сообщения, полученного внешним адресатом.

• Запишите назначение писем и ожидаемый домен From.
• Определите домен MAIL FROM и домен DKIM-подписи, если она есть.
• Уточните, кто управляет исходящим сервером и его аутентификацией.
• Проверьте отдельные поддомены, старые интеграции и редко запускаемые уведомления.
• Отметьте пересылки, почтовые группы и промежуточные шлюзы.

Не ограничивайтесь письмом директора. Подтверждение заказа может уходить через другой сервис, а ежемесячный счёт — через систему, о которой не знает веб-разработчик. Карта должна отражать реальные потоки и ответственных за них. Неизвестный источник сначала исследуют; разрешать его только ради красивого отчёта нельзя.

Определите действующие авторитетные DNS-серверы. Именно они хранят записи, которыми пользуется внешняя инфраструктура; это поясняет документация Cloudflare о nameservers. Панель регистратора и фактический DNS-хостинг могут находиться у разных компаний. Правка в неиспользуемой зоне не изменит проверку писем.

Сохраните исходные значения TXT и CNAME, их имена и TTL, а также настройки подписи у провайдеров. Назначьте человека, который сможет вернуть предыдущую конфигурацию. Сохраняйте действующие записи сайта и основного приёма почты. Дополнительные записи технического поддомена MAIL FROM добавляйте по инструкции отправителя: например, Amazon SES требует для него отдельную MX-запись. Это не означает переноса основных ящиков.

Шаг 2. Соберите одну корректную SPF-запись

Выберите доменное имя, для которого нужна политика

SPF использует домен MAIL FROM из SMTP-конверта. У полученного сообщения этот технический адрес обычно виден в Return-Path. SPF также может проверять HELO/EHLO; при пустом MAIL FROM применяется определение идентификатора через HELO, описанное в RFC 7208. Домен обычного видимого From автоматически не становится доменом SPF-проверки.

Если сервис отправляет через собственный домен возвратов, добавление его в SPF основного домена компании может не повлиять на проверяемую идентичность. Выясните, поддерживает ли провайдер собственный MAIL FROM или return-path для клиента. Настройку такого поддомена выполняйте по инструкции конкретного сервиса.

Объедините законные источники

Для одного доменного имени публикуют одну SPF-политику. Несколько самостоятельных TXT-записей, начинающихся с v=spf1, создают ошибку. Правило и необходимость учитывать дополнительные отправители разобраны в инструкции Microsoft по SPF. Другие TXT-записи, например подтверждения сервисов, удалять не требуется.

Учебный пример для условного собственного сервера и условного провайдера:

v=spf1 ip4:192.0.2.10 include:_spf.provider.example.net -all

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

Не заменяйте существующую политику готовой строкой для одного сервиса, пока не сверили карту отправителей. Например, Яндекс отдельно показывает вариант для своей почты и вариант с дополнительными серверами. Механизмы include и модификатор redirect не следует механически склеивать как список независимых настроек.

Проверьте ограничения и завершение политики

SPF ограничивает десятью число вызывающих DNS-поиск механизмов и модификаторов, учитываемых при вычислении результата: в том числе include, a, mx, exists, ptr и redirect. Вложенные политики тоже учитываются. Это не равнозначно подсчёту всех сетевых DNS-запросов; ip4 и ip6 этот лимит не расходуют. Правило определено в разделе 4.6.4 RFC 7208.

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

Завершение -all даёт SPF fail для неразрешённого источника, ~all — softfail; ни одно не означает успешную аутентификацию этого источника. Выбор согласуют с фактическими отправителями и правилами принимающих систем. +all разрешает любой источник и уничтожает смысл ограничения.

Отдельные строки внутри одной TXT-записи могут объединяться в единое значение. Это отличается от нескольких SPF-записей. Лимит 255 октетов относится к одной строке TXT, а не автоматически ко всей SPF-политике; правила объединения описаны в разделе 3.3 RFC 7208. Проверяйте опубликованный результат, а не только вид поля в панели.

Шаг 3. Настройте DKIM у каждого сервиса отправки

Получите ключ и селектор у отправителя

DKIM использует пару ключей: закрытый остаётся у системы подписания, публичный доступен через DNS. В заголовке DKIM-Signature параметр d= задаёт домен подписи, а s= — селектор. По ним получатель находит ключ. Механизм описан в RFC 6376.

Для учебных d=example.com и s=mail2026 имя поиска будет mail2026._domainkey.example.com. Само слово mail2026 не является обязательным: используйте селектор своего сервиса. При нескольких отправителях у одного домена могут существовать разные селекторы; не заменяйте ключ CRM ключом основного почтового провайдера.

Для RSA ориентируйтесь на ключи не короче 2048 бит, когда это поддерживает выбранная инфраструктура; рекомендация приведена в RFC 8301. Не сокращайте опубликованный ключ вручную. Если панель ограничивает длину значения, выясните поддерживаемый способ размещения длинной TXT-записи.

Опубликуйте данные и включите подписывание

Возьмите имя, тип и значение записи из собственного кабинета. В Яндекс 360 используется TXT с публичным ключом. У других решений возможна делегация через CNAME: например, Amazon SES различает записи для Easy DKIM и BYODKIM. Копируйте весь набор, выданный именно вашей настройке.

Проверьте, добавляет ли DNS-панель доменный суффикс автоматически. Ошибка вроде повторного example.com.example.com делает запись недоступной по ожидаемому имени. Закрытый ключ в DNS не публикуют, в переписку со специалистом его тоже не прикладывают.

После появления записи завершите активацию у отправителя. Например, в Google Workspace публикация ключа и включение аутентификации — отдельные шаги. Затем отправьте контрольное сообщение через этот сервис и проверьте результат у внешнего получателя. Наличие ключа без реальной подписи не завершает настройку.

Шаг 4. Проверьте выравнивание доменов

Выравнивание, или alignment, связывает подтверждённый домен SPF либо DKIM с доменом видимого From. В relaxed-режиме допускается общий организационный домен, в strict требуется точное совпадение. Организационный домен определяется правилами DMARC, а не просто последними двумя частями любого имени.

Учебный пример: From использует example.com, MAIL FROM — bounce.example.com, подпись — d=example.com. При общем организационном домене SPF может соответствовать relaxed-режиму, а подпись — strict. Адрес bounce@provider.example.net не выравнивается с From sales@example.com только из-за успешного SPF.

Таблица ниже предполагает, что для сообщения найдена корректная применимая политика DMARC.

SPF	DKIM	Результат DMARC
Pass и домен выровнен	Fail или отсутствует	Pass
Fail или домен не выровнен	Pass и домен выровнен	Pass
Pass, но чужой домен	Pass, но чужой домен	Fail
Ни один механизм не дал выровненный pass	Нет подходящей успешной подписи	Fail

Не включайте aspf=s и adkim=s автоматически ради ощущения большей строгости. Сначала проверьте домены всех потоков и полномочия владельцев поддоменов. Настройка должна соответствовать архитектуре компании; иначе законный сервис с техническим поддоменом перестанет проходить нужную проверку.

Учебный пример: письма сотрудников проходят, письма CRM — нет

Предположим, компания использует example.com. Письма менеджера подписываются этим доменом и проходят DMARC. У CRM видимый From тоже относится к example.com, но MAIL FROM и DKIM-подпись используют mailer.example.net. У получателя оба отдельных результата — pass, а DMARC — fail. Это согласуется с отсутствием выравнивания: подтверждён домен технического сервиса, а не домен видимого автора.

Простое добавление ещё одного include в SPF example.com не меняет MAIL FROM уже отправленного письма. Администратор выясняет, поддерживает ли CRM подпись от собственного домена клиента или согласованный домен возвратов. Затем получает настройки в кабинете, подтверждает право на домен и публикует нужные записи. Менять только надпись отправителя недостаточно.

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

Шаг 5. Начните DMARC с наблюдения

Создайте контролируемый адрес для агрегированных отчётов и определите, кто их разбирает. Затем опубликуйте единую DMARC-запись для нужного имени. Учебная конфигурация наблюдения для example.com:

Имя: _dmarc.example.com
Тип: TXT
Значение: v=DMARC1; p=none; rua=mailto:dmarc@example.com

В реальной панели имя может вводиться как _dmarc, если суффикс добавляется автоматически. Адрес для отчётов должен существовать и принимать сообщения. p=none не просит ограничивать доставку из-за результата DMARC, но собственные антиспам-правила получателя продолжают работать. Такой режим не гарантирует попадания во входящие.

Общий порядок публикации и смысл rua разобраны в руководстве Google по DMARC. Если отчёты направляются в другой организационный домен, принимающая сторона должна подтвердить право получать их через предусмотренную DNS-авторизацию. Этот механизм описан в RFC 9990; одной чужой почты в rua недостаточно.

Что учитывать в инструкциях после обновления стандарта

В мае 2026 года RFC 9989 заменил прежнюю спецификацию DMARC RFC 7489. В частности, процентный тег pct удалён. Поэтому старую схему «сразу reject, но применить лишь к части писем» нельзя считать универсальным безопасным запуском. Проверяйте актуальные возможности провайдера и получателей; базовый путь остаётся понятным: наблюдение, исправление потоков, затем усиление политики.

Отдельно составьте список поддоменов и их политик. Настройки основного домена могут влиять на них; собственная запись и параметры политики поддоменов требуют проверки. Не делайте вывод о всей организации по одной записи у корня, особенно если рассылками или сервисными уведомлениями управляют разные команды.

Шаг 6. Проверьте опубликованные записи и реальные письма

Сначала DNS, затем каждый маршрут отправки

В DNS-проверке запросите точные имена SPF, селектора DKIM и DMARC. Сверьте тип, значение и число подходящих записей. Если провайдер выдал CNAME, проверьте разрешение ссылки до ожидаемого ключа. Результат проверки корневого домена не описывает автоматически отдельный домен возвратов.

Учитывайте кэширование. По описанию TTL Cloudflare, срок хранения DNS-ответов влияет на видимость изменений. Уменьшение TTL сейчас не отменяет уже сохранённые ответы со старым сроком. Проверяйте, какие данные опубликованы у авторитетного сервера и какие видит используемый резолвер; единого обязательного ожидания для всех доменов нет.

Проведите согласованные отправки с собственными тестовыми данными: из веб-почты, сайта, CRM и остальных источников карты. Используйте внешний контрольный ящик; переписка внутри одной организации может пройти другим маршрутом. Для каждого письма запишите время, систему, ожидаемый From, технический идентификатор и итог проверки.

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

У получателя откройте полный исходник или технические заголовки. В Gmail это действие описано в справке о просмотре полного заголовка. Сопоставьте From, Return-Path, DKIM-Signature и Authentication-Results. Последнее поле содержит результаты проверки, но доверять нужно результатам своего принимающего сервиса, а не любой строке с таким названием: границы доверия определены в RFC 8601.

Учебная сокращённая запись результата может выглядеть так:

spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com

Это иллюстрация полей, а не доказательство работы какого-либо домена. В реальном письме проверяйте значения и выравнивание. Удачное сообщение из одного сервиса не подтверждает остальные; сохраните отдельный результат для каждого маршрута и важного поддомена.

Зафиксируйте результат так, чтобы его можно было повторить

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

• Каждый используемый домен возвратов проверен по его собственной SPF-политике.
• Сообщение подписывается ожидаемым доменом, ключ находится по правильному селектору.
• Выравнивание соответствует выбранному режиму, результат DMARC понятен.
• Отчёты принимаются, а новые ошибки поступают ответственному на разбор.
• Проверены важные дополнительные маршруты: вложения, автоответы, группы и уведомления по расписанию.

Если какой-то поток ещё не проверен, укажите это явно вместе с ответственным и сроком. Такая запись полезнее общей отметки «настроено»: она показывает реальные границы выполненной работы и помогает планировать следующий этап.

Как читать DMARC-отчёты и находить забытые отправители

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

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

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

Когда переходить от наблюдения к quarantine или reject

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

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

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

Перед усилением сохраните предыдущую политику и согласуйте реакцию на сбой. Если после изменения перестали доходить законные письма, локализуйте источник и при необходимости верните предыдущий согласованный режим. Возврат тоже зависит от DNS-кэшей. Одновременно исправьте причину, иначе повторное включение защиты воспроизведёт проблему.

Типичные ошибки настройки и следующая проверка

Симптом	Вероятное направление проверки	Что проверить
SPF permerror	Несколько политик, синтаксис или лимит поиска	Опубликованные TXT и полную цепочку вложенных источников
Ключ DKIM есть, подписи нет	Не включено подписывание или используется другой маршрут	Настройки фактического отправителя и исходник письма
DKIM fail	Неверный ключ, селектор или изменение сообщения	Параметры d и s, запись DNS, промежуточные шлюзы
SPF и DKIM pass, DMARC fail	Нет выравнивания с From	Домены MAIL FROM и d относительно видимого отправителя
Отчёты не приходят	Адрес rua, внешний получатель или недостаток данных	Приём ящика, DNS-авторизацию и факт отправок
Проблема только у части писем	Другой сервис, поддомен, пересылка или старый кэш	Сравнение конкретных сообщений и маршрутов

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

Как поддерживать настройку после запуска

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

При смене DKIM-ключа сначала опубликуйте новый селектор, затем переключите подписывание и проверьте письма. Старый публичный ключ сохраняют на переходный период для сообщений, которые ещё находятся в пути; такой порядок описан в RFC 6376. При компрометации закрытого ключа применяется отдельный срочный порядок отзыва, согласованный с провайдером.

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

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

Нужны ли одновременно SPF и DKIM для DMARC?

Для pass достаточно одного успешного и выровненного механизма. На практике стоит настроить оба: они проверяют разные свойства и по-разному ведут себя на промежуточных маршрутах. Условия конкретного почтового провайдера могут предъявлять дополнительные требования.

Можно ли настроить всё одним SMTP-плагином?

Плагин может подключить отправку к сервису, который подписывает письма, но DNS и политика домена требуют отдельной настройки. Проверяйте реальный маршрут и результат у получателя; сохранение SMTP-пароля само по себе не создаёт SPF, DKIM и DMARC.

Нужно ли копировать публичный ключ из чужой инструкции?

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

Почему письмо в спаме при трёх pass?

Аутентификация подтверждает определённые технические свойства. Фильтрация также оценивает другие признаки сообщения и отправки. Сохраните успешные результаты, затем исследуйте доставляемость отдельно; ослабление корректной аутентификации проблему не объясняет.

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

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