Дата изменения раздела: 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: “v=spf1 mx ip4:{IP-адреса всех серверов, используемых для отправки} include:spf.messaging.microsoft.com ~all”
	Используемая версия SPF.
	Этот параметр указывает, что разрешена отправка с любого сервера, указанного в записи MX.
	Список разрешенных IP-адресов сервера (не требуется для серверов FOPE, если включена запись SPF FOPE и отправка производится только через FOPE).
	В этом параметре перечислены дополнительные записи, разрешающие отправку для домена.
	Параметр all содержит три ключа: - : принимать сообщения электронной почты только от отправителей, перечисленных выше (жесткий отказ). ~ : не принимать сообщения электронной почты, если отправитель отсутствует в указанном списке (мягкий отказ, сообщение будет принято, но помечено как нежелательное). ? : указывает на наличие дополнительных серверов, которые могут отправлять сообщения из домена.

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

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

SPF (Sender Policy Framework) - одна из мер для борьбы со СПАМом. Это специальная запись, в которой указываются IP адреса и сервисы, с которых отправляется почта от имени вашего домена, а так же политика обработки писем.

Тонкости настройки SPF записи

SPF запись прописывается в DNS. Вам нужно зайти в панель DNS хостинга, выбрать домен и зайти в его записи. Далее, создать новую запись:

• Имя записи: адрес домена с точкой в конце. Например, website.ru.
• Тип записи: TXT
• Значение: v=spf1 ip4:133.133.133.133 include:_spf.yandex.net ~all

Параметры SPF записи

Все параметры записи задаются через пробел:

1. v=spf1 - версия протокола. Оставляем как есть
2. ip4:133.133.133.133 - IP сервера, с которого отправляется почта. Если серверов несколько, указываем эти параметры через пробел
3. include:_spf.yandex.net - разрешает так же отправку писем от Яндекс.Почты на домене (если вы используете этот сервис)
4. Параметр перед all:
   1. "-" - означает, что разрешено принимать письма только с указанных сервисов и адресов. Остальные не принимать.
   2. "~" - разрешено принимать письма с указанных сервисов. Если письмо пришло с другого сервера, то помечать его, как нежелательное.
   3. "?" - значит, что могут быть еще сервисы, с которых отправляется почта.

Правильная настройка SPF записи позволит повысить уровень доставляемости писем до адресата. Мы можем настроить SPF на VPS или выделенном сервере абсолютно бесплатно. Важно добавить домен на этот сервер. Если у вас возникли трудности в настройке записи - смело обращайтесь к специалистам компании RigWEB. Мы бесплатно настроим вам SPF запись домена.

The SPF record helps lower the risk that email sent from your domain will be marked as spam. This record lists the addresses of servers that are responsible for sending email from mailboxes on your domain.

To set up the SPF record, you need to create a special TXT record on the servers that your domain is delegated to.

If you delegated your domain to Yandex servers, the SPF record will be set up automatically. You can view it and edit its parameters in the DNS editor in Yandex.Mail for Domain.

Log in to the control panel on your DNS hosting company"s website.

Delete the existing TXT records.

Create a TXT record with the value “v=spf1 redirect=_spf.yandex.net” .

If you want to send email from other servers in addition to Yandex servers, specify the additional servers in this format: “v=spf1 ip4:IP-1 ip4:IP-2 ip4:IP-3 include:_spf.yandex.net ~all” , where IP-1, IP-2, and IP-3 are the IP addresses of the additional servers.

If there is a field for the name or host, enter “@” .

In some control panels, you need to enter the name of your domain instead of “@” (for example, “yourdomain.com.” ). If you are not able to set either “@” or the domain name, leave this field empty.

Wait while the changes take effect in DNS. This process may take up to 72 hours.

SPF-запись — проверка отправителя.

Как всем известно, протокол отправки электронной почты SMTP, подразумевает, что в качестве отправителя можно указать любой почтовый ящик. Таким образом можно послать письмо, подставив в поле «From» вымышленное значение. Процесс такого почтового обмана называется Спуфинг (e-mail spoofing). Чтобы бороться с этим явлением, был разработан и введен в действие стандарт SPF – Sender Policy Framework (структура политики отправителя).

SPF позволяет владельцу домена указать в TXT-записи домена специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Рассмотрим простой пример SPF-записи:

example.org. IN TXT «v=spf1 +a +mx -all»

Теперь более детально о допустимых опциях. Рассмотрим варианты поведения получателя, в зависимости от используемых опций:

• «v=spf1» — используемая версия SPF.
• «+» — принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это «Pass»;
• «-» — Отклонить (Fail);
• «~» — «мягкое» отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ;
• «?» — нейтральное отношение;
• «mx» — включает в себя все адреса серверов, указанные в MX-записях домена;
• «ip4» — опция позволяет указать конкретный IP-адрес или сеть адресов;
• «a» — указываем поведение в случае получения письма от конкретного домена;
• «include» — включает в себя хосты, разрешенные SPF-записью указанного домена;
• «all» — все остальные сервера, не перечисленные в SPF-записи.

Итак, попробуем разобраться, что же значит SPF-запись, указанная выше.

• «+a» — разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org;
• «+mx» — разрешает прием писем, если отправляющий хост указан в одной из MX-записей для example.org;
• «-all» — все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать.

Для лучшего понимания того, как работает SPF, рассмотрим еще один, более сложный пример:

example.org. IN TXT «v=spf1 mx ip4:78.110.50.123 +a:mail.ht-systems.ru include:gmail.com ~all»

Теперь более подробно о используемых опциях...

• «mx» — принимать письма от серверов, указанных в MX-записях;
• «ip4:78.110.50.123» — принимать письма, отправленные с IP-адреса 78.110.50.123;
• «+a:mail.ht-systems.ru» — то же, что и a:mail.ht-systems.ru. Принимать от mail.ht-systems.ru;
• «include:gmail.com» — принимать письма с серверов, разрешенных SPF-записями gmail.com;
• «~all» — принимать письма со всех остальных серверов, но помечать их как СПАМ

А теперь рассмотрим еще более «экзотичный» пример. В описании возможных опций указывалось, что возможно указание сетей ip-адресов. Стоит отметить, что это применимо и к записям «a» и «mx». Рассмотрим следующий пример:

example.org. IN TXT «v=spf1 mx/24 a:hts.ru/24 -all»

«mx/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX-ы домена;
«a:hts.ru/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена hts.ru;
«-all» — всех остальных отправителей — блокируем.

Иногда можно встретить следующие записи (очень редко):

«ptr» — проверяет PTR-запись IP-адреса отправителя. Если она сходится с указаным доменом, то механизм проверки выдает положительный результат. Тоесть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен. Серьезным недостатком даного метода есть то, что генерируется очень большое количество DNS-запросов;
«exists» — выполняется проверка, резолвится ли домен на какой-либо IP-адрес. Тоесть, по существу, выполняется проверка работоспособности доменного имени. Кстати, не имеет значения, на какой IP-адрес резолвится домен, даже если это «серые» сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) или loopback (127.0.0.1).

Пример использования:

example.org. IN TXT «v=spf1 ptr:example.org exist:example.org -all»

Также не будет излишним ознакомиться со следующими опциями: redirect и exp.

«redirect» — указывает получателю, что нужно проверять SPF-запись указаного домена, вместо текущего домена. Пример:

example.org. IN TXT «v=spf1 redirect:example.com ~all»

В даном примере будет проводится проверка SPF-записи домена example.com, а не example.org.

«exp» — использование даной опции позволяет задать сообщение о ошибке, которое будет передано отправителю при возникновении таковой. Размещается в конце SPF-записи, даже после опции all. Рассмотрим более детально механизм работы опции exp.

Допустим, что у домена example.org следущая SPF-запись:

example.org. IN TXT «v=spf1 +a +mx -all exp=spf.example.org»

Теперь содаем TXT-запись для домена spf.example.org:

spf.example.org. IN TXT «You host not allowed e-mail to me»

В результате этих шаманских действий SPF-запись будет контролировать, чтобы почта доставлялась только от валидных хостов, а всем остальным будет отправляться сообщение о ошибке, прописанное в TXT-записи домена spf.example.org.

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

Сегодня хочу рассказать вам о таком понятии, как 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.