А ваш сайт защищен от спуфинга? SPF простым языком.

Сегодня хочу рассказать вам о таком понятии, как Sender Policy Framework или, сокращенно, SPF.

Прежде всего эта статья будет полезна тем, у кого есть собственный сайт, а особенно тем, кто ведет свои Email-рассылки.

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

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

Так, злоумышленник может купить базу email-адресов какого-то сайта, найти или арендовать smtp-сервер и разослать по этой базе сообщение от имени владельца этого сайта.

Пару лет назад такой случай произошел с моим коллегой.

Предположим, его звали Иван Иванов, а его сайт назывался ivanivanov.ru.

Он уже несколько лет пользовался одним известным сервисом рассылок, назовем его для примера «сервис X» с адресом xservicex.ru, и с помощью него отправлял письма десяткам тысяч своих подписчиков, указывая в качестве обратного адреса ящик vip@ivanivanov.ru.

В один «прекрасный» день сервис Х был взломан, и базу подписчиков Ивана оттуда украли. Далее по украденной базе была произведена мошенническая рассылка. При этом для рассылки использовались разные спамерские сервера, а в качестве обратного адреса было указано имя Ивана и его e-mail ящик vip@ivanivanov.ru.

Письмо было составлено от имени Ивана и написано в его стиле. В письме «Иван» предлагал купить все его товары с огромной скидкой. Мошенники даже купили очень похожий домен и разместили на нем продающую страницу с распродажей, на которую и отправляли людей из письма.

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

Процесс такого обмана называется спуфингом (spoofing от англ. — подмена).

Чтобы бороться с этим явлением был разработан стандарт SPF.

Он позволяет владельцу сайта четко прописать — кому можно отправлять письма от имени его домена, а кому нет. В нашем примере, если бы Иван знал про SPF, он мог бы указать, что только сервис X может слать письма от имени его сайта, а всем остальным серверам это делать запрещено.

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

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

Думаю, вы знаете, что у любого домена есть так называемые DNS-записи, которые доступны всем желающим. В этих записях хранится разная служебная информация, необходимая для правильной работы сайта. Владелец сайта может добавлять, изменять, удалять эти записи. Это обычно делается либо у регистратора домена, либо в панели управления хостинг-провайдера.

Например, у вашего сайта есть А-запись. В ней прописано на сервере с каким IP-адресом живет ваш сайт.

Когда потенциальные клиенты обращаются к вашему сайту по имени (например, site.ru), то браузер сначала
обращается к DNS-серверу и запрашивает значение А-записи, из которой узнает IP-адрес сервера, на котором живет ваш сайт, и уже у этого сервера запрашивает весь HTML-код, картинки, таблицы стилей и т.д.

И таких DNS-записей у сайта может быть много. Значение этих записей у любого сайта можно посмотреть через сервис mxtoolbox.com

Как вы уже поняли, одной из таких служебных записей для сайта является SPF-запись, в которой владелец сайта указывает, кто имеет право слать письма от имени его сайта. 

Чуть позже мы с вами научимся генерировать SFP-записи и прописывать их для вашего домена. А сейчас давайте разберемся, как используют SPF все современные почтовые сервисы.

Любой современный почтовый сервис (Google mail, Яндекс.Почта, Mail.ru и т.д.) при получении письма сначала смотрит на домен ящика отправителя и на сайт (сервер), с которого пришло письмо. Например, письмо пришло с сайта сервиса рассылок xservicex.ru, а в поле отправитель стоит ящик admin@site.ru.

Теперь почтовому сервису надо понять, разрешил ли владелец сайта site.ru отправлять письма от имени его домена сервису xservicex.ru. Для этого почтовый сервис обращается к DNS-серверу и запрашивает у него значение SPF-записи для сайта site.ru, по которой он сможет понять, разрешено ли сайту xservicex.ru слать письма от имени site.ru или нет.

В зависимости от ответа почтовый сервис присвоит письму SPF-статус, который может принимать одно из следующих значений:

- Pass — отправитель сообщения разрешен (согласно анализу SPF-политики).
- Softfail — сообщение не отвечает «жестким» критериям достоверности отправителя, но нельзя и быть уверенным, что отправитель подделан.
- Fail — отправитель подделан.
- Прочие варианты на тот случай, когда у домена нет SPF-записи. Например, None, Neutral, Unknown и т.д.

После того, как письму присвоен SPF-статус, оно передается следующим фильтрам почтового сервиса для дальнейших проверок.

Пример SPF-статуса письма в почтовой службе Gmail:

 

Среди прочей информации по письму, вы увидите такую строку:

 


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

Как составить SPF-запись для вашего сайта?

Возьмем для примера такую SPF-запись:

site.ru. IN TXT "v=spf1 a mx -all"

Разберем ее по частям:

site.ru. — означает, что SPF запись относится к домену site.ru.

IN TXT — означает, что это текстовая запись (это нам пригодится дальше).

v=spf1 — используется первая версия протокола SPF.

a — означает, что мы разрешаем слать письма с сервера, который указан в A-записи домена site.ru. По сути, этим мы разрешаем слать письма с того сервера, на котором и расположен сайт. Эту опцию полезно указать, если движок вашего сайта шлет какие-то письма или вы используете почту от вашего хостинг-провайдера, или, если ведете почтовую рассылку через скрипт, который живет на вашем основном домене. В общем, этот параметр обычно указывается. Если вам надо, наоборот, запретить принимать письма от сервера, указанного в A-записи, то поставьте знак минуса перед параметром -a.

mx — означает, что мы разрешаем слать письма с сервера, который указан в MX-записи для нашего домена. MX-запись указывает на сервер, который занимается обработкой входящей почты для нашего домена. Например, если вы захотите использовать яндекс.почту для создания почтовых ящиков вашего сайта, то в процессе настройки вас попросят добавить в DNS-записи вашего сайта mx-запись с таким значением: mx.yandex.net, которая указывает, что почту для вашего сайта надо пересылать на почтовые сервера яндекса. А когда мы указываем параметр mx в SPF-записи, то этим мы говорим, что разрешаем домену mx.yandex.net отправлять почту от имени нашего домена. 

-all — этим мы говорим почтовым сервисам, что все письма, которые приходят от имени нашего домена с серверов, которые не указаны в нашей SPF-записи, нужно отклонять. Кроме этого, данный параметр может принимать вид ~all — мягкое отклонение, т.е. письмо будет принято, но будет помечено как СПАМ, а также есть вариант ?all — нейтральное отношение, здесь уже почтовый сервер будет действовать на свое усмотрение.

Теперь давайте разберем еще один пример, в котором будет больше параметров:

site.ru. IN TXT "v=spf1 a mx ip4:176.9.92.131 include:_spf.mlsend.com -all"

Из нового здесь появились два момента:

ip4:176.9.92.131 — означает, что мы разрешаем слать письма от имени нашего сайта с сервера с IP-адресом 176.9.92.131. Это может пригодиться во многих ситуациях. Например, если поддомен вашего сайта расположен на другом сервере, но с этого поддомена идет отправка писем, в которых в качестве обратного адреса используется корневой домен. Или, например, если на каком-то сервере находится сразу несколько доменов, с которых вы разрешаете отправку. Чтобы не перечислять их все, достаточно указать лишь IP-адрес сервера, на котором они находятся.

include:_spf.mlsend.com — этой записью мы говорим следующее — все сервера, которые указаны в SPF-записи для домена mlsend.com, также имеют право отправлять письма от имени моего домена. Это обычно используется в тех случаях, когда вы ведете рассылку, используя сторонний сервис рассылок. Т.к. сервисы рассылок шлют письма со многих разных серверов и они у них постоянно меняются, то было бы неудобно указывать все эти сервера в нашей SPF-записи. Для таких случаев гораздо удобнее использовать опцию include, которой мы разрешаем слать письма от имени нашего домена всем серверам, указанным в SPF-записи нашего сервиса рассылок. В данном случае приведен пример для сервиса Mailerlite.

И последний пример, который познакомит нас с еще одним параметром:

site.ru. IN TXT "v=spf1 redirect=site.com -all"

redirect=site.com — это уже не параметр, а так называемый модификатор. Он заменяет SPF-запись для домена site.ru SPF-записью, которая прописана для домена site.com. Это может пригодиться в том случае, если у нас много доменов в разных языковых зонах, а обработкой и отправкой почты для всех этих доменов занимается один сервер. Чтобы нам не прописывать SPF для всех доменов, мы прописываем их только для одного, а для всех остальных прописываем модификатор redirect. Теперь, если нам надо будет что-то изменить в SPF-записи, то нам не надо будет менять ее во всех наших доменах, а достаточно будет поменять в одном. Этот модификатор похож на параметр include, но отличается от него тем, что он просто заменяет всю текущую запись, а include лишь добавляет параметры целевого домена к существующим параметрам.

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

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

Самое простое, что вы можете сейчас прописать для защиты вашего сайта от спуфинга, это:

site.ru. IN TXT "v=spf1 a mx -all"

Вместо site.ru. будет ваш домен. Если, например, вы используете Яндекс.почту для создания почтовых ящиков своего домена, то запись нужно расширить до такой:

site.ru. IN TXT "v=spf1 a mx include:_spf.yandex.net -all"

Если вы ведете почтовую рассылку через сторонние сервисы, то уточните у них, какие сервера они используют для отправки вашей рассылки, и пропишите их либо через параметр ip4, либо через include.

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

site.ru. IN TXT "v=spf1 a mx include:_spf.yandex.net include:_spf.mlsend.com -all"

Как настроить SPF для вашего сайта?

Шаг 1. Добавляем новую DNS-запись.
Зайдите в интерфейс добавления новых DNS-записей у вашего регистратора или хостинг-провайдера. Найдите там возможность добавить новую DNS-запись.

Это может выглядеть так:


Шаг 2. Заполняем поля и добавляем запись

В поле Хост укажите @ или название вашего домена с точкой на конце, например site.ru.
Тип записи укажите TXT. В поле Значение пропишите получившуюся у вас SPF-строку в кавычках.

Пример:

 

Шаг 3. Ждем обновления. Проверяем результат

После добавления записи вы увидите ее в списке ваших DNS-записей.

Это может выглядеть так:


Теперь надо подождать, пока эти изменения станут видны на всех DNS-серверах сети Интернет. Обычно этот процесс занимает от нескольких секунд до 72 часов. Далее можно проверить вашу SPF-запись, через этот сервис:

mxtoolbox.com

Пример проверки:

 

Учтите, что SPF-запись у домена может быть только одна. Если вы добавите несколько SPF-записей, это будет считаться ошибкой.

Итоговые мысли

SPF — это только первый этап защиты от спуфинга. Это один из параметров, который учитывает почтовый сервис в своей комплексной антиспам-политике при обработке входящей почты. Итоговое решение о том, поместить письмо в папку «Входящие», отправить его в спам или вовсе отклонить, почтовый сервис принимает по совокупности всех параметров, которые он учитывает.

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

В следующих статьях мы с вами поговорим о других инструментах защиты от спуфинга таких, как: DKIM и DMARC.

А вы уже прописали SPF-запись для вашего домена?

Александр

Евгений информация полезная. Буду "застегиваться на все пуговицы"

Александр Дырза

Благодарю Евгений! Некоторые моменты мне теперь прояснились. Почта для домена привязана к biz.mail.ru а рассылка идет через джастклик, и нашел ошибку в настройке, сейчас настрою правильно.

Ильдар Шагиахметов

У Вас таже проблема. Письмо о спуфинге пришло и почтовый сервис выдал сообщение "Мы не можем проверить подлинность отправителя. Рекомендуем вам быть внимательнее при совершении действий, указанных в письме.". Почтовая программа Mozilla Thunderbird таких пометок не делает.

Евгений

Тест

Евгений Амягин

Спасибо, хорошая статья

Мария

Пример ящика вот так mail@domain.ru хотела написать.

Надежда Суптеля

Женя, Спасибо Огромное за подробности спуфинга. У меня такого варианта еще не было, только вот в gmail точка com почта до невозможного забита спамом - удаляю или блокирую емел адреса, но они все равно будут оставаться в спаме. Вот если бы служба Гугла сделала черный список, как у Яндекса, было бы намного проще. Видимо кто - то продал базу и мой емел там же очутился. Немного нашла информации, как сразу отписывать этих товарищей в gmail точка com в спаме, но не смогла внедрить, видимо что - то не совсем понимаю.

Надежда Суптеля

Олег, у меня тоже на днях лили трафик с разных P стран, люди кликали рекламу и очень даже хорошо. Но Адзенс за такую активность снял с меня почему - то почти 3 доллара. А почему - не знаю.

Мария

Была такая проблема, что на общие ящики нескольких доменов стали приходить письма о том, что не доставлены письма, отправленные с поддельных ящиков. То есть, например, ящика mail.domain.ru не существует, но на общий ящик сайта domain.ru приходят письма, что с ящика mail.domain.ru не доставлен какой-то спам. Где-то пару месяцев назад сделала, чтобы почта ходила через Яндекс. При стандартных яндексовских настройках (для spf там по умолчанию редирект: "v=spf1 redirect=_spf.yandex.net") продолжают подобные сообщения о недоставленных письмах приходить, хотя реже уже. Спасибо за эту статью. Понятно, что более строгие настройки лучше поставить.

Валерий Черепанов

Здравствуйте, Евгений! У меня 2 года назад был сайт. Потом он стал рассылать порнуху. Обратился за помощью на хостинг "Timeweb". Они в помощи отказали. Пришлось сайт закрыть. А SPF сайт может защитить? С уважением, Валерий.

Евгений Кольченко

Спасибо, Евгений! Выполнил рекомендации. DNS - записями управляю через регистратора R01. Значение параметра, например, v=spf1 a mx include:_spf.mlsend.com -all нужно вводить без кавычек. Если ввести с кавычками, то пропадают пробелы в значении и сервис mxtoolbox.com выдаёт синтаксическую ошибку. Обязательно сделайте проверку.

Анатолий

Спасибо Олег! А я, как новичок, и не знал ещё об о такой защите. Очень полезный пост

Александр

Спасибо.

Григорий Иванов

Ожидаю статью о DKIM и DMARC.

VLAD STEP

Нет. Просто и не знал про это. Было бы интересно узнать ещё и про вариант другой. На мой почтовый ящик стал получать письма ... от себя самого же с этого же ящика!!! В сервисе рассылок был указан Getresponder , даже его логотип присутствовал. Когда это "явление" стало повторяться, то обратился в техподдержку вышеуказанного сервиса. Именно предоставление им скрина "показать оригинал" как они просили и помогло решить проблему . Мне они только сообщили, что отправитель выяснен ими и более приносить мне неудобства как многим другим в своих посланиях уже не будет. Но что и как они делали я до сих пор не знаю.Предположу теперь что именно этими настройками они и смогли устранить, выяснив отправителя, данную несправедливость.

Олег

Здравствуйте, Евгений! А если на мой сайт кто-то льет трафик с разных ip и стран и эти люди кликают по рекламе на сайте. Помимо скликивания объявлений они еще и дополнительную нагрузку на сервер создают и статистику портят. Не знаете, что это такое и как с ним бороться

Вячеслав

Жень, спасибо. На днях займусь защитой.

Дмитрий Покревский

Какой интересный сервис для комментариев! Супер!

Alex

Спасибо, Женя!

Евгений

Спасибо за полезную информацию! Ожидаю статью о DKIM и DMARC.

Сергей Гапонов

Добрый день Евгений! Это я Сергей когда буду доделывать твой сайт можно будет обратится за этой информацией? С уважением Сергей!

Светлана Лыжина

*Спасибо, Евгений, за полезную и нужную информацию.*

Anna Semyonova

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

Константин

Спасибо :)

Евгений Попов

Да, конечно. Это две разные технологии. На днях хочу сделать подобную статью про DKIM.

Константин

А если есть DKIM подпись, нужна ли защита SPF?

Ертай Қуанышов

Осылай қорғануға болатынын білмеппін, егер базам үлкейетін болса міндетті түрде сіздің кеңесіңізді қолданатын боламын.

Закрыть
Наверх