руководство · DMARC в Cloudflare

Как продуктовой команде безопасно внедрить DMARC в Cloudflare?

Чтобы настроить DMARC в Cloudflare, составьте список всех сервисов, которые отправляют письма с вашими видимыми доменами From, проверьте выравнивание SPF или DKIM на контрольных письмах и добавьте одну TXT-запись с политикой точно по имени _dmarc. Начните с режима отчётов, сохраните прежнее состояние DNS, проверьте ответы авторитетных и рекурсивных серверов и изучите агрегированные отчёты, прежде чем запрашивать quarantine или reject. Cloudflare размещает или анализирует DNS-политику; он не делает отправителя выровненным и не доказывает доставку.

Разделите DNS в Cloudflare и настройку отправителей

Cloudflare может обслуживать авторитетный DNS, в то время как письма приложения отправляет и подписывает другой провайдер. Зафиксируйте эти границы, прежде чем что-либо менять. Зона публикует TXT-запись с политикой DMARC; каждый почтовый провайдер управляет своим return path, доменом и селектором подписи DKIM, подтверждением, а иногда и отчётами; приложение определяет тенанта, класс письма, получателя, шаблон, видимый адрес From и путь через провайдера. Корректная DNS-запись не исправит неавторизованного отправителя, отсутствующую подпись DKIM, невыровненный return path или значение From, относящееся к чужому тенанту. Составьте список систем продакшена, стейджинга, поддержки, оплаты, идентификации, мониторинга, CRM, маркетинга и личной переписки по видимому домену From. Назначьте каждой владельца и контакт для отката и классифицируйте неизвестные источники в отчётах, прежде чем ужесточать режим применения.

Запрашивайте то имя политики, которое проверяют получатели

Для писем от alerts@notify.example.test начните с TXT-записи по имени _dmarc.notify.example.test. Не опубликуйте политику по ошибке на имени веб-сайта, почтового сервера (MX), селектора DKIM или return path. Современный механизм обнаружения DMARC может выбрать применимую политику организационного домена или публичного суффикса, если у домена автора нет корректной записи, поэтому фиксируйте и запрошенное имя, и выбранный домен политики. Запросите текущие ответы авторитетных и рекурсивных серверов до того, как открывать Cloudflare. Несколько записей политики на одном имени, некорректный синтаксис тегов или конфликтующая CNAME-запись могут сделать результат непригодным. Сохраните старое содержимое, TTL, вывод резолвера, владельца и ожидаемое значение после изменения, чтобы откат был точным, а не восстанавливался по памяти во время инцидента.

Создайте одну проверенную TXT-запись в Cloudflare

Откройте нужный аккаунт и зону Cloudflare, перейдите в DNS Records, нажмите Add record и выберите TXT. Для политики на корневом домене используйте относительное имя _dmarc, а для нужного поддомена — точную метку _dmarc. Введите одно проверенное значение без непоследовательных кавычек; в документации Cloudflare сказано, что новое содержимое TXT, сохранённое без кавычек, автоматически заключается в кавычки. Выберите TTL, соответствующий плану развёртывания и восстановления, при необходимости добавьте ссылку на изменение без персональных данных и сохраняйте запись только после проверки зоны, имени, старого и нового значения. TXT-политики — это данные DNS, а не проксируемые веб-маршруты. Если зоной управляет хостинг-партнёр или другой авторитетный провайдер, вносите изменение там, а не исходите из того, что панель Cloudflare авторитетна.

Формируйте значение DMARC из осознанных решений

Запись на этапе наблюдения может начинаться с v=DMARC1; p=none и согласованного URI для агрегированных отчётов, но это пример, а не универсальное значение. Ставьте версию первой, задавайте запрашиваемую политику осознанно и авторизуйте каждый адрес для отчётов. Пересматривайте политику для поддоменов, режим выравнивания, процент и теги отчётов только при наличии задокументированного требования и актуального толкования стандарта. Не копируйте пример от вендора с чужим почтовым ящиком в rua и не переходите сразу к p=reject только потому, что синтаксис корректен. Корректная запись выражает желаемую обработку на стороне получателя; она не доказывает, что SPF или DKIM проходят аутентификацию, что хотя бы один аутентифицированный идентификатор выровнен с доменом From, что учтены все легитимные пути отправки или что хоть одно письмо попало во «Входящие».

Проверьте выравнивание SPF и DKIM на реальных письмах

Отправьте контрольные письма по каждому пути отправки приложения получателям, чьи исходные заголовки вы можете просмотреть. Зафиксируйте видимый From, SMTP MAIL FROM, IP-адрес отправки, домен d= и селектор DKIM, Authentication-Results, идентификатор провайдера, класс письма, окружение и время. DMARC может пройти благодаря выровненному аутентифицированному SPF или выровненной проверенной подписи DKIM. SPF проверяет SMTP-идентификатор, и его результат может измениться при пересылке; DKIM проверяет подпись над выбранным содержимым. Ни то, ни другое не заменяет авторизацию в приложении. Осознанно тестируйте мягкое (relaxed) и строгое (strict) выравнивание, включая поддомены и резервные маршруты. Приём запроса API провайдером, приём письма сервером назначения, прохождение DMARC, попадание в папку и вовлечённость — это разные наблюдения. Разделяйте эти состояния, чтобы успешный вызов API или зелёный индикатор политики никогда не выдавались за более сильное доказательство доставки.

Проверяйте DNS и отчёты вне панели управления

После сохранения запросите TXT-запись по точному имени _dmarc у авторитетных серверов имён Cloudflare и у нескольких независимых рекурсивных резолверов. Сохраните исходные ответы, выбранный домен политики, TTL, резолвер, время и результат парсера. Убедитесь, что пригодная запись ровно одна, v=DMARC1 стоит первым, обязательные значения корректны, а URI для отчётов согласованы. Повторите проверку после ожидаемого окна кеширования. Снова отправьте контрольные письма и изучите заголовки у получателя. Cloudflare описывает DMARC Management как способ увидеть источники отправки и сводные результаты SPF, DKIM и DMARC, но отчёты — это запаздывающие наблюдения, предоставленные получателями, а не полная картина в реальном времени. Сопоставляйте их с данными провайдера. Останавливайтесь при расхождении резолверов, отсутствии редкого трафика, неизвестных легитимных источниках, невыровненных контрольных письмах или неожиданных изменениях объёма отчётов.

Относитесь к Cloudflare DMARC Management как к изменению DNS

Cloudflare сообщает, что при включении DMARC Management может быть предложено создать запись, если её нет, или добавить адрес Cloudflare для агрегированных отчётов в существующий тег rua. Проверяйте такое предлагаемое изменение как изменение продакшен-инфраструктуры: экспортируйте прежнее значение, убедитесь, что существующие адреса оставлены намеренно, проверьте охват доменов и сохраните возможность отката. В документации по включению также описаны текущие ограничения — работа только с корневым доменом — и оговорка о внешней SPF-записи. Не делайте вывода, что функция может безопасно переписать SPF, размещённый в другом месте. Указанный источник или IP-адрес не доказывает, какое приложение, тенант или человек его авторизовал, а отсутствие строки не доказывает отсутствия трафика. Используйте этот раздел для сбора данных, сохраняя при этом данные авторитетного DNS, исходные письма, логи провайдера и аудит приложения.

Ужесточайте режим применения поэтапно, опираясь на данные

Наблюдайте достаточно долго, чтобы охватить всех легитимных отправителей, классы писем, недельные закономерности, пакетные задания, резервные маршруты и редкие сценарии. Классифицируйте источники как собственные, согласованные вендоры, пересылка, неизвестные или злоупотребления. Исправьте выравнивание для легитимного трафика, прежде чем запрашивать более строгую обработку. Критерий «да/нет» должен включать корректный DNS, успешное прохождение контрольных писем, приемлемую долю выровненного трафика, отсутствие неизвестных легитимных источников, назначенных ответственных за инциденты, готовность поддержки и проверенный откат. Ужесточайте политику только ограниченным согласованным изменением и отслеживайте как ошибки аутентификации, так и сбои бизнес-процессов. Откатывайте или приостанавливайте изменения при отклонении легитимных писем, пропаже отчётов, неожиданных источниках, несогласованности резолверов, смене провайдера или сюрпризах с наследованием политики поддоменами. По возможности меняйте SPF, DKIM и DMARC по отдельности, чтобы причина регрессии оставалась понятной.

Избегайте типичных ошибок DMARC в Cloudflare

Частые ошибки: правка не той зоны, публикация не по тому имени _dmarc, две записи политики одновременно, испорченные кавычки, замена согласованного списка rua, предположение, что политика корневого домена и поддомена одинаковы, и переход к p=reject до того, как проявятся редкие отправители. Ещё одна ошибка — считать сохранённое или обнаруженное в панели состояние доказательством на уровне писем. Используйте точные диффы, контрольных получателей, независимые запросы, исходные заголовки и логи инцидентов с ограниченным кругом получателей. Не допускайте попадания адресов клиентов, текстов писем, API-ключей и неограниченных данных отчётов в тикеты и аналитику. Если ответы авторитетных серверов и кешей остаются несогласованными дольше запланированного, ожидаемый отправитель отсутствует или реальное письмо не проходит выравнивание, остановитесь и отдельно диагностируйте делегирование, кеш, синтаксис записи, список отправителей, SPF и DKIM.

Как SendHQ вписывается в эту схему

Безопасная граница не зависит от провайдера: приложение авторизует письмо, провайдер отправки аутентифицирует его, Cloudflare публикует или анализирует состояние DNS, а получатели оценивают письмо. Опирайтесь на актуальную официальную документацию Cloudflare, действующий стандарт DMARC, наблюдаемые ответы DNS и данные контролируемых полученных писем.

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

По какому имени в Cloudflare размещается DMARC-политика корневого домена?

Создайте TXT-запись _dmarc для зоны — она будет разрешаться как _dmarc.example.com. Для адреса From на поддомене оценивайте именно этот домен автора и текущие правила обнаружения.

Нужно ли вручную ставить кавычки в значении TXT?

По данным Cloudflare, новое содержимое TXT, сохранённое без кавычек, заключается в них автоматически. Избегайте непоследовательных ручных кавычек, а затем проверьте исходный ответ авторитетного сервера и результат парсера.

Проксирует ли Cloudflare TXT-запись DMARC?

Нет, для этой TXT-политики решение о HTTP-проксировании не применяется. Опубликуйте её в авторитетном DNS и проверьте извне; проксирование веб-трафика — это отдельная функция.

Может ли DMARC Management изменить запись?

В документации Cloudflare по включению функции сказано, что она может предложить добавить запись или адрес Cloudflare для rua. Явно проверьте это изменение, сохраните прежнее состояние, убедитесь в результате и при необходимости откатите его.

Отклоняет ли p=none письма, не прошедшие проверку?

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

Доказывает ли прохождение DMARC попадание во «Входящие»?

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

Почему SPF проходит, а DMARC — нет?

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

Доказывает ли запись DMARC интеграцию с провайдером почты?

Нет. Одна лишь запись DMARC не доказывает интеграцию с провайдером почты.

Источники

Что почитать дальше

Как проверить DMARC для писем приложенияПроверка обнаружения DMARC-записи, синтаксиса, выравнивания SPF и DKIM, политики, отчётов и реальных писем приложения — без путаницы между DNS-запросом и доставкой.Синтаксис SPF-записи для писем приложенияСинтаксис SPF v=spf1, механизмы, квалификаторы, модификаторы, лимит DNS-запросов, поведение include и redirect, проверка и выравнивание DMARC.Как проверить DKIM для писем приложенияПроверка DKIM: изучение реальной подписи, запрос селектора и домена, проверка письма, чтение результатов у получателя и тестирование выравнивания.Как выбрать сервис доставляемости emailОценка сервисов доставляемости по охвату, доказательствам, аутентификации, петлям обратной связи, стоп-листам, приватности, переносимости и удобству эксплуатации.