Загадки и мифы 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. Заблуждение: одна SPF-запись — хорошо, а две — лучше
На самом деле: запись должна быть ровно одна.
Объяснение: это требование стандарта. Если записей будет более одной, это приведет к постоянной ошибке (permerror). Если необходимо объединить несколько SPF-записей, опубликуйте запись с несколькими include.
15. Заблуждение: spf1 хорошо, spf2.0 — лучше
На самом деле: надо использовать v=spf1.
Объяснение: spf2.0 не существует. Публикация записи spf2.0 может приводить к непредсказуемым результатам. spf2.0 никогда не существовал и не был стандартом, но отсылка на него есть в экспериментальном стандарте RFC 4406 (Sender ID), который писался в предположении, что такой стандарт будет принят, ведь его принятие обсуждалось на тот момент. Sender ID, который должен был решить проблему подмены адресов, не стал общепринятым стандартом и от него следует отказаться в пользу DMARC. Даже в том случае, если вы решаете использовать Sender ID и опубликовать spf2.0 запись, она не заменит записи spf1.
Я практически закончил писать эту статью, когда меня перехватила служба поддержки пользователей и настоятельно (с угрозой применения грубой силы) рекомендовала напомнить о следующих нюансах SPF, с которыми им чаще всего приходится сталкиваться при разрешении проблем:
- SPF-политика должна заканчиваться директивой
allилиredirect. После этих директив ничего идти не должно. - Директивы
allилиredirectмогут встретиться в политике ровно один раз, они заменяют друг друга (то есть в одной политике не может бытьallиredirectодновременно). - Директива
includeне заменяет директивыallилиredirect.includeможет встретиться в политике несколько раз, при этом политику всё равно следует завершать директивамиallилиredirect. Политика, включаемая черезincludeилиredirect, также должна быть валидной политикой, оканчивающейся на директивуallилиredirect. При этом дляincludeбезразлично, какое правило (-all,~all,?all) используется дляallво включаемой политике, а дляredirectразница есть. - Директива
includeиспользуется с двоеточием (include:example.com), директиваredirect— со знаком равенства (redirect=example.com). - 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"
