Как настроить SPF, DKIM и DMARC в Cloudflare

Если вы хотите разобраться, как настроить SPF, DKIM и DMARC в Cloudflare, начните с простого факта: Cloudflare хранит DNS-записи, а значения для них предоставляет ваш почтовый сервис. Звучит мелко. На самом деле это очень важно, особенно если вы хотите настроить SPF DKIM DMARC в Cloudflare без лишних ошибок.

Cloudflare — это место, где живут записи, а значит, именно там вы будете редактировать TXT- или CNAME-записи в панели DNS. Но сам SPF include-стринг, селектор DKIM, публичный ключ и политика DMARC приходят от сервиса, который отправляет вашу почту — будь то Google Workspace, Microsoft 365, SendGrid, Mailgun или другая платформа. Без этих значений вы будете действовать наугад, поэтому заранее уточните SPF запись Cloudflare для домена у вашего провайдера.

1. Поймите, что Cloudflare может и чего не может делать для почтовой аутентификации

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

Это важно, потому что многие сначала открывают Cloudflare и ищут там волшебную кнопку. Её нет. Вам нужно точное содержимое записи от отправителя, прежде чем трогать DNS, иначе можно опубликовать запись, которая проходит проверку в панели, но ломается в реальном почтовом ящике. Именно поэтому так часто ищут как добавить DKIM запись в Cloudflare до того, как начнут редактировать DNS.

2. Соберите DNS-значения из платформы, через которую вы отправляете почту

Перед тем как что-либо редактировать, соберите три вещи из документации провайдера. Сначала — SPF include-механизмы и все IP-адреса, которые сервис должен видеть в вашей SPF-записи. Затем — имена селекторов DKIM и данные публичного ключа, либо CNAME-цели, если провайдер использует DKIM на основе CNAME. И наконец — строку политики DMARC, включая ту политику, с которой вы планируете начать, и любые теги для отчётности.

Запишите всё в одном месте. Используйте точные имена селекторов. Если провайдер даёт вам два селектора, не переименовывайте их только потому, что они выглядят неаккуратно. Если в документации указано, что запись должна быть `_spf.example.net`, оставьте именно так. Мелкие ошибки в форматировании легко превращают настройку в долгий вечер.

Полезная привычка: заранее соберите в одной таблице имя отправителя, хостнейм, тип записи и строку назначения ещё до входа в Cloudflare. Так редактирование пойдёт быстрее, и вы не перепутаете нужное значение с полем имени.

3. Добавьте SPF-запись в DNS Cloudflare

В Cloudflare откройте DNS и создайте или отредактируйте TXT-запись в корне домена, если ваш провайдер отправляет почту с основного домена. Некоторые сервисы используют поддомен, например `mail.example.com`, поэтому ориентируйтесь на тот хостнейм, который указал провайдер, а не на тот, который кажется вам логичным. Один хостнейм. Одна запись.

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

Типичное значение SPF включает механизмы вроде `include:` или `ip4:`. Если позже сервис добавит ещё одного отправителя, обновите существующую запись, а не добавляйте новую. Дублирующая SPF-запись может привести к permerror, из-за чего принимающие системы сочтут проверку неуспешной, даже если отдельные части выглядят правильно.

Используйте то имя записи, которое даёт провайдер. Для корневого домена Cloudflare часто показывает `@` в поле имени. Для поддомена введите точную метку. Не ставьте кавычки вокруг значения, если провайдер прямо не просит этого. Cloudflare хранит текст как обычное DNS-содержимое.

4. Опубликуйте DKIM-записи TXT или CNAME в Cloudflare

В DKIM главное — селектор. Провайдер может дать TXT-запись вроде `selector1._domainkey` с длинным публичным ключом, либо CNAME-запись, которая указывает на другой хостнейм. Cloudflare поддерживает оба варианта, но тип должен соответствовать тому, что указал провайдер. TXT-значение в поле CNAME не поможет.

Многие сервисы используют два селектора. Это нормально. В Google Workspace, например, часто применяют два ключа во время ротации, и другие провайдеры делают похожим образом, чтобы можно было заменить один ключ без остановки доставки. Если отправитель даёт `s1` и `s2`, опубликуйте оба. Если у другого отправителя другая схема селекторов, храните эти записи отдельно. Названия могут выглядеть повторяющимися; записи — нет.

Введите DKIM-хостнейм точно так, как он указан. Если провайдер просит создать `selector1._domainkey.example.com`, используйте в Cloudflare именно это полное имя. Если провайдер выдаёт CNAME-цель, вставьте адрес назначения без изменений. Cloudflare не нужен перевод. Ему нужна точность.

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

5. Создайте запись DMARC в _dmarc

DMARC размещается в `_dmarc.yourdomain.com`. В Cloudflare создайте TXT-запись с этим точным именем. Значение начинается с `v=DMARC1`, затем добавляется политика и необязательные теги. Часто на старте выбирают политику `p=none`, потому что она позволяет собирать отчёты, прежде чем что-либо блокировать. Это самый мягкий вариант для начала.

Если ваша организация готова принимать отчёты, добавьте тег `rua` с адресом для агрегированных отчётов и, если нужно, тег `ruf` для форензик-отчётов. Используйте адрес, который кто-то действительно проверяет. Мёртвый почтовый ящик — это не стратегия. Это ловушка.

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

Cloudflare будет хранить TXT-запись DMARC как любую другую текстовую запись, но детали важны. Имя записи должно быть `_dmarc`, а не `dmarc`, не `_dmarc1` и не корневой домен. Строка политики должна соответствовать синтаксису, который ожидает ваш провайдер. Если почтовая платформа предлагает теги вроде `sp`, `adkim` или `aspf`, добавляйте их только тогда, когда понимаете эффект.

6. Проверьте настройки DNS, специфичные для Cloudflare, которые могут мешать проверке

В Cloudflare есть одна настройка, которая вызывает больше путаницы, чем следовало бы: проксирование. Записи для почтовой аутентификации не должны быть проксированы. SPF, DKIM и DMARC живут в DNS, а не за оранжевым облаком. Если вы случайно проксируете хостнейм, связанный с почтой, вы смешиваете правила веб-трафика с DNS-записями для email.

Имена записей — ещё одна частая причина сбоя. DKIM-селектор, который должен быть `selector1._domainkey`, могут ввести как `selector1._domainkey.` с лишней точкой или как `selector1 domainkey` со случайным пробелом, скопированным со страницы провайдера. Cloudflare принимает многие DNS-записи, но принимающие системы куда менее снисходительны, чем интерфейс.

Старые записи тоже могут мешать. Если рядом с новой SPF-записью остаётся старая TXT-запись SPF или если устаревшая DKIM CNAME по-прежнему указывает на уже неиспользуемый сервис, проверка может провалиться весьма неожиданным образом. Удаляйте старую запись только после того, как убедитесь, что она больше не нужна. Так вы не сломаете активного отправителя.

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

7. Проверьте распространение записей и аутентификацию почты через DNS, управляемый Cloudflare

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

Затем отправьте настоящее тестовое письмо через сервис, который использует эти записи. Не тестируйте из случайного ящика, который обходит ваш обычный почтовый поток. Откройте заголовки письма в принимающем ящике и проверьте SPF pass, DKIM pass и DMARC alignment pass. Само письмо всё равно может попасть в спам по другим причинам, но результат аутентификации должен показать, верна ли DNS-часть.

Для первого прохода достаточно одной быстрой проверки, но вторая проверка из другого почтового ящика даст более надёжный сигнал. Тест в Gmail и тест в Microsoft 365 могут вести себя по-разному, если один резолвер на мгновение видит старую запись, а другой — новую. Это не редкость. Так бывает.

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

8. Обновляйте записи при смене почтового провайдера

Почтовые схемы меняются. Провайдер ротирует DKIM-ключи, добавляется маркетинговая платформа или после миграции переносится сервис транзакционных писем. Когда это происходит, обновляйте DNS-записи в Cloudflare до переключения трафика, а не после. Такой порядок убережёт вас от дня с поломанными подписями.

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

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

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

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

Cloudflare делает публикацию довольно простой, но к самим записям всё равно нужен дисциплинированный подход. Один отправитель. Одна SPF-запись. Каждый DKIM-селектор на своём месте. Одна DMARC-запись в `_dmarc`. Если держать эти четыре пункта под контролем, всё остальное — это в основном терпение, несколько проверок заголовков и готовность обновлять DNS до того, как придёт очередное изменение платформы.