Записи SPF (Sender Policy Framework) позволяют владельцам доменов указывать, каким хостам разрешается отправлять электронную почту от имени их доменов. Обычно протокол SMTP позволяет любому компьютеру отправлять сообщения электронной почты от имени какого угодно отправителя. Таким образом спамеры могут легко отправлять сообщения электронной почты с поддельным адресом отправителя. SPF позволяет владельцам домена с помощью текстовых записей DNS специального формата указывать, какие компьютеры или хосты имеют право передавать электронную почту в этом домене, затрудняя таким образом подделку адреса отправителя.
dig example.com txt @8.8.8.8
Принцип работы технологии SPF состоит в следующем. Например, администратор почтового сервера, обслуживающего некий домен, хочет "сообщить" остальным серверам, которые принимают почту от него, какие ip-адреса (хосты) являются "разрешёнными" для его домена. Чтобы выделить "разрешённые" адреса, владельцу домена надо указать, почта с каких хостов может быть подписана адресом в этом домене. Для этого в DNS-зоне для данного домена создаётся дополнительная SPF- запись (или TXT- запись), в которой перечисляются "разрёшенные" адреса. Сервер получателя при приходе письма, подписанного адресом из этого домена, проверяет соответствие ip-адреса, с которого письмо было отправлено, с SPF-записью для данного домена. В случае совпадения такое письмо будет считаться прошедшим проверку и принимается получателем. Если же ip-адрес отправителя не находится в списке "разрешённых" адресов для данного домена, то письмо или отвергается, или считается подозрительным на спам, в зависимости от используемой SPF- политики.
Следует отметить один важный момент: технология SPF является по сути "двусторонней", то есть наиболее эффективного её использования можно достичь только в том случае, если почтовая система (сервер или домен) и отправителя, и получателя используют SPF. Если Вы добавляете в DNS-зону SPF-записи для Вашего домена, то это даст Вам дополнительные гарантии фильтрации спаммерских сообщений, посылаемых только с хостов, которые также поддерживают SPF.
Для размещения данных используется поле TXT в DNS. Так IANA назначила DNS поле с кодом 99 для SPF. Формат SPF поля идентичен TXT. Вообще, использование поля TXT не является оптимальным, но проблема в том, что не всякий DNS сервер и клиент понимает новый SPF тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие. Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны. Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all» example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Эта запись содержит следующую информацию: версия SPF — 1 (кстати, пока единственная используемая) письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28 Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным. Вообще, в условии есть 2 части — определитель и механизм. Определители могут быть: "+" Pass, "-" Fail, "~" SoftFail, "?" Neutral Механизмы: all, include, A, MX, PTR, IP4, IP6, exists Результатами проверки условий могут являться следующие определенные результаты:
Возьмем, для примера, какой-нибудь реальный домен. Допустим Google.com. Запрос TXT возвращает
«v=spf1 include:_netblocks.google.com ~all»
тут говорится, что нужно включить правила из записи _netblocks.google.com. Интересно, что у _netblocks.google.com отсутствует A-запись, а есть только TXT-запись. Вот она:
«v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all»
Тут перечислены подсети, в которых могут находится почтовые сервера Google. Последний механизм all c определителем Neutral сообщает анализатору о том, что адрес отправителя может быть не из разрешенного диапазона. Письма из чужих адресных пространств рекомендуется проверять дополнительно, а не отвергать безусловно. Для такой масштабной структуры, как Google — это верное решение, ибо в процессе работы адреса могут изменятся, например, при временном отказе и переключении на резерв. И к тому же, адрес может меняться пересылками. Более хитрая SPF запись у Рамблера:
«v=spf1 ip4:81.19.66.0/23 ip4:81.19.88.0/24 -exists:%{ir}.spf.rambler.ru -exists:%{l}.u.spf.rambler.ru ~all»
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
v=spf1 +mx -all
. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.
Не знаешь какой SPF запись тебе нужно добавить? Впиши эту подходящую на все случаи жизни.
example.org. IN TXT "v=spf1 +a +mx ~all"
Вышеприведённый пример SPF записи как говорится ни о чем (отсылай письма откуда хочешь), но зато валидная. Итак, попробуем разобраться, что же значит SPF-запись, указанная выше.
Читайте также: Как защитить домен от спуфинга и спама с помощью DMARC, Настройка DKIM: Защита вашей электронной почты.