Что такое SPF
Думаю, никому не нужно объяснять, какой проблемой является спам в наше время. Борьба с этим злом — дело не простое, и если хочется приблизится к идеалу, требующее сочетания нескольких элементов. Одним из этих элементов является протокол SPF. Будучи опубликованным в апреле 2006 года в RFC 2006 года к настоящему времени протокол имеет статус «экспериментальный», и достаточно неплохую распространенность.
SPF взят на вооружение такими гигантами, как Google, Яндекс, Mail.Ru, Microsoft, Рамблер. Yahoo не поддерживает SPF, а пытается продвигать свою разработку DKIM, к слову, не слишком успешно.
Итак — как же работает SPF?
Общие принципы работы
Основная идея такова — хозяин адреса указывает, с каких адресов следует ожидать его почту, и как интерпретировать ошибку, в случае несоответствия. Важно понимать, что эти данные — всего лишь рекомендация отправителя по проверке. Да-да, конечно же, стандарт описывает, как должна принимающая сторона обрабатывать результат, но по всяким причинам принимающая сторона фактически может с ними делать все, что заблагорассудится — полностью соблюсти, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Механизм взаимодействия
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC
> 250 example.net Hello mx.example.com., pleased to meet you
Если бы, вдруг, фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовику, что входящее сообщение не валидно, и лучше бы его вообще не принимать, ну или на крайний случай отмаркировать отдельно.
Формат записи
» SoftFail, «?» Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные результаты:
* None — означает, что либо в домене нет записей, либо вообще не удается проверить домен. В общем никакого внятного ответа не получено.
* Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить разрешен ли IP. Этот результат должен обрабатываться так же, как и None.
* Pass — означает, что все ОК и получатель может принять письмо.
* Fail — явно указывает на то, что письмо принимать не следует. Проверяющая сторона может отмаркировать письмо либо отбросить.
* SoftFail — находится где-то между Fail и Neutral. Принимающая сторона не должна отбрасывать письмо на основании только этого результата.
* TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть.
* PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
Проблема пересылки
Заключение
SPF является простым и достаточно эффективным способом оценить легитимность передаваемой почты. Администраторам почтовых серверов стоит минимальных телодвижений добавление SPF записей в DNS. Простота внедрения и поддержка основными популярными MTA делают распространение SPF все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше 🙂
Настройка SPF-записи
Для доменов, делегированных на наши NS-серверы, SPF-запись указывается автоматически и выглядит примерно следующим образом:
Такая запись означает, что письма с данного домена могут отправляться из подсетей 176.57.223.0/24 и 92.53.116.0/22, а письма, пришедшие с других серверов (all), должны проходить дополнительную проверку (
Основной синтаксис
Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1.
Далее указываются параметры (механизмы). Чаще всего используются следующие: all, ip4, ip6, a, mx, include, redirect. Также существуют, но используются значительно реже: ptr, exists, exp. Они все будут рассмотрены ниже.
Помимо механизмов используются префиксы (определители):
Параметр «all» подразумевает все серверы, не упомянутые отдельно в SPF-записи. «All» задает обработку полученных с них писем и указывается в конце записи.
— принимать почту только из подсети 176.57.223.0/24; письма с других адресов должны быть помечены как спам.
— принимать почту только с A-записи домена; письма с других адресов должны отвергаться.
— отвергать все письма с домена. Такую настройку можно использовать для доменов, с которых не должна отправляться вообще никакая почта.
В последующих примерах мы не будем дополнительно комментировать значения параметров
all и -all в SPF-записях.
ip4 / ip6
Используется для указания конкретных адресов и подсетей, из которых могут отправляться письма. Синтаксис для IPv4 и IPv6 идентичен.
— принимать почту из подсети 176.57.223.0/24.
— принимать почту с IPv6-адреса 2001:db8::10.
IP отправителя проверяется на соответствие A-записи домена.
— принимать почту с A-записи текущего домена.
— принимать почту с A-записи домена sub.domain.com.
IP отправителя проверяется на соответствие IP-адресам серверов, указанных в MX-записях домена. На текущий день для многих современных сервисов эта директива уже не так важна, так как серверы входящей и исходящей почты зачастую имеют разные IP.
— принимать почту с MX-серверов текущего домена и домена sub.domain.com.
— принимать почту из подсети, в которую входят MX-серверы текущего домена.
include
Позволяет учитывать в SPF-записи настройки SPF другого домена.
— принимать почту с A-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com.
redirect
Технически, redirect является модификатором, а не механизмом. Он выполняет одну основную функцию: сообщает, что необходимо применять настройки SPF другого домена.
— почта должна приниматься или отклоняться согласно настройкам домена other-domain.com.
Прочие механизмы
Здесь мы рассмотрим оставшиеся механизмы, которые используются в настройках значительно реже.
PTR-запись IP-адреса отправителя проверяется на соответствие указанному домену. Данный механизм требует большого количества DNS-запросов при проверке, поэтому без острой необходимости использовать его в SPF не рекомендуется.
— принимать почту со всех адресов, PTR-запись которых направлена на домен other-domain.com
exists
Запрашивается А-запись указанного домена; если она существует, проверка считается пройденной. Другими словами, проверяется, резолвится ли домен на какой-либо (любой) IP-адрес.
— принимать почту, если существует A-запись домена mydomain.com.
Параметр «exp» применяется для отправки сообщения об ошибке отправителю письма. С помощью «exp» в SPF прописывается определенный поддомен, в TXT-записи которого указан текст сообщения об ошибке. Имя поддомена и текст ошибки может быть любым.
Параметр «exp» всегда указывается в конце записи (после all).
При этом TXT-запись домена error-spf.mydomain.com содержит: «Not authorized to send mail for this domain».
Примеры настроек
Настройка SPF для «Почты для доменов» от Mail.Ru
(подробнее о настройке DNS для Mail.ru см. здесь)
Если вы отправляете почту только с серверов Mail.Ru:
Если вы отправляете почту так же и с других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):
Настройка SPF для Яндекс.Почты
(подробнее о настройке DNS для Яндекса см. здесь)
При использовании только серверов Яндекса:
При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):
Настройка SPF для Google
(подробнее о настройке DNS для Google см. здесь)
При использовании только серверов Google:
При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):
Другие примеры
— принимать почту с IP-адресов, соответствующих A-записям текущего домена, с IP-адреса 176.57.223.12 и серверов, указанных в SPF-записи domain2.com; прочие письма отклонять.
— принимать почту из подсети, в которую входят MX-серверы текущего домена, и из подсети, в которую входят A-записи домена domain2.com; прочие письма отклонять.
— принимать почту с A-записи текущего домена, IP-адреса 176.57.223.12, а также с серверов, указанных в SPF домена domain2.com.
Видеоинструкция
Создать SPF: Как сделать так, чтобы письма не попадали в СПАМ
P.S. будет много технических терминов, но мы их просто объясним.:)
SPF (Sender Policy Framework/структура политики отправителя) — это метод борьбы со спамом, который работает по принципу паспорта. Как главный документ удостоверяет нашу личность, так SPF подтверждает, что емейл пришел с проверенного надежного адреса. Но в отличие от объемной книжечки, Sender Policy Framework представляет собой одну строку в TXT-записи домена. Например, такую:
Это самый простой пример записи, который говорит о том, что отправлять письма от имени домена example.org могут все все сервера, указанные в записях a и mx. Другие же адреса должны быть удалены: -all.
Более сложный уровень SPF-защиты для того же домена может выглядеть так:
example.org. IN TXT «v=spf1 mx ip4:195.3.159.250 +a:smtp.mail.ru include:gmail.com
и означает, что отправлять сообщения от имени домена example.org. могут все сервера, указанные в mx-записях, а также отправленные с IP 195.3.159.250. Кроме того, можно принимать письма с серверов, указанных в SPF-записи домена gmail.com. Письма со всех остальных серверов нужно отправить в спам без проверки:
И это далеко не самая сложная SPF-запись. При необходимости, она может вмещать до 10 параметров. Для удобства, мы собрали их все в одном месте:
принять емейл, но пометить как СПАМ.
mx все адреса, указанные в MX-записях домена;
all все остальные IP, которые не указаны в SPF-записи;
exists проверяет работоспособность доменного имени;
spf.example.org. IN TXT «You host not allowed e-mail to me from this domain!»
Как известно, основной метод спуфинга — это подмена адреса в поле “FROM”. SPF-запись, как противоядие, направлено именно на это поле, поскольку оно содержит главный критерий для проверки: домен отправителя и его IP адрес. Сопоставляя его с теми айпишниками, которые прописаны в SPF-записи как разрешенные, сервер-получатель принимает решение о безопасности сообщения.
Коротко, алгоритм работы SPF проходит четыре этапа. Для примера, возьмем отправку сообщения с адреса info@example.com на адрес example@beispiel.com через почтовый сервис Estismail:
И такие этапы проходит каждое письмо. Графически, преодоление SPF-фильтра выглядит следующим образом:
Базовую роль в проверке домена играет список IP адресов, указанных в SPF-записи. Именно он подтверждает честные намерения отправителя. Поэтому постарайтесь вписать в этот список все возможные IP, которым вы разрешаете отправку: все корпоративные адреса, а также не забудьте о сервисах почтовых рассылок.
Создание SPF — простая операция. В большинстве случаев для установки базовой защиты достаточно прописать одну строку в TXT-записи домена. Но и здесь есть много подводных камней:
Процесс настройки SPF-записи проходит на сайте провайдера и состоит из 5 этапов. Последний из них — проверка работоспособности и правильности SPF. Ее можно провести на одном из специальных сервисах:
Не попадаем в СПАМ. Часть 1: проверка SPF.
В настоящее время почтовые сервисы всё больше уделяют внимания системам для борьбы со СПАМом. Но всё чаше сообщения которые ждут от нас наши клиенты попадают в СПАМ. В большинстве случаев это происходит потому что почтовый сервер на который мы отправили почту не может распознать действительно ли почту отправили мы а не кто то посторонний.
Есть несколько способов как это исправить, самый простой это добавление SPF-записи. SPF-запись добавляется к описанию домена и показывает, с каких серверов можно отправлять почту от имени домена.
Для этого нам потребуется:
Доступ к редактированию наших DNS записей.
Знать адрес сервера с которого отправляются сообщения.
Основы SPF
В SPF используется 3 блока:
Примеры
Игнорировать всю почту с домена.
Принимать сообщения с серверов указанных в A и MX записях, сообщения с остальных серверов должны быть отклонены.
Принимать сообщения с серверов указанных MX записях, сообщения с остальных серверов будут приняты, но отправлены в СПАМ.
Забрать все правила с домена example.com.
Доверять всей почте из адресного пространства example.com класса C (например, есле example.com имеет ip адрес 10.123.41.12, то доверие будет всем 10.123.41.45). Остальная почта будет проигнорирована.
Какие могут быть серверы отправки почты?
Условно серверы отправки почты можно разделить на 3 группы:
Популярные почтовые сервисы, к которым вы привязали свой домен. Например: Google App, Yandex PDD, Mail.ru для бизнеса.
Собственный почтовый сервер
SPF для популярных сервисов.
На момент написания статьи они выглядят следующим образом.
Как подобрать SPF для собственного почтового сервера или хостинга.
Для начала Вы можете заглянуть в настройки своего почтового клиента и посмотреть какой используется для отправки почты (SMTP сервер). Но этот адрес не всегда может соответствовать адресу сервера с которого действительно будет отправлено сообщение.
Самый верный вариант, это просмотреть исходное сообщение полученного письма и найти там информацию о сервере отправителя.
Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com. [67.18.36.18])
Из этого сообщения мы можем понять имя сервера “gateway08.websitewelcome.com” и ip адрес 67.18.36.18. IP адрес лучше не использовать, т.к. он может изменяться очень часто. Домен 3-го уровня в этом случае то же лучше не использовать, т.к. из его названия понятно что он не один, и следующее письмо может быть отправлено уже с другого домена. Лучше просто взять “websitewelcome.com”.
Далее проверяем, есть ли у websitewelcome.com SPF запись. В этом нам может помочь утилита dig.
$ dig TXT websitewelcome.com
websitewelcome.com. 19117 IN TXT «v=spf1 a mx ip4:64.5.0.0/16 ip4:67.18.0.0/16 ip4:69.41.0.0/16 ip4:69.56.0.0/16 ip4:69.93.0.0/16 ip4:70.85.0.0/16 ip4:74.52.0.0/16 ip4:174.132.0.0/16 ip4:174.120.0.0/16 ip4:173.192.100.229 ip4:173.192.111.0/24 include:spf.websitewelcome.com»
Данная запись выглядит вполне жизнеспособной, можем просто забрать её:
Заключение
SPF позволяет ограничить с каких серверов может отправляться почта от имени Вашего домена. При настройке, необходимо быть внимательным что бы не дать “лишним” адресам разрешения. Так же Вы можете воспользоваться конструктором, который поможет сгенерировать SPF запись.
Автор: Сергей Степанов
Мне в техподдержке яндекса ответили так (я только буковку «a» добавил от себя))):
v=spf1 a include:servers.mcsv.net include:_spf.yandex.net
all
А должен (подчеркиваю красным)
v=spf1 ip4:Х.Х.Х.Х
Префикс ip4: в коде потеряли, поправьте пожалуйста.
А ваш сайт защищен от спуфинга? 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. — означает, что 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 — нейтральное отношение, здесь уже почтовый сервер будет действовать на свое усмотрение.
Теперь давайте разберем еще один пример, в котором будет больше параметров:
Из нового здесь появились два момента:
ip4:176.9.92.131 — означает, что мы разрешаем слать письма от имени нашего сайта с сервера с IP-адресом 176.9.92.131. Это может пригодиться во многих ситуациях. Например, если поддомен вашего сайта расположен на другом сервере, но с этого поддомена идет отправка писем, в которых в качестве обратного адреса используется корневой домен. Или, например, если на каком-то сервере находится сразу несколько доменов, с которых вы разрешаете отправку. Чтобы не перечислять их все, достаточно указать лишь IP-адрес сервера, на котором они находятся.
include:_spf.mlsend.com — этой записью мы говорим следующее — все сервера, которые указаны в SPF-записи для домена mlsend.com, также имеют право отправлять письма от имени моего домена. Это обычно используется в тех случаях, когда вы ведете рассылку, используя сторонний сервис рассылок. Т.к. сервисы рассылок шлют письма со многих разных серверов и они у них постоянно меняются, то было бы неудобно указывать все эти сервера в нашей SPF-записи. Для таких случаев гораздо удобнее использовать опцию include, которой мы разрешаем слать письма от имени нашего домена всем серверам, указанным в SPF-записи нашего сервиса рассылок. В данном случае приведен пример для сервиса Mailerlite.
И последний пример, который познакомит нас с еще одним параметром:
redirect=site.com — это уже не параметр, а так называемый модификатор. Он заменяет SPF-запись для домена site.ru SPF-записью, которая прописана для домена site.com. Это может пригодиться в том случае, если у нас много доменов в разных языковых зонах, а обработкой и отправкой почты для всех этих доменов занимается один сервер. Чтобы нам не прописывать SPF для всех доменов, мы прописываем их только для одного, а для всех остальных прописываем модификатор redirect. Теперь, если нам надо будет что-то изменить в SPF-записи, то нам не надо будет менять ее во всех наших доменах, а достаточно будет поменять в одном. Этот модификатор похож на параметр include, но отличается от него тем, что он просто заменяет всю текущую запись, а include лишь добавляет параметры целевого домена к существующим параметрам.
О других, более редких параметрах и модификаторах SPF-записи, вы можете почитать на официальном сайте.
Таким образом, чтобы составить верную SPF-запись, вам надо определиться с тем, какие сервера имеют право слать почту от имени вашего домена, а затем указать их в качестве параметров.
Самое простое, что вы можете сейчас прописать для защиты вашего сайта от спуфинга, это:
Вместо site.ru. будет ваш домен. Если, например, вы используете Яндекс.почту для создания почтовых ящиков своего домена, то запись нужно расширить до такой:
Если вы ведете почтовую рассылку через сторонние сервисы, то уточните у них, какие сервера они используют для отправки вашей рассылки, и пропишите их либо через параметр ip4, либо через include.
Например, если я веду рассылку через сервис MailerLite и при этом для этого домена использую яндекс.почту, то SPF-запись у меня будет выглядеть так:
Как настроить SPF для вашего сайта?
Шаг 1. Добавляем новую DNS-запись.
Зайдите в интерфейс добавления новых DNS-записей у вашего регистратора или хостинг-провайдера. Найдите там возможность добавить новую DNS-запись.
Это может выглядеть так:
Шаг 2. Заполняем поля и добавляем запись
В поле Хост укажите @ или название вашего домена с точкой на конце, например site.ru.
Тип записи укажите TXT. В поле Значение пропишите получившуюся у вас SPF-строку в кавычках.
Шаг 3. Ждем обновления. Проверяем результат
После добавления записи вы увидите ее в списке ваших DNS-записей.
Это может выглядеть так:
Теперь надо подождать, пока эти изменения станут видны на всех DNS-серверах сети Интернет. Обычно этот процесс занимает от нескольких секунд до 72 часов. Далее можно проверить вашу SPF-запись, через этот сервис:
Учтите, что SPF-запись у домена может быть только одна. Если вы добавите несколько SPF-записей, это будет считаться ошибкой.
Итоговые мысли
SPF — это только первый этап защиты от спуфинга. Это один из параметров, который учитывает почтовый сервис в своей комплексной антиспам-политике при обработке входящей почты. Итоговое решение о том, поместить письмо в папку «Входящие», отправить его в спам или вовсе отклонить, почтовый сервис принимает по совокупности всех параметров, которые он учитывает.
В любом случае, я советую вам настроить SPF-политику для вашего домена. Чем больше людей будет использовать данную технологию, тем она быстрее станет массовой и станет работать гораздо эффективнее.
В следующих статьях мы с вами поговорим о других инструментах защиты от спуфинга таких, как: DKIM и DMARC.