Защита домена от спуфинга

Записи SPF помогают предотвратить спуфинг – рассылку спамерами нежелательных писем из вашего домена. Для этого используется технология Sender Policy Framework (SPF) .

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

Использование SPF с DKIM и DMARC

Помимо SPF, рекомендуем использовать проверки DomainKeys Identified Mail (DKIM) и Domain-based Message Authentication, Reporting & Conformance (DMARC) . SPF определяет круг доменов, из которых вам могут поступать письма. DKIM позволяет удостовериться, что контент сообщения не менялся после отправки. А DMARC указывает, что делать с подозрительными сообщениями, поступившими в ваш домен.

Как создать запись SPF для домена

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

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

Если вам требуется помощь, обратитесь к своему регистратору.

Новая запись SPF начнет действовать в течение 48 часов.

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

Запись SPF можно проверить с помощью Набора инструментов G Suite.

1. Перейдите по адресу https://toolbox.googleapps.com/apps/checkmx/ .
2. Введите доменное имя.
3. Нажмите Начать проверку .
4. После ее окончания нажмите Диапазоны действующих адресов SPF .
5. Проверьте результаты. Они должны содержать следующие строки:
   • _spf.google.com
   • _netblocks.google.com и несколько IP-адресов
   • _netblocks2.google.com и несколько IP-адресов
   • _netblocks3.google.com и несколько IP-адресов

Как обновить запись SPF для нескольких почтовых серверов

Использование нескольких записей SPF может вызывать проблемы авторизации. Вместо этого рекомендуем добавить в существующую запись SPF дополнительные серверы.

Например, если вы настроили шлюз исходящей почты , запись SPF будет содержать адрес сервера Gmail и адрес SMTP-сервера этого шлюза.

Чтобы добавить почтовый сервер в существующую запись SPF, введите перед аргументом ~ all IP-адрес этого сервера в формате ip4:адрес или ip6: адрес , как показано в примере ниже.

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

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

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

Допустим вы получили на почте крайне подозрительного вида посылку, якобы от любимого дедушки Константина Макаровича, но почему то штемпель отправителя указывает не на почтовое отделение села Макаровки, а на хутор Гадюкино совсем в другом конце страны. Будете вы открывать такую посылку, рискуя обнаружить вместо банки варенья из райских яблочек споры сибирской язвы, или отправите ее назад, от греха подальше?

Точно также и в системах электронной почты. Если вам пришло письмо от дедушки [email protected] , но сервер отправитель почему-то mail.spam.com , то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.

Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.

Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись . Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com , в то время как согласно переданной при соединении информации должен быть mail.example.com . Все понятно, письмо падает в спам.

Однако если в заголовке будет указано, что сервер отправитель у нас mail.spam.com , то такое письмо успешно пройдет проверку по PTR-записи , не смотря на то, что домен сервера отправителя не совпадает с почтовым доменом письма.

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

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

Разберем простой пример.

Сервер mail.example.com отправляет письмо для обслуживаемого им домена eхample.org . Сервер-получатель делает запрос PTR-записи и убеждается, что по адресу 123.123.123.123 действительно находится mail.example.com , следовательно такое письмо будет принято, хотя домен отправителя письма и домен сервера-отправителя не совпадают.

А теперь иная ситуация.

Администратор неправильно настроил DNS-зону, указав неправильный хост в PTR-записи . Cервер-получатель, проверив PTR-запись отклонит наше письмо, так как сервер отправитель не совпадает с результатом обратного DNS-запроса.

Отсутствие PTR-записи практически всегда ведет к отклонению письма, потому как существует негласное соглашение о том, что добросовестный отправитель имеет правильно настроенную обратную зону.

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

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

Example.com. IN TXT "v=spf1 +a +mx -all"

Что она означает? То, что для домена example.сom почту могут отправлять узлы указанные в А-записи (+а) и MX-записях (+mx), всю остальную почту следует отклонять (-all).

Однако не все так радужно. Во первых, поддержка SPF все еще не является стандартом де-факто и отсутвие SPF-записи у домена отправителя не повод отклонять письмо. Вторая проблема - сервера пересылки или случаи когда почту отправляют сервера не указанные в А или MX записях, а то и вообще находящиеся в других доменах. Это может быть обусловлено как архитектурой IT-системы предприятия, так и использованием для отправки чужих серверов, когда вы привязываете свой домен к провайдерскому или публичному сервису. В последнем случае нужно быть особо осторожным и крайне желательно проконсультироваться с поддержкой сервиса.

Рассмотрим еще одну ситуацию.

Ваша компания, кроме своего основного почтового сервера mail.example.com , использует услуги сторонних сервисов, которые могут отправлять почту клиентам компании от ее имени. Это может быть сервис экспресс-почты, который от вашего имени будет уведомлять клиентов о статусе доставки и т.п.

В нашем примере такая почта будет отправляться от имени [email protected] с сервера mail.web-service.com , так как данный сервер не указан в MX-записях домена example.com , то, согласно указанному нами в SPF-записи правилу, такое письмо будет получателем отклонено.

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

Example.org. IN TXT "v=spf1 +a +mx ~all"

В отличие от -all (fail), ~all (soft fail) обозначает, что отправители, кроме указанных явно, не имеют права отправлять почту, но не содержит требования отклонять такие письма. Чаще всего такая почта принимается, помечаясь как нежелательная .

Можно также использовать нейтральный префикс:

Example.org. IN TXT "v=spf1 +a +mx ?all"

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

Как быть в нашем случае? Самым правильным решением будет добавить в SPF-запись еще одно правило:

Example.org. IN TXT "v=spf1 +a +mx +mx:web-service.com -all"

Example.org. IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"

в первом случае мы разрешим прием почты также от всех серверов, перечисленных в MX-записях домена web-service.com , во втором случае только для сервера mail.web-service.com .

В завершение рассмотрим случай, когда почта для вашего домена обслуживается сервером находящимся в другом домене. Например mail.example.com отправляет также почту для домена example.org . В этой ситуации будет правильно использовать для домена example.org те же самые правила, что и для example.com . Для этого используйте специальный вид записи:

Example.org. IN TXT "v=spf1 redirect=example.com"

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

• Теги:

Используя запись SPF можно определить подделан e-mail отправителя или является оригиналом. Содержание SPF прописывается в запись TXT.

Есть понятие e-mail спуфинга, которое означает маскировку одного объекта под другой объект. Следовательно IP-адрес отправителя можно подменить, а запись SPF запросто решает проблему с подменой адреса.

Создать SPF запись просто. Создание записи SPF заключается в формировании строки, текстовой записи для сервера доменных имен.

Строка содержит список серверов, которым позволено отправлять письма. Если письмо приходит от сервера, которого нет в списке, то письмо попадает в spam.

Агент, который принимает почту, например GMail, запрашивает SPF запись доменного имени и сверяет адрес отправителя со списком разрешенных адресов из DNS.

Строка для DNS с записью SPF должна состоять из ряда параметров.

Например:

V=spf1 include:_spf.google.com ~all v=spf1 означает версию протокола SPF.

После версии протокола SPF может идти ряд параметров. Например:

• include;
• redirect;

Настройка SPF записи

Параметр "mx" указывает, что письма могут приниматься, если отправка произошла с узла, который указан в записи "mx" доменного имени. В записи "mx" обычные указывается почтовый сервис, который обрабатывает отправку писем.

Ip4: или ip6: указывает IP-адреса дополнительных серверов, от которых можно принимать электронную почту, соответственно "ip4" и "ip6" означает форматам адреса IP.

Параметр all задается в конце записи.

Параметр ~all указывает, что если все предыдущие правила не выполнены, то письма необходимо направить на тщательную проверку.

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

Запись include указывает на то, с каких указанных хостов можно принимать электронную почту, кроме прочих правил. Например, include:_spf.google.com.

Запись redirect указывать на то, с каких указанных хостов требуется проверять SPF-запись. Например, redirect=_spf.mail.ru .

Как использовать на практике. Например, если есть сайт и электронная почта на gmail.com или mail.ru и отправка почты происходит только с gmail.com, или только с mail.ru, то можно прописать redirect с указанием ссылки на сервис. Например, v=spf1 redirect=_spf.google.com. Таким образом, вы оградите себя от рассылки конкурентов от вашего имени.

Множественное использование SPF-записей в DNS не рекомендуется, поскольку все правила можно прописать одной строкой и несколько записей могут привести к ошибке обработки.

Проверка SPF записи

Например, можно использовать mxtoolbox.com/ или инструменты указанные на официальном сайте фреймворка по ссылке http://www.openspf.org/Tools . Даже если вы не страдаете от спама, рассылаемого от имени вашего домена, явное описание легальных источников почты из вашего домена может помочь прохождению легальной почты от вас во входящие.

SPF-запись на DNS-сервере для владельца проекта является одним из методов настройки безопасности, есть и альтернативные дополнительные методы. Методы рекомендуется комбинировать. Например, рекомендуется проверять IP-адрес перед размещением сайта на предмет наличия в black-листе.

Дата изменения раздела: 2013-05-09

С помощью сведений в этом разделе можно определить наилучший способ управления записями и параметрами DNS, MX и SPF при настройке и использовании службы Forefront Online Protection for Exchange (FOPE).

Записи DNS

При оформлении подписки на службу FOPE для проверки домена рекомендуется добавить запись TXT в записи DNS домена или в параметры домена поставщика услуг Интернета. При добавлении записи TXT в параметры домена поставщика интернет-услуг следует помнить, что для создания и изменения записей DNS потребуется обратиться к поставщику DNS.

Записи TXT

TXT или текстовая запись состоит из произвольной текстовой строки, которую можно присоединить к узлу DNS. Этот узел может иметь несколько записей TXT.

Активация службы FOPE для любого домена возможна только после проверки домена. Предпочтительным методом проверки домена является добавление записи TXT для каждого домена. Запись TXT добавляется в домен на этапе проверки домена в центре администрирования FOPE. Дополнительные сведения о проверке и включении домена см. в разделе Проверка и включение доменов .

Записи, относящиеся к электронной почте

Для электронной почты используются три основные записи: записи почтового обменника (MX), записи указателя (PTR) и записи инфраструктуры политики отправителей (TXT).

Записи MX (почтового обменника)

Запись MX указывает системам электронной почты способ обработки сообщения электронной почты, отправленного в конкретный домен. Иными словами, запись обмена электронной почтой указывает серверу, отправляющему сообщение электронной почты, куда необходимо отправить сообщение. Для надлежащей работы службы FOPE запись MX должна указывать на mail.messaging.microsoft.com, а не на IP-адрес. Это обеспечивает ретрансляцию сообщения электронной почты, отправленного в домен организации, в FOPE для фильтрации.

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

Примечание

Если записи TXT недоступны для домена, как альтернативный метод проверки домена можно использовать обновление записи MX. Дополнительные сведения см. в разделе Проверка и включение доменов .

Записи PTR (указателя)

PTR (запись указателя) - это запись, которая используется для обратного поиска в DNS. Эта запись является противоположной записи A и используется в файлах зон обратного просмотра для преобразования IP-адреса (IP версии 4 или IP версии 6) в имя узла. При отправке сообщения электронной почты конечный сервер получает IP-адрес отправителя и проверяет запись PTR, чтобы убедиться в том, что IP-адрес является адресом домена.

Записи SPF (инфраструктура политики отправителей)

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

Пример записи TXT с определениями для каждой ее части приведен ниже.

Обычная запись TXT для клиента, который отправляет электронную почту только через службу FOPE, может выглядеть следующим образом: "v=spf1 include:spf.messaging.microsoft.com ip4:192.168.254.254 -all"

Дополнительные сведения о том, как служба FOPE использует записи SPF, см. в разделе Рекомендации по настройке FOPE , подпункт "Параметры записи SPF".

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

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

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

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

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

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

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

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

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

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

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, а в поле отправитель стоит ящик [email protected].

Теперь почтовому сервису надо понять, разрешил ли владелец сайта 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 - нейтральное отношение, здесь уже почтовый сервер будет действовать на свое усмотрение.

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

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"

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-запись, через этот сервис:

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

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

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

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

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

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