Загадки и мифы SPF

SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.

TL;DR — рекомендации в конце.

1. Заблуждение: SPF защищает мой домен от подделок

На самом деле: SPF никак не защищает видимый пользователю адрес отправителя.

Объяснение: SPF вообще не работает с содержимым письма, которое видит пользователь, в частности с адресом отправителя. SPF авторизует и проверяет адреса на уровне почтового транспорта (SMTP) между двумя MTA (envelope-from, RFC5321.MailFrom aka Return-Path). Эти адреса не видны пользователю и могут отличаться от видимых пользователю адресов из заголовка From письма (RFC5322.From). Таким образом, письмо с поддельным отправителем во From запросто может пройти SPF-авторизацию.

2. Заблуждение: Я внедрю SPF и станет безопасней и меньше спама

На самом деле: скорей всего, изменений в плане безопасности и спама вы не заметите.

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

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

3. Заблуждение: SPF отрицательно (положительно) влияет на доставляемость писем

На самом деле: Всё зависит от типа письма и пути, по которому оно доставляется.

Объяснение: SPF сам по себе не влияет на доставляемость писем обычным потоком, и отрицательно влияет при неправильном внедрении или на непрямых потоках писем (indirect flow), когда пользователь получает письма не от того сервера, с которого письмо было отправлено, например на перенаправленные письма. Но системы спам-фильтрации и репутационные классификаторы учитывают наличие SPF, что в целом, на основном потоке писем, дает положительный результат. Если, конечно, вы не рассылаете спам.

4. Заблуждение: SPF авторизует отправителя письма

На самом деле: SPF авторизует почтовый сервер, отправляющий письмо от имени домена.

Объяснение: Во-первых, SPF работает только на уровне доменов, а не для отдельных адресов электронной почты. Во-вторых, даже если вы являетесь легальным пользователем почты определенного домена, SPF не позволяет вам отправить письмо из любого места. Чтобы письмо прошло SPF-валидацию, вы должны отправлять только через авторизованный сервер. В-третьих, если вы авторизовали сервер по SPF (например, разрешили отправку писем от вашего домена через какого-либо ESP или хостинг-провайдера) и он не реализует дополнительных ограничений, то все пользователи данного сервера могут рассылать письма от имени вашего домена. Всё это следует учитывать при внедрении SPF и аутентификации писем в целом.

5. Заблуждение: письма, не прошедшие авторизацию SPF, отсеиваются

На самом деле: SPF-авторизация или ее отсутствие в общем случае не влияет кардинально на доставку писем.

Объяснение: стандарт SPF является только стандартом авторизации и в явном виде указывает, что действия, применяемые к письмам, не прошедшим авторизацию, находятся за пределами стандарта и определяются локальной политикой получателя. Отказ в получении таких писем приводит к проблемам с письмами, идущими через непрямые маршруты доставки, например, перенаправления или списки рассылки, и этот факт должен учитываться в локальной политике. На практике, строгий отказ из-за сбоя SPF-авторизации не рекомендуется к использованию и возможен только при публикации доменом политики -all (hardfail) в отсутствии других средств фильтрации. В большинстве случаев, SPF-авторизация используется как один из признаков в классификаторах или как один из факторов в весовых системах. Причем вес этого фактора очень небольшой, потому что нарушение SPF-авторизации обычно не является сколь-либо достоверным признаком спама — многие спам-письма проходят SPF-авторизацию, а вполне легальные — нет, и вряд ли эта ситуация когда-нибудь кардинально изменится. При таком использовании, разницы между -all и ~all нет.

Факт наличия SPF-авторизации важен не столько для доставки письма и принятия решения о том, является ли оно спамом, сколько для подтверждения адреса отправителя и связи с доменом, что позволяет для письма использовать не репутацию IP, а репутацию домена.

На принятие решения о действии над письмом, не прошедшим авторизацию, гораздо больше влияет политика DMARC. Политика DMARC позволяет отбросить (или поместить в карантин) все письма, не прошедшие авторизацию или их процент.

6. Заблуждение: в SPF надо использовать -all (hardfail), это безопасней чем ?all или ~all

На самом деле: на практике -all никак не влияет ни на чью безопасность, зато негативно влияет на доставляемость писем.

Объяснение: -all приводит к блокировке писем, отправленных через непрямые маршруты теми немногими получателями, которые используют результат SPF напрямую и блокируют письма. При этом на большую часть спама и поддельных писем эта политика существенного влияния не окажет. На текущий момент наиболее разумной политикой считается ~all (softfail), она используется практически всеми крупными доменам, даже теми, у которых очень высокие требованиями к безопасности (paypal.com, например). -all можно использовать для доменов, с которых не производится отправки легальных писем. Для DMARC -, ~ и ? являются эквивалентными.

7. Заблуждение: достаточно прописать SPF только для доменов, с которых отправляется почта

На самом деле: необходимо также прописать SPF для доменов, используемых в HELO почтовых серверов, и желательно прописать блокирующую политику для неиспользуемых для отправки почты A-записей и вайлдкарда.

Объяснение: в некоторых случаях, в частности, при доставке NDR (сообщение о невозможности доставки), DSN (сообщение подтверждения доставки) и некоторых автоответах, адрес отправителя в SMTP-конверте (envelope-from) является пустым. В таком случае SPF проверяет имя хоста из команды HELO/EHLO. Необходимо проверить, какое имя используется в данной команде (например, заглянув в конфигурацию сервера или отправив письмо на публичный сервер и посмотрев заголовки) и прописать для него SPF.

Спамерам совершенно не обязательно слать спам с тех же доменов, с которых вы отправляете письма, они могут отправлять от имени любого хоста, имеющего A- или MX-запись. Поэтому, если вы публикуете SPF из альтруистических соображений, то надо добавлять SPF для всех таких записей, и желательно еще wildcard (*) для несуществующих записей.

8. Заблуждение: лучше добавлять в DNS запись специального типа SPF, а не TXT

На самом деле: надо добавлять запись типа TXT.

Объяснение: в текущей версии стандарта SPF (RFC 7208) записи типа SPF являются deprecated и не должны больше использоваться.

9. Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться

На самом деле: по возможности, следует максимально сократить SPF-запись и использовать в ней только адреса сетей через ip4/ip6.

Объяснение: на разрешение SPF-политики отведен лимит в 10 DNS-запросов. Его превышение приведет к постоянной ошибке политики (permerror). Кроме того, DNS является ненадежной службой, и для каждого запроса есть вероятность сбоя (temperror), которая возрастает с количеством запросов. Каждая дополнительная запись a или include требует дополнительного DNS-запроса, для include также необходимо запросить всё, что указано в include-записи. mx требует запроса MX-записей и дополнительного запроса A-записи для каждого MX-сервера. ptr требует дополнительного запроса, к тому же в принципе является небезопасной. Только адреса сетей, перечисленные через ip4/ip6, не требуют дополнительных DNS-запросов.

10. Заблуждение: TTL для SPF-записи следует сделать поменьше (побольше)

На самом деле: как и для большинства DNS-записей, лучше иметь TTL в диапазоне от 1 часа до 1 суток, заблаговременно снижая его при внедрении или планируемых изменениях и повышая при стабильно работающей политике.

Объяснение: более высокий TTL снижает вероятность ошибок DNS и, как следствие, temperror SPF, но повышает время реакции при необходимости внесения изменений в SPF-запись.

11. Заблуждение: если я не знаю, с каких IP могут уходить мои письма, то лучше опубликовать политику с +all

На самом деле: политика с явным +all или неявным правилом, разрешающим рассылку от имени домена с любых IP-адресов, негативно скажется на доставке почты.

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

12. Заблуждение: SPF бесполезен

На самом деле: SPF необходим.

Объяснение: SPF — это один из механизмов авторизации отправителя в электронной почте и способ идентификации домена в репутационных системах. В настоящее время крупные провайдеры почтовых сервисов постепенно начинают требовать наличие авторизации писем, и на письма, не имеющие авторизации, могут накладываться «штрафные санкции» по их доставке или отображению пользователю. Кроме того, на письма, не прошедшие SPF-авторизации, могут не возвращаться автоответы и отчеты о доставке или невозможности доставки. Причина в том, что эти категории ответов, как правило, идут именно на адрес SMTP-конверта и требуют, чтобы он был авторизован. Поэтому SPF необходим даже в том случае, если все письма авторизованы DKIM. Также SPF совершенно необходим в IPv6-сетях и облачных сервисах: в таких сетях практически невозможно использовать репутацию IP-адреса и письма с адресов, не авторизованных SPF, как правило, не принимаются. Одна из основных задач SPF, определенная в стандарте — как раз использование репутации доменного имени вместо репутации IP.

13. Заблуждение: SPF самодостаточен

На самом деле: необходимы также DKIM и DMARC.

Объяснение: DKIM необходим для прохождения писем через различные пересылки. DMARC необходим для защиты адреса отправителя от подделок. Кроме того, DMARC позволяет получать отчеты о нарушениях политики SPF.

14. Заблуждение: если сервер пересылает письма, необходимо использовать SRS (Sender Rewriting Schema) для сохранения SPF-авторизации.

На самом деле: SRS следует использовать только в том случае, если вы хотите дать перенаправляемым письмам авторизацию (и, как следствие, репутацию) своего домена.

Объяснение: SRS перезаписывает адрес конверта отправителя на адрес из домена перенаправляющего сервера, таким образом, для письма проходит SPF-авторизация с доменом осуществляющим перенаправление. Однако, домен отправителя RFC5322.From у такого письма не будет совпадать с доменом конверта, для которого проходит SPF-авторизация. С точки зрения DMARC такая авторизация не рассматривается как валидная. Кроме того, перенаправляемое письмо получает авторизацию домена, если бывают ситуации в которых перенаправляются спам-письма (например, переправляется общий поток писем в котором даже при наличии хорошей спам-фильтрации присутствует некоторая доля спама) — это негативно затрагивает репутацию перенаправляющего домена и наоборот, распространяет репутацию домена на спам-письма. SRS имеет смысл использовать там, где входящие письма проходят дополнительную авторзацию и спам-фильтрацию, например в списках рассылки с ограничением по отправителям, возможно в сочетании с опцией From rewrite для сохранения DMARC-аутентификации. Во всех остальных случаях, лучше уделить внимание тому, чтобы пересылки сохраняли целостность DKIM-сигнатуры.

15. Заблуждение: spf1 хорошо, spf2.0 — лучше

На самом деле: надо использовать v=spf1.

Объяснение: spf2.0 не существует. Публикация записи spf2.0 может приводить к непредсказуемым результатам. spf2.0 никогда не существовал и не был стандартом, но отсылка на него есть в серии экспериментальных стандартов, самым известным из которых является RFC 4406 (Sender ID). Эта серия стандартов разрабатывалась независимой рабочей группой, параллельно с принятием стандарта spf, что и внесло путаницу. Sender ID, который должен был решить проблему подмены адресов, не стал общепринятым стандартом и от него следует отказаться в пользу DMARC. Даже в том случае, если вы решаете использовать Sender ID и опубликовать spf2.0 запись, она не заменит записи spf1.

Я практически закончил писать эту статью, когда меня перехватила служба поддержки пользователей и настоятельно (с угрозой применения грубой силы) рекомендовала напомнить о следующих нюансах SPF, с которыми им чаще всего приходится сталкиваться при разрешении проблем:

1. SPF-политика должна заканчиваться директивой all или redirect. После этих директив ничего идти не должно.
2. Директивы all или redirect могут встретиться в политике ровно один раз, они заменяют друг друга (то есть в одной политике не может быть all и redirect одновременно).
3. Директива include не заменяет директивы all или redirect. include может встретиться в политике несколько раз, при этом политику всё равно следует завершать директивами all или redirect. Политика, включаемая через include или redirect, также должна быть валидной политикой, оканчивающейся на директиву all или redirect. При этом для include безразлично, какое правило (-all, ~all, ?all) используется для all во включаемой политике, а для redirect разница есть.
4. Директива include используется с двоеточием (include:example.com), директива redirect — со знаком равенства (redirect=example.com).
5. SPF не распространяется на поддомены. SPF. Не. Распространяется. На. Поддомены. SPF НЕ РАСПРОСТРАНЯЕТСЯ НА ПОДДОМЕНЫ. (а DMARC, по умолчанию, распространяется). Надо публиковать SPF для каждой записи A или MX в DNS, по которой производится (или может производиться) доставка почты.

Резюме

• Обязательно создайте политику для всех MX- и, желательно, A-записей.
• Добавьте SPF-политики для имен, используемых в HELO/EHLO почтового сервера.
• Публикуйте SPF-политику как TXT-запись с v=spf1 в DNS.
• В политике преимущественно используйте адреса сетей заданные через ip4/ip6. Располагайте их в начале политики, чтобы избежать лишних DNS-запросов. Минимизируйте использование include, не используйте без необходимости a, без крайней и непреодолимой необходимости не используйте mx и никогда не используйте ptr.
• Указывайте ~all для доменов, с которых реально отправляются письма, -all — для неиспользуемых доменов и записей.
• Используйте маленькие TTL на период внедрения и тестирования, затем повысьте TTL до разумных значений. Заблаговременно снижайте TTL при необходимости внесения изменений.
• Обязательно тестируйте правильность SPF-политики, например, здесь.
• Не ограничивайтесь только SPF, постарайтесь внедрить DKIM и обязательно внедрите DMARC. DMARC поможет защитить ваши письма от подделок и позволит вам получать информацию по нарушениям SPF. Это позволит выявить подделки, непрямые потоки писем и ошибки конфигурации.
• После внедрения SPF, DKIM и/или DMARC проверьте их с помощью сервиса https://postmaster.mail.ru/security/.
  SPF и DMARC проверяются по текущему состоянию, наличие DKIM проверяется по статистическим данным за предыдущий день и будет показываться только при наличии переписки с ящиками на Mail.Ru в предшествующий день или ранее.

Пример политики SPF: @ IN TXT "v=spf1 ip4:1.2.3.0/24 include:_spf.myesp.example.com ~all"