Я пытался осмыслить некоторую информацию, которую собрал в Интернете, и надеялся на некоторые разъяснения.
Мы используем Office 365 в качестве нашего почтового сервера.
A.) Действительно ли записи SPF и DKIM что-то делают сами по себе, если DMARC не включен или установлен на p=none?
Б.) Запись SPF определяет, каким почтовым серверам, IP-адресам или внешним доменам разрешено отправлять электронную почту в качестве нашего домена, правильно? Например, мы могли бы разрешить gmail.com или yahoo.com отправлять электронную почту в качестве нашего домена с записью SPF?
или
Когда кто-то пытается отправить электронное письмо из любой точки мира как user@ourdomain.com, это будет наша запись SPF, которая проверяет, что письмо было отправлено из действительного источника, верно?
C.) Согласно моим отчетам DMARC, единственный IP-адрес, который не поддерживает DKIM, - это наш внутренний корпоративный IP. Почему это может быть? Все внешнее проходит DKIM.
* Электронные письма, отправленные внутри компании, от сотрудника к сотруднику, в заголовке указано DKIM = none
* Кажется, я не могу найти никаких писем, в которых написано DKIM = fail.
D.) DKIM больше похож на нас, защищая наших клиентов от получения мошеннических писем. Если только кто-то не попытается подделать наш домен и что-нибудь нам отправить. Верный?
В дополнение к отличному ответу, который написал Микаэль Х, я хотел бы еще немного подчеркнуть придирчивость.
Очень важно понимать, что SPF и DKIM (и DMARC в этом отношении) - это просто набор текстовых записей DNS. Принимающий почтовый сервер должен принимать меры на основе того, что он находит в этих записях, и результатов проверок, для выполнения которых он настроен.
Кроме того, SPF и DKIM не защищают принимающую сторону от спуфинга. Фактически, SPF проверяется по домену электронной почты в адресе возврата, а DKIM сравнивается с доменом в d= значение в подписи DKIM. Оба поля обычно не видны получателю электронного письма без просмотра фактических заголовков этого письма.
Это означает, что и SPF, и DKIM могут пройти, не аутентифицируя поддельный домен. Это то, что DMARC стремится исправить: связь между адресами электронной почты, отображаемыми в почтовом клиенте (FROM поле) и аутентифицированный домен в адресе возврата или DKIM d= стоимость.
Итак, чтобы ответить на ваши вопросы с учетом этого:
A. Да, они позволяют вам аутентифицировать домены, которые вы используете для получения отказов (SPF) и для которых ваша криптографическая подпись (DKIM). Все больше и больше ESP проверяют соответствие DMARC независимо от того, публикуете ли вы такую запись. Определенно, Office 365 работает именно так (проверьте заголовки результатов проверки подлинности для dmarc=bestguesspass). Он влияет на классификацию, он не обрабатывает электронные письма, как если бы они были p=reject политика опубликована.
Б. Нет. SPF не защитит ваш домен от подделки. Если FROM адрес user@ourdomain.com и адрес возврата bounces@spoofersdomain.com и spoofersdomain.com перечисляет отправляющий IP-адрес в своей записи SPF, SPF пройдет. Однако выравнивание DMARC не удастся.
C. Электронные письма не подписываются DKIM. Довольно часто встречается в локальном сервере Exchange, так как подпись DKIM не поддерживается изначально. В ваших отчетах DMARC результат DKIM может отсутствовать. Однако с точки зрения DMARC это будет отображаться как сбой (в policy_evaluated раздел XML документ). Все электронные письма (обычные, без DSN или переадресации), отправляемые из вашего клиента Office 365, должны быть подписаны. Если вы не включили DKIM для некоторых из своих доменов, эти письма будут подписаны selector1-ourdomain-com._domainkey.ourdomain.onmicrosoft.com.
D. Помня, почему DMARC так важен, ответ - нет. Подпись DKIM аутентифицирует домен, используемый в подписи DKIM (d=). Это может быть совершенно другой домен, чем используемый в FROM поле, которое получатель видит в своем почтовом клиенте. DMARC обеспечивает согласование между доменами, используемыми в FROM поле и либо домен в адресе возврата, либо домен, используемый для DKIM-подписи сообщения.
Кроме того, большая часть схем фишинга заключается в подделке того же домена, в котором находится получатель. CxO-мошенничество - один из самых известных примеров.
Я надеюсь, это поможет вам.
A) Да, фильтр спама для принимающего сервера может использовать записи SPF и DKIM самостоятельно для оценки почты, которая, как утверждается, отправлена с вашего домена. DMARC не только добавляет дополнительный уровень безопасности, но и предоставляет получателю возможность автоматически сообщать вам о полученной почте. Анализируя отчеты XML, отправленные получателями почты, вы можете узнать, отправляется ли почта третьими лицами, как если бы из вашего домена.
Б) Да. Например: мы отправляем большую часть нашей почты через Microsoft EOP, но некоторые отправляются напрямую с локального сервера Postfix. Добавляя псевдоним DNS для EOP и конкретный IP-адрес для нашего локального исходящего сервера в нашу запись SPF, мы помечаем оба источника как допустимые.
Просто для придирки: ваша запись SPF сама по себе ничего не проверяет; это просто тупая текстовая строка. Проверка выполняется серверами, которые сравнивают содержимое почтового заголовка с несколькими записями DNS TXT, включая SPF, если он существует.
В) Описанное вами поведение означает, что вы не используете DKIM для подписи почты в своих собственных системах. Это довольно часто встречается в средах на базе Microsoft. Поскольку письмо вообще не подписано, вы не получите ошибку проверки подписи.
Если вместо этого вы добавите подпись DKIM к своему письму и укажете точку заголовка на общедоступном ключе DKIM, который математически не соответствует подписи, или если вы подделали письмо после того, как оно было подписано, вы получите фактическое DKIM сбои.
D) DKIM - это в основном цифровая подпись и указатель на открытый ключ. Он сообщает получателю, что письмо с этим конкретным значением хеш-функции действительно прошло через почтовый сервер, которому вы доверяете как действительный отправитель.