Определение
DMARC (Domain-based Message Authentication, Reporting, and Conformance) — масштабируемый механизм аутентификации электронной почты, позволяющий владельцу домена опубликовать в DNS машинно-читаемую политику. Она определяет, что должны делать принимающие серверы при провале проверок выравнивания SPF или DKIM, и одновременно открывает им возможность отправлять структурированные отчёты владельцу домена. Три значения политики DMARC — none, quarantine и reject — дают владельцу градуированный контроль над тем, как обрабатывается несанкционированная почта, выдающая себя за исходящую с его домена.
DMARC создан совместно представителями PayPal, Google, Microsoft, Yahoo, ReturnPath и других участников экосистемы email и впервые опубликован как RFC 7489 IETF в марте 2015 года. Спецификация поддерживается рабочей группой DMARC.org. DMARC расширяет и согласует две более ранние стандарты аутентификации: SPF (RFC 7208) и DKIM (RFC 6376), используя их как входные сигналы, не заменяя их.
Как это работает
Политика DMARC публикуется как DNS-запись TXT по адресу _dmarc.<домен>. Типичная запись выглядит так: v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s. Ключевые теги:
v=DMARC1— идентификатор версииp=— политика:none(только мониторинг),quarantine(доставлять в спам/нежелательное) илиreject(полный отказ от сообщения)rua=— URI получателя агрегированных отчётов; туда ежедневно приходят XML-сводки результатов аутентификации от участвующих провайдеровruf=— URI получателя форензических отчётов; туда приходят обезличенные отчёты на уровне сообщения по каждому отказуpct=— процент сообщений, к которым применяется политика (для поэтапного выкатывания)adkim=иaspf=— режим выравнивания:s(строгий, требуется точное совпадение домена) илиr(нестрогий, допускается совпадение поддомена)
Ключевая инновация DMARC — выравнивание идентификаторов. SPF-pass или DKIM-pass считается соответствующим DMARC только если аутентифицированный домен выровнен с доменом заголовка RFC5322.From — того адреса «От:», который видит пользователь. Это закрывает зазор, оставшийся при независимой работе SPF и DKIM: сообщение может пройти SPF на другом домене (envelope sender) и пройти DKIM по стороннему подписывающему домену, но при этом быть мошенническим, если From показывает иной домен. DMARC требует, чтобы хотя бы один из двух — SPF или DKIM — давал выровненный pass.
Агрегированные отчёты (RUA) присылаются как сжатые XML-файлы, обычно в течение 24 часов после окончания периода. Их шлют такие провайдеры, как Google (Gmail), Microsoft (Outlook/Exchange Online Protection), Yahoo Mail, Apple iCloud Mail, Comcast и другие. Отчёты содержат по каждой исходной IP количество сообщений, результаты SPF, DKIM и итог DMARC. Инструменты вроде DMARCIAN, Valimail, Postmark DMARC Digests и Google Postmaster Tools позволяют разбирать и визуализировать эти отчёты.
Где вы это встречаете
DMARC встречается везде, где идёт высокообъёмная или ответственная отправка email. С февраля 2024 года Google и Yahoo требуют, чтобы отправители более 5 000 сообщений в сутки на адреса Gmail или Yahoo Mail имели опубликованную DMARC-запись хотя бы с p=none — серьёзное отраслевое изменение, фактически сделавшее DMARC обязательным для массовых отправителей. Microsoft анонсировала аналогичные требования для потребительских ящиков Outlook.com на 2025 год.
Для конкурсных платформ, рассылающих подтверждения голосов в массовом масштабе, DMARC выполняет две роли. Во-первых, защищает репутацию домена-отправителя, давая принимающим серверам команду отвергать поддельные сообщения — и тем мешая третьим лицам подделывать адрес «От» в фишинговых кампаниях, что подорвало бы доставляемость домена. Во-вторых, агрегированные отчёты DMARC дают канал операционного мониторинга: владелец домена видит у всех участвующих провайдеров, какая доля исходящих писем проходит SPF и DKIM, и заранее замечает ошибки конфигурации, до того как они приведут к массовому провалу подтверждений.
Email-провайдеры — SendGrid, Mailgun, Amazon SES, Postmark, SparkPost — публикуют рекомендации по настройке DMARC параллельно с собственной инфраструктурой отправки. DNS-инструменты MXToolbox DMARC Lookup, DMARC Inspector от DMARCIAN и проверка записи EasyDMARC помогают валидировать опубликованные политики.
Практические примеры
Конкурсная компания в России начинает рассылать подтверждения с нового поддомена confirm.votes.example.com. У родительского домена votes.example.com действует политика p=reject в DMARC. Поскольку SPF- и DKIM-записи для нового поддомена ещё не настроены, подтверждающие письма проваливают выравнивание DMARC и отвергаются Gmail. Администратор по агрегированным отчётам видит 100 % провал DMARC по поддомену, добавляет в DNS соответствующие SPF include и DKIM-селектор и временно меняет политику поддомена (sp=none) на время выкатывания.
Бренд проводит фотоконкурс с призовым фондом 5 миллионов рублей. Мошенник пытается рассылать фишинг с домена конкурса в поле «От», направляя голосующих на поддельную страницу подтверждения для перехвата учётных данных. Поскольку политика DMARC домена — p=reject, Gmail, Outlook, Mail.ru и Yandex Почта отвергают мошеннические сообщения до доставки, защищая участников и репутацию отправителя бренда.
Связанные понятия
DMARC опирается одновременно на SPF-запись и DKIM как на входы аутентификации — DMARC-pass требует, чтобы хотя бы один из них был выровнен с доменом заголовка From. В операциях конкурсов совокупный эффект SPF, DKIM и DMARC на попадание в Inbox — главный технический фактор, определяющий, дойдут ли сообщения Голосования по подтверждению email до получателей. Стандарт BIMI, позволяющий отображать логотип бренда в почтовых клиентах как сигнал доверия, требует политики DMARC p=quarantine или p=reject как предусловия.
