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

Важно!

Улучшенный Центр безопасности Microsoft 365 теперь доступен в общедоступной предварительной версии.The improved Microsoft 365 security center is now available. Этот новый интерфейс Центра безопасности Microsoft 365 объединяет Defender для конечной точки, Defender для Office 365, Microsoft 365 Defender и другие решения.This new experience brings Defender for Endpoint, Defender for Office 365, Microsoft 365 Defender, and more into the Microsoft 365 security center. Узнайте о новых возможностях.Learn what's new.

Область примененияApplies to

Протокол DMARC (Domain-based Message Authentication, Reporting, and Conformance) используется в сочетании с инфраструктурой политики отправителей (SPF) и механизмом DKIM (DomainKeys Identified Mail) для проверки подлинности отправителей и подтверждения того, что сообщения, отправленные в конечные почтовые системы из вашего домена, являются доверенными.Domain-based Message Authentication, Reporting, and Conformance (DMARC) works with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate mail senders and ensure that destination email systems trust messages sent from your domain. Реализация DMARC в сочетании с SPF и DKIM обеспечивает дополнительную защиту от спуфинга и фишинга.Implementing DMARC with SPF and DKIM provides additional protection against spoofing and phishing email. DMARC помогает получающим почтовым системам определить, что делать с сообщениями, отправленными из вашего домена, которые не прошли проверки SPF или DKIM.DMARC helps receiving mail systems determine what to do with messages sent from your domain that fail SPF or DKIM checks.

Совет

Посетите каталог Ассоциации информационной безопасности Майкрософт (MISA), чтобы просмотреть сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.Visit the Microsoft Intelligent Security Association (MISA) catalog to view third-party vendors offering DMARC reporting for Microsoft 365.

Как SPF в сочетании с протоколом DMARC обеспечивают защиту электронной почты в Microsoft 365?How do SPF and DMARC work together to protect email in Microsoft 365?

Электронное сообщение может содержать несколько адресов отправителей.An email message may contain multiple originator or sender addresses. Эти адреса могут использоваться для различных целей.These addresses are used for different purposes. Вот примеры некоторых таких адресов.For example, consider these addresses:

  • "Mail From" address — указывает отправителя и адрес, на который следует отправлять уведомления о возврате, если возникнут проблемы с доставкой сообщения."Mail From" address: Identifies the sender and specifies where to send return notices if any problems occur with the delivery of the message, such as non-delivery notices. Этот адрес задан в конверте сообщения и обычно не отображается почтовым приложением.This appears in the envelope portion of an email message and is not usually displayed by your email application. Он иногда называется адресом 5321.MailFrom или адресом reverse-path.This is sometimes called the 5321.MailFrom address or the reverse-path address.

  • "From" address — адрес, который указывается в почтовом приложении как адрес отправителя."From" address: The address displayed as the From address by your mail application. Этот адрес указывает автора сообщения электронной почты,This address identifies the author of the email. Этот адрес указывает автора сообщения, вернее, почтовый ящик человека или систему, где оно было создано.That is, the mailbox of the person or system responsible for writing the message. Это поле иногда зовется адресом 5322.From.This is sometimes called the 5322.From address.

Для предоставления списка авторизованных IP-адресов отправки для указанного домена инфраструктура SPF использует запись DNS TXT. Как правило, проверки SPF выполняются только для адреса 5321.MailFrom. Это означает, что если используется только инфраструктура SPF, то проверка подлинности адреса 5322.From не выполняется. Такое поведение приводит к возникновению ситуаций, когда пользователь может получить сообщение с поддельного адреса 5322.From, которое, тем не менее, успешно прошло проверку SPF. Например, рассмотрим следующую запись SMTP:SPF uses a DNS TXT record to provide a list of authorized sending IP addresses for a given domain. Normally, SPF checks are only performed against the 5321.MailFrom address. This means that the 5322.From address is not authenticated when you use SPF by itself. This allows for a scenario where a user can receive a message which passes an SPF check but has a spoofed 5322.From sender address. For example, consider this SMTP transcript:

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: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

В этой записи имеются следующие адреса отправителей:In this transcript, the sender addresses are as follows:

  • Адрес отправителя (5321.MailFrom): phish@phishing.contoso.comMail from address (5321.MailFrom): phish@phishing.contoso.com

  • Адрес "От" (5322.From): security@woodgrovebank.comFrom address (5322.From): security@woodgrovebank.com

Если вы настроили SPF, то принимающий сервер проверяет адрес "Отправитель" phish@phishing.contoso.com. Если сообщение получено из допустимого источника для домена phishing.contoso.com, то проверка SPF проходит успешно. Поскольку в почтовом клиенте отображается только адрес "От", пользователь видит, что это письмо отправлено с адреса security@woodgrovebank.com. Ввиду того, что использовалась лишь одна инфраструктура SPF, проверка допустимости адреса woodgrovebank.com никогда не выполнялась.If you configured SPF, then the receiving server performs a check against the Mail from address phish@phishing.contoso.com. If the message came from a valid source for the domain phishing.contoso.com then the SPF check passes. Since the email client only displays the From address, the user sees that this message came from security@woodgrovebank.com. With SPF alone, the validity of woodgrovebank.com was never authenticated.

Если используется DMARC, принимающий сервер также проверяет адрес "От". В примере выше, если имеется запись DMARC TXT для адреса woodgrovebank.com, то проверка адреса "От" завершится сбоем.When you use DMARC, the receiving server also performs a check against the From address. In the example above, if there is a DMARC TXT record in place for woodgrovebank.com, then the check against the From address fails.

Что такое запись DMARC TXT?What is a DMARC TXT record?

Аналогично записям DNS для SPF, запись для DMARC представляет собой текстовую запись DNS (TXT), которая позволяет предотвратить спуфинг и фишинг. Записи DMARC TXT публикуются в DNS. Записи DMARC TXT позволяют проверить происхождение сообщения электронной почты путем сверки IP-адреса автора письма с предполагаемым владельцем отправляющего домена. Запись DMARC TXT позволяет определить уполномоченные серверы исходящей электронной почты. Конечные почтовые системы в свою очередь проверяют, были ли получаемые сообщения отправлены уполномоченными серверами исходящей электронной почты.Like the DNS records for SPF, the record for DMARC is a DNS text (TXT) record that helps prevent spoofing and phishing. You publish DMARC TXT records in DNS. DMARC TXT records validate the origin of email messages by verifying the IP address of an email's author against the alleged owner of the sending domain. The DMARC TXT record identifies authorized outbound email servers. Destination email systems can then verify that messages they receive originate from authorized outbound email servers.

Запись DMARC TXT корпорации Майкрософт имеет примерно следующий вид:Microsoft's DMARC TXT record looks something like this:

_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.Microsoft sends its DMARC reports to Agari, a third party. Эта компания собирает и анализирует полученные отчеты.Agari collects and analyzes DMARC reports. Посетите каталог MISA, чтобы просмотреть других сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.Please visit the MISA catalog to view more third-party vendors offering DMARC reporting for Microsoft 365.

Реализация протокола DMARC для входящей почтыImplement DMARC for inbound mail

Вам не нужно абсолютно ничего делать, чтобы настроить протокол DMARC в отношении почты, которую вы получаете в Microsoft 365. Мы позаботились об этом за вас. Если хотите узнать, что происходит с почтой, которая не прошла наши проверки DMARC, ознакомьтесь c разделом Как Microsoft 365 обрабатывает входящую почту, не прошедшую проверки DMARC.You don't have to do a thing to set up DMARC for mail that you receive in Microsoft 365. We've taken care of everything for you. If you want to learn what happens to mail that fails to pass our DMARC checks, see How Microsoft 365 handles inbound email that fails DMARC.

Реализация DMARC для исходящей почты из Microsoft 365Implement DMARC for outbound mail from Microsoft 365

Если вы пользуетесь Microsoft 365 без личного домена, то есть используете домен onmicrosoft.com, вам не нужно ничего делать, чтобы настроить или реализовать DMARC для своей организации. Инфраструктура политики отправителей уже автоматически настроена, и в Microsoft 365 автоматически создается подпись DKIM для исходящей почты. Дополнительные сведения об этой подписи см. в разделе Настройка по умолчанию для DKIM и Microsoft 365.If you use Microsoft 365 but you aren't using a custom domain, that is, you use onmicrosoft.com, you don't need to do anything else to configure or implement DMARC for your organization. SPF is already set up for you and Microsoft 365 automatically generates a DKIM signature for your outgoing mail. For more information about this signature, see Default behavior for DKIM and Microsoft 365.

Если у вас есть личный домен или помимо Microsoft 365 вы также используете локальные серверы Exchange, необходимо вручную реализовать DMARC для исходящей почты. Вот как реализовать DMARC для личного домена:If you have a custom domain or you are using on-premises Exchange servers in addition to Microsoft 365, you need to manually implement DMARC for your outbound mail. Implementing DMARC for your custom domain includes these steps:

Шаг 1. Определение допустимых источников почты для доменаStep 1: Identify valid sources of mail for your domain

Если вы уже настроили инфраструктуру SPF, то вы уже выполнили все необходимые действия. Тем не менее, существует ряд дополнительных факторов, которые следует учитывать при развертывании DMARC. При определении источников почты для домена вы должны задать себе два вопроса:If you have already set up SPF then you have already gone through this exercise. However, for DMARC, there are additional considerations. When identifying sources of mail for your domain there are two questions you need to answer:

  • Какие IP-адреса используются для отправки почты из моего домена?What IP addresses send messages from my domain?

  • Будут ли совпадать домены в адресах 5321.MailFrom и 5322 в сообщениях, отправляемых третьими сторонами от моего имени?For mail sent from third parties on my behalf, will the 5321.MailFrom and 5322.From domains match?

Шаг 2. Настройка SPF для вашего доменаStep 2: Set up SPF for your domain

Теперь, когда у вас есть список всех допустимых отправителей, можно приступать к выполнению инструкций из статьи Настройка SPF для предотвращения спуфинга.Now that you have a list of all your valid senders you can follow the steps to Set up SPF to help prevent spoofing.

Например, предположим, что для отправки почты с домена contoso.com используются Exchange Online, локальный сервер Exchange с IP-адресом 192.168.0.1 и веб-приложение с IP-адресом 192.168.100.100. Тогда запись SPF TXT будет выглядеть следующим образом:For example, assuming contoso.com sends mail from Exchange Online, an on-premises Exchange server whose IP address is 192.168.0.1, and a web application whose IP address is 192.168.100.100, the SPF TXT record would look like this:

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

Рекомендуется, чтобы в записи SPF TXT учитывались сторонние отправители.As a best practice, ensure that your SPF TXT record takes into account third-party senders.

Шаг 3. Настройка DKIM для вашего личного доменаStep 3: Set up DKIM for your custom domain

После настройки инфраструктуры SPF необходимо настроить метод DKIM. DKIM позволяет добавлять цифровую подпись в заголовки сообщений электронной почты. Если не настраивать DKIM и вместо этого позволить Microsoft 365 использовать для вашего домена конфигурацию DKIM по умолчанию, то это может привести к тому, что проверки DMARC будут завершаться сбоем. Это вызвано тем, что в конфигурации DKIM по умолчанию в качестве адреса 5322.From указан начальный домен onmicrosoft.com, а не ваш личный домен. Это приводит к несоответствию адресов 5321.MailFrom и 5322.From в сообщениях электронной почты, отправляемых из вашего домена.Once you have set up SPF, you need to set up DKIM. DKIM lets you add a digital signature to email messages in the message header. If you do not set up DKIM and instead allow Microsoft 365 to use the default DKIM configuration for your domain, DMARC may fail. This is because the default DKIM configuration uses your initial onmicrosoft.com domain as the 5322.From address, not your custom domain. This forces a mismatch between the 5321.MailFrom and the 5322.From addresses in all email sent from your domain.

Если у вас имеются сторонние отправители, которые отправляют почту от вашего имени, и адреса 5321.MailFrom и 5322.From в такой почте не совпадают, то проверки DMARC для такой почты будут завешаться сбоем. Чтобы избежать этого, необходимо настроить DKIM для своего домена с учетом сведений о таких сторонних отправителях. Это позволит Microsoft 365 проверять подлинность электронной почты из таких сторонних служб. Кроме того, с помощью этого метода другие почтовые системы, такие как Yahoo, Gmail и Comcast, могут проверять почту, отправляемую в эти системы сторонними почтовыми службами, так, будто она была отправлена вами. Преимущество этого заключается в том, что ваши клиенты могут устанавливать отношения доверия с вашим доменом, независимо от расположения вашего почтового ящика. Одновременно с этим, Office 365 не будет отмечать сообщения как спам из-за спуфинга, поскольку почта будет проходить проверку подлинности для вашего домена.If you have third-party senders that send mail on your behalf and the mail they send has mismatched 5321.MailFrom and 5322.From addresses, DMARC will fail for that email. To avoid this, you need to set up DKIM for your domain specifically with that third-party sender. This allows Microsoft 365 to authenticate email from this 3rd-party service. However, it also allows others, for example, Yahoo, Gmail, and Comcast, to verify email sent to them by the third-party as if it was email sent by you. This is beneficial because it allows your customers to build trust with your domain no matter where their mailbox is located, and at the same time Microsoft 365 won't mark a message as spam due to spoofing because it passes authentication checks for your domain.

Инструкции по настройке DKIM для вашего домена, включая порядок настройки метода DKIM для сторонних отправителей, чтобы они могли подделывать ваш домен, см. в статье Проверка исходящей электронной почты, отправляемой с личного домена, с помощью DKIM.For instructions on setting up DKIM for your domain, including how to set up DKIM for third-party senders so they can spoof your domain, see Use DKIM to validate outbound email sent from your custom domain.

Шаг 4. Создание записи DMARC TXT для вашего доменаStep 4: Form the DMARC TXT record for your domain

В этом разделе описаны наиболее часто используемые варианты использования синтаксиса для Microsoft 365, хотя существуют и другие. Создайте запись DMARC TXT для вашего домена в следующем формате:Although there are other syntax options that are not mentioned here, these are the most commonly used options for Microsoft 365. Form the DMARC TXT record for your domain in the format:

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

где:where:

  • domain — домен, который нужно защитить.domain is the domain you want to protect. По умолчанию запись защищает почту из домена и всех его поддоменов.By default, the record protects mail from the domain and all subdomains. Например, если указать _dmarc.contoso.com, то DMARC будет обеспечивать защиту почты из этого домена и всех его поддоменов, таких как housewares.contoso.com или plumbing.contoso.com.For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as housewares.contoso.com or plumbing.contoso.com.

  • TTL — этот параметр всегда должен быть равен одному часу. Срок жизни (TTL) измеряется либо в часах (1 час), либо в минутах (60 минут) или в секундах (3600 секунд). Это зависит от регистратора доменных имен.TTL should always be the equivalent of one hour. The unit used for TTL, either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds), will vary depending on the registrar for your domain.

  • pct=100 — обозначает, что это правило следует применять в отношении абсолютно всей почты.pct=100 indicates that this rule should be used for 100% of email.

  • policy — определяет политику, которой должен руководствоваться принимающий сервер в случае, если почта не прошла проверки DMARC. Для этого параметра можно задать значение "none", "quarantine" или "reject".policy specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to none, quarantine, or reject.

Чтобы узнать больше о параметрах, которые следует использовать, ознакомьтесь с понятиями, изложенными в разделе Рекомендации по реализации протокола DMARC в Microsoft 365.For information about which options to use, become familiar with the concepts in Best practices for implementing DMARC in Microsoft 365.

Примеры:Examples:

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

    _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=none"
    
  • Параметру "policy" присвоено значение "quarantine"Policy set to quarantine

    _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=quarantine"
    
  • Параметру "policy" присвоено значение "reject"Policy set to reject

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

Создав запись, необходимо обновить ее у регистратора доменных имен. Инструкции по добавлению записи DMARC TXT в свои записи DNS для Microsoft 365 см. в статье Создание записей DNS для Microsoft 365 при самостоятельном управлении записями DNS.Once you have formed your record, you need to update the record at your domain registrar. For instructions on adding the DMARC TXT record to your DNS records for Microsoft 365, see Create DNS records for Microsoft 365 when you manage your DNS records.

Рекомендации по реализации протокола DMARC в Microsoft 365Best practices for implementing DMARC in Microsoft 365

Реализовать DMARC можно постепенно, чтобы это не влияло на остальной поток обработки почты. Создайте и внедрите план расширения, руководствуясь приведенными ниже действиями. Прежде чем переходить к следующему действию, каждое из этих действий следует сначала выполнить в отношении поддомена, других поддоменов и, наконец, в отношении домена верхнего уровня.You can implement DMARC gradually without impacting the rest of your mail flow. Create and implement a roll-out plan that follows these steps. Do each of these steps first with a sub-domain, then other sub-domains, and finally with the top-level domain in your organization before moving on to the next step.

  1. Организуйте отслеживание влияния реализации DMARCMonitor the impact of implementing DMARC

    Начните с простой записи режима отслеживания для поддомена или домена, запрашивающих у получателей DMARC отправку статистики о сообщениях, которые, как им видно, используют ваш домен. Запись режима отслеживания это запись DMARC TXT, в которой параметру политики присвоено значение "none" (p=none). Многие компании публикуют записи DMARC TXT с параметром "p=none", поскольку они точно не знают, какой объем почты они могут потерять, если применят более строгую политику DMARC.Start with a simple monitoring-mode record for a sub-domain or domain that requests that DMARC receivers send you statistics about messages that they see using that domain. A monitoring-mode record is a DMARC TXT record that has its policy set to none (p=none). Many companies publish a DMARC TXT record with p=none because they are unsure about how much email they may lose by publishing a more restrictive DMARC policy.

    Это можно сделать даже до реализации SPF или метода DKIM в своей инфраструктуре обмена сообщениями. Однако вы не сможете организовать эффективное помещение почты в карантин или ее отклонение с помощью DMARC, пока также не реализуете SPF и DKIM. После внедрения SPF и DKIM в отчетах, создаваемых DMARC, будут указываться сведения о количестве и источниках сообщений, прошедших проверки, а также тех, которые не прошли их. Можно с легкостью увидеть, какой объем допустимого трафика подвергается проверкам, а какой нет. После чего можно устранить любые возникшие проблемы. Вы также сможете увидеть объем отправляемых мошеннических сообщений и их источники.You can do this even before you've implemented SPF or DKIM in your messaging infrastructure. However, you won't be able to effectively quarantine or reject mail by using DMARC until you also implement SPF and DKIM. As you introduce SPF and DKIM, the reports generated through DMARC will provide the numbers and sources of messages that pass these checks, and those that don't. You can easily see how much of your legitimate traffic is or isn't covered by them, and troubleshoot any problems. You'll also begin to see how many fraudulent messages are being sent, and from where.

  2. Запросите у внешних почтовых систем помещение на карантин почты, не прошедшей проверки DMARCRequest that external mail systems quarantine mail that fails DMARC

    Если вы полагаете, что весь или почти весь ваш допустимый трафик защищен с помощью инфраструктуры SPF и DKIM, а также понимаете последствия реализации протокола DMARC, можно внедрить политику карантина. Политика карантина это запись DMARC TXT, в которой параметру политики присвоено значение "quarantine" (p=quarantine). Таким образом вы просите получателей DMARC помещать сообщения из вашего домена, которые не прошли проверки DMARC, в локальный аналог папки нежелательной почты, а не в папки входящей почты ваших клиентов.When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, and you understand the impact of implementing DMARC, you can implement a quarantine policy. A quarantine policy is a DMARC TXT record that has its policy set to quarantine (p=quarantine). By doing this, you are asking DMARC receivers to put messages from your domain that fail DMARC into the local equivalent of a spam folder instead of your customers' inboxes.

  3. Запросите у внешних почтовых систем не принимать сообщения, не прошедшие проверки DMARCRequest that external mail systems not accept messages that fail DMARC

    Последним шагом является реализация политики отклонения. Политика отклонения это запись DMARC TXT, в которой параметру политики присвоено значение "reject" (p=reject). Таким образом вы просите получателей DMARC не принимать сообщения, которые не прошли проверки DMARC.The final step is implementing a reject policy. A reject policy is a DMARC TXT record that has its policy set to reject (p=reject). When you do this, you're asking DMARC receivers not to accept messages that fail the DMARC checks.

  4. Как настроить DMARC для поддомена?How to set up DMARC for subdomain?

    DMARC реализуется путем публикации политики в виде TXT-записи в DNS и является иерархическим объектом (например, политика, опубликованная для contoso.com, будет применяться к sub.domain.contonos.com, если для этого поддомена явным образом не определена другая политика).DMARC is implemented by publishing a policy as a TXT record in DNS and is hierarchical (e.g. a policy published for contoso.com will apply to sub.domain.contonos.com unless a different policy is explicitly defined for the subdomain). Это удобно, так как организации могут указывать меньшее число записей DMARC верхнего уровня для большего покрытия.This is useful as organizations may be able to specify a smaller number of high-level DMARC records for wider coverage. Следует проявлять осторожность при настройке явных записей DMARC поддомена, где не нужно, чтобы дочерние домены наследовали запись DMARC домена верхнего уровня.Care should be taken to configure explicit subdomain DMARC records where you do not want the subdomains to inherit the top-level domain's DMARC record.

    Кроме того, вы можете добавить политику с подстановочным знаком для DMARC, если поддомены не должны отправлять почту, добавив значение sp=reject.Also, you can add a wildcard-type policy for DMARC when subdomains shouldn't be sending email, by adding the sp=reject value. Например:For example:

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

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

Если исходящее из Microsoft 365 сообщение не прошло проверки DMARC, а вы реализовали политику карантина (p=quarantine) или политику отклонения (p=reject), то такое сообщение перенаправляется через Пул доставки сообщений с более высокой степенью опасности для исходящих сообщений.If a message is outbound from Microsoft 365 and fails DMARC, and you have set the policy to p=quarantine or p=reject, the message is routed through the High-risk delivery pool for outbound messages. Возможность переопределить исходящую почту отсутствует.There is no override for outbound email.

Если опубликовать политику отклонения DMARC (p=reject), никто из клиентов в Microsoft 365 не сможет подделать ваш домен, поскольку сообщения не будут проходить через проверки SPF или DKIM для вашего домена при перенаправлении исходящей почты через службу. Однако если опубликовать политику отклонения DMARC, но не применять проверку подлинности через Microsoft 365 абсолютно для всей почты, часть входящей почты может быть отмечена как спам (как описано выше), или она будет отклонена, если не опубликовать SPF и попытаться перенаправить ее через службу в качестве исходящей почты. Это может произойти, например, если при создании записи DMARC TXT вы забыли включить в нее ряд IP-адресов серверов и приложений, отправляющих почту от имени вашего домена.If you publish a DMARC reject policy (p=reject), no other customer in Microsoft 365 can spoof your domain because messages will not be able to pass SPF or DKIM for your domain when relaying a message outbound through the service. However, if you do publish a DMARC reject policy but don't have all of your email authenticated through Microsoft 365, some of it may be marked as spam for inbound email (as described above), or it will be rejected if you do not publish SPF and try to relay it outbound through the service. This happens, for example, if you forget to include some of the IP addresses for servers and apps that send mail on behalf of your domain when you form your DMARC TXT record.

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

Если политика DMARC отправляющего сервера имеет значение p=reject, Exchange Online Protection (EOP) будет отмечать сообщения как поддельные, а не отклонять их.If the DMARC policy of the sending server is p=reject, Exchange Online Protection (EOP) marks the message as spoof instead of rejecting it. Другими словами, в случае исходящей почты служба Microsoft 365 рассматривает политики p=reject и p=quarantine как одинаковые.In other words, for inbound email, Microsoft 365 treats p=reject and p=quarantine the same way. Администраторы могут настроить действия для сообщений, классифицированных как поддельные, в политике защиты от фишинга.Admins can define the action to take on messages classified as spoof within the anti-phishing policy.

Такая конфигурация Microsoft 365 обусловлена тем, что некоторые допустимые сообщения могут не проходить проверки DMARC.Microsoft 365 is configured like this because some legitimate email may fail DMARC. Например, сообщение может не пройти проверки DMARC, если оно отправлено в список рассылки, который в последствии пересылает его всем получателям, указанным в списке.For example, a message might fail DMARC if it is sent to a mailing list that then relays the message to all list participants. Если Microsoft 365 отклонит эти сообщения, получатели могут безвозвратно потерять важную почту.If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Вместо этого такие сообщения будут по-прежнему не проходить проверки DMARC, однако они будут отмечены как спам, а не отклонены.Instead, these messages will still fail DMARC but they will be marked as spam and not rejected. При необходимости пользователи могут воспользоваться приведенными ниже способами, чтобы получить такие сообщения.If desired, users can still get these messages in their inbox through these methods:

  • Пользователи могут добавить надежных отправителей в список с помощью своих почтовых клиентов.Users add safe senders individually by using their email client.

  • Администраторы могут обновить отчеты аналитики спуфинга, чтобы разрешить спуфинг.Administrators can update the Spoof Intelligence reporting to allow the spoof.

  • Администраторы могут создать для всех пользователей правило обработки потока почты Exchange (правило транспорта), разрешающее отправку сообщений для этих конкретных отправителей.Administrators create an Exchange mail flow rule (also known as a transport rule) for all users that allows messages for those particular senders.

Дополнительные сведения см. в статье Создание списков надежных отправителей.For more information, see Create safe sender lists.

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

Все размещенные почтовые ящики в Microsoft 365 теперь получают преимущества ARC с улучшенной надежностью доставки сообщений и защитой от спуфинга.All hosted mailboxes in Microsoft 365 will now gain the benefit of ARC with improved deliverability of messages and enhanced anti-spoofing protection. ARC сохраняет результаты проверки подлинности писем от всех посредников (переходов), когда письмо направляется с исходного сервера в почтовый ящик получателя.ARC preserves the email authentication results from all participating intermediaries, or hops, when an email is routed from the originating server to the recipient mailbox. До ARC изменения, вносимые посредниками в маршрут письма, например правила пересылки или автоматические подписи, могли приводить к сбоям DMARC к моменту поступления письма в почтовый ящик получателя.Before ARC, modifications performed by intermediaries in email routing, like forwarding rules or automatic signatures, could cause DMARC failures by the time the email reached the recipient mailbox. При использовании ARC криптографическая сохранность результатов проверки подлинности позволяет Microsoft 365 подтверждать подлинность отправителя сообщения электронной почты.With ARC, the cryptographic preservation of the authentication results allows Microsoft 365 to verify the authenticity of an email's sender.

В настоящее время Microsoft 365 использует ARC для подтверждения результатов проверки подлинности, если корпорация Майкрософт является подтверждающим центром ARC, но в будущем планируется добавить поддержку сторонних подтверждающих центров.Microsoft 365 currently utilizes ARC to verify authentication results when Microsoft is the ARC Sealer, but plan to add support for third-party ARC sealers in the future.

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

Если в записях MX своего домена первым указан домен, отличный от EOP, то для вашего домена не будут принудительно применяться проверки DMARC.If you have configured your domain's MX records where EOP is not the first entry, DMARC failures will not be enforced for your domain.

Если вы являетесь клиентом, а ваша основная запись MX не указывает на EOP, вы не сможете воспользоваться преимуществами DMARC.If you're a customer, and your domain's primary MX record does not point to EOP, you will not get the benefits of DMARC. Например, DMARC не будет работать, если вы настроите запись MX таким образом, чтобы она указывала на локальный почтовый сервер, а затем перенаправите почту в EOP с помощью соединителя.For example, DMARC won't work if you point the MX record to your on-premises mail server and then route email to EOP by using a connector. В этом случае получающий домен является одним из ваших обслуживающих доменов, тогда как EOP не является основной системой обмена электронной почтой.In this scenario, the receiving domain is one of your Accepted-Domains but EOP is not the primary MX. К примеру, допустим, что в записи MX домен contoso.com указывает сам на себя и использует EOP в качестве вспомогательной записи MX, тогда запись MX для домена contoso.com будет выглядеть следующим образом:For example, suppose contoso.com points its MX at itself and uses EOP as a secondary MX record, contoso.com's MX record looks like the following:

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.All, or most, email will first be routed to mail.contoso.com since it's the primary MX, and then mail will get routed to EOP. В некоторых случаях вы можете даже не указать EOP в записи MX и просто воспользоваться соединителями для перенаправления почты.In some cases, you might not even list EOP as an MX record at all and simply hook up connectors to route your email. Домен EOP не обязательно должен быть первым элементом, для которого требуется выполнить проверку DMARC.EOP does not have to be the first entry for DMARC validation to be done. Просто это обеспечивает проверку, так как мы не можем быть уверены, что все локальные серверы и серверы, не связанные с Office 365, выполняют проверки DMARC.It just ensures the validation, as we cannot be certain that all on-premise/non-O365 servers will do DMARC checks. DMARC может быть принудительно применен для домена клиента (не сервера) при настройке записи TXT DMARC, но такое применение осуществляется сервером-получателем.DMARC is eligible to be enforced for a customer's domain (not server) when you set up the DMARC TXT record, but it is up to the receiving server to actually do the enforcement. Если настроить EOP как сервер-получатель, EOP принудительно применит DMARC.If you set up EOP as the receiving server, then EOP does the DMARC enforcement.

Изображение устранения неполадок DMARC, предоставленное Дэниелом Манде

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

Хотите узнать больше о протоколе DMARC? Эти ресурсы помогут вам.Want more information about DMARC? These resources can help.

См. такжеSee also

Как Microsoft 365 использует инфраструктуру политики отправителей (SPF) для предотвращения спуфингаHow Microsoft 365 uses Sender Policy Framework (SPF) to prevent spoofing

Настройка SPF в Microsoft 365 для предотвращения спуфингаSet up SPF in Microsoft 365 to help prevent spoofing

Проверка исходящей электронной почты, отправляемой с личного домена в Microsoft 365, с помощью DKIMUse DKIM to validate outbound email sent from your custom domain in Microsoft 365