Dmarc quarantine reject policy not enabled как исправить

Использование протокола DMARC для проверки электронной почты

Знаете ли вы, что можете бесплатно опробовать функции в Microsoft Defender XDR для Office 365 плана 2? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft Defender. Сведения о том, кто может зарегистрироваться и условия пробной версии , см. здесь.

Проверка подлинности, отчетность и соответствие сообщений на основе домена (DMARC) работает с Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM) для проверки подлинности отправителей почты.

DMARC гарантирует, что целевые почтовые системы доверяют сообщениям, отправленным с этого домена. Использование DMARC с SPF и DKIM дает организациям дополнительную защиту от спуфинга и фишинга. DMARC помогает принимающим почтовым системам решить, что делать с сообщениями из этого домена, не прошедшими проверку SPF или DKIM.

Посетите каталог Ассоциации информационной безопасности Майкрософт (MISA), чтобы просмотреть сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.

Вы видели наши пошаговые руководства? Конфигурация 1-2-3s и без излишеств, для администраторов в спешке. См. инструкции по включению отчетов DMARC для Microsoft Online Email адреса маршрутизации (MOERA) и припаркованные домены.

Как SPF в сочетании с протоколом DMARC обеспечивают защиту электронной почты в Microsoft 365?

Электронное сообщение может содержать несколько адресов отправителей. Эти адреса могут использоваться для различных целей. Вот примеры некоторых таких адресов.

• Адрес Mail From: идентифицирует отправителя и указывает, куда отправлять обратные уведомления, если есть проблема с доставкой сообщения (например, уведомления о недоставке). Адрес Mail From отображается в конверте сообщения электронной почты и не отображается вашим почтовым приложением. Иногда его называют адресом 5321. Mail From или адресом обратного пути.
• «From» address — адрес, который указывается в почтовом приложении как адрес отправителя. Адрес From идентифицирует автора электронного письма. Этот адрес указывает автора сообщения, вернее, почтовый ящик человека или систему, где оно было создано. Адрес From иногда называется адресом отправителя 5322. From.

SPF использует запись DNS TXT для перечисления авторизованных отправляющих IP-адресов для данного домена. Как правило, проверки SPF выполняются только для адреса 5321.MailFrom. Адрес 5322.From не проходит проверку подлинности, когда вы используете SPF сам по себе, что допускает сценарий, когда пользователь получает сообщение, прошедшее проверку SPF, но имеет поддельный адрес отправителя 5322.From. Например, рассмотрим следующую запись SMTP:

S: Helo woodgrovebank.com S: Mail from: phish@phishing.contoso.com S: Rcpt to: astobes@tailspintoys.com S: data S: To: "Andrew Stobes" S: From: "Woodgrove Bank Security" S: Subject: Woodgrove Bank - Action required S: S: Greetings User, S: S: We need to verify your banking details. S: Please click the following link to verify that Microsoft has the right information for your account. S: S: https://short.url/woodgrovebank/updateaccount/12-121.aspx S: S: Thank you, S: Woodgrove Bank S: . 

В этой записи имеются следующие адреса отправителей:

• Почта с адреса (5321.MailFrom): phish@phishing.contoso.com
• С адреса (5322.From): security@woodgrovebank.com

Если вы настроили SPF, принимающий сервер выполняет проверка в адресе phish@phishing.contoso.comпочты. Если сообщение получено из допустимого источника для домена phishing.contoso.com, то проверка SPF проходит успешно. Так как почтовый клиент отображает только адрес From, пользователь видит, что это сообщение пришло от security@woodgrovebank.com. Ввиду того, что использовалась лишь одна инфраструктура SPF, проверка допустимости адреса woodgrovebank.com никогда не выполнялась.

Если используется DMARC, принимающий сервер также проверяет адрес «От». В приведенном выше примере при наличии записи DMARC TXT для woodgrovebank.com проверка адреса отправителя завершается неудачей.

Что такое запись DMARC TXT?

Аналогично записям DNS для SPF, запись для DMARC представляет собой текстовую запись DNS (TXT), которая позволяет предотвратить спуфинг и фишинг. Записи DMARC TXT публикуются в DNS. Записи DMARC TXT позволяют проверить происхождение сообщения электронной почты путем сверки IP-адреса автора письма с предполагаемым владельцем отправляющего домена. Запись DMARC TXT позволяет определить уполномоченные серверы исходящей электронной почты. Конечные почтовые системы в свою очередь проверяют, были ли получаемые сообщения отправлены уполномоченными серверами исходящей электронной почты.

Запись DMARC TXT корпорации Майкрософт имеет примерно следующий вид:

_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1" 

Посетите каталог MISA, чтобы просмотреть других сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.

Настройка протокола DMARC для входящей почты

Вам не нужно ничего делать, чтобы настроить протокол DMARC для почты, которую вы получаете в Microsoft 365. Все выполняется автоматически. Если хотите узнать, что происходит с почтой, которая не прошла наши проверки DMARC, ознакомьтесь c разделом Как Microsoft 365 обрабатывает входящую почту, не прошедшую проверки DMARC.

Настройка DMARC для исходящей почты из Microsoft 365

Если вы пользуетесь Microsoft 365 без личного домена (вы используете onmicrosoft.com), инфраструктура политики отправителей уже автоматически настроена и в Microsoft 365 автоматически создается подпись DKIM для вашей исходящей почты (дополнительные сведения об этой подписи см. в разделе Настройка по умолчанию для DKIM и Microsoft 365). Чтобы настроить DMARC для организации, необходимо сформировать запись DMARC TXT для домена onmicrosoft.com и опубликовать ее в DNS с помощью Администратор Office 365 Center> Settings Domains > (Домены>) onmicrosoft.com добавить запись домена>.

Если у вас есть личный домен или вы используете локальные серверы Exchange вместе с Microsoft 365, вам необходимо вручную настроить DMARC для исходящей почты. Настройка DMARC для личного домена включает следующие шаги:

• Шаг 1. Определение допустимых источников почты для домена
• Шаг 2. Настройка SPF для вашего домена
• Шаг 3. Настройка DKIM для вашего личного домена
• Шаг 4. Создание записи DMARC TXT для вашего домена

Шаг 1. Определение допустимых источников почты для домена

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

• Какие IP-адреса используются для отправки почты из моего домена?
• Будут ли совпадать домены в адресах 5321.MailFrom и 5322 в сообщениях, отправляемых третьими сторонами от моего имени?

Шаг 2. Настройка SPF для вашего домена

Теперь, когда у вас есть список всех допустимых отправителей, можно приступать к выполнению инструкций из статьи Настройка SPF для предотвращения спуфинга.

Например, предположим, что для отправки почты с домена contoso.com используются Exchange Online, локальный сервер Exchange с IP-адресом 192.168.0.1 и веб-приложение с IP-адресом 192.168.100.100. Тогда запись SPF TXT будет выглядеть следующим образом:

contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all" 

Рекомендуется, чтобы в записи SPF TXT учитывались сторонние отправители.

Шаг 3. Настройка DKIM для вашего личного домена

После настройки SPF, вам нужно настроить DKIM. DKIM позволяет добавлять цифровую подпись в заголовки сообщений электронной почты. Если вы не настроите DKIM и вместо этого разрешите Microsoft 365 использовать конфигурацию DKIM по умолчанию для своего домена, DMARC может завершиться сбоем. Этот сбой может произойти из-за того, что конфигурация DKIM по умолчанию использует исходный домен onmicrosoft.com в качестве адреса 5321.MailFrom, а не личный домен. Это создает несоответствие между адресами 5321.MailFrom и 5322.From во всех электронных письмах, отправляемых с этого домена.

Если у вас имеются сторонние отправители, которые отправляют почту от вашего имени, и адреса 5321.MailFrom и 5322.From в такой почте не совпадают, то проверки DMARC для такой почты будут завешаться сбоем. Чтобы избежать этого, необходимо настроить DKIM для своего домена с учетом сведений о таких сторонних отправителях. Благодаря этому Microsoft 365 сможет проверять подлинность электронной почты из таких сторонних служб. Кроме того, с помощью этого метода другие почтовые системы, такие как Yahoo, Gmail и Comcast, могут проверять почту, отправляемую в эти системы сторонними почтовыми службами, так, будто она была отправлена вами. Преимущество этого заключается в том, что ваши клиенты могут устанавливать отношения доверия с вашим доменом, независимо от расположения вашего почтового ящика. В то же время Microsoft 365 не будет отмечать сообщения как спам из-за спуфинга, поскольку почта будет проходить проверку подлинности для вашего домена.

Инструкции по настройке DKIM для вашего домена, включая порядок настройки метода DKIM для сторонних отправителей, чтобы они могли подделывать ваш домен, см. в статье Проверка исходящей электронной почты, отправляемой с личного домена, с помощью DKIM.

Шаг 4. Создание записи DMARC TXT для вашего домена

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

_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100" 

• domain — домен, который нужно защитить. По умолчанию запись защищает почту из домена и всех его поддоменов. Например, если указать «_dmarc.contoso.com», то DMARC будет обеспечивать защиту из этого домена и всех его поддоменов, таких как housewares.contoso.com или plumbing.contoso.com.
• TTL — этот параметр всегда должен быть равен одному часу. Срок жизни (TTL) измеряется либо в часах (1 час), либо в минутах (60 минут) или в секундах (3 600 секунд). Это зависит от регистратора доменных имен.
• pct=100 — обозначает, что это правило следует применять в отношении абсолютно всей почты.
• policy — определяет политику, которой должен руководствоваться принимающий сервер в случае, если почта не прошла проверки DMARC. Для этого параметра можно задать значение «none», «quarantine» или «reject».

Чтобы узнать больше о параметрах, которые следует использовать, ознакомьтесь с понятиями, изложенными в разделе Рекомендации по реализации протокола DMARC в Microsoft 365.

Параметру «policy» присвоено значение «none»

_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none" 

_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine" 

_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject" 

После того, как вы сформировали свою запись, вам необходимо обновить запись у своего регистратора доменов.

Почта DMARC

Сообщения не могут отправляться ежедневно.

В этом примере запись DMARC TXT: dmarc.microsoft.com. 3600 IN TXT «v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1» , вы можете увидеть адрес rua . Этот адрес используется для отправки «совокупной обратной связи» для анализа, который используется для создания отчета.

Посетите каталог MISA, чтобы просмотреть других сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365. Дополнительные сведения об адресах rua DMARC см. в статье Доменная проверка подлинности сообщений, создание отчетов и соответствие IETF.org (DMARC).

Рекомендации по реализации протокола DMARC в Microsoft 365

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

1. Организуйте отслеживание влияния реализации DMARC Начните с простой записи режима отслеживания для поддомена или домена, запрашивающих у получателей DMARC отправку статистики о сообщениях, которые, как им видно, используют ваш домен. Запись режима отслеживания — это запись DMARC TXT, в которой параметру политики присвоено значение «none» (p=none). Многие компании публикуют запись DMARC TXT со значением p=none, потому что они не уверены в том, сколько электронной почты они могут потерять, опубликовав более строгую политику DMARC. Это можно сделать даже до реализации SPF или метода DKIM в своей инфраструктуре обмена сообщениями. Однако вы не сможете организовать эффективное помещение почты в карантин или ее отклонение с помощью DMARC, пока также не реализуете SPF и DKIM. При введении SPF и DKIM, отчеты, созданные с помощью DMARC, будут показывать количество и источники сообщений, прошедших эти проверки, по сравнению с теми, которые не прошли. Можно с легкостью увидеть, какой объем допустимого трафика подвергается проверкам, а какой — нет. После чего можно устранить любые возникшие проблемы. Вы также сможете увидеть объем отправляемых мошеннических сообщений и источники отправки.
2. Запросите у внешних почтовых систем помещение на карантин почты, не прошедшей проверки DMARC Если вы полагаете, что весь или почти весь ваш допустимый трафик защищен с помощью инфраструктуры SPF и DKIM, а также понимаете последствия реализации протокола DMARC, можно внедрить политику карантина. Политика карантина — это запись DMARC TXT, в которой параметру политики присвоено значение «quarantine» (p=quarantine). Таким образом вы просите получателей DMARC помещать сообщения из этого домена, которые не прошли проверки DMARC, в локальный аналог папки нежелательной почты, а не в папки входящей почты клиентов.
3. Запросите у внешних почтовых систем не принимать сообщения, не прошедшие проверки DMARC Последним шагом является реализация политики отклонения. Политика отклонения — это запись DMARC TXT, в которой параметру политики присвоено значение «reject» (p=reject). Таким образом вы просите получателей DMARC не принимать сообщения, которые не прошли проверки DMARC.
4. Как настроить DMARC для поддомена? DMARC реализуется путем публикации политики в виде записи TXT в DNS и является иерархической (например, политика, опубликованная для contoso.com, будет применяться к sub.domain.contoso.com, если для поддомена явно не определена другая политика). Это удобно, так как организации могут указывать меньшее число записей DMARC верхнего уровня для большего покрытия. Следует соблюдать осторожность при настройке явных записей DMARC поддоменов, если вы не хотите, чтобы поддомены наследовали запись DMARC домена верхнего уровня. Кроме того, вы можете добавить политику с подстановочным знаком для DMARC, если поддомены не должны отправлять почту, добавив значение sp=reject . Например:

_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com" 

Отклонение DMARC

DMARC p=reject — это политика, которая задается в записи DMARC TXT владельцами домена, чтобы уведомлять поставщиков служб об отклонении электронной почты, которая завершается сбоем DMARC.

Это произошло потому, что, когда OReject задан в качестве значения по умолчанию, отклоненное сообщение было отправлено в карантин на предприятии и в папку Нежелательная Email в потребителе (из-за отсутствия карантина в consumer). Однако при использовании DMARC p=reject сообщение электронной почты отклоняется.

Настройку можно выполнить на портале Microsoft Defender или с помощью командлетов New-AntiPhishPolicy или Set-AntiPhishPolicy в Exchange Online PowerShell. Дополнительные сведения см. в следующих статьях:

• Защита от подделки и политики DMARC отправителя
• Настройка политик защиты от фишинга в EOP
• Настройка политик защиты от фишинга в Microsoft Defender для Office 365

Как Microsoft 365 обрабатывает исходящую почту, не прошедшую проверку DMARC

Если исходящее из Microsoft 365 сообщение не прошло проверки DMARC, а вы реализовали политику карантина (p=quarantine) или политику отклонения (p=reject), то такое сообщение перенаправляется через Пул доставки сообщений с более высокой степенью опасности для исходящих сообщений. Для исходящей электронной почты нет переопределения.

Если вы опубликуете политику отклонения DMARC (p=reject), другой клиент в Microsoft 365 не сможет подделать этот домен, поскольку сообщения не смогут передавать SPF или DKIM для этого домена при ретрансляции исходящего сообщения через службу. Однако, если вы опубликуете политику отклонения DMARC, но не проверите подлинность всей своей электронной почты через Microsoft 365, некоторые из них могут быть помечены как спам для входящей электронной почты (как описано выше) или отклонены, если вы этого не сделаете. Не публикуйте SPF и не пытайтесь ретранслировать его через службу. Это может произойти, например, если при создании записи DMARC TXT вы забыли включить в нее ряд IP-адресов серверов и приложений, отправляющих почту от имени вашего домена.

Как Microsoft 365 обрабатывает входящую почту, не прошедшую проверку DMARC

Если для отправляющего домена используется p=reject политика DMARC , Exchange Online Protection (EOP) отклоняет сообщение по умолчанию. Вы можете настроить политики защиты от фишинга, чтобы учитывать или не учитывать p=quarantine и p=reject в политиках DMARC отправителя, а также указать отдельные действия для p=quarantine и p=reject . Дополнительные сведения см. в статье Защита от подделки и политики DMARC отправителя.

Если политики защиты от фишинга настроены так, чтобы они не соблюдались p=quarantine или p=reject в политиках DMARC, сообщения, неудавшиеся DMARC, помечаются как спам и не отклоняются. Пользователи по-прежнему могут получать эти сообщения в папку «Входящие» с помощью следующих методов:

• Пользователи могут добавить надежных отправителей в список с помощью своих почтовых клиентов.
• Администраторы могут использовать аналитику спуфинга или список разрешенных и заблокированных клиентов, чтобы разрешить сообщения от подделанных отправителей.
• Администраторы могут создать для всех пользователей правило обработки потока почты Exchange (правило транспорта), разрешающее отправку сообщений для этих конкретных отправителей.
• Администраторы создают правило потока обработки почты Exchange для всех пользователей для отклоненной электронной почты, которое не выполняет политику DMARC организации.

Как Microsoft 365 использует Authenticated Received Chain (ARC)

Все размещенные почтовые ящики в Microsoft 365 теперь получают преимущества ARC с улучшенной надежностью доставки сообщений и защитой от спуфинга. ARC сохраняет результаты проверки подлинности писем от всех посредников (переходов), когда письмо направляется с исходного сервера в почтовый ящик получателя. До ARC изменения, вносимые посредниками в маршрут письма, например правила пересылки или автоматические подписи, могли приводить к сбоям DMARC к моменту поступления письма в почтовый ящик получателя. При использовании ARC криптографическая сохранность результатов проверки подлинности позволяет Microsoft 365 подтверждать подлинность отправителя сообщения электронной почты.

В настоящее время Microsoft 365 использует ARC для подтверждения результатов проверки подлинности, если корпорация Майкрософт является подтверждающим центром ARC, но в будущем планируется добавить поддержку сторонних подтверждающих центров.

Устранение неполадок реализации DMARC

Если вы настроили записи MX своего домена, где EOP не является первой записью, сбои DMARC не будут применяться для вашего домена.

Если вы являетесь клиентом и основная запись MX вашего домена не указывает на EOP, вы не сможете воспользоваться преимуществами DMARC. Например, DMARC не будет работать, если вы настроите запись MX таким образом, чтобы она указывала на локальный почтовый сервер, а затем перенаправите почту в EOP с помощью соединителя. В этом сценарии принимающий домен является одним из ваших обслуживаемых доменов, но EOP не является основным MX. К примеру, допустим, что в записи MX домен contoso.com указывает сам на себя и использует EOP в качестве вспомогательной записи MX, тогда запись MX для домена contoso.com будет выглядеть следующим образом:

contoso.com 3600 IN MX 0 mail.contoso.com contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com 

Вся или почти вся электронная почта сначала будет перенаправляться в домен mail.contoso.com, поскольку это основная система обмена электронной почтой, а затем в домен EOP. В некоторых случаях вы можете даже не указать EOP в записи MX и просто воспользоваться соединителями для перенаправления почты. EOP не обязательно должен быть первой записью для проверки DMARC. Просто это обеспечивает проверку того, что все локальные серверы и серверы, не связанные с Office 365, выполняют проверки DMARC. DMARC может быть применен для домена клиента (не сервера), когда вы настроите запись DMARC TXT, но фактическое принудительное выполнение зависит от принимающего сервера. Если настроить EOP как сервер-получатель, EOP принудительно применит DMARC.

Дополнительные сведения

Хотите узнать больше о протоколе DMARC? Эти ресурсы помогут вам.

• Заголовки сообщений защиты от спама включают поля синтаксиса и заголовка, которые Microsoft 365 использует для проверок DMARC.
• Пройдите курс обучения DMARC, предлагаемый компанией M 3 AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
• Воспользуйтесь контрольным списком, представленным на сайте dmarcian.
• Посетите сайт источника по адресу DMARC.org.

Dmarc quarantine reject policy not enabled как исправить

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

«No DMARC record found»

«DMARC record not found»

«Missing DMARC record»

«Unable to find DMARC record»

«No DMARC record published»

«Hostname returned a missing or invalid DMARC record»

«DMARC policy not enabled»

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

Чтобы исправить это, вам нужно начать внедрять DMARC, который является ратифицированным отраслевым стандартом для проверки подлинности электронной почты, для вашего домена.

Что такое DMARC

DMARC расшифровывается как «Domain-based Message Authentication, Reporting & Conformance». Это протокол проверки подлинности электронной почты со встроенными функциями отчетности и применения политик. DMARC построен на основе двух других широко распространенных протоколов электронной почты, SPF и DKIM. DMARC проверяет результаты, возвращаемые SPF и DKIM, и определяет, проходит ли входящая электронная почта аутентификацию или нет, и, в зависимости от политики, указанной в записи DMARC, предпринимает определенные действия для предотвращения попыток злонамеренной подделки.

Вот визуальное представление о том, как работает DMARC, с сайта dmarc.org:

См. официальную спецификацию DMARC здесь: DMARC RFC7489.

Что такое запись DMARC

Запись DMARC — это запись типа TXT, опубликованная для домена в DNS владельцем или администратором домена. Когда принимающему почтовому серверу необходимо проверить входящую электронную почту по DMARC, он будет искать запись DMARC в домене, извлеченную из адреса электронной почты отправителя.

Запись DMARC определяет политику DMARC, которая применяется, когда электронная почта не проходит аутентификацию DMARC с использованием тега p, например, none (никаких действий), quarantine (переместить в спам) или reject (полностью отклонить электронное письмо).

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

Вот пример записи DMARC:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected];

Приведенная выше запись DMARC предписывает помещать в карантин сообщения электронной почты, не прошедшие проверку подлинности, сводные отчеты DMARC следует отправлять на адрес [email protected], а отчеты судебной экспертизы следует отправлять на адрес [email protected].

Как исправить «No DMARC Record Found»

Эту проблему легко исправить: нужно создать DMARC-запись с соответствующими настройками, опубликовать ее в DNS, а затем проверить.

Вот 3 шага, чтобы исправить «No DMARC Record Found».

1. Создать запись DMARC

Прежде чем мы сможем его опубликовать, используйте наш бесплатный DMARC record generator, чтобы создать запись DMARC.

2 вещи, чтобы отметить здесь. Во-первых, если вы внедряете DMARC впервые, скорее всего, вам нужно установить политику на none (p=none), что переводит DMARC в режим мониторинга. Это никоим образом не влияет на ваши потоки электронной почты, но позволяет вам получать отчеты DMARC, которые дают представление о вашем статусе аутентификации электронной почты.

Во-вторых, вы можете запросить у DMARC отправку сводных отчетов на почтовый ящик, к которому у вас есть доступ, указав тег rua на этот почтовый ящик. Если вы используете DMARCLY’s dashboard для создания такой записи DMARC, она также настроит для вас почтовый ящик. Таким образом, вам не нужно беспокоиться о настройке почтового ящика и его обслуживании.

2. Опубликовать запись DMARC

DMARC работает, публикуя запись в DNS, чтобы она была доступна для принимающих почтовых серверов. После создания записи вам необходимо войти в панель управления DNS-провайдера домена, чтобы добавить запись.

Например, если ваш домен domain.com размещен на Cloudflare, вам необходимо войти в Cloudflare.

Вот несколько ссылок на руководства по добавлению записи DMARC с различными службами DNS:

• Как добавить запись DMARC в Cloudflare
• Как добавить запись DMARC в Namecheap
• Как добавить запись DMARC в GoDaddy
• Как добавить запись DMARC в cPanel

3. Проверьте запись DMARC

После публикации записи вы можете использовать нашу бесплатную онлайн-проверку DMARC, чтобы убедиться, что она действительно находится в DNS и доступна для всех.

Protect Business Email & Improve Email Deliverability

Get a 14 day trial. No credit card required.

DMARC

В Unisender есть все для рассылок: можно создавать и отправлять клиентам письма и SMS, настроить чат-бота и делать рассылки в Telegram и даже собрать простой лендинг для пополнения базы контактов.

DMARC (domain-based message authentication reporting and conformance) — это политика защиты пользователей от спама и фишинговых писем.

Зачем нужна политика DMARC

DMARC позволяет противостоять фишингу — мошенничеству, целью которого является кража конфиденциальных данных пользователя (логинов, паролей, данных кредитных карт). Главный инструмент фишинга — email-рассылки. Обычно злоумышленники маскируют свои письма под сообщения известных компаний, используя их домены. Если пользователь следует инструкциям из такого письма, он теряет личные данные и нередко деньги. А компания получает существенный репутационный ущерб.

Если же у компании настроен DMARC, то письмо, которое отправят мошенники от ее имени, либо вовсе не будет доставлено, либо будет помечено как подозрительное.

Как работает DMARC

DMARC — протокол, который указывает серверу, что делать с письмом, если записи DKIM и SPF окажутся некорректны. Корректные DKIM и SPF подтверждают, что письмо отправлено от имени домена, указанного в поле «От:» в письме.

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

Разберемся, чем отличаются эти записи.

DKIM работает так: в письме есть зашифрованные данные о том, кем и когда было отправлено письмо. Почтовый провайдер, Gmail или Mail.ru, получает эти данные вместе с письмом. Провайдер расшифровывает их с помощью публичного ключа, выложенного на домене, с которого отправлено письмо. Если данные совпадают — значит, это честный отправитель, письмо можно пропускать во «Входящие». Если нет — мошенник, письмо отправляется в «Спам».

SPF показывает, разрешено ли конкретному серверу отправлять письма с этого домена. Сервер определяется по IP-адресу. Например, когда вы отправляете рассылку через Unisender или настраиваете корпоративную почту на Mail.ru, вы делегируете серверам Unisender и Mail.ru право отправлять письма с вашего домена.

SPF выявляет доверенного отправителя по IP

Теперь разберемся с DMARC. Эта запись:

• указывает почтовому провайдеру, что делать с письмом в зависимости от результатов прочтения DKIM и SPF;
• говорит серверу отправить отчет на почту администратора домена (то есть вам или вашему системному администратору) с информацией, какие письма были отправлены и как провайдер поступил с письмами.

DMARC говорит серверу, что делать с письмами, которые не прошли проверку

Чтобы лучше разобраться, посмотрим, как эти протоколы работают при отправке обычной рассылки.

Как провайдер проверяет письма с учетом настроек DMARC

Допустим, вы отправили рассылку через Unisender пользователю на Mail.ru.

После того как письмо получает провайдер подписчика (Mail.ru), он проверяет репутацию домена, наличие email и домена в черных списках, IP-адреса серверов, с которых отправлено письмо. В рамках этой проверки почтовый провайдер:

• Расшифровывает и верифицирует DKIM. Точно ли от этого домена отправлено письмо, или это подделка.
• Расшифровывает и верифицирует SPF. Разрешено ли слать письма от имени этого домена этому IP.
• Применяет политику, прописанную в DMARC. Допустим, в DMARC написано отправить в «Спам» тех, у кого DKIM не совпадает, и отослать отчет об этом администратору домена.

Далее к письму применяются стандартные спам-фильтры.

Варианты развития событий после проверки:

• Письмо пропущено и попадает во «Входящие». Если DKIM и SPF в порядке, а спам-фильтры пройдены.
• Письмо добавлено в карантин (в «Спам»). Если DKIM не совпадает и/или спам-фильтры не пройдены.
• Письмо отклонено (не доставлено). Индивидуальные причины: к примеру, у пользователя забит почтовый ящик.

После распределения писем отправителю высылается автоматический отчёт, где написано, что произошло с отправленными письмами.

Процесс проверки письма почтовым провайдером

Как настроить DMARC

1. Зайдите в панель управления хостингом вашего сайта.
2. Найдите в настройках управление DNS-записями.
3. Внесите новую TXT-запись DMARC. Запись TXT — это тип записи DNS в текстовом формате, которая говорит внешним источникам, что делать. Самые распространённые записи мы перечислили в примерах ниже. Можете скопировать запись оттуда.
4. Сохраните внесенные изменения.

Например, на хостинге Fornex TXT-записи редактируются в разделе «Домены»

Примеры записей DMARC и что они означают

Вы можете скопировать запись, которая подходит для вашей задачи.

Пример 1. Если не делаете рассылки.

Если у вас небольшой сайт, вы не делаете массовую рассылку и используете только корпоративную почту, вам достаточно базовой записи DMARC:

"v=DMARC1; p=none;"

Запись есть, а политика — ничего не делать.

Пример 2. Если делаете рассылки.

Если вы делаете рассылки, вам нужно прописать DMARC так, чтобы вы получали отчёт об отправках. Политику лучше указать none, так как вы пока не знаете, какие еще письма отправляются с вашего домена. Если вы поставите quarantine, можете отправить хорошие, но неправильно настроенные письма в «Спам».

"v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld"

Это один из самых популярных вариантов записи.

Тег «rua» с адресом означает, что на эту почту будет приходить отчёт. Упростить чтение отчётов можно с помощью сервиса Uriports .

Пример 3. Отклонять все сообщения, которые не прошли проверку DMARC.

Такая запись будет означать, что все письма, у которых не совпадает DKIM, не будут доставлены. Ее можно использовать, если вы уверены, что письма отправляете только вы и всё у вас настроено корректно. Отчетов вы получать не будете.

"v=DMARC1; p=reject"

Пример 4. Отклонять все сообщения, которые не прошли проверку DMARC, и отправлять все отчёты на ящик admin@test.ru.

Используйте такую запись, когда точно знаете, что вас взломали и от вашего имени отправляют спам. Но сначала убедитесь, что DKIM настроен. Не забудьте вписать ваш email вместо admin@test.ru.

"v=DMARC1; p=reject; rua=mailto:admin@test.ru"

Пример 5. 30% сообщений, которые приходят от вашего домена, но не проходят проверки DMARC, помещать в карантин.
Запись подходит, если вы начали понемногу работать с доставляемостью. Тогда 30% писем будут проверяться на DKIM и отправляться в «Спам», если он не соответствует. А к остальным сообщениям карантин применяться не будет.

"v=DMARC1; p=quarantine; pct=30"

Что писать в настройках DMARC

Теги DMARC бывают обязательные и не обязательные. Обязательные — это v=DMARC1 и p= со значением политики.

"v=DMARC1; p=none;"

v=DMARC1 — версия протокола DMARC, должна быть 1. Запись позволяет провайдеру распознать, что именно эта TXT-запись определяет политику DMARC. Если этот параметр не будет идти первым в записи, DMARC не распознается.

p — это Requested Mail Receiver Policy, то есть что именно сделать с письмом, если DKIM не прошел проверку.

У политики может быть три варианта значений:

• p=none — не предпринимать особых действий, или все на усмотрение почтового провайдера;
• p=quarantine — отправить в «Спам»;
• p=reject — не принимать письмо.

Кроме обязательных тегов, можно указать дополнительные. Они будут указывать, какие отчёты и куда отправлять или к какому проценту писем применять политику. Перечислим необязательные теги:

• aspf и adkim позволяют проверять SPF и DKIM и могут принимать значения r (relaxed) — мягкая проверка и s (strict) — строгая; для начала выбирайте мягкую проверку, чтобы не заблокировать некорректно настроенные, но нужные письма от вашего домена, например, автоматическую отправку счетов из 1С;
• pct отвечает за % писем, подлежащих фильтрации по этому протоколу. Если не заполнено, то будут фильтроваться все письма. Если pct=20 — только 20% писем.
• sp — политика субдомена (или субдоменов), которая работает так же, как и политика домена. Когда вы делаете массовую рассылку, почта отправляется с разных поддоменов на вашем домене. Вы можете регулировать каждый из них.
• rua — email, на который раз в сутки будет приходить агрегированный отчёт в XML. Этот отчёт и поможет узнать, кто отправляет письма от вашего имени и какие письма вообще отправляются от вашего домена.
• rf — отчёт, если письмо не прошло проверку;
• fo — failure reporting options, если механизм отчёта не сработал:
  • fo=0 (используется по умолчанию) — отправить отчёт, если не пройден ни один этап аутентификации;
  • fo=1 — если не пройден хотя бы один этап аутентификации;
  • fo=d — если не пройдена DKIM;
  • fo=s — если не пройдена SPF.

  Какую политику DMARC выбрать

  В настройке DMARC самое сложное понять, какая политика подойдет для ваших текущих задач.

  None — это просто доставлять все письма. Такая политика подходит, когда вы только начали настраивать DMARC и хотите видеть, от кого вообще отправляется почта с вашего домена. Вы же не в курсе всех в вашей компании, кто отправляет письма, в том числе автоматические. Это могут быть разработчики, бухгалтерия (которая подключила 1С), маркетологи из других отделов.

  Quarantine — это политика карантина. С этой пометкой письма в зависимости от почтового провайдера будут:

  • отправлены в спам;
  • отмечены к более строгой проверке;
  • помечены как подозрительные у пользователя во «Входящих».

  

  Пример пометки письма как подозрительного в Gmaill

  Reject — самая строгая политика и самый высокий уровень защиты. Все письма, которые не прошли проверку SPF и/или DKIM, будут заблокированы. Казалось бы, выбираем reject и все защищены ��. Но тут есть нюансы.

  DKIM/SPF корректно не работают в случае, если:

  • пользователи настроили пересылку писем с одного ящика на другой, такие письма от вашего имени не будут доставляться;
  • сервис, через который вы отправляете письма, например, платежка, не позволяет прописать DMARC, DKIM и SPF;
  • вы забыли внести сервис рассылок или CRM в белый список отправителей, или белый список работает некорректно, тогда все массовые рассылки по вашему же выбору не будут доставляться пользователям;
  • другие виды ошибок и поломок в DMARC-записи.

  Если вы настроите политику reject, во всех этих случаях письма не будут доставляться отправителям.

  Эксперты советуют сначала прописать в политику DMARC политику p=none и корректные отчёты с помощью тегов rua и fo. В отчётах будет видно, с каких адресов уходят письма и что с ними происходит. Не исключено, что вы найдете и мошеннические отправки.

  Затем продумать, что нужно изменить в рассылке, чтобы в политике DMARC можно было указать quarantine. В этой стратегии нужно учитывать интересы всех отделов, которые работают с доменом и сайтом. Важно убедиться, что у всех корректно настроены письма и прописаны SPF, DKIM, DMAR, тогда письма из бухгалтерии или биллинга не будут отмечаться как подозрительные.

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

  Служба заботы о клиентах помогает настроить политику DMARC для клиентов. Если вы клиент Unisender, просто обратитесь в чат поддержки.

  Как исправить ошибку DMARC policy

  DMARC (Domain-based Message Authentication, Reporting, and Conformance) — это протокол аутентификации электронной почты, который соответствует стандартам DKIM и SPF. С помощью DMARC можно защитить почтовый домен от использования в рассылке спама и фишинговых писем.

  Например, если компания включила политику DMARC для своего корпоративного почтового домена, то письмо, отправленное мошенниками или спамерами, от имени этого домена, не дойдет до получателей или попадет в спам , в зависимости от принятой политики.

  

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

  • none — письмо доставляется в папку «Входящие» получателя;
  • quarantine — письмо попадает в папку «Спам»;
  • reject — письмо отклоняется.

  Владельцы почтовых доменов, которые настроили политику, сами решают, что будет с письмом, если оно не пройдет проверку DMARC.

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

  В статье рассмотрим, что делать, если вы столкнулись с ошибкой DMARC policy.

  Ошибка DMARC policy: как решить проблему

  Почта Mail.Ru для всех бесплатных доменов почтового сервиса включила DMARC. Теперь письма с сайтов, отправленные с доменов бесплатных почтовых ящиков — mail.ru, list.ru, inbox.ru, bk.ru — могут быть отклонены с указанием ошибки «550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489)». Согласно введенной политике, письма, отправленные с помощью функции PHP-mail, с указанием в почтовых заголовках ящика, который принадлежит Mail.Ru, отклоняются.

  Есть несколько способов решить проблему. Чтобы исправить ошибку, вы можете:

  • Настроить SMTP-авторизацию. В этом случае менять адрес электронной почты не нужно.
  • Изменить адрес электронной почты в скрипте рассылки, в поле «From».
  • Изменить адрес, от имени которого отправляются письма, в админке CMS.

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

  Также изменить ящик необходимо в php .ini. Для этого вам нужно в панели управления хостингом открыть редактирование файла php.ini, найти строку sendmail_path = «/usr/sbin/sendmail -t -i -f e-mail@mail.ru» и заменить значение e-mail@mail.ru на почтовый домен, не относящийся к доменам mail.ru, list.ru, inbox.ru, bk.ru. Желательно указать электронный адрес на вашем почтовом домене.

  Похожие публикации:

  1. L sep что это
  2. Makefile phony что это
  3. Как открыть 3d модель в blender
  4. Ожидание других участников в ватсапе как убрать