Дальнейшее понимание SPF, DKIM и DMARC
Я пытался осмыслить некоторую информацию, собранную в Интернете, и надеялся на некоторые разъяснения.
Мы используем Office 365, для нашего почтового сервера.
A.) Действительно ли записи SPF и DKIM что-то делают сами по себе, если DMARC не включен или установлен на p = none ?
B.) Запись SPF диктует какие почтовые серверы, IP-адреса или внешние домены могут отправлять электронную почту в качестве нашего домена, правильно? Например, мы могли бы разрешить gmail.com или yahoo.com отправлять электронную почту в качестве нашего домена с записью SPF?
или
Когда кто-то пытается отправить электронное письмо из любой точки мира, как (скрыто) это будет быть нашей записью SPF, которая проверяет, что электронное письмо было отправлено из действительного источника, верно?
C.) Согласно моим отчетам DMARC, единственный IP-адрес, который не поддерживает DKIM, - это наш внутренний корпоративный IP-адрес, почему это может быть? Все внешние данные проходят через DKIM.
* Электронные письма, отправляемые внутри компании, от сотрудника к сотруднику, в заголовке указано DKIM = none
* Кажется, я не могу найти никаких писем, в которых говорится, что DKIM = сбой.
D.) DKIM больше похоже на нас, защищая наших клиентов от получения мошеннических писем. Если только кто-то не попытается подделать наш домен и что-то отправить нам. Верно?
A) Да, фильтр спама для принимающего сервера может использовать записи SPF и DKIM самостоятельно для оценки почты, которая, как утверждается, отправлена из вашего домена. DMARC не только добавляет дополнительный уровень безопасности, но и предоставляет получателю возможность автоматически сообщать вам о полученной почте. Анализируя отчеты XML, отправленные получателями почты, вы можете узнать, отправляется ли почта третьими лицами, как если бы из вашего домена.
B) Да. Например: мы отправляем большую часть нашей почты через Microsoft EOP, но некоторые отправляются напрямую с локального сервера Postfix. Добавляя псевдоним DNS для EOP и конкретный IP-адрес для нашего локального исходящего сервера в нашу запись SPF, мы помечаем оба источника как законные.
Просто для придирки: ваша запись SPF сама по себе ничего не проверяет ; это просто тупая текстовая строка. Проверка выполняется серверами, которые сравнивают содержимое заголовка почты с несколькими записями TXT DNS, включая SPF, если он существует.
C) Поведение, которое вы описываете, означает, что вы не используете DKIM для подписи почты в своих собственных системах. Это довольно часто встречается в средах на базе Microsoft. Поскольку письмо вообще не подписано, вы не получите ошибку проверки подписи.
Если вместо этого вы добавите к своему письму подпись DKIM, а в качестве точки заголовка укажите открытый ключ DKIM, который математически не соответствует к подписи, или если вы подделали письмо после того, как оно было подписано, вы столкнетесь с фактическими сбоями DKIM.
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 = отклонить .
B. Нет. SPF не защитит ваш домен от подделки. Если адрес FROM (скрыт), а адрес возврата (скрыт) и spoofersdomain.com перечисляет IP-адрес отправителя в своей записи SPF, SPF пройдет. Однако выравнивание DMARC не удастся.
C. Электронные письма не подписываются DKIM. Довольно распространено для Exchange Server в локальной среде, поскольку подписывание 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.
Надеюсь, это вам поможет.