SPF, DKIM и DMARC: как настроить домен для почты

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

Что именно проверяют три механизма

Представьте, что домен в поле «От» — это адрес на конверте. Сам по себе он не доказывает, что письмо действительно отправил владелец адреса.

• SPF перечисляет серверы и сервисы, которым разрешено отправлять почту от имени домена. Проверка обычно опирается на домен отправителя в SMTP-конверте — он может отличаться от видимого адреса в поле «От».
• DKIM добавляет к письму криптографическую подпись. Получатель проверяет её по открытому ключу, опубликованному в DNS. Подпись также связывает письмо с доменом, который её создал.
• DMARC проверяет, согласуется ли домен в видимом адресе отправителя с доменом, прошедшим SPF или DKIM, и сообщает получателю, как обращаться с письмами, которые эту проверку не прошли.

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

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

Сначала соберите всех, кто отправляет почту

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

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

Записи в DNS: что публиковать

Пример ниже показывает только форму записей. Домены с окончанием .example и значение YOUR_PUBLIC_KEY — заглушки, а не готовые настройки. Скопируйте значения у своего почтового провайдера и замените примеры до публикации.

Домен: example.com
TXT для SPF: v=spf1 include:_spf.provider.example ~all
TXT для DKIM: selector._domainkey.example.com → значение, выданное почтовым сервисом
TXT для DMARC: _dmarc.example.com → v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

У домена может быть только одна SPF-запись. Если добавить вторую вместо объединения правил, проверяющий сервер может вернуть ошибку. Записи нескольких отправителей объединяют в одну, пользуясь инструкциями каждого сервиса. У SPF также есть ограничение на количество DNS-поисков при проверке: чрезмерное число подключённых механизмов может привести к ошибке. Не добавляйте новые include наугад и не пытайтесь исправить ситуацию автоматическим «сплющиванием» записей без понимания последствий.

DKIM-селектор — имя, по которому получатель находит публичный ключ отправителя в DNS. У разных сервисов селекторы и ключи различаются; часто селектор можно менять при ротации ключей, но порядок и срок хранения старой записи задаёт провайдер.

DMARC-запись с p=none просит получателя не менять доставку из-за DMARC, но позволяет собирать отчёты, если настроен адрес rua. Укажите настоящий доступный почтовый ящик или систему обработки отчётов: адрес из примера не существует. Сырые агрегированные отчёты часто приходят в XML и могут содержать технические данные об источниках отправки.

Термин: выравнивание (alignment) — совпадение домена в адресе «От» с доменом, который прошёл SPF или DKIM. Для DMARC могут применяться строгий и ослабленный режимы совпадения; конкретные параметры не стоит менять, пока вы не проверили требования своих почтовых сервисов.

Вводите DMARC поэтапно

1. Инвентаризируйте отправителей. Проверьте, кто отправляет письма от имени домена, и запросите у каждого поставщика точные DNS-значения. Результат: у вас есть список сервисов и записи для каждого из них.
2. Настройте SPF и DKIM. Обновите единственную SPF-запись, добавив только подтверждённые источники, и опубликуйте DKIM-записи, выданные сервисами. Результат: тестовые письма от каждого источника проходят SPF или DKIM и используют ожидаемый домен.
3. Добавьте DMARC с политикой наблюдения. Начните с p=none и настройте получение отчётов через rua. Результат: запись видна в DNS, а отчёты начинают поступать на указанный адрес. Учитывайте, что не каждый получатель присылает их.
4. Сопоставьте отчёты со списком отправителей. Неизвестный источник — повод выяснить, чей это сервис, а не сразу заблокировать его. Результат: легитимные отправители проходят проверку и выравнивание, а неавторизованные источники отделены от ваших систем.
5. Ужесточайте политику постепенно. После проверки всех источников можно переходить к p=quarantine, а затем, если ошибки устранены, к p=reject. Между изменениями наблюдайте за отчётами и тестируйте разные типы писем. Результат: выбранная политика не ломает нужную рассылку и применяется так, как ожидает ваша организация.

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

Что чаще всего ломается

• Несколько SPF-записей. Проверьте TXT-записи домена и объедините разрешения отправителей в одну по инструкциям провайдеров.
• SPF проходит, а DMARC — нет. Вероятно, домен SPF-проверки не выровнен с адресом «От». Проверьте также DKIM: его домен может обеспечить прохождение DMARC.
• После включения DMARC пропали письма сайта. Ищите источник отправки, который не попал в SPF или не подписывает письма подходящим DKIM-ключом. До исправления верните политику наблюдения, если она блокирует рабочие сообщения.
• Пересылка меняет результат SPF. Пересылающий сервер может не пройти проверку как разрешённый отправитель. DKIM-подпись иногда сохраняется, но может сломаться, если посредник изменит содержимое письма. Поэтому важны оба механизма и корректное выравнивание DMARC.
• Запись опубликована, но не находится. Проверьте имя записи, её тип и значение у DNS-провайдера, затем дождитесь обновления кешей. Для DKIM часто ошибаются в имени селектора.

Что делать дальше

Начните с тестового письма от каждого сервиса и проверьте заголовки Authentication-Results: там обычно указаны результаты SPF, DKIM и DMARC. Затем сопоставьте источники из отчётов DMARC со своим реестром отправителей. Меняйте только одно правило за раз и следите, не исчезли ли письма сайта, CRM или рассылки. Инвалидация кеша и защита домена от похожих адресов — отдельные задачи; здесь речь только об аутентификации почты.