Какие параметры должны быть связаны с DMARC?
Последнее обновление:
5 Время чтения: 5 минут
Электронная почта - одно из самых распространенных средств связи. Но она очень подвержена атакам хакеров и спамеров. Таким образом, внедрение SPF, DKIMи DMARC защищает ваши электронные сообщения и предотвращает их захват угрозами. В этом блоге мы рассмотрим основные параметры DMARC, которые помогут вам начать этот процесс.
Ключевые выводы
- Внедрение DMARC с SPF и DKIM необходимо для защиты ваших почтовых сообщений от поддельных и фишинговых атак.
- Три политики DMARC - отсутствие, карантин и отклонение - определяют, как неаутентифицированные письма будут обрабатываться почтовыми ящиками получателей.
- Использование политики мониторинга (p=none) помогает анализировать активность электронной почты, не влияя на доставку на начальном этапе внедрения DMARC.
- Политики карантина(p=quarantine) направляют почтовые серверы на фильтрацию подозрительных фишинговых попыток в папку спама для дальнейшей проверки.
- Политики отклонения (p=reject) обеспечивают наивысший уровень безопасности, не позволяя несанкционированным письмам попадать в почтовые ящики получателей.
Что такое ДМАРК?
Чтобы понять, какие параметры должны быть связаны с DMARC, вам нужно сначала узнать , что такое DMARC и как он работает.
DMARC - это сокращение от Domain-based Message Authentication Reporting and Conformance. Это протокол аутентификации электронной почты, который позволяет вам создавать и публиковать определенную политику безопасности в отношении процесса аутентификации электронной почты. Он указывает почтовому ящику получателя, как относиться к неаутентичным письмам, отправленным с вашего официального домена.
Упростите безопасность с помощью PowerDMARC!
Как работает DMARC?
DMARC реализуется в сочетании с SPF и DKIM. Владелец домена создает и публикует DNS-запись DMARC у своего DNS-провайдера. Когда с этого домена отправляется письмо (либо вами и вашими сотрудниками, либо злоумышленниками), почтовый сервер получателя проверяет его подлинность, проверяя, опубликована ли в DNS запись DMARC.
Кроме того, сервер получателя выполняет проверки DKIM и SPF, чтобы узнать, действительно ли отправитель является тем, за кого себя выдает. Выполняются следующие проверки:
- Если сообщение имеет действительную DKIM-подпись?
- Если IP-адрес отправителя совпадает с авторизованными отправителями в записи SPF?
- Проходят ли заголовки сообщений тесты на выравнивание домена?
После получения результатов SPF и DKIM почтовый сервер применяет политику. В итоге на адрес электронной почты, указанный для получения отчетов, отправляется отчет под названием DMARC Aggregate Report.
Политики DMARC
Одним из основных параметров DMARC являются три политики DMARC. Вы можете отслеживать их в течение некоторого времени, а затем решить, как почтовые ящики получателей должны относиться к неаутентифицированным письмам, отправленным с вашего домена. Вот три политики:
Политика мониторинга: p=none
Это политика DMARC указывает почтовым серверам доставлять отчеты на адрес, указанный в теге rua или ruf вашей DMARC-записи. Она называется политикой только мониторинга и применяется на начальном этапе соответствия DMARC для анализа активности вашего почтового канала.
Он предлагает информацию о канале электронной почты, но не указывает принимающим серверам, как обращаться с письмами, не прошедшими проверку DMARC.
Политика карантина: p=quarantine
Этот параметр DMARC-записи предписывает принимающим серверам помещать письма, не прошедшие проверку подлинности DMARC, в папку спама. Письма, прошедшие проверку подлинности, будут попадать в папку "Входящие". Это минимизирует вероятность случайного обращения к фишинговому письму, однако такие вредоносные письма все равно будут попадать в папку "Спам".
Политика отклонения: p=отклонить
Параметр p=reject DMARC предписывает почтовым серверам полностью отказывать в приеме писем, не прошедших проверку подлинности DMARC. Все прошедшие проверку электронные письма доставляются в почтовый ящик. Однако существует вероятность ложных отказов, что означает, что значимые и подлинные электронные письма иногда не доходят до адресатов.
Типы тегов DMARC и их назначение
Теги DMARC определяют аспекты параметров DMARC, и не все из них так важны и используются, как другие. Они делятся на три категории.
- Требуется: Это обязательные теги. Каждая запись DMARC TXT должна начинаться с обязательного тега 'v' или версии и добавлять его значение как 'DMARC1'.
- Необязательно, но рекомендуется: Добавлять эти теги необязательно, однако они помогают генерировать отчеты.
- Дополнительно: Вы можете полностью пропустить эти теги.
Функции тегов DMARC
Всего существует 11 тегов, важных для параметров записи DMARC, причем теги "v" и "p" являются обязательными. Давайте узнаем, какова функция каждого тега.
| Имя тега DMARC | Введите . | Функция |
| v (версия) | Требуется | Этот тег DMARC определяет версию. На данный момент существует только одна версия, поэтому его значение фиксировано как v=DMARC1. |
| p (политика) | Требуется | Параметр DMARC показывает режим политики DMARC. Он указывает получателю сообщать, помещать в карантин или отклонять электронные письма, не прошедшие проверку подлинности. |
| адким | Дополнительно | Это сокращение для обозначения режима выравнивания DKIM. Его значение может быть либо строгим (s), либо расслабленным (r). В расслабленном режиме проверка показывает результат pass, если проверенная DKIM-запись адресована домену d=sample.com, а адрес электронной почты отправителя относится к категории [email protected]. В строгом режиме проверка показывает результат pass, если письмо приходит с адреса в домене sample.com. Субдомены не проходят валидацию. |
| aspf | Дополнительно | Этот параметр DMARC обозначает режим выравнивания SPF. Его значение может быть либо Строгим (s), либо Расслабленным (r). По умолчанию используется значение Relaxed "r". |
| sp (политика субдоменов) | Дополнительно | Тег DMARC sp определяет политику субдомена. Режим политики настраивается для вашего основного домена (p). |
| fo (сообщение о неисправности) | Дополнительно | Значение тега DMARC fo по умолчанию равно 0. Оно соответствует вариантам отчетов о сбоях, которые могут выбрать владельцы домена. Доступны следующие варианты: fo=0: отчет о неудаче DMARC/криминалистической экспертизе отправляется вам, если ваше письмо не прошло согласование по SPF и DKIM. fo=1: отчет о сбое DMARC/криминалистической экспертизе отправляется вам, когда ваша электронная почта не прошла согласование по SPF или DKIM. fo=d: отчет о неудаче DKIM отправляется, если DKIM-подпись письма не прошла проверку, независимо от выравнивания fo=s: отчет о неудаче SPF отправляется, если письмо не прошло оценку SPF, независимо от выравнивания. |
| ruf (сообщение о сбое RUI) | Необязательно, но рекомендуется | Он определяет, куда должен быть отправлен отчет DMARC forensic ruf. В настоящее время его отправляют только несколько компаний, соответствующих стандарту DMARC. |
| rua (совокупный отчет RUI) | Необязательно, но рекомендуется | В то время как параметры DMARC объясняются, тег rua показывает адрес электронной почты или веб-сервера, на который компании, предоставляющие отчетность, должны ее доставить. |
| rf (формат отчета) | Дополнительно | Значение этого DMARC-тега по умолчанию - 'afrf'. Он регистрирует форматы отчетов судебной экспертизы. |
| пкт (процент) | Дополнительно | Его значение по умолчанию - '100'. Этот тег указывает процент писем, к которым пытаются применить режим политики Например, "pct = 40" будет отфильтровывать 40% писем. |
| ri (интервал отчета) | Дополнительно | Значение тега ri по умолчанию - '86400'. Он задает временной интервал в секундах между двумя последовательными агрегированными отчетами. |
Резюме
Параметры DMARC работают вместе, чтобы помочь вам предотвратить фишинговые и поддельные атаки с использованием имени вашего бренда. Они работают в сочетании с SPF и DKIM, где политики DMARC применяются, чтобы указать принимающему серверу, как обращаться с письмами, не прошедшими проверку. Три тега: p= none (никаких действий с неудачными письмами не предпринимается), p=quarantine (неудачные письма попадают в папку "Спам" вместо папки "Входящие") и p=reject (неудачным письмам полностью запрещено попадать в почтовые ящики адресатов).
Эксперт по безопасности доменов и электронной почты в PowerDMARC
Аона - менеджер по маркетингу в PowerDMARC, имеет более чем 5-летний опыт написания статей на темы кибербезопасности, специализируясь на безопасности доменов и электронной почты. Ахона получила диплом о высшем образовании по специальности "Журналистика и коммуникации", а с 2019 года начала работать в сфере безопасности.
Последние сообщения Ахона Рудра (см. все)
- Политика защиты от фишинга в Office 365: как ее настроить - 3 июня 2026 г.
- Безопасность ИИ-агентов: риски, передовой опыт и аутентификация электронной почты - 2 июня 2026 г.
- PowerDMARC теперь интегрирован с HaloPSA - 1 июня 2026 г.
