Как поставщику услуг DMARC, нам часто задают этот вопрос: "Если DMARC просто использует SPF и DKIM аутентификацию, зачем нам беспокоиться о DMARC? Разве это не является излишним?"
На первый взгляд может показаться, что это мало что меняет, но реальность совсем другая. DMARC - это не просто комбинация технологий SPF и DKIM, это совершенно новый протокол сам по себе. Он имеет несколько особенностей, которые делают его одним из самых продвинутых стандартов аутентификации электронной почты в мире, и абсолютную необходимость для бизнеса.
Но подожди минутку. Мы не ответили точно, зачем вам нужен DMARC. Что он предлагает, чего нет у SPF и DKIM? Ну, это довольно длинный ответ, слишком длинный для одной записи в блоге. Так что давайте разделим его и сначала поговорим о SPF. На случай, если вы не знакомы с ним, вот краткое вступление.
Что такое SPF?
SPF, или Sender Policy Framework, является протоколом аутентификации электронной почты, который защищает получателя электронной почты от подделок. По сути, это список всех IP-адресов, разрешенных для отправки электронной почты по вашим (владельца домена) каналам. Когда принимающий сервер видит сообщение из вашего домена, он проверяет SPF запись, опубликованную в вашем DNS. Если IP-адрес отправителя находится в этом 'списке', электронная почта доставляется. Если нет, то сервер отклоняет сообщение.
Как вы видите, SPF делает довольно хорошую работу, удерживая в тайне множество неприятных электронных писем, которые могут нанести вред вашему устройству или скомпрометировать системы безопасности вашей организации. Но SPF не так хорош, как некоторые могут подумать. Это потому, что у него есть некоторые очень серьезные недостатки. Давайте поговорим о некоторых из этих проблем.
Ограничения СПФ
Записи SPF не применимы к адресу "From".
Электронная почта имеет несколько адресов для идентификации отправителя: адрес From, который вы обычно видите, и адрес Return Path, который скрыт и требует одного или двух щелчков мыши для просмотра. С включенной функцией SPF принимающий почтовый сервер смотрит на путь возврата и проверяет записи SPF домена с этого адреса.
Проблема здесь заключается в том, что злоумышленники могут использовать это, используя поддельный домен в своем адресе пути возврата (Return Path address) и легитимный (или легальный) адрес электронной почты в разделе От (From). Даже если бы получатель проверял почтовый ID отправителя, он бы сначала увидел адрес From, и обычно не утруждается проверкой пути возврата. На самом деле, большинство людей даже не знает, что существует такая вещь, как адрес Return Path.
SPF можно довольно легко обойти, используя этот простой трюк, и даже домены, защищенные SPF, остаются в значительной степени уязвимыми.
Записи SPF имеют ограничение на поиск DNS
Записи SPF содержат список всех IP-адресов, разрешенных владельцем домена для отправки электронной почты. Однако, у них есть важный недостаток. Принимающему серверу необходимо проверить запись, чтобы убедиться, что отправитель авторизован, и, чтобы уменьшить нагрузку на сервер, записи SPF имеют ограничение на 10 DNS поисков.
Это означает, что если ваша организация использует несколько сторонних производителей, которые посылают электронную почту через ваш домен, запись SPF может в конечном итоге превысить этот лимит. Если правильно не оптимизировать (что не так-то просто сделать самому), записи SPF будут иметь очень ограничительный лимит. Когда вы превышаете этот лимит, реализация SPF считается недействительной и ваша электронная почта не работает SPF. Это может потенциально повредить скорости доставки вашей электронной почты.
SPF не всегда работает, когда электронная почта пересылается.
SPF имеет еще одну критическую точку отказа, которая может навредить доставке вашей электронной почты. Когда вы внедрили SPF на вашем домене и кто-то пересылает вашу электронную почту, пересылаемая электронная почта может быть отклонена из-за вашей политики SPF.
Это происходит потому, что переадресованное сообщение изменило получателя письма, но адрес отправителя остался прежним. Это становится проблемой, потому что сообщение содержит адрес From оригинального отправителя, но принимающий сервер видит другой IP. IP-адрес почтового сервера пересылки не включен в SPF-запись домена оригинального отправителя. Это может привести к тому, что письмо будет отклонено принимающим сервером.
Как DMARC решает эти проблемы?
DMARC использует комбинацию SPF и DKIM для аутентификации электронной почты. Электронная почта должна пройти либо SPF, либо DKIM, чтобы пройти DMARC и быть доставлена успешно. И это также добавляет одну ключевую особенность, которая делает его намного более эффективным, чем SPF или DKIM в одиночку: Отчетность.
С помощью DMARC-отчетов вы ежедневно получаете информацию о состоянии ваших каналов электронной почты. Это включает информацию о согласовании DMARC, данные о письмах, не прошедших аутентификацию, и сведения о возможных попытках подмены.
Если вам интересно, что можно сделать, чтобы не подделать, обратитесь к нашему удобному руководству по 5-ти лучшим способам избежать подделки электронной почты.
- Может ли блокчейн помочь повысить безопасность электронной почты? - 9 мая 2024 г.
- Прокси для дата-центров: Раскрытие рабочей лошадки мира прокси - 7 мая 2024 г.
- Kimsuky использует политику DMARC "None" в последних фишинговых атаках - 6 мая 2024 г.