Больше нет писем в папке Spam: настройка SMTP-сервера. Что такое и как создать 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.

Проблема почтового спама сейчас стоит достаточно остро. Спаммеры часто подделывают электронные письма, указывая в качестве отправителя e-mail произвольного пользователя. SPF (Sender Policy Framework) — простой стандарт, помогающий отличить настоящие письма от подделки. SPF работает только при условии, что в DNS-записи о домене отправителя присутствует специальное поле. В настоящей статье описывается как с помощью этой технологии защитить письма с собственного домена от подделки.

Стандарт отправки электронной почты SMTP позволяет указывать произвольный адрес в качестве адреса отправителя. Такая незащищенность приводит к массовым злоупотреблениям. Для защиты от неавторизованной отправки писем в 2003 году был предложен стандарт SPF, а в апреле 2006 года SPF принят в качестве стандарта RFC-4408 . Сейчас SPF поддерживается подавляющим большинством интернет-провайдеров и крупных интернет-компаний.

Идея стандарта состоит в следующем: в DNS-запись домена добавляется специальное поле типа TXT, содержащее информацию о серверах, которым разрешено или запрещено отправлять почту от имени данного домена. Кроме того, запись может содержать описание политики поведения для всех посторонних серверов. Рассмотрим пример SPF-записи для домена сайт

@ IN TXT "v=spf1 +mx +ip4:77.91.227.90/26 +a:mail.2x4.ru +a:sendmail.2x4.ru +ip4:92.241.168.112 include:gmail.com include:yandex.ru ~all"

Запись начинается с v=spf1, а затем следует перечень серверов или групп серверов с указанием политики поведения (в форме модификатора). Возможны 4 модификатора:

• + принять (модификатор по умолчанию)
• - отклонить
• ~ мягкое отклонение, пометить как возможный спам
• ? отнестить нейтрально (поведение по умолчанию, если сервер не соответствует ни одному выражению).

После модификатора указывается идентификатор механизма верификации. Перечислим несколько наиболее часто используемых механизмов:

• mx - относится к почтовым серверам данного домена
• ip4 - задает ip-адрес или подсеть ip-адресов
• a - задает доменное имя сервера
• include - разрешает отправку писем серверам, разрешенным SPF-записью другого домена
• all - любой сервер; указывают обычно последним, задавая таким образом политику по умолчанию.

Подробное описание синтаксиса записей доступно на английском языке на официальном сайте SPF .

При получении письма, согласно стандарту, принимающий письмо сервер должен запросить текстовые DNS-записи домена отправителя. Если существует текстовая запись, начинающаяся с v=spf1, то принимающий сервер последовательно проверяет сервер, от которого получено письмо на соответствие с выражениями в строке. Если произошло совпадение, то процесс сравнения останавливается и дальнейшее поведение определяется модификатором совпавшего выражения. Например, в приведенном выше примере, отправка разрешена для почтового сервера домена, серверов c ip-адресом или доменным именем среди заданных, а также для всех серверов, разрешенных SPF-записью доменов gmail.com и yandex.ru. Политика по умолчанию - мягкое отклонение.

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

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

Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all» » говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).

Важно понимать:

1. SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.
2. SPF проверяет только HELO и MAIL FROM поля.

Всю подробную информацию о данной технологии можно найти на сайте проекта «Sender Policy Framework» .

Почему это важно?

На текущий момент все продвинутые анти-спам системы используют 3 основных типа анализа писем (и их вариации):

1. Анализ IP-адреса сервера отправителя: его репутация, корректность A и PTR-записей.
2. Анализ SPF/DMARC записей домена и цифровой подписи DKIM.
3. Анализ содержимого: заголовки, тема, текст, ссылки и т.д.

Чтобы успешно пройти анти-спам систему спамеру (или мошеннику) будет необходимо: «чистый ip», красивое письмо и домен без защиты (примеры №1 и №3). Чтобы предотвратить отправку писем от «вашего имени» (фишинг) достаточно лишь добавить соответствующую TXT-запись к домену (пример №2).

Примеры

В качестве примера я отправил 3 простых письма с помощью telnet и SMTP команд. 2 письма покажут работу спам-фильтра SpamAssassin (сервис mail-tester.com), а последнее письмо будет проходить анти-спам фильтр Gmail. Для чистоты экспериментов я использовал «чистый» IP-адрес (найти его было не так и сложно) и текст без ссылок и HTML.

Письмо №1:


Письмо №2:


Письмо №3:

Как видно из результатов, письмо от домена «microsoft.com» не прошло бы анти-спам фильтр, даже если у него идеально чистое содержание. А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено.

1. Перед установкой SPF-записи удостоверьтесь, что учтены все сервера, отправляющие письма в интернет. Не забудьте про web-сервера и другие внешние системы, иначе вы можете потерять часть писем, и тем самым навредить себе и бизнесу.
2. Правильно выбирайте механизм обработки писем (Pass, Fail, SoftFail, Neutral). При безусловной переадресации вашего письма из одной почтовой системы в другую может возникнуть проблема, так как SPF проверяет только последний «хоп».
3. Рекомендуется создавать SPF-записи для всех доменов второго уровня, которые принадлежат вам или вашей компании, даже если вы не отправляете от их имени письма. Для таких доменов желательно использовать простую запись «v=spf1 -all », которая говорит, что никто не можем отправлять письма от этих доменов.
4. Домены третьего уровня защитить можно с помощью wildcard-записи типа «». Но, обратите внимание на то, что wildcard работает только для несуществующих поддоменов. Например, если у вас есть поддомен moscow.example.com с MX-записями, запись «*.example.com. IN TXT «v=spf1 -all» » не будет на нее распространяться. Подробнее описано в статье на Wikipedia и RFC 1034 .
   

   Moreover, the wildcard is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for. Even the definition of «does not exist» as defined in the search algorithm of RFC 1034 section 4.3.2 can result in the wild card not matching cases that one might expect with other types of wildcards.

5. SPF-записи рекомендуется создавать не только для доменов, но и для почтовых серверов, которые занимаются отправкой писем в интернет. Это необходимо, чтобы пройти HELO/EHLO Test принимающего сервера. Стандартная запись: «mx.example.com. IN TXT «v=spf1 a -all» ».
6. Если у вас много доменов, которые обслуживаются несколькими основными MX-серверами, то советую использовать механизм «redirect». Например, основной домен «example.com» имеет SPF-запись «v=spf1 +a +mx -all », то остальным доменам (example1.com, example2.com и т.д.), для упрощения обслуживания, можно прописать запись «v=spf1 redirect=example.com ».
7. Если у вас много доменов и много почтовых серверов отправителей, распределенных географически и организационно, то можно использовать механизм «include» и отдельную зону «_spf.example.com». Как пример можно посмотреть запись для домена gmail.com – «v=spf1 redirect=_spf.google.com ».
8. Кроме защиты своих доменов рекомендуется защитить свою почтовую систему и пользователей, включив проверку SPF/DKIM/DMARC записей на ваших внешних почтовых серверах. Это будет хорошим дополнением даже для таких мощных программно-аппаратных комплексов, как Cisco IronPort.
9. Как только полностью разберетесь с SPF, советую изучить вопрос подписи ваших электронных писем с помощью технологии DKIM и политики DMARC, это существенно увеличит репутацию ваших исходящих писем.

Товарищи айтишники, не подставляйте себя и свою компанию – установите SPF-записи для всех своих доменов и MX-серверов.

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

Серверов, с которых разрешена отправка электронной почты. Это необходимо для защиты репутации домена и снижения вероятности попадания писем в спам. Дело в том, что при отправке письма, можно подставить абсолютно любой адрес отправителя в поле "From:" , чем и пользуются злоумышленники при рассылке спама и фишинга от чужого имени. Такие рассылки могут значительно навредить репутации вашего домена, и создать проблемы с доставкой электронной почты с вашего домена. А вот IP адреса почтового сервера, с которого была произведена отправка, подделать нельзя. Соответственно если SPF запись для домена есть, то почтовые службы сначала проверят с того ли IP адреса идет рассылка и если не с того, то будут действовать согласно правилам указанным в SPF.

Как создать SPF запись

Как уже писалось выше, SPF это обычная текстовая запись, но данные указываются с использованием определенного синтаксиса, который мы сейчас и рассмотрим.
Пример SPF записи: " v=spf1 +a +mx -all " . Означает эта запись следующее — принимать почту с IP адресов, которые указаны в DNS записях типа A и MX для этого же домена (имеется ввиду домен, для которого это запись указана), со всех остальных почту отклонить. Можно ее немного укоротить и написать так: " v=spf1 a mx -all " , результат работы будет тот же. Рассмотрим синтаксис более детально.

• "v=spf1" — используемая версия SPF. На текущий момент она одна, первая версия.
• "+" — принимать почту. Этот параметр установлен по умолчанию, его отсутствие означает то же самое, что и его наличие.
• "-" — отклонять почту.
• "~" — принимать почту, но помещать ее в спам.
• "?" — относится нейтрально. То есть, принимать как обычное письмо.
• "mx" — содержит IP адреса всех серверов, указанных в DNS записях типа MX для домена.
• "ip4" — позволяет указать конкретные IPv4 адреса .
• "ip6" — то же, что и "Ip4", только указывается IPv6 адрес .
• "a" — указывает на IP адреса, которые указаны в DNS записях типа A для домена.
• "include" — разрешает получение почты, согласно SPF другого домена.
• "all" — все остальные, не перечисленные в SPF записи.

Рассмотрим сложный пример SPF записи

"v=spf1 mx a ip4:154.56.125.94 a:some-domain.com mx: some-domain.com include: some-domain .com ~all"
mx — принимать почту со своих почтовых серверов.
a — принимать почту с серверов, которые указаны в записях типа A для своего домена.
ip4:154.56.125.94 — принимать почту отправленную с IP 154.56.125.94. Также можно указывать подсети в формате 154.56.125.0/24.
a:some-domain.com — принимать почту с серверов, которые указаны в записях типа A для домена some-domain.com. Здесь также есть возможность указать подсеть в формате some-domain.com/24.
mx:some-domain.com — принимать почту с почтовых серверов, указанных в записях типа MX для домена some-domain.com. Возможно указание подсети аналогично с a:some-domain.com.
include:some-domain.com — разрешает получать почту согласно правилам, указанным в SPF для домена some-domain.com.
~all — помещать в спам все письма, отправленные с адресов, не указанных в SPF. Если указать -all, почта будет отклонятся.
Это наиболее часто используемые конструкции для создания SPF, но есть и другие, редко используемые, но о которых стоит знать.​

• "ptr" — проверяется PTR запись IP адреса отправителя на совпадение с указанным доменом.
  "v=spf1 ptr:your-domain.com -all"
• "exists" — проверяется резолвится ли домен по какому либо IP адресу, причем IP адрес может быть абсолютно любой.
  "v=spf1 exists:your-domain.com -all"
• "redirect" — говорит о том, что правила в SPF записи необходимо проверять на другом домене, а не на текущем.
  "v=spf1 redirect:some-domain.com -all"
• "exp" — позволяет указать текст, который будет отправляеться отправителю письма в случае не соответствия правил, указанных в SPF. Указывается самым последним.
  "v=spf1 a mx -all exp=spferror.your-domain.com"
  Небольшое пояснение, для того, что бы отдавался текст ошибки, необходимо создать домен spferror.your-domain.com и добавить для него TXT запись с желаемым текстом.