Политика DMARC: Полное руководство по реализации, настройке и мониторингу

Источник и точность: примечание

Этот гайд в основном основан на спецификациях протокола — RFC 7489, RFC 7208, RFC 6376, RFC 8301, RFC 8463, RFC 8601, RFC 8617, RFC 8461, RFC 8460, RFC 7960, а также RFC 8553 и RFC 8616, которые обновляют или влияют на RFC 7489 — дополненные текущей документацией Microsoft, Google и Yahoo, а также активной работой DMARCbis в рабочей группе IETF DMARC. DMARC — это протокол рекомендаций: он выражает предпочтение владельца домена, но система приема электронной почты решает, что делать с сообщением, которое не проходит проверку. Поведение провайдеров может меняться, иногда без предварительного уведомления. Примеры DNS в этой статье используют зарезервированные имена-заполнители в стиле примера. Замените каждый домен политики, домен отчета, селектор и запись авторизации внешнего отчета на значения, контролируемые вашей организацией или процессом отчетности. Прежде чем применять любую конфигурацию, описанную здесь, к производственному домену, проверьте ее в тестовой среде — обычно p=none с агрегированной отчетностью — и никогда не публикуйте p=reject, пока агрегированные отчеты не подтвердят, что ваши легитимные источники электронной почты соответствуют требованиям.

Введение: почему SMTP позволяет подделывать адреса отправителей

SMTP, изначально определенный в RFC 821 (1982) и модернизированный в RFC 5321, был разработан для небольшой, взаимодоверяемой исследовательской сети. Он не выполняет аутентификацию отправителя на уровне протокола. Подключающийся сервер электронной почты может указывать любое значение в команде MAIL FROM и любой адрес в заголовке From:. Система приема электронной почты не имеет встроенного способа проверки ни того, ни другого.

Фактически, электронная почта имеет три «адреса отправителя», и путаница между ними является основной причиной подделки адресов:

• Отправитель письма (также известный как MAIL FROM, Return-Path или RFC 5321.MailFrom). Это адрес, используемый во время транзакции SMTP, и именно сюда возвращаются письма, которые не были доставлены. Получатель обычно никогда его не видит.
• Заголовок: От (RFC 5322.From). Это отображаемое поле. From: формат, который почтовые клиенты отображают пользователю.
• Домен для подписи DKIM (мы d= тег внутри заголовка DKIM-Signature). Это домен, ключ которого использовался для подписи сообщения, и он может отличаться от указанных выше адресов.

Сообщение, содержащее фишинговую атаку, может отображать billing@bank.example.com в видимой части From:, используя bounce@attacker.example.net в качестве отправителя. SPF, в обычном процессе оценки MAIL FROM, соответствующем DMARC, проверяет отправителя, а не видимый адрес отправителя. SPF также может проверять HELO/EHLO, но это не является видимым идентификатором для пользователя. DKIM, сам по себе, только проверяет, какой домен подписал сообщение. Ни один из них не защищает идентификатор, который видит пользователь в своем почтовом клиенте, если аутентифицированный идентификатор соответствует домену, указанному в видимом адресе отправителя в рамках DMARC.

DMARC был определен в RFC 7489 в марте 2015 года со статусом «Информационный», опубликованный через независимый поток подачи документов от RFC Editor, а не как результат работы группы IETF. DMARCbis — это стандартная версия протокола DMARC, разработанная рабочей группой IETF DMARC — это первая спецификация DMARC, разработанная в рамках IETF, а не «реклама» существующего документа IETF. DMARC связывает результаты SPF и DKIM с видимым адресом отправителя с помощью концепции, называемой «соответствие», и позволяет владельцу домена публиковать политику в DNS, указывающую получателям, что делать, если ни один из механизмов не проходит проверку. DMARC — это не волшебный антифишинговый слой — он ничего не делает с похожими доменами, атаками с использованием символов, похожих на буквы, или сообщениями, отправленными с скомпрометированных учетных записей, которые проходят нормальную аутентификацию, и он не гарантирует размещение в папке «Входящие». То, что предоставляет DMARC, — это подтверждение того, что использование видимого адреса отправителя было санкционировано для сообщения, которое прошло проверку, а также канал обратной связи, чтобы владельцы доменов могли видеть, кто отправляет им электронные письма от их имени. Это не является заключением о том, что содержание сообщения, намерения отправителя или учетная запись почтового ящика являются надежными.

Роли SPF, DKIM и DMARC

Эти три протокола связаны, но являются независимыми. Каждый отвечает на другой вопрос.

SPF может оценивать как идентификаторы HELO/EHLO, так и MAIL FROM. DMARC использует результаты SPF для идентификатора RFC5321.MailFrom. Если поле MAIL FROM пусто, SPF определяет идентификатор MAIL FROM, полученный на основе HELO, как проверенный. postmaster@<helo-domain> идентификация; это относится к случаю, когда отправляется сообщение «bounce», а не к использованию DMARC для получения произвольных результатов HELO.

DKIM обычно защищает выбранные зашифрованные заголовки и хеш тела, но точный охват зависит от используемой подписи. Редко используемый тег DKIM `l=` для указания длины тела может быть намеренно использован для шифрования только первой части тела, поэтому наиболее безопасным способом является проверка фактического `DKIM-Signature` и решения получателя, а не предположение, что каждый байт отправленного сообщения зашифрован.

Сообщение может успешно пройти проверку SPF, но при этом не пройти проверку DMARC. Если отправитель письма указан как bounce.esp-mailer.example, но отображается имя отправителя как noreply@example.com, то SPF подтверждает неверную информацию с точки зрения DMARC. То же касается DKIM: подпись с d=esp-mailer.example криптографически проверяется, но домен, который ее подписал, не совпадает с доменом, отображаемым в имени отправителя, поэтому проверка DKIM не проходит.

Предоставляем Authentication-Results заголовок, определенный в RFC 8601, является основным инструментом для диагностики и устранения неполадок. Серверы электронной почты, которые выполняют аутентификацию, обычно добавляют один из этих заголовков в полученное сообщение, в котором суммируются результаты проверок SPF, DKIM и DMARC, а также идентификаторы, использованные для их вычисления. Когда сообщение попадает в папку «Спам» или отклоняется, этот заголовок обычно содержит ответ. При диагностике следует доверять только Authentication-Results заголовок, добавленный вашим собственным MTA или конечной системой приема, которую вы анализируете — заголовки «Authentication-Results» от ненадежных промежуточных систем могут быть поддельными или устаревшими. RFC 8601 §5 описывает, почему системы, выступающие в качестве «граничных», должны удалять или игнорировать поля «Authentication-Results» от ненадежных промежуточных систем.

Как работает DMARC шаг за шагом

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

Техническая оценка, согласно RFC 7489 §6, осуществляется примерно следующим образом:

1. Получатель извлекает домен из заголовка RFC 5322.
2. Получатель запрашивает TXT-запись в _dmarc.<domain>. Если запись не найдена, он запрашивает запись с тем же именем в домене организации (полученном в соответствии с RFC 7489 с использованием Public Suffix List). В случае DMARCbis, fallback Public Suffix List заменяется ограниченным обходом DNS-дерева; поведение Public Suffix List, описанное в RFC 7489, остается актуальным для многих получателей до публикации и внедрения DMARCbis.
3. Получатель оценивает SPF для отправителя письма и записывает результат.
4. Получатель оценивает все DKIM-подписи в письме и записывает каждый результат.
5. Получатель проверяет соответствие SPF: соответствует ли домен отправителя (из заголовка письма) домену, указанному в политике в режиме aspf?
6. Получатель проверяет соответствие DKIM: соответствует ли значение любой проверенной подписи в режиме d= домену, указанному в политике в режиме adkim?
7. DMARC считается успешным, если либо SPF, либо DKIM успешно пройдены.
8. Если DMARC не пройден, получатель консультируется с опубликованной политикой (p= или sp= для поддоменов).
9. Получатель может использовать none, quarantine или reject, при этом pct может использоваться для выборки.
10. Местная политика получателя — системы репутации, списки разрешенных адресов, доверие ARC, фильтрация контента — может переопределять или дополнять запрошенную обработку.

Шаг 10 особенно важен, и его часто понимают неправильно. Политика DMARC — это запрос, а не команда. Получатель может соблюдать её, игнорировать, всё равно отправить письмо в спам или применить дополнительную оценку на основе машинного обучения. Microsoft 365, Google Workspace и крупные поставщики потребительских почтовых сервисов применяют собственные локальные правила поверх DMARC. DMARCbis §5.4 подчёркивает этот подход: получателям почты НЕ СЛЕДУЕТ (SHOULD NOT) отклонять входящие сообщения исключительно из-за опубликованной политики p=reject. В последующих разделах об обработке сообщений и соответствии требованиям используется более строгое правило: получатели почты НЕ ДОЛЖНЫ (MUST NOT) отклонять входящие сообщения исключительно из-за опубликованной политики p=reject. При отсутствии другой информации и анализа сообщения, не прошедшие проверку, должны обрабатываться так, как если бы действовала политика p=quarantine.

Свободный против строгого соответствия

Соответствие — это то, что отличает DMARC от SPF и DKIM. Существуют два режима, управляемых независимо для SPF (aspf) и DKIM (adkim). По умолчанию для обоих режимов «свободное соответствие«.

• Свободная выравнивание требует, чтобы оба домена использовали одну и ту же организационную доменную зону. mail.example.com соответствует example.com.
• Строгая выравнивание требует точного соответствия домену. mail.example.com не соответствует.example.com

Рассмотрим сообщение с From: billing@example.com и следующими возможными идентификаторами:

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

Сценарии успешного и неуспешного прохождения DMARC

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

Чтение заголовков Authentication-Results

При устранении неполадок, внимательно изучите руководство пользователя приемника. Authentication-Results Заголовок. Пример сообщения может выглядеть следующим образом:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Сообщение, которое проходит проверку SPF, но не проходит проверку DMARC, потому что SPF не соответствует требованиям, может выглядеть следующим образом:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=esp-mailer.example;
  dkim=fail header.d=example.com;
  dmarc=fail header.from=example.com

Точная структура может отличаться в зависимости от получателя, но основная задача обычно одна: какой домен успешно проверен, и соответствует ли он видимому домену отправителя?

Политики DMARC

Тег `p=` определяет, что владелец домена хочет, чтобы получатели делали с сообщениями, которые не проходят проверку DMARC. В RFC 7489 определены следующие значения:

• `p=none` — только мониторинг. Владелец домена не запрашивает применение DMARC; получатели по-прежнему используют собственные фильтры для борьбы со спамом, злоупотреблениями, для улучшения репутации и в соответствии с политиками. Если установлено `rua`, участвующие получатели могут отправлять агрегированные отчеты.
• p=quarantine — получатели должны рассматривать недействительные письма как подозрительные. В практическом плане это обычно означает перенаправление в папку «Спам» или «Мусор», но точное обращение определяется получателем.
• `p=reject` — владелец домена запрашивает отклонение сообщений, которые не проходят проверку, обычно во время транзакции SMTP. Окончательное обращение по-прежнему зависит от политики получателя.

Два дополнительных тега определяют политику:

• pct= управляет выборочным применением политики: определяет долю сообщений, не прошедших проверку, к которым применяется запрошенная политика. Согласно RFC 7489 §6.6.4, сообщения вне выбранной доли обрабатываются по следующей, менее строгой политике: p=reject заменяется на p=quarantine, p=quarantine — на p=none, а p=none остаётся без изменений. Поэтому p=reject; pct=10 означает «отклонять 10% сообщений, не прошедших проверку; остальные 90% обрабатывать так, как если бы применялось p=quarantine». Для p=quarantine; pct<100 RFC 7489 §6.6.4 предписывает получателям применять обычную локальную классификацию к невыбранным сообщениям: фактически DMARC не переопределяет их обработку, а обычная фильтрация спама, репутации и содержимого на стороне получателя продолжает действовать. Сводные отчёты охватывают проверенный трафик независимо от pct; pct не задаёт выборку для отчётности.
• `sp=` определяет политику для поддоменов, которые не публикуют свой собственный запись DMARC. В случае отсутствия, поддомены наследуют значение `p` от родительского домена.

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

Безопасное внедрение DMARC

Непосредственное применение `p=reject` на производственном домене – это высокорискованный способ нарушения законной почты. Безопасное внедрение – это методичный процесс:

1. Опубликуйте `p=none` с указанием `rua` на адрес электронной почты или сервис анализа. Не изменяйте ничего другое.
2. Собирайте агрегированные отчеты в течение как минимум двух-четырех недель. Определите все IP-адреса и платформы, отправляющие почту от вашего имени. Для доменов электронной почты пользователей, которые могут быть рассмотрены для `p=reject`, DMARCbis рекомендует как минимум один месяц при использовании `p=none`, затем такой же длительный период `p=quarantine`, прежде чем сравнивать результаты и решать, допустимо ли использование `p=reject`.
3. Составьте список законных отправителей. Сравните с данными отчетов. Любые законные отправки, которые не соответствуют требованиям, должны быть исправлены до применения.
4. Исправьте SPF, настройте DKIM на всех платформах, поддерживающих его, и убедитесь, что домен, используемый для подписи, или адрес возврата соответствуют вашему видимому «От».
5. Перейдите к `p=quarantine` с низким значением `pct` (10–25%). Следите за отчетами.
6. Постепенно увеличивайте pct, пока количество ошибок от легитимных источников остается стабильным.
7. Переходите на p=reject только тогда, когда общие отчеты показывают, что практически весь легитимный объем проходит успешно, и только если использование домена позволяет минимизировать риски, связанные с перенаправлением и списками рассылки.
8. Продолжайте постоянный мониторинг. Новые инструменты SaaS, изменения у поставщиков и «теневые» IT-решения со временем приведут к появлению новых источников отправки.

Не предполагайте, что Microsoft 365, Google Workspace, ваш почтовый сервис, CRM, платформа выставления счетов или ваш Helpdesk автоматически настроены правильно. Они не настроены. Каждый должен быть настроен таким образом, чтобы он подписывал или отправлял сообщения, обеспечивая соответствие домену, который вы планируете использовать.

Для специализированных транзакционных, платежных, систем оповещения о безопасности и «припаркованных» доменов, p=reject часто является оптимальным зрелым состоянием, когда отчеты чистые. Для общих доменов электронной почты, где сотрудники публикуют сообщения в списках рассылки или используют пути перенаправления, p=quarantine может быть более безопасной конечной политикой. Рассматривайте p=reject как решение, основанное на оценке рисков, а не как универсальный знак зрелости.

В соответствии с текущим стандартом RFC 7489 для оценки DMARC, сообщение может пройти проверку DMARC, если выполнены как SPF, так и DKIM. Однако, для доменов, выбирающих p=reject, проект DMARCbis добавляет более строгие рекомендации: такие домены ДОЛЖНЫ полагаться исключительно на SPF для успешной проверки DMARC и ДОЛЖНЫ использовать действительные подписи DKIM, поскольку SPF может быть ненадежным при перенаправлении и косвенной доставке почты. До публикации и широкого внедрения DMARCbis, рассматривайте это как операционные рекомендации, а не как изменение поведения, определенное в RFC 7489.

Что DMARC не решает

DMARC эффективно защищает от прямой подмены вашего видимого домена «От», но это не является полным средством обеспечения безопасности электронной почты. Он не решает следующие проблемы:

• Учетные записи пользователей, скомпрометированные, отправляющие аутентифицированные сообщения из легитимной инфраструктуры.
• Домены, похожие на ваш, например, examp1e.com или example-billing.com.
• Подделка имени отправителя, когда злоумышленник использует другой домен, но выдает себя за другого отправителя.
• Вредоносные вложения или URL-адреса в сообщениях, которые правильно аутентифицируются.
• Размещение в папке «Входящие», репутация отправителя, жалобы на спам или фильтрация контента.
• Компрометация корпоративной электронной почты с использованием легитимных доменов, принадлежащих злоумышленникам.

Чек-лист практической готовности перед созданием записи DMARC

• Проверьте все системы, которые отправляют электронную почту, используя ваш домен: основная почтовая платформа, маркетинговый ESP, CRM, ERP, служба поддержки, API для транзакционной почты, платформа выставления счетов, оповещения мониторинга и любой сервер приложений, который отправляет уведомления.
• Проверьте синтаксис текущего SPF-записи и убедитесь, что количество DNS-запросов значительно ниже лимита, установленного RFC 7208 (10 запросов).
• Убедитесь, что для каждого домена существует ровно один запись SPF TXT. Наличие нескольких записей SPF TXT с одинаковым именем приводит к тому, что результат SPF будет permerror, что препятствует участию SPF в успешном прохождении DMARC. Сообщение все равно может пройти проверку DMARC, если успешно пройдены проверки DKIM.
• Убедитесь, что DKIM-подпись включена на всех платформах, которые ее поддерживают, и проверьте, разрешаются ли записи с публичным ключом.
• Проверьте соответствие в тестовых сообщениях от каждой отправляющей платформы, используя инструмент, который отображает заголовок Authentication-Results.
• Проверьте пути перенаправления (списки рассылки, пересылки на основе ролей и учетных записей, сторонние шлюзы) и оцените влияние, о котором говорится ниже.
• Определите, куда будут отправляться агрегированные отчеты — для одного или двух доменов внутренний почтовый ящик может быть достаточным, но большинство операционных команд используют сервис парсинга.
• Подтвердите доступ к DNS и разумное значение TTL (от 300 до 3600 секунд является приемлемым на этапе внедрения).
• Подготовьте план отката: сохраните предыдущее значение TXT-записи, чтобы можно было быстро вернуться к прежнему состоянию.
• Документируйте все изменения в системе управления конфигурацией или в руководстве по эксплуатации для целей аудита и обеспечения непрерывности.

Создание TXT-записи DMARC

TXT-запись DMARC — это запись, размещаемая на специальном доменном имени _dmarc.<your-domain>. Она не размещается в корневом домене. Значение записи — это последовательность тегов, разделенных точкой с запятой, начинающихся с v=DMARC1.

Для домена, который отправляет рабочую электронную почту и ранее не применял DMARC, режим мониторинга является нормальной отправной точкой:

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

То же самое в режиме мониторинга, но отправка отчетов внешнему поставщику аналитических услуг. Вторая запись должна быть опубликована доменом, получающим отчеты, для авторизации получения отчетов для example.com:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example-dmarc-vendor.example"
example.com._report._dmarc.example-dmarc-vendor.example. 3600 IN TXT "v=DMARC1"

Промежуточный этап: применение карантина для четверти недействительных писем с явно ослабленными правилами:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Строгая конфигурация отклонения для выделенного домена, используемого для транзакционных целей, безопасности, парковки или другого строго контролируемого использования, где известные отправители имеют действительные DKIM-подписи, и владельцы приняли риск перенаправления и списков рассылки:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Используя adkim=s или aspf=s, выполняется только точное соответствие доменам. Сообщение, использующее From: billing@example.com, не получит строгого соответствия SPF от MAIL FROM bounce.example.com и не получит строгого соответствия DKIM от d=mail.example.com. Используйте строгое соответствие только после того, как заголовки реального получателя и агрегированные отчеты подтвердят, что точные идентификаторы доменов совпадают.

Карантин в родительском домене с более строгим значением поддомена по умолчанию (полезно, когда не ожидается отправка электронной почты с поддоменов):

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@example.com"

Мониторинг с несколькими целевыми агрегированными отчетами. Каждый внешний организационный домен должен иметь свой собственный запись авторизации:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com,mailto:dmarc-vendor@example.net"
example.com._report._dmarc.example.net. 3600 IN TXT "v=DMARC1"

Важные ограничения и предупреждения:

• Если целевое место назначения находится в другом организационном домене, чем политика, целевой домен должен опубликовать запись «внешняя проверка назначения«. Для отчетов, отправленных от dmarc@vendor.example к example.com, запись имеет значение example.com._report._dmarc.vendor.example со значением v=DMARC1. Авторитетные сервисы анализа DMARC автоматически обрабатывают это, но необходимо проверить после внедрения.
• Тег ri — это необязательный интервал отчетности, запрошенный в соответствии с RFC 7489. Получатели могут его игнорировать, и многие отправляют агрегированные отчеты примерно раз в 24 часа, независимо от этого. В примерах отсутствуют ri и rf, поскольку они являются необязательными и слабо соблюдаются на практике, а не потому, что DMARCbis уже универсально внедрен. Сохраняйте записи, совместимые с RFC 7489, до публикации и фактического внедрения DMARCbis получателями.
• Отчеты для расследования (ruf) не широко поддерживаются и несут значительные последствия для конфиденциальности, поскольку они могут содержать полный текст сообщений. Рассматривайте их как необязательные и ненадежные для операций.
• Никогда не публикуйте более одного TXT-записи DMARC с одним и тем же именем. В соответствии с политикой RFC 7489, если после разбора остается более одной записи политики DMARC, процесс обнаружения политики DMARC завершается, и получатель обрабатывает сообщение, как будто запись политики DMARC не была найдена.
• Никогда не размещайте запись в корневом домене (example.com). Она должна находиться в поддомене _dmarc.example.com.

Распространение DNS, TTL и проверка

TTL (Time To Live) в DNS определяет, как долго рекурсивный сервер кэширует запись. TTL в размере 3600 (один час) является разумным значением для стабильной записи DMARC; при активной развертке, уменьшение TTL до 300 позволяет быстро отменить изменения. TTL — это время жизни кэша, а не гарантия распространения — кэши, которые уже содержат старую запись, продолжат использовать ее до истечения срока ее действия.

Команды проверки:

dig TXT _dmarc.example.com

nslookup -type=TXT _dmarc.example.com

Для получения полной картины обычно необходимо одновременно проверять SPF и DKIM. Проверьте запись SPF на фактическом домене RFC5321.MailFrom, используемом каждым отправляющим потоком, а не только на видимом домене «От», и проверьте все пары «селектор/домен» DKIM, используемые вашими почтовыми платформами:

dig TXT example.com
dig TXT bounce.example.com
dig TXT selector1._domainkey.example.com
dig TXT selector2._domainkey.mail.example.com

Инструменты сторонних валидаторов, такие как Google Admin Toolbox, MxToolbox, dmarcian, EasyDMARC и другие, полезны для проверки синтаксиса и визуализации, но они являются лишь инструментами для диагностики, а не официальными источниками информации о протоколах. В случае возникновения проблемы с доставкой для конкретного получателя, получатель должен самостоятельно Authentication-Results Заголовок обычно является наиболее релевантным доказательством, при условии, что вы читаете заголовок, который был добавлен самим отправителем, а не ненадежным посредником.

Полный разбор синтаксиса DMARC

Распространенные ошибки, которые стоит отметить: отсутствие v=DMARC1 в качестве первого тега, использование некорректной синтаксической структуры тега, размещение записи в корневом домене вместо _dmarc, публикация нескольких TXT-записей под одним и тем же именем, а также чрезмерное доверие к ruf для обеспечения видимости, поскольку многие получатели вообще не будут отправлять отчеты о расследовании.

Агрегированные отчеты против отчетов о расследовании

Агрегированные отчеты (RUA) – это отчеты в формате XML, которые обычно поставляются в виде сжатых вложений, таких как файлы gzip или zip. Это основной механизм для понимания того, что происходит с электронной почтой, связанной с вашим доменом. Один отчет содержит метаданные отчета, краткое описание примененной политики и один или несколько блоков <record>. Каждый <record> описывает трафик от одного источника IP-адреса, включая:

• IP-адрес источника и количество сообщений за отчетный период.
• Действие, предпринятое получателем (none, quarantine или reject).
• Результаты аутентификации DKIM и SPF.
• Домен отправителя, который был проверен.
• Результаты прохождения/непрохождения DKIM и SPF, оцененные DMARC после обработки, а также исходные результаты аутентификации, если они были предоставлены.

В XML ниже значения под policy_evaluated отражают оценку DMARC по механизму, использованному в этой строке; значения под auth_results отражают исходные результаты аутентификации SPF/DKIM, предоставленные получателем. Таким образом, прохождение SPF без выравнивания может законно отображаться как <spf>fail</spf> под policy_evaluated, одновременно отображаясь как <result>pass</result> под auth_results.

Пример агрегированного отчета:

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <email>dmarc-noreply@receiver.example</email>
    <report_id>20260512-abc123</report_id>
    <date_range>
      <begin>1778544000</begin>
      <end>1778630400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <pct>25</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.45</source_ip>
      <count>127</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.esp.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Данные выше являются иллюстративными и не описывают какую-либо реальную организацию.

Охват RUA полезен, но не является всеобъемлющим. Только участвующие получатели отправляют агрегированные отчеты, некоторые получатели подавляют или агрегируют детали по-разному, и сама доставка может завершиться неудачей. Рассматривайте RUA как основной источник операционной телеметрии для DMARC, а не как полное пересчет всех сообщений, отправленных с вашего домена.

Ручное парсинг агрегированных отчетов подходит для одного домена с небольшим количеством отправителей. Для более сложных случаев, маршрутизируйте отчеты в парсер, управляемую службу отчетности DMARC или в SIEM-пайплайн, который может нормализовать XML и сохранять исторические тенденции. Вы можете настроить оповещения о сигналах, таких как:

• Новый IP-адрес отправителя, превышающий определенный порог объема.
• Внезапный рост ошибок DMARC от ранее выровненного источника — обычно это ранний признак неправильной конфигурации после изменения поставщика.
• Новый header_from Поддомен, который ранее не использовался.
• Изменение количества сообщений после изменения DNS или платформы.

Сообщения об ошибках (RUF) являются отдельными, для каждого сообщения, и содержат данные сообщения, включая, возможно, полную информацию о заголовках. Многие получатели их не отправляют. Некоторые, которые отправляют, требуют дополнительного авторизования. Они могут быть полезны в узких сценариях расследования, но не должны быть основой стратегии мониторинга.

Рассмотрение Microsoft 365 и Google Workspace

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

Microsoft 365. Microsoft Официальная документация по настройке DMARC описывает рабочий процесс: SPF-запись публикуется у вашего регистратора домена (обычно это включает в себя spf.protection.outlook.com); DKIM включен для каждого домена через страницу DKIM в Microsoft Defender, которая создает записи-селекторы на основе CNAME, которые вы публикуете у своего DNS-провайдера; запись DMARC TXT создается _dmarc.<domain>. В соответствии с правилами обнаружения политики, указанными в RFC 7489, запись DMARC верхнего уровня применяется к поддоменам, которые не публикуют собственные записи DMARC, и Microsoft документирует это поведение наследования для доменов Microsoft 365. Обратите внимание на специальное обращение к домену клиента. *.onmicrosoft.com для доменов и для доменов, находящихся в «очереди»: оба должны быть защищены с использованием собственных записей DMARC, указывающих на реальный адрес назначения, даже если вы не отправляете электронные письма с них, чтобы сделать подделку этих доменов видимой.

Microsoft 365 сам по себе не обеспечивает полную защиту электронной почты. Настройка администратора Microsoft 365, правила почтового трафика, политики почтовых ящиков и Defender для Office 365 охватывают стороны приема и политики; выравнивание DMARC для исходящей почты все еще зависит от того, что ваш домен публикует в DNS и от того, как настроены все сторонние отправители.

Microsoft также объявила отдельные требования к отправителям для своих потребительских почтовых сервисов (Outlook.com, Hotmail.com, Live.com, msn.com). Согласно объявлению Microsoft за 2025 год и документации Microsoft по ошибке NDR 550 5.7.515, домены, отправляющие в эти сервисы 5 000 и более сообщений в день, должны публиковать записи SPF и DKIM, успешно проходить обе проверки, публиковать DMARC как минимум с p=none и иметь хотя бы один механизм аутентификации с согласованием доменов DMARC. Это строже базовых правил DMARC, по которым достаточно одной успешной проверки аутентификации с согласованием доменов. Массовая почта, не соответствующая требованиям, может отклоняться по SMTP с сообщением вида 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Google Workspace. В документации Google по настройке DMARC и рекомендациях для отправителей описаны включение DKIM в консоли администратора (при этом создаётся TXT-запись для публикации по имени селектора), разрешение Google Workspace в SPF с помощью include:_spf.google.com и публикация записи DMARC по адресу _dmarc. При этом согласование SPF по-прежнему зависит от соответствия домена отправителя SMTP-конверта домену видимого заголовка From. Требования Google к массовым отправителям распространяются именно на доставку в личные аккаунты Gmail: отправители, доставляющие примерно 5 000 и более сообщений за 24 часа в такие аккаунты, считаются массовыми и должны выполнять аутентификацию и согласование доменов, публиковать DMARC, поддерживать отписку одним нажатием для маркетинговых и рекламных писем и соблюдать допустимый уровень жалоб на спам. Google указывает, что порог рассчитывается для одного основного домена, включая поддомены. Это правило классификации провайдера Google, а не алгоритм определения организационного домена DMARC; присвоенный статус массового отправителя не отменяется автоматически. Сам факт отправки из Workspace не обеспечивает соответствие этим требованиям: домен необходимо настроить.

Yahoo. Сервисы Yahoo Рекомендации для отправителей описать аналогичные требования: внедрить SPF и DKIM, опубликовать действительную политику DMARC, содержащую p=noneи убедитесь, что домен отправителя соответствует либо SPF, либо DKIM. Yahoo и Google объявили о требованиях к массовым отправителям в 2024 году; для получения актуальных пороговых значений и точных правил рекомендуется обращаться непосредственно к документации Yahoo, а не полагаться на обобщенные сводки от сторонних источников. Yahoo также описывает свою классификацию массовых отправителей как основанную на шаблонах, а не на фиксированном количестве ежедневных отправлений. Часто задаваемые вопросы отправителя добавляет специфическое условие для DKIM, зависящее от провайдера: если сообщение содержит несколько подписей DKIM, соответствующих требованиям DMARC, и не все из них проходят проверку, Yahoo не гарантирует, что сообщение пройдет проверку DMARC.

Для любой из этих платформ, пользовательские домены и поддомены должны быть зарегистрированы индивидуально. Домены для массовой отправки (маркетинг, выставление счетов, транзакции) должны быть перечислены и аутентифицированы отдельно от почты корпоративных пользователей. DMARC также не заменяет защиту почтового ящика: MFA (в идеале, устойчивая к фишингу, такая как FIDO2 или WebAuthn passkeys), Условный доступ, хранение логов для проведения расследований, мониторинг правил перенаправления в папку входящих, созданных злоумышленниками, и процесс реагирования на инциденты для скомпрометированных учетных записей – все это являются дополнительными мерами безопасности, которые DMARC не заменяет.

Общие проблемы и решения, связанные с DMARC

Перенаправление электронной почты

Перенаправление – классическая проблема, связанная с DMARC. Когда получатель перенаправляет сообщение (через серверный пересыльщик, список рассылки или учетную запись), IP-адрес, используемый для следующего шага, – это пересыльщик, а не ваш авторизованный отправитель. SPF, проверенный в этом новом SMTP-транзакции, не проходит. DKIM может быть успешным, если пересыльщик не изменяет тело сообщения или заголовки, подписанные DKIM; он часто не проходит, если сообщение изменяется (например, вставка подписи в подвал сообщения).

Существуют два способа решения этой проблемы. Схема переписывания отправителя (SRS) переписывает отправителя, чтобы SPF мог пройти через пересыльщик; SRS не влияет на DKIM и не решает проблему соответствия DMARC для видимого домена «От». Аутентированная цепочка полученных сообщений (ARC), определенная в RFC 8617, позволяет каждому промежуточному серверу криптографически подтверждать результаты первоначальной аутентификации, чтобы конечный получатель мог доверять решению пересыльщика, даже если SPF и DKIM больше не проходят напрямую.

RFC 8617 является экспериментальным, а не стандартным документом. Также активно обсуждается в IETF вопрос о долгосрочном статусе ARC — в частности, предложение draft-ietf-dmarc-arc-to-historic («Переклассификация ARC как исторической»), которое заменило более раннее предложение draft-adams-arc-experiment-conclusion. Текущий вариант предлагает, чтобы ARC больше не использовался или не полагался на при передаче почты между различными отправителями и получателями. Поддержка со стороны получателей неравномерна, доверие основано на каждом отправителе, и ARC не следует использовать в качестве общего решения для произвольной пересылки почты. RFC 7960 подробно описывает вопросы пересылки и другие проблемы совместимости.

Маркетинговые ESP (поставщики электронной почты)

Большинство ESP по умолчанию подписывают исходящую почту своим доменом и используют общий адрес возврата. Оба варианта не соответствуют требованиям DMARC для вашего поля «От». Чтобы это исправить, вам необходимо:

• Настроить собственный адрес возврата (домен для уведомлений об ошибках) на поддомене, который вы контролируете, с использованием данных SPF или CNAME, предоставленных ESP.
• Настройте собственный домен для подписи DKIM, чтобы ESP подписывал сообщения. d= домен, который соответствует вашему адресу электронной почты с точки зрения организационной структуры.
• Необязательно настроить домен для отслеживания с фирменным логотипом.
• Запускать тестовые кампании и проверять Authentication-Resultsзаголовок «От» на стороне получателя перед применением.

Часто лучшей практикой является размещение маркетинговой почты на выделенном поддомене (news.example.com, marketing.example.com), чтобы ее репутация была изолирована от корпоративной почты.

CRM, ERP, системы выставления счетов, системы управления заявками и службы поддержки

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

• Подтвердите шаги конфигурации отправителя для включения SPF и подписи DKIM.
• Оцените влияние использования директив `include:` на количество запросов к вашему SPF-серверу, прежде чем добавлять их — каждая директива может рекурсивно использовать бюджет в 10 запросов.
• Проверьте, что реальные исходящие сообщения генерируют согласованные SPF или DKIM.
• Если поставщик не может подписать сообщения для вашего домена, направляйте его трафик через поддомен, чтобы сбой в этом поддомене не поставил под угрозу репутацию вашего основного домена.

Поддомены

Организационный домен — зарегистрированный домен, расположенный непосредственно под публичным суффиксом (как определено в Public Suffix List согласно RFC 7489; DMARCbis вводит другой механизм — обход DNS-дерева, о котором будет сказано ниже). Каждый поддомен наследует политику DMARC родительского домена, если он не публикует свою собственную. sp= позволяет установить другую политику по умолчанию для поддоменов. Распространенный шаблон:

• example.com — электронная почта корпоративных пользователей, обычно p=quarantine или p=reject в зависимости от перенаправления и использования списков рассылки.
• marketing.example.com — трафик ESP с собственным записом DMARC, соответствующим возможностям выравнивания ESP.
• billing.example.com — транзакционная электронная почта, p=reject после стабилизации.
• support.example.com — ответы службы поддержки, настроенные для соответствия политике поставщика службы поддержки.

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

Неиспользуемые и неактивные домены

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

Для полностью неиспользуемого домена необходимо опубликовать следующие записи:

• Запись SPF, указывающая, что ни один хост не имеет разрешения на отправку электронной почты от имени домена.
• Отсутствующий MX-запись (для RFC 7505) заявляя о том, что домен не принимает электронную почту.
• Строгая запись DMARC по адресу _dmarc с p=reject и действительным адресом rua для получения отчётов, чтобы видеть попытки подмены отправителя. Если домен публикует null MX, не направляйте rua на тот же домен: отчёты должны поступать в ящик, способный принимать почту.

Пример DNS для неиспользуемого домена:

example.com.                         3600 IN TXT "v=spf1 -all"
example.com.                         3600 IN MX  0 .
_dmarc.example.com.                  3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.org"
example.com._report._dmarc.example.org. 3600 IN TXT "v=DMARC1"

Если домен получает электронные письма, но не отправляет их, необходимо опустить нулевой MX-запись и сохранить нулевую SPF-запись и строгую DMARC, указывая rua на рабочую электронную почту в этом домене или на авторизованный внешний процессор отчетности. Если домен отправляет электронные письма, шаблон для неиспользуемого домена не применяется — необходимо перейти к поэтапному внедрению. Указание rua на реальный адрес, принимающий электронные письма, превращает блокировку из пассивной в активно контролируемую: без адреса для отчетности попытки подделки, направленные против ваших заблокированных доменов, остаются незамеченными. В приведенном выше примере example.org представляет собой отдельный домен отчетности, поэтому включается запись для проверки внешнего адреса.

Несколько записей SPF

RFC 7208 §3.2 прямо указывает: у домена ДОЛЖНА быть ровно одна запись SPF. Несколько записей TXT с одним и тем же именем, каждая из которых начинается с v=spf1, приводят к результату permerror. В таком случае проверка SPF не проходит, и выравнивание SPF в рамках DMARC также не выполняется. Объедините всех разрешённых отправителей в одной записи SPF, соблюдая ограничение в 10 DNS-запросов. SPF flattening — замена механизмов include: явными диапазонами IP-адресов, сформированными сервисом поставщика, — возможный вариант, но он создаёт операционную зависимость: при изменении IP-адресов у поставщика такую запись необходимо сформировать заново, иначе почта начнёт незаметно для вас не проходить проверку.

Неправильная работа DKIM

Наиболее распространенные причины сбоев DKIM: отсутствие или неправильная запись публичного ключа в имени домена; изменения в почтовом шлюзе (добавление антивирусных подписей, переписывание ссылок, изменение содержимого), которые приводят к недействительности подписи; неправильное указание домена, под которым выполняется подпись (то есть, сообщение технически имеет действительную подпись, но не соответствует требованиям); нераспространение ключей; истекшие или отозванные ключи.

DKIM определен в RFC 6376, а RFC 8301 (Стандартный уровень) обновляет его криптографическую основу: rsa-sha1 использование запрещено, минимальный размер ключа RSA составляет 1024 бита, а для долгоживущих ключей рекомендуется RSA размером 2048 бит. RFC 8463 также регистрирует ed25519-sha256 как поддерживаемый алгоритм DKIM. Прежде чем использовать Ed25519, убедитесь в поддержке на вашей платформе отправки, промежуточных шлюзах и у получателей. Публичный ключ RSA размером 2048 бит превышает ограничение в 255 октетов для одного строкового значения DNS и должен быть опубликован в виде нескольких кавычных строк внутри одного TXT-записи; проверяющие объединяют строки перед парсингом. Проведите тестирование после любых изменений в работе почты — особенно после внедрения нового шлюза, антивирусного продукта или гибридной конфигурации Exchange.

Компрометированные учетные записи

DMARC не предотвращает доставку легитимных, аутентифицированных писем с скомпрометированной учетной записи. Если злоумышленник имеет учетные данные пользователя и отправляет письмо из Microsoft 365 или Google Workspace через обычный исходящий канал, письмо будет правильно соответствовать SPF- и DKIM. DMARC не является подходящим средством защиты для этой угрозы. Подходящие средства защиты включают устойчивость к фишингу, многофакторную аутентификацию (MFA) с условным доступом, политики, ограничивающие места и способы аутентификации пользователей, назначение ролей с минимальными привилегиями, периодическую проверку правил перенаправления почты и правил входящей почты (частый механизм, используемый злоумышленниками), хранение логов с оповещениями о необычных шаблонах отправки и документированный процесс реагирования на инциденты.

DMARC как часть комплексных мер по обеспечению безопасности

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

Это полезно при обосновании работы для нетехнического заинтересованного лица, но не следует преувеличивать. DMARC не обеспечивает защиту данных при передаче (для этого используйте TLS, MTA-STS и TLS-RPT), не обнаруживает вредоносное ПО, не предотвращает компрометацию учетных записей и не блокирует фишинговые атаки с использованием похожих доменных имен. Сочетайте его с устранением уязвимостей, дисциплиной управления конфигурацией на почтовом сервере, непрерывным мониторингом сбоев аутентификации и обучением пользователей распознаванию фишинга.

Гипотетический сценарий внедрения

Ниже представлен гипотетический сценарий, использующий иллюстративные цифры. Он не основан на какой-либо конкретной реальной организации.

Начальное состояние. Средняя компания использует Microsoft 365 для корпоративной почты. example.com SPF присутствует, но включает девять поставщиков; DKIM включен только для домена по умолчанию. onmicrosoft.com Отправка транзакционной почты для клиентов осуществляется через SaaS-платформу, отправляющуюся как example.com; маркетинговые кампании проходят через ESP, отправляющуюся как example.com; ответы службы поддержки поступают через инструмент для управления тикетами, отправляющиеся как example.com.

Этап 1, недели 1–2. Инженерия обеспечивает возможность подписи DKIM для пользовательского домена в Microsoft 365 (публикация записей CNAME, включение подписи после разрешения записей). Они публикуют v=DMARC1; p=none; rua=mailto:dmarc@example.com и направлять отчеты в сервис аналитики DMARC. Первые отчеты показывают пятнадцать различных диапазонов IP-адресов, используемых для отправки. Большинство из них ожидаемы (Microsoft 365, провайдер электронной почты, платформа выставления счетов, инструмент для управления билетами). Три диапазона — это устаревшие серверы, находящиеся в локальной сети, о которых никто не документировал, и один — тестовая среда для разработчиков.

Этап 2, недели 3–6. Проверяются ранее неучтённые отправители. Локальные серверы переводятся на ретрансляцию через Microsoft 365 с соответствующей аутентификацией коннектора; тестовая среда переносится с основного рабочего домена на отдельный тестовый поддомен. У поставщика рассылок настраиваются собственный адрес возврата и собственный домен подписи DKIM; доля маркетингового трафика с согласованными доменами растёт с 0% почти до всего объёма. На платформе выставления счетов настраивается DKIM с доменом подписи, согласованным с доменом отправителя. Аналогично настраивается система обработки заявок. Проверяется SPF; два неиспользуемых включения поставщиков удаляются, чтобы сократить число DNS-поисков до семи.

3-й этап, 7–10 недели. Политика переносится в v=DMARC1; p=quarantine; pct=10; rua=.... Еженедельный анализ сводных отчетов продолжается. После двух периодов без ошибок, pct переходит на 25, затем на 50, а затем на 100.

4-й этап, 11-я неделя и далее. При наличии отчетов, показывающих, что практически весь легитимный трафик соответствует хотя бы одному механизму, и после подтверждения того, что риск, связанный с перенаправлением доменов и списками рассылки, приемлем, политика переносится в p=reject. Маркетинговый трафик разделяется на news.example.com с собственным записом DMARC, чтобы будущие изменения в маркетинговых инструментах не нарушали корпоративную почту. Непрерывный мониторинг продолжается; команда добавляет оповещение о любых новых источниках IP, превышающих дневной порог.

Уроки. Наибольшие риски не были связаны с техническими проблемами — они заключались в не документированных системах, которые были обнаружены только благодаря агрегированным отчетам. Без этапа мониторинга, переход к применению правил привел бы к незаметному сбою этих процессов. Ни один из приведенных здесь процентов или показателей не должен рассматриваться как гарантия результата; они являются реалистичными с оперативной точки зрения, но специфичны для данного гипотетического сценария.

Тенденции и смежные стандарты на 2025–2026 годы

Несколько развитий, которые стоит отслеживать к 2026 году.

DMARCbis. По состоянию на 13 мая 2026 года Черновик RFC IETF: DMARC-DMARCBIS-41 указан в базе данных IETF Datatracker со статусом IESG RFC Ed Queue и заявление от RFC Editor AUTH48, с указанным статусом Proposed Standard. До тех пор, пока не будет присвоен номер RFC и документ не будет опубликован, рассматривайте его как «Интернет-проект» в процессе разработки и проверяйте состояние в Datatracker. Этот проект предназначен для замены RFC 7489 и RFC 9091, если он будет одобрен. Ключевое изменение заключается в том, что DMARCbis заменяет Public Suffix List в качестве механизма определения организационного домена с помощью обхода DNS-дерева, устраняя зависимость от внешнего, вручную поддерживаемого списка.

Черновики спецификации DMARCbis. DMARCbis разделяет работу протокола на три документа: основную спецификацию DMARCbis, отчет о агрегированных данных и отчет об ошибках. По состоянию на 13 мая 2026 года, основная спецификация DMARCbis, согласно IETF Datatracker, находится в статусе RFC Ed Queue и у IESG AUTH48. Также, черновики отчетов об агрегированных данных и об ошибках находятся в статусе IETF DMARC Working Group (draft-ietf-dmarc-aggregate-reporting и draft-ietf-dmarc-failure-reporting) с IESG статусом RFC Ed Queue и статусом у IESG Editor RFC-EDITOR. До тех пор, пока не будут присвоены номера RFC и опубликованы документы, следует рассматривать все три документа как черновики в процессе разработки. Ожидается, что изменение парсера не произойдет только из-за того, что отчет об агрегированных данных был разделен на отдельный документ, но операторы, получающие отчеты, должны отслеживать окончательный отчет об агрегированных данных, прежде чем рассматривать поведение парсера как неизменное.

Изменения тегов DMARCbis. DMARCbis также отменяет три тега RFC 7489 и вводит три новых. pct заменяется двоичным флагом тестирования t=: t=y требует, чтобы получатели применяли политику на один уровень ниже указанного значения p / sp / np (следовательно, p=reject; t=y рассматривается как quarantine, а p=quarantine; t=y как none); t=n (по умолчанию) требует применения указанной политики в том виде, в котором она есть. Опыт эксплуатации показал, что промежуточные значения pct реализовывались непоследовательно у получателей — на практике только pct=0 и pct=100 были надежными — поэтому рабочая группа отказалась от процентного отбора в пользу однозначного сигнала включения/выключения. Также удалены ri и rf, по аналогичным причинам (получатели игнорировали ri, и только одно значение rf было определено). Что касается новых тегов, np= объявляет политику для несуществующих поддоменов (ответов NXDOMAIN), закрывая пробел, который позволяет злоумышленникам подделывать случайные вымышленные поддомены; psd= формализует тег Public Suffix Domain, который изначально был введен экспериментально в RFC 9091, чтобы регистры, такие как gov.uk, могли публиковать осмысленные политики. Существующие записи v=DMARC1 остаются действительными: получатели DMARCbis игнорируют неизвестные теги, а получатели RFC 7489 игнорируют новые — но при развертывании в производственной среде необходимо поддерживать совместимость с RFC 7489 до публикации и фактического внедрения DMARCbis получателями. Рассматривайте t=, np= и psd= как элементы для мониторинга и тестирования, а не как универсальное поведение получателей на сегодняшний день.

Требования Gmail, Yahoo и Outlook к отправителям. Требования Google к массовым отправителям применяются к тем, кто доставляет около 5 000 и более сообщений за 24 часа в личные аккаунты Gmail. В ответах Google на вопросы о правилах отправки указано, что сообщения с одного основного домена, включая поддомены, учитываются в этом пороге, а статус массового отправителя не отменяется автоматически. Google требует от массовых отправителей аутентификацию SPF и DKIM, публикацию политики DMARC, согласование доменов, возможность отписки одним нажатием для маркетинговых и рекламных писем и допустимый уровень жалоб на спам. Yahoo публикует аналогичные рекомендации: внедрить SPF и DKIM, опубликовать действительную политику DMARC как минимум с p=none и обеспечить согласование домена From с доменом SPF или DKIM. В 2025 году Microsoft объявила требования к отправителям для потребительских ящиков Outlook.com / Hotmail.com / Live.com / msn.com: домены, отправляющие в эти сервисы 5 000 и более сообщений в день, должны публиковать SPF и DKIM, успешно проходить обе проверки, публиковать DMARC и обеспечивать согласование SPF и/или DKIM для проверки DMARC. Несоответствующая почта может отклоняться по SMTP с кодом 550 5.7.515.

BIMI. Brand Indicators for Message Identification в настоящее время является IETF Internet-Draft, а не RFC. Он не усиливает аутентификацию сам по себе — он опирается на существующие SPF, DKIM и DMARC. Текущий проект требует сильной политики DMARC как для Organizational Domain, так и для From: domain: p=reject, или p=quarantine с действительным pct=100, и любая политика поддомена (sp) НЕ ДОЛЖНА none. Как BIMI будет обрабатывать флаг тестирования t=y от DMARCbis вместо pct=0, пока не определено в проекте BIMI. Предоставители почтовых ящиков решают, отображать ли индикатор и логотип в нескольких крупных провайдерах, также требуется сертификат Verified Mark (VMC) или Common Mark Certificate (CMC), что является отдельной стоимостью и процессом от самой настройки DNS.

MTA-STS и TLS-RPT. RFC 8461 (MTA-STS) и RFC 8460 (SMTP TLS Reporting) защищают электронную почту при передаче между MTA, обеспечивая TLS и отчетность об ошибках. Они независимы от DMARC, но обычно развертываются вместе с ним в рамках комплексной стратегии безопасности электронной почты.

Список проверок для внедрения

• Определите всех легитимных отправителей, использующих ваш домен в поле «From».
• Проверьте синтаксис вашего записи SPF и количество DNS-запросов; удалите все дублирующиеся записи SPF TXT.
• Включите DKIM на всех поддерживаемых платформах, используя домен для подписи, соответствующий вашему «From».
• Подтвердите соответствие SPF и DKIM для репрезентативных сообщений с каждой платформы.
• Опубликуйте _dmarc.<domain> с p=none и реальным rua адресом получателя.
• Заблокируйте неиспользуемые и припаркованные домены с нулевым SPF, нулевым MX (если они не получают почту) и p=reject DMARC, указывающим на реальный адрес получателя.
• Собирайте агрегированные отчеты в течение нескольких недель. Загружайте их в парсер или сервис.
• Изучите каждый IP-адрес отправителя, который появляется в отчетах. Устраните неизвестные значения до внесения каких-либо изменений в политику.
• Протестируйте весь процесс отправки транзакционных писем, начиная с Microsoft 365 или Google Workspace, включая ESP, CRM, системы выставления счетов, службу поддержки и любые другие системы.
• Начните с p=quarantine с низким pct; отслеживайте; постепенно увеличивайте.
• Переходите к p=reject только тогда, когда отчеты подтверждают, что легитимный трафик чист, и риск перенаправления/списков рассылки для домена приемлем; в противном случае задокументируйте p=quarantine как окончательную политику для этого домена.
• Продолжайте постоянный мониторинг. Пересматривайте SPF, DKIM и DMARC после любых изменений в потоке почты, изменений поставщика или добавления домена.
• Документируйте позицию DMARC в рамках оценки безопасности и доказательства соответствия.

Заключение

DMARC — это не однократное редактирование DNS. Это итеративный операционный процесс: инвентаризация, оснащение мониторингом, исправление выявленных проблем, постепенное внедрение и постоянный контроль. Начальная точка — p=none с отчетностью; зрелая конечная точка зависит от функциональности домена. Специализированные транзакционные и «припаркованные» домены часто находятся в состоянии p=reject, в то время как домены электронной почты общего назначения могут оставаться безопаснее в состоянии p=quarantine, когда неизбежны списки рассылки или перенаправление. Пропуск этого этапа приводит к несанкционированным сбоям в работе электронной почты.

При таком подходе DMARC — это ценный контроль. Он снижает прямую подделку адреса отправителя, обеспечивает постоянный обзор оценок получателей, использующих ваш домен, и предоставляет полезные доказательства охвата аутентификацией, при условии участия получателей и ограничений на доставку отчетов. В сочетании со SPF, DKIM, MFA, Conditional Access, MTA-STS, TLS-RPT, хранением логов, обучением пользователей, реагированием на инциденты и непрерывным мониторингом, это является частью защищенной программы безопасности электронной почты. Само по себе — нет. Настройте его соответствующим образом.

Источники

• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC), Информационные
• RFC 7208 — Фреймворк политики отправителя (SPF)
• RFC 6376 — Подписи DKIM (DomainKeys Identified Mail)
• RFC 8301 — Обновление алгоритма шифрования и использования ключей для DomainKeys Identified Mail (DKIM)
• RFC 8463 — Новый метод криптографической подписи для DomainKeys Identified Mail (DKIM)
• RFC 8601 — Поле заголовка сообщения для указания статуса аутентификации сообщения
• RFC 8617 — Протокол «Аутентифицированная цепочка полученных сообщений» (ARC), экспериментальный
• RFC 8461 — Строгая транспортная безопасность (MTA-STS) для почтовых серверов
• RFC 8460 — Отчетность TLS для SMTP
• RFC 7960 — Проблемы совместимости между DMARC и косвенными потоками электронной почты (списки рассылки, пересылки, шлюзы, посредники)
• RFC 7505 — Запись ресурса «Null MX» для доменов, которые не принимают электронную почту
• RFC 8553 — Изменения в Attrleaf DNS: исправление спецификаций с использованием имени узла, содержащего подчеркивания
• RFC 8616 — Аутентификация электронной почты для международных почтовых сервисов
• RFC 9091 — Экспериментальное расширение DMARC для доменов публичных суффиксов
• IETF Datatracker — проект DMARCbis (DMARCbis, предварительная версия)
• IETF Datatracker — draft-ietf-dmarc-aggregate-reporting
• IETF Datatracker — draft-ietf-dmarc-failure-reporting
• IETF Datatracker — черновик-ietf-dmarc-arc-to-historic
• IETF Datatracker — черновик-adams-arc-experiment-conclusion
• IETF Datatracker — Индикаторы брендов для идентификации сообщений (BIMI), проект Интернета
• Microsoft Learn — Использование DMARC для проверки электронной почты, инструкции
• Microsoft Learn — Отчетность DMARC для MOERA и доменов-поддоменов
• Microsoft Tech Community — Требования Outlook для отправчиков большого объема
• Microsoft Support — Исправление ошибки NDR 550 5.7.515 в Outlook.com
• Google Workspace Admin Help — Предотвращение подделки и спама с помощью DMARC
• Google Workspace Admin Help — Руководство для отправчиков электронной почты
• Google Workspace Admin Help — Часто задаваемые вопросы о руководстве для отправчиков электронной почты
• Yahoo Sender Hub — Лучшие практики и требования для отправчиков
• Yahoo Sender Hub — Часто задаваемые вопросы для отправчиков