Данная статья переведена с помощью средств машинного перевода. Чтобы просмотреть ее на английском языке, установите флажок Английский. Вы также можете просматривать английский текст во всплывающем окне, наводя указатель мыши на переведенный текст.
Перевод
Английский

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

Exchange Online
 

Последнее изменение раздела:2017-10-09

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

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

  • Адрес "Mail From". Указывает отправителя и адрес, на который следует отправлять уведомления о возврате, если возникнут проблемы с доставкой сообщения. Он задан в конверте сообщения и обычно не отображается почтовым приложением. Такой адрес иногда зовется адресом 5321.MailFrom или адресом reverse-path.

  • Адрес «от» Адреса в качестве адреса отправителя почтового приложения. Этот адрес идентифицирует автора сообщение электронной почты. То есть, почтовый ящик пользователя или системы, отвечает за написание сообщения. Это иногда называется адрес 5322.From.

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

S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
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 we have the right information for your account.
S: 
S: http://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 проходит успешно. Поскольку в почтовом клиенте отображается только адрес "От", пользователь видит, что это письмо отправлено с адреса security@woodgrovebank.com. Ввиду того, что использовалась лишь одна инфраструктура SPF, проверка допустимости адреса woodgrovebank.com никогда не выполнялась.

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

Аналогично записям 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.agari.com; ruf=mailto:d@ruf.agari.com; fo=1" 

Корпорация Майкрософт отправляет свои отчеты DMARC сторонней компании Agari, которая собирает и анализирует эти отчеты.

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

Если вы пользуетесь Office 365 без личного домена, то есть используете домен onmicrosoft.com, вам не нужно ничего делать, чтобы настроить или реализовать DMARC для своей организации. Инфраструктура политики отправителей уже автоматически настроена, и в Office 365 автоматически создается подпись DKIM для исходящей почты. Дополнительные сведения об этой подписи см. в разделе Настройка по умолчанию для DKIM и Office 365.

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

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

  • Какие IP-адреса используются для отправки почты из моего домена?

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

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

Например, предположим, что для отправки почты с домена 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 учитывались сторонние отправители.

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

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

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

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

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

где:

  • domain — домен, который нужно защитить. По умолчанию запись защищает почту из домена и всех его поддоменов. Например, если указать "_dmarc.contoso.com", то DMARC будет обеспечивать защиту из этого домена и всех его поддоменов, таких как housewares.contoso.com или plumbing.contoso.com.

  • TTL — этот параметр всегда должен быть равен одному часу. Срок жизни (TTL) измеряется либо в часах (1 час), либо в минутах (60 минут) или в секундах (3600 секунд). Это зависит от регистратора доменных имен.

  • pct=100 — обозначает, что это правило следует применять в отношении абсолютно всей почты.

  • policy — определяет политику, которой должен руководствоваться принимающий сервер в случае, если почта не прошла проверки DMARC. Для этого параметра можно задать значение "none", "quarantine" или "reject".

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

Сегодня

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

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

Параметру "policy" присвоено значение "quarantine"

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

Параметру "policy" присвоено значение "reject"

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

Создав запись, необходимо обновить ее у регистратора доменных имен. Инструкции по добавлению записи DMARC TXT в свои записи DNS для Office 365 см. в статье Создание записей DNS для Office 365 при самостоятельном управлении записями DNS.

Реализовать 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.

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

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

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

Такая настройка Office 365 обусловлена тем, что некоторая допустимая электронная почта может не пройти проверки DMARC. Например, сообщение может не пройти проверки DMARC, если оно отправлено в список рассылки, который в последствии пересылает его всем получателям, указанным в списке. Если Office 365 отклонит такие сообщения, люди могут никогда не получить допустимую электронную почту. Вместо этого такие сообщения будут по-прежнему не проходить проверки DMARC, однако они будут отмечены как спам, а не отклонены. При необходимости пользователи могут воспользоваться приведенными ниже способами, чтобы получить такие сообщения.

  • Пользователи могут добавить надежных отправителей по отдельности с помощью своего почтового клиента

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

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

Если вы используете Office 365 и ваша основная запись MX не указывает на EOP, вы не сможете воспользоваться преимуществами DMARC. Например, DMARC не будет работать, если вы настроите запись MX таким образом, чтобы она указывала на локальный почтовый сервер, а затем перенаправите почту в EOP с помощью соединителя. В этом случае получающий домен является одним из ваших обслуживающих доменов, тогда как EOP не является основной системой обмена электронной почтой. К примеру, допустим, что в записи 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 и просто воспользоваться соединителями для перенаправления почты. Чтобы проверки DMARC принудительно применялись к вашему домену, в записях MX вашего домена первым следует указать домен EOP.

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

 
Показ: