Ключевые выводы
- DMARC описан в RFC 7489 (Informational RFC), а проект IETF DMARCbis призван устареть и заменить его в качестве официального Standards Track RFC.
- Он использует результаты SPF и DKIM для проверки подлинности сообщений.
- Владельцы доменов публикуют политики DMARC в DNS, чтобы контролировать обработку неудачной аутентификации.
- DMARC поддерживает отчетность, предоставляя владельцам доменов возможность отслеживать почтовый трафик.
- DMARC защищает от прямой подмены домена и многих фишинговых попыток, которые на это опираются, но не предотвращает подмену доменов или злоупотребление отображаемыми именами.
- Принятие DMARC укрепляет репутацию бренда и повышает эффективность доставки электронной почты.
DMARC (Domain-based Message Authentication Reporting and Conformance) - это протокол аутентификации электронной почты, описанный в RFC 7489 (Informational); его преемник, проект IETF DMARCbis, обновляет и уточняет протокол и призван устареть RFC 7489.
DMARC основывается на SPF (Sender Policy Framework) и DKIM (DomainKeys Identified Mail) для защиты почтовых доменов от спуфинга, фишинга и несанкционированного использования. Публикуя политику DMARC в DNS, владельцы доменов инструктируют принимающие почтовые серверы о том, как обрабатывать сообщения, не прошедшие проверку подлинности. Эта техническая основа делает DMARC краеугольным камнем современной безопасности и доверия к электронной почте.
Что такое DMARC RFC?
IETF опубликовала DMARC в виде RFC 7489 (Informational) в марте 2015 года. Он определяет, как владельцы доменов могут публиковать политики DNS, указывающие получателям, что делать, если сообщение не прошло проверку DMARC.
Изначально протокол был разработан отраслевым консорциумом, в который вошли Google, Microsoft, Yahoo, PayPal и другие компании, работающие под вывеской DMARC.org. Их целью было сокращение мошенничества с электронной почтой путем создания общего способа сигнализации и обеспечения аутентификации на уровне домена; позже эта работа была представлена в IETFкоторая опубликовала ее как RFC 7489. Хотя RFC 7489 является информационным RFC, а не документом Standards Track, он стал де-факто эталоном для реализации DMARC.
Что включает в себя RFC 7489?
RFC 7489 определяет полную структуру для DMARC. Хотя сам документ является техническим, его основные цели просты:
Обеспечить механизм политики
С помощью DMARC владельцы доменов могут публиковать четкие политики, которые указывают получателям, что делать с письмами, не прошедшими проверку подлинности.
Преимущества комплексной отчетности
DMARC также является протоколом отчетности. Это означает, что владельцы доменов могут получать данные о том, какие письма проходят проверку подлинности, а какие нет. Это помогает им отличать легитимные письма от вредоносных.
Сокращение мошенничества с использованием электронной почты
DMARC проверяет, соответствует ли домен RFC5322.From идентификаторам, подтвержденным через SPF или DKIM. Это позволяет предотвратить прямую подделку домена, но не предотвращает подмену похожих доменов или обман отображаемого имени и может быть затронуто непрямыми почтовыми потоками.
Опирайтесь на существующие стандарты
DMARC использует результаты SPF и/или DKIM и добавляет выравнивание идентификаторов, политику (p=) и отчетность (rua/ruf).
Техническая разбивка требований
DMARC оценивает соответствие и применяет политику. Очень важно, что он добавляет новое важное требование: согласование идентификаторов.
Как DMARC использует результаты SPF и DKIM
DMARC не просто проверяет, прошли ли SPF или DKIM; он требует соответствия идентификатора домену RFC5322.From.
Выравнивание SPF
DMARC использует SPF-аутентифицированный домен RFC5321.MailFrom (или HELO) и требует, чтобы он совпадал с доменом RFC5322.From. Это должно быть как минимум организационное совпадение в расслабленном режиме (aspf=r, по умолчанию) или точное совпадение в строгом режиме (aspf=s).
Выравнивание DKIM
DMARC использует домен DKIM d= и требует, чтобы он соответствовал домену RFC5322.From. Он должен быть как минимум организационным в расслабленном режиме (adkim=r, по умолчанию) или точным совпадением в строгом режиме (adkim=s).
Это требование согласования является суперсилой DMARC. Оно напрямую связывает результаты аутентификации с видимым доменом бренда, что закрывает лазейку, которой ранее пользовались злоумышленники.
Режимы политики (p=)
Запись DMARC определяет одну из трех политик, которым должны следовать получатели, если письмо не прошло проверку DMARC:
- p=none: только мониторинг; запрашивать отчеты.
- p=карантин: сигнал о том, что провалившееся письмо является подозрительным (типичная обработка: спам/хлам).
- p=reject: сильный сигнал о том, что неработающая почта должна быть отклонена. Хотя RFC допускает исключения из локальной политики (например, для известных хороших отправителей), основные провайдеры обычно соблюдают эту политику строго для неаутентифицированных попыток подделки.
Функции отчетности (RUA и RUF)
DMARC предоставляет полезную обратную связь через два типа отчетов:
Агрегированные отчеты (RUA)
Отчеты RUA это машиночитаемые XML-резюме (обычно ежедневные) результатов DMARC. Они включают такие данные, как IP-адрес отправителя, результаты SPF/DKIM, детали выравнивания и количество сообщений. Однако эти необработанные XML-файлы плохо читаются человеком, и их трудно анализировать вручную без специальных инструментов. Сайт PowerDMARC DMARC Report Analyzer автоматизирует этот процесс и преобразует сложные данные в интуитивно понятные графики и диаграммы.
Отчеты о сбоях по конкретным сообщениям (RUF, часто называемые "криминалистическими")
Они необязательны и редко отправляются по соображениям конфиденциальности. Многие получатели редактируют или отключают их. DMARCbis документирует эти проблемы и ссылается на отдельный проект отчетов о сбоях, все более отказываясь от отчетов RUF.
DMARCbis и предстоящие изменения
Технологические стандарты быстро меняются, и DMARC не является исключением. DMARCbis - это предстоящая обновленная спецификация протокола DMARC, формализованная IETF. Она создана с учетом уроков, полученных за последние несколько лет, и призвана продвинуть DMARC от "Информационного" RFC до официального "Предлагаемого стандарта".
Воспринимайте это не как революцию или отказ от DMARC, а как эволюцию. Основные изменения и уточнения в DMARCbis включают:
p=карантинное поведение
DMARCbis уточняет семантику карантина и указания для получателей, но все еще позволяет им действовать по своему усмотрению.
Новые условия и реструктуризация
Хотя DMARCbis основан на оригинальном RFC 7489, он был реструктурирован и теперь более прост для восприятия обычным пользователем.
В настоящее время спецификация разделена на три отдельных документа (RFC). К ним относятся:
- Сайт основной документ
- Сайт сводная отчётность спецификация
- Сайт отчёт о сбоях спецификация
Некоторые термины и фразы также были изменены для большей ясности, например:
- "Получатель отчета" вместо "потребитель отчета"
- "Политика оценки владельца домена" вместо "политика DMARC"
- "Исполнение" для p=карантин и p=отклонение
- Режим "Мониторинг" для p=none
Вопросы отчетности
Переадресация может нарушить SPF, а списки рассылки часто нарушают DKIM. DMARCbis теперь не рекомендует использовать политику p=reject, если списки рассылки являются обычными получателями.
Также ужесточаются правила агрегированной отчетности более строгими, а формат XML-отчета был обновлен с учетом новых тегов.
Поощрение РУФ
DMARCbis не рекомендует использовать отчеты RUF из-за соображений конфиденциальности и упоминает отчеты о неудачах в отдельном проекте.
DNS Прогулка по деревьям
Первоначальный метод определения организационного домена в значительной степени опирался на публичный список суффиксов (PSL), который мог быть неполным. DMARCbis официально специфицирует более гибкий и надежный алгоритм "DNS Tree Walk" для обнаружения применимой политики DMARC.
Новые и удаленные метки записей DMARC
Некоторые теги DMARC, такие как "pct", "rf" и "ri", полностью удаляются. Вместо них добавляются новые теги DMARC-записей, такие как "np", "psd" и "t".
Важность для организаций
Понимание DMARC RFC может помочь организациям в нескольких направлениях, включая:
Повышение соответствия
Google, Yahoo, Microsoft и Apple Mail теперь требуют массовые отправители публиковать запись DMARC наряду с другими средствами контроля (SPF/DKIM, выравнивание, низкий уровень спама и т. д.). Несоблюдение этого требования может серьезно повлиять на доставляемость электронной почты.
Избегайте неправильных конфигураций
Непонимание основных концепций RFC, особенно выравнивания, может привести к блокировке законных сообщений электронной почты. Знание RFC 7489 поможет вам устранить неполадки и правильно настроить политики с самого начала.
Для предотвращения ошибок можно также использовать DMARC Record Generator для создания правильной политики. Если у вас уже есть запись и вам просто нужно ее проверить, вы можете воспользоваться инструментом PowerDMARC DMARC Record Checker чтобы убедиться, что она опубликована правильно, прежде чем переходить к политике внедрения.
Множество преимуществ в сфере безопасности
Правильно применяемая политика DMARC с параметром p=reject является одним из наиболее эффективных средств защиты от прямой подмены домена, которая является одной из основных причин компрометации деловой электронной почты и многих фишинговых атак. Внедрив DMARC, вы сможете защитить своих сотрудников, клиентов и репутацию бренда от широкого спектра мошенничества с использованием электронной почты.
Подведение итогов
DMARC RFC обеспечивает прочную фундаментальную основу для защиты доменов от почтового мошенничества. В нем изложены четкие и ясные стандарты и рекомендации по настройке и применению DMARC. Если вы будете строго следовать правилам DMARC RFC, это поможет повысить безопасность электронной почты, защитить репутацию бренда и улучшить качество доставки.
Что еще лучше, так это то, что внедрение и эффективное управление DMARC не обязательно должно осуществляться вручную. Платформа PowerDMARC упрощает весь процесс - от быстрой настройки до тщательного мониторинга и внедрения.
Свяжитесь с PowerDMARC и позвольте экспертам позаботиться о безопасности вашей электронной почты!
Часто задаваемые вопросы
Когда был опубликован RFC 7489?
RFC 7489 был опубликован в марте 2015 года.
Кто может использовать DMARC?
Любая организация или частное лицо, отправляющее электронную почту с домена, может и должна использовать DMARC. Лицензионные сборы и ограничения отсутствуют, что делает этот стандарт доступным для всех, чтобы защитить свой домен от подделки.
Почему крупные почтовые провайдеры требуют DMARC для массовых отправителей?
Обычный пользователь обычно не может понять, является ли сообщение или электронное письмо настоящим или поддельным. Поэтому провайдеры почтовых ящиков должны тщательно следить за тем, какие письма попадают в основной почтовый ящик. DMARC помогает решить эту проблему. Он позволяет отправителям, получателям и провайдерам почтовых ящиков совместно бороться с почтовым мошенничеством. С февраля 2024 года Google/Yahoo требуют аутентификации SPF или DKIM, DMARC с p=none или более сильным, низкий уровень жалоб на спам и соответствие RFC5322.From.
Существуют ли инструменты, облегчающие настройку и применение DMARC?
PowerDMARC предлагает множество таких инструментов и услуг, включая генератор DMARC, проверку, хостинговые услуги и многое другое!
- 10 лучших решений для обеспечения безопасности корпоративной электронной почты в 2026 году — 5 января 2026 года
- Фишинг сотрудников: риски, примеры и советы по предотвращению — 15 декабря 2025 г.
- Locky Ransomware: защититесь от угроз, исходящих из электронной почты — 11 декабря 2025 г.
