Значимость SPF

Для доменов третьего уровня можно использовать wildcard-записи (со звездочкой): www.openspf.org/FAQ/The_demon_question
Правда, их поддерживают не все панели управления.

По какой-то причине, ни в одном клиенте нет проверки SPF и DKIM по умолчанию. У меня стоит замечательное дополнение ThunderSec для Thunderbird, которое выводит огромную красную панель, если вдруг есть какие-то проблемы с SPF, DKIM и DNSBL. Сразу дает понять, кто есть кто, если сервер вдруг пропустил письмо.

Хорошая идея, на деле потерявшая смысл из-за: необязательности ее использования, политик вида ~ вместо -, и из-за кривых рук админов вмех мастей. Лично имел радость, когда почта с нашего домена не доходила до одного из банков, админы которого настроилт проверялку spf как-то не так (притом на просьбу решить вопрос на их стороне ответ был один — мы банк, у нас все ок, ищите проблему у себя; наша spf-запись была правильной).

По факту получаем, что технолгия как бы есть, но работает вполсилы, отчего не уважаема и не набирает авторитета. С учетом ее возраста можно считать, что по-настоящему она уже не «взлетела». Увы.

Если я поведусь на советы и пропишу "-all", не будет ли это мешать при пересылке/перенаправлении письма почтовыми хостерами? Иногда получаю dmarc-отчеты, в которых в качестве отправителя указан ip mail.ru. Письма то проходят, т. к. настроен dkim, но не всех же он есть.

Проблема в том, что SPF проверяет только параметр Return-Path, а не From. Пользователи же видят именно From. Так что штука практически бесполезная в контексте защиты от фишинга и нужна больше для защиты от спама ответными сообщениями об ошибках.

Очень сумбурная статья путающая спам и фишинг, жесткие правила и эвристику.
По порядку:

SPF (Sender Policy Framework) представляет из себя текстовую запись в SPF и/или TXT-записи

Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.

Важно понимать, что SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.

Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).

анти-спам системы используют… Анализ SPF/DMARC записей домена и цифровой подписи DKIM. Чтобы предотвратить отправку спама/вирусов или другой информации от «вашего имени» достаточно лишь добавить соответствующую SPF/TXT-запись к домену

Вообще говорить о спаме в разрезе SPF/DKIM/DMARC некорректно. Потому что это защиты против фишига. У них жесткие правила, они защищают конкретны вещи. Тогда как антиспам, используя статистику, базы ip, репутационные базы, сложную эвристику текста сообщений запрещают письма с нежелательным содержимым. Если вы направите письмо от microsoft.ru с полезным содержимым, то оно никогда в спам и не попадет, но будет фишингом.

DMARC — это предписывающая запись для результатов проверки DKIM, потом, на всяких случай SPF (если dkim по каким-то причинам сломался или поврежден). SPF защищает только envelope-from (smtp mail from). DKIM — From: (и другие поля) уже в самом письме. И подставить красивый envelope-from не составляет труда для спамера или, наример, при некорректных пересылках писем. Поэтому у всех стоят ~softfail политики, нужные для подстраховки при DMARC проверке, в которой SPF проверятся только как pass.

А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено

у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)

Рекомендуется создавать SPF-записи для всех доменов второго уровня

Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.

(здесь вы увидите кто отправляет письма от имени вашего домена)

Настраивайте DMARC и вам репорты будут на ваш ящик приходить. Ну или тот же dmarcian.com вам красиво это разложит в статистику.

Итого:
Вся ваша статья должна быть про DMARC! SPF с жесткой политикой (-all) сама по себе принесет скорее вред, чем пользу.
Указывайте запрещающие политики в DMARC для доменов, которые не рассылают почту.
Проверяйте DMARC для других и настраивайте для своих доменов.

К сожалению, от статьи действительно может быть больше вреда чем пользы. Есть такие аспекты:

1. На доменах с «живыми» пользователями нельзя использовать потитику -all
   
   существуют списки рассылки и редиректоры (например перенаправления с одного ящика в другой), которые не меняют адрес в SMTP-конверте. Ваши пользователи на смогут писать пользователям на адреса-редиректоры и в списки рассылки, т.к. SPF будет биться.
   
   Политику -all можно использовать только на «тразакционных» доменах, в которых находятся только ролевые адреса.
   
2. Для «живых» получателей нельзя реджектить письма по результатам только SPF проверки
   
   по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
   
   По этим двум причинам ни один Mailbox Provider не устанавливает политику -all для своих доменов и не реджектит письмо только на основании SPF. Так что ваш эксперимент с письмам от microsoft на google в общем-то был ошибочен, SPF так не работает.
   
3. При установке SPF "-all" для поддоменов скорей всего отломается хождение NDR (отчетов о доставке письма от Mailer Daemon).
   
   Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
   
4. DMARC это не шифрование
   
   это политика, в которой вы можете в явном виде указать, как следует поступать с письмами от вашего домена, которые не проходят аутентификацию. Я бы настоятельно рекомендовал вам до включения "-all" в SPF вместо "~all" сделать запись DMARC для получения отчетов. По этим отчетам вы сможете понять, какое количество валидных писем вы можете потенциально потерять.
   
5. SPF не принесет вам профита. Внедрение SPF для вашего домена не дает вам никакой пользы.
   
   SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
   
   SPF защищает только адрес конверта, который не видим получателю. Об этом выше сказали. Точно так же, сам по себе не работает DKIM. Поэтому имеет смысл использовать SPF только как один из механизмов аутентификации отправителя письма в рамках политики DMARC.
   

Проблема с DMARC еще в том, что это совершенно отвратительно работает со списками рассылки. Цитата из FAQ по DMARC:

Is there special handling required to receive DMARC email from mailing lists?

Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the «Original Authentication Results» header of mailing lists that support this feature.

А из реально «жестких» примеров я видел paypal.com и amazon.com, причем первый ставит вообще reject.

$ dig +short _dmarc.paypal.com txt
"v=DMARC1\; p=reject\; rua=mailto:d@rua.agari.com\; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"

$ dig +short _dmarc.amazon.com txt
"v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:dmarc-reports@bounces.amazon.com\; ruf=mailto:dmarc-reports@bounces.amazon.com"

На самом деле смысла много, даже с p=none, просто проблемы надо решать, если они появляются. И способов много:

Во-первых использовать на постороннем сервере ваш домен без вашего ведома — в общем-то это именно то, с чем борется DMARC. Поэтому я и пишу, что в первую очередь, надо работать с community, чтобы сообщество понимало, что так делать не надо.

Во-вторых, имея IP адрес, вы почти всегда можете отследить всю необходимую информацию по собственным логам (если кто-то настроил отправку с вашего домена и не шлет на ваши адреса — это немного странно). Настроить у себя проверку DMARC не сложно, помимо «референсного» OpenDMARC могу порекомендовать еще очень неплохой, хотя и малоизвестный проект yenma.

В-третьих, в DMARC кроме аггрегированных отчетов есть еще forensic (включаются через fo= и ruf= в _dmarc-записи), правда большая часть мейлбокс-провайдеров пока не шлет форенсик-отчеты из соображений безопасности. Ситуация может измениться, когда DMARC будет окончательно принят как стандарт. Сейчас из крупных сервисов forensic-отчеты шлют Microsoft и Linkedin. Forensic-отчет включает в себя практически полный набор заголовков, а иногда и текст письма.

В-четвертых, mail.ru на таких письмах будет показывать предупреждение о возможной подмене отправителя. А mail.ru это примерно половина всех русскоязычных получателей и это лишний повод для «Кто-то (из пользователей)» так не делать.

В-пятых, на уровне крупных организаций, можно воспользоваться услугами специализирующихся на безопасности и доставляемости электронной почты компаний, таких как ReturnPath и Agari. Последняя практически полностью специализируется на DMARC. Они «умеют» получать forensic-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.

Реальный кейс:

1) Есть мой домен example.com, я настроил p=quarantine (понаблюдать).

2) Есть домен партнера partner.com, у них есть список рассылки вида group123@partner.com, в который входят получатели user1@example.com, user2@example.com

3) Мой пользователь user3@example.com шлет на group123@partner.com, в результате user1 и user2 получают это письмо помарканое как спам, потому что From: указан как example.com, а IP в SPF не из моих блоков.

4) В результате, если был бы p=reject, то письмо пропало бы вовсе.

На партнера повлиять нельзя (в плане настройки его серверов).
Замкнутый круг =(