Sender Policy Framework (SPF): уровень защиты в инфраструктуре электронной почты

Опубликовано: 2020-03-04

Случалось ли вам когда-нибудь, чтобы кто-то (шутливо или злонамеренно) брал ваш телефон и писал кому-то, притворяясь вами? Это не очень хорошо, не так ли? Даже после того, как вы разъясните правду получателю, он, скорее всего, будет с осторожностью относиться ко всем вашим сообщениям в будущем. И вы, вероятно, будете намного осторожнее с теми, кому вы позволите одолжить свой телефон. Доверие было нарушено.

Аналогичный сценарий возможен и в мире электронной почты, и потенциальным фишерам не нужны ваши имя пользователя и пароль, чтобы выдать себя за ваш бизнес. Страшно, правда?

К счастью, мы знаем простой и не очень секретный способ защитить репутацию вашего бренда. Он называется Sender Policy Framework (SPF) и спасает репутацию электронной почты.

Когда электронная почта отправляется с одного сервера на другой, для передачи сообщения от отправителя получателю используется простой протокол передачи почты (SMTP). В качестве службы SMTP Twilio SendGrid упрощает этот процесс.

Одним из недостатков безопасности в инфраструктуре электронной почты является способность любого отправителя или хоста идентифицировать себя и свою электронную почту как любой домен, который они хотят (вроде того, как люди создали ТОННЫ аккаунтов Дональда Трампа в Твиттере). Это мешает получателям поверить в то, что сообщение действительно от того, от кого оно написано. Это также беспокоит отправителей, зная, что кто-то может отправлять почту с их домена и потенциально наносить ущерб репутации их бренда.

Получатели теряют доверие к подлинности электронной почты, а отправители становятся параноидальными самозванцами, выдающими себя за свой бренд — никому не на пользу! Частью решения является запись SPF, которая хранится в записи txt в DNS. В этой статье мы собираемся изучить все, что связано с SPF — от того, что это такое, до обнаружения ошибок с помощью ваших собственных, мы рассмотрим все это.

Что такое SPF-запись?

SPF расшифровывается как Sender Policy Framework. Это метод проверки подлинности электронной почты, который помогает определить почтовые серверы, которым разрешено отправлять электронную почту с определенного домена. Используя этот протокол проверки, интернет-провайдеры могут определить, когда спуферы и фишеры пытаются подделать электронные письма из вашего домена, чтобы отправить вредоносную электронную почту вашим пользователям.

С помощью SPF получатели могут быть уверены, что получаемые ими сообщения электронной почты исходят от того, кого они ожидают. И отправители могут быть спокойны, зная, что фишеры не подделывают электронную почту и не выманивают аудиторию из своего бренда.

С технической точки зрения запись SPF представляет собой короткую строку текста, которую администратор домена добавляет в свою текстовую запись. Запись txt хранится в DNS (системе доменных имен) вместе с их записями A, PTR и MX. Запись SPF выглядит примерно так:

"v=spf1 ip4:12.34.56.78 include:example.com -все"

Как работает SPF

Приведенная выше строка текста используется, чтобы сообщить принимающему SMTP-серверу, каким хостам разрешено отправлять почту с данного домена.

Запись SPF обычно проверяется в самом начале SMTP-диалога, задолго до того, как тело сообщения будет передано. При попытке отправить сообщение между отправителем и сервером-получателем открывается TCP-соединение.

Как только соединение установлено, выдается команда HELO, которая, по сути, сообщает принимающему серверу, какой домен пытается отправить ему почту. Затем следует команда MAIL FROM, которая сообщает принимающему серверу, с какого адреса электронной почты пришло сообщение. Домен, найденный в команде MAIL FROM (также известный как конверт из и обратный путь), является доменом, используемым для проверки записи SPF.

Итак, предположим, что сообщение было получено, а адрес MAIL FROM — [email protected]. Принимающий сервер проверит общедоступные записи DNS для example.com и найдет запись TXT, начинающуюся с v=spf1. Если нет записи TXT, начинающейся с v=spf1, аутентификация пройдет. Если имеется более одной записи TXT с v=spf1, может возникнуть ошибка.

Предположим, что он найден, и он выглядит как наш предыдущий пример:

"v=spf1 ip4:12.34.56.78 include:example.com -все"

Теперь принимающий сервер проверит, включен ли IP-адрес SMTP-клиента, пытающегося отправить сообщение, в запись SPF. Если IP-адрес указан, сообщение пройдет аутентификацию SPF.

Суть в мельчайших подробностях: разбивая каждую часть записи SPF

Запись SPF состоит из различных механизмов, в том числе:

ВКЛЮЧАТЬ

Всегда следует доменное имя. Когда принимающий сервер сталкивается с механизмом включения, проверяется запись SPF для этого домена. Если IP-адрес отправителя отображается в этой записи, почта аутентифицируется и проверка SPF завершена. Если он не найден, проверка SPF переходит к следующему механизму.

А

Также следует доменное имя. Однако в этом случае SPF просто проверяет IP-адреса, связанные с этим доменом. Если он совпадает с IP-адресом отправителя, он проходит и проверка SPF останавливается. Если нет, он переходит к следующему механизму.

МХ

Похож на «А». За ним всегда следует доменное имя. Если указанный домен разрешается в IP-адрес отправляющего клиента, проверка подлинности проходит и выполняется проверка SPF. Если нет, он переходит к следующему механизму.

IP4 и IP6

Всегда следует определенный IP-адрес или диапазон CIDR. Если IP-адрес отправляющего клиента указан после любого механизма IP4 или IP6, аутентификация пройдет и будет выполнена проверка SPF. Если нет, он переходит к следующему механизму.

PTR

Никогда не следует включать в записи SPF. По некоторым техническим причинам они подвержены ошибкам и требуют много памяти и пропускной способности для принимающих серверов. Некоторые серверы не смогут пройти аутентификацию SPF из-за наличия механизма PTR.

ПЕРЕНАПРАВЛЕНИЕ

Хотя технически это модификатор, а не механизм, он позволяет администратору домена указывать домен на запись SPF другого домена. Если используется функция REDIRECT, никакие другие механизмы не могут быть включены в запись SPF, включая механизм «все». Пример записи перенаправления: «v=spf1 redirect:example.com»

Все механизмы «INCLUDE», «A», «MX», «PTR», «EXISTS» и «REDIRECT» требуют поиска DNS, поэтому их может быть не более 10. Это кажется достаточно простым, но это также включает вложенные поиски DNS, то есть «INCLUDE», ведущее к другой записи SPF, которая имеет еще два механизма «INCLUDE», будет считаться тремя поисками DNS. Они быстро складываются!

Как насчет клиентов Twilio SendGrid?

Большинство наших отправителей настроили CNAME, указывающее их домен отправителя на sendgrid.net. Это означает, что принимающий сервер видит CNAME, указывающий на sendgrid.net, и вместо этого проверяет эту запись SPF. Поэтому не удивляйтесь, если большинство запрашиваемых вами записей SPF будут идентичными.

Дополнительные вопросы, касающиеся Twilio SendGrid, см. на странице документации Sender Policy Framework. В нем есть дополнительные ответы на некоторые общие вопросы и сценарии.

Как проверить запись SPF?

Не все используют аутентификацию SPF, но получатели, которые отклоняют сообщение из-за сбоя SPF, также отклонят доставку. Некоторые получатели могут также помещать в карантин почту, которая не соответствует SPF, не блокируя ее.

Каждая запись SPF будет немного отличаться, но вы должны проверить ее правильность. Вот три инструмента, которые могут помочь проверить ваши записи:

Инструменты тестирования SPF Скотта Киттермана : проверьте, существует ли уже запись SPF для вашего домена, проверьте ее достоверность или протестируйте ее производительность.
OpenSPF.org : просмотрите серию форм и тестеров на основе электронной почты.
Проверка записи SPF: Проверка записи SPF действует как поиск и проверка записи SPF. Он будет искать запись SPF для запрошенного доменного имени и запускать диагностические тесты для записи, выделяя ошибки, которые могут повлиять на доставку электронной почты.
Мастер SPF : Мастер SPF — это браузерный инструмент для создания записей SPF. Заполните форму, и сайт сгенерирует для вас запись SPF.

Сделайте структуру политики отправителей приоритетом

Проще говоря, вредоносные сообщения электронной почты наносят ущерб вашему бизнесу и ухудшают работу канала электронной почты. Когда фишеры увидят ваш домен, защищенный Sender Policy Framework, они с большей вероятностью перейдут к более легким целям. Хотя SPF не защитит от спама, он может служить сдерживающим фактором и сделать вас менее уязвимыми для атак. А кто этого не хочет, верно? Вот почему мы рекомендуем всем почтовым клиентам создавать запись SPF.

В сочетании с Sender ID, DKIM и DMARC SPF обеспечивает дополнительный уровень безопасности электронной почты, который лучше поддерживает ваших пользователей, помогая интернет-провайдерам правильно идентифицировать вашу электронную почту и, в свою очередь, спамеров.