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

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

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

SPF: TXT-запись на вашем домене, в которой перечислены IP-адреса, имеющие право использовать домен в SMTP-конверте отправителя (Return-Path). Результат pass доказывает только то, что отправляющий сервер был в вашем списке. Запись ничего не говорит об адресе From, который видит пользователь, и ломается при пересылке письма.

DKIM: криптографическая подпись, которую ваш почтовый сервер добавляет к каждому письму. Публичный ключ хранится в DNS под селектором, например s1._domainkey.example.com. Результат pass доказывает, что тело письма и ключевые заголовки не менялись с момента, когда их подписал владелец вашего приватного ключа. Пересылку такая подпись переживает.

DMARC связывает обе проверки с видимым доменом From (это называется alignment, выравнивание) и публикует политику, которая говорит получателям, что делать при провале обеих проверок: ничего не делать, отправлять в карантин или отклонять. Она же просит получателей присылать вам отчёты. Без DMARC результаты SPF и DKIM остаются лишь рекомендательными сигналами.

Готовые записи для типичной схемы

Допустим, example.com отправляет транзакционную почту со своего сервера 192.0.2.10, а рассылки идут через внешний сервис. Подставьте свои имена и адреса.

SPF, одна TXT-запись в корне домена:

example.com.  TXT  "v=spf1 ip4:192.0.2.10 include:servers.mcsv.net -all"

Значение include берётся из документации сервиса рассылок, в примере вариант Mailchimp. Механизмы mx и a добавляйте только если эти хосты действительно отправляют почту.

DKIM: сгенерируйте на сервере пару ключей на 2048 бит:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -outform der | openssl base64 -A

Опубликуйте вывод base64 как TXT-запись:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ...AQAB"

Затем укажите вашему MTA (OpenDKIM, rspamd, Exim, что у вас установлено) приватный ключ и селектор s1. Сервис рассылок подписывает письма своими ключами: он выдаст вам две или три CNAME-записи, чтобы его подписи были выровнены с вашим доменом. Добавьте их, иначе рассылки позже начнут проваливать DMARC.

DMARC, начните в режиме наблюдения:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Проверьте всё с любой машины:

dig +short TXT example.com
dig +short TXT s1._domainkey.example.com
dig +short TXT _dmarc.example.com

Затем отправьте тестовое письмо на адрес Gmail и откройте Show original: на одном экране должны быть spf=pass, dkim=pass и dmarc=pass.

Ошибки SPF, которые реально вредят

• Две записи SPF. Стандарт допускает ровно одну. Если панель или мастер настройки SaaS добавит вторую, получатели вернут permerror и засчитают это как fail. Объедините все механизмы в одну запись.
• +all. Такая запись разрешает всему интернету отправлять письма от имени вашего домена. Спам-фильтры это знают, и некоторые считают это признаком спама само по себе. Заканчивайте запись на -all или на ~all, пока переносите отправителей.
• Слишком много DNS-запросов. SPF допускает не более 10 механизмов, требующих обращения к DNS (include, a, mx, redirect). Вложенные include нескольких SaaS-сервисов быстро съедают лимит, и результатом снова будет permerror. Посчитайте запросы любым SPF-чекером, удалите сервисы, которыми больше не пользуетесь, и замените a/mx на явные ip4 там, где адреса стабильны.

Основы ротации ключей DKIM

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

1. Сгенерируйте новую пару ключей и опубликуйте её под новым селектором, например s2._domainkey.
2. Дождитесь истечения TTL записи, затем переключите MTA на подпись селектором s2.
3. Оставьте старую запись s1 в DNS примерно на неделю, чтобы письма в очередях и в пути ещё проходили проверку, затем удалите её.

Держитесь 2048 бит. Некоторые DNS-панели требуют разбивать длинное значение p= на куски по 255 символов в кавычках; это нормально, резолверы склеивают их обратно.

DMARC: от none к reject, ничего не сломав

1. Держите p=none с отчётами rua минимум две-четыре недели. Пока ничего не блокируется, вы только собираете данные.
2. Исправьте каждый легитимный источник, который проваливает выравнивание. Обычные подозреваемые: контактная форма сайта, сервис выставления счетов, CRM, которую кто-то подключил два года назад.
3. Перейдите на p=quarantine; pct=25, затем поднимайте pct до 100, пока отчёты остаются чистыми. Провалившая проверку почта теперь уходит в спам, а не во входящие.
4. Завершите переходом на p=reject. Пересылка и списки рассылки регулярно ломают SPF, поэтому делайте этот шаг только тогда, когда DKIM подписывает всё, что вы отправляете: выровненный DKIM переживает пересылку и сохраняет DMARC в статусе pass.

Поддомены наследуют политику, если отдельно не задать sp=. Если поддомен никогда не отправляет почту, явная запись v=spf1 -all и политика reject для него закрывают распространённую дыру для подделки отправителя.

Как читать отчёты DMARC и не утонуть в них

Агрегированные отчёты (rua) приходят в виде архивов с XML, по одному от каждого получателя в день. В сыром виде их долго никто не читает. Загружайте их в парсер: развёрнутый на своём сервере parsedmarc работает хорошо, у ряда веб-панелей есть бесплатный уровень. Дальше раз в неделю проверяйте ровно две вещи:

• Легитимные источники с провалами проверок: почините их SPF include или подпись DKIM до ужесточения политики.
• Неизвестные IP, отправляющие заметные объёмы от имени вашего домена: это подделка, и именно её отрежет ваша политика reject.

Форензик-отчёты (ruf) можно игнорировать, большинство крупных получателей их больше не отправляет. Все три записи живут в обычном DNS, поэтому ничего здесь не зависит от того, где размещён почтовый ящик: если ваш домен обслуживается через нашу регистрацию доменов, эти TXT-записи редактируются в той же DNS-панели, а на тарифах нашего хостинга сайтов записи SPF и DKIM для включённой почты можно сгенерировать из панели управления. Включите p=none сегодня, прочитайте первые отчёты через неделю, и вы уже будете впереди большинства отправителей.