• Sender Policy Framework - официальный сайт

• dig
• SPF Record Testing Tools
• SPF-запись - проверяем валидность отправителя

Записи SPF (Sender Policy Framework) позволяют владельцам доменов указывать, каким хостам разрешается отправлять электронную почту от имени их доменов. Обычно протокол SMTP позволяет любому компьютеру отправлять сообщения электронной почты от имени какого угодно отправителя. Таким образом спамеры могут легко отправлять сообщения электронной почты с поддельным адресом отправителя. SPF позволяет владельцам домена с помощью текстовых записей DNS специального формата указывать, какие компьютеры или хосты имеют право передавать электронную почту в этом домене, затрудняя таким образом подделку адреса отправителя.

Принцип работы технологии 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 Результатами проверки условий могут являться следующие определенные результаты:

• None — означает, что либо в домене нет записей, либо вообще не удается проверить домен. В общем никакого внятного ответа не получено.
• Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить разрешен ли IP. Этот результат должен обрабатываться так же, как и None.
• Pass — означает, что все ОК и получатель может принять письмо.
• Fail — явно указывает на то, что письмо принимать не следует. Проверяющая сторона может отмаркировать письмо либо отбросить.
• SoftFail — находится где-то между Fail и Neutral. Принимающая сторона не должна отбрасывать письмо на основании только этого результата.
• TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть.
• PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.

Возьмем, для примера, какой-нибудь реальный домен. Допустим 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.

 Определив SPF-запись вы снижаете вероятность ошибочного отнесения ваших писем к числу спама. Чем более жесткая политика по умолчанию, тем больше доверие к письмам с данного домена. Если указать в конце записи "-all", то все письма с неавторизованных серверов должны отклоняться принимающим сервером. Задавая столь жесткую политику, необходимо быть уверенным, что никто из пользователей не отправляет почту через сервер локального провайдера, отсутствующий в списке. После настройки SPF обязательно протестируйте отправку писем разными способами разным адресатам. Не забудьте также, что сайт обычно тоже отправляет письма.

 Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов