SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).
Важно понимать:
- SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.
- SPF проверяет только HELO и MAIL FROM поля.
Всю подробную информацию о данной технологии можно найти на сайте проекта «Sender Policy Framework».
Почему это важно?
На текущий момент все продвинутые анти-спам системы используют 3 основных типа анализа писем (и их вариации):
- Анализ IP-адреса сервера отправителя: его репутация, корректность A и PTR-записей.
- Анализ SPF/DMARC записей домена и цифровой подписи DKIM.
- Анализ содержимого: заголовки, тема, текст, ссылки и т.д.
Чтобы успешно пройти анти-спам систему спамеру (или мошеннику) будет необходимо: «чистый ip», красивое письмо и домен без защиты (примеры №1 и №3). Чтобы предотвратить отправку писем от «вашего имени» (фишинг) достаточно лишь добавить соответствующую TXT-запись к домену (пример №2).
Примеры
В качестве примера я отправил 3 простых письма с помощью telnet и SMTP команд. 2 письма покажут работу спам-фильтра SpamAssassin (сервис mail-tester.com), а последнее письмо будет проходить анти-спам фильтр Gmail. Для чистоты экспериментов я использовал «чистый» IP-адрес (найти его было не так и сложно) и текст без ссылок и HTML.
| # | From | To | Результат | SPF домена отправителя |
| 1 | bill.gates@microsoft.ru | *@mail-tester.com | Успешно. Баллов в mail-tester.com: 7/10 | - |
| 2 | bill.gates@microsoft.com | *@mail-tester.com | Неуспешно. Баллов в mail-tester.com: 2.1/10 | v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all |
| 3 | bill.gates@microsoft.ru | *@gmail.com | Успешно | - |
Письмо №1:
Письмо №2:
Письмо №3:
Как видно из результатов, письмо от домена «microsoft.com» не прошло бы анти-спам фильтр, даже если у него идеально чистое содержание. А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено.
Советы
- Перед установкой SPF-записи удостоверьтесь, что все ваши сервера, отправляющие письма в интернет, учтены. Не забудьте про web-сервера и другие внешние системы, иначе вы можете потерять часть писем, и тем самым навредить себе и бизнесу.
- Правильно выбирайте механизм обработки писем (Pass, Fail, SoftFail, Neutral). При безусловной переадресации вашего письма может возникнуть проблема, так как SPF проверяет только последний «хоп».
- Рекомендуется создавать SPF-записи для всех доменов второго уровня, которые принадлежат вам или вашей компании, даже если вы не отправляете от их имени письма. Для таких доменов желательно использовать простую запись «v=spf1 -all», которая говорит, что никто не можем отправлять письма от этих доменов.
Домены третьего уровня защитить можно с помощью wildcard-записи типа «* IN TXT «v=spf1 -all»». Например, проверьте SPF любого поддомена «telegram.org». - SPF-записи рекомендуется создавать не только для доменов, но и для почтовых серверов, которые занимаются отправкой писем в интернет. Это необходимо, чтобы пройти HELO/EHLO Test принимающего сервера. Стандартная запись: «mx.example.com. IN TXT «v=spf1 a -all»».
- Если у вас много доменов, которые обслуживаются несколькими основными MX-серверами, то советую использовать механизм «redirect». Например, основной домен «example.com» имеет SPF-запись «v=spf1 +a +mx -all», то остальным доменам (example1.com, example2.com и т.д.), для упрощения обслуживания, можно прописать запись «v=spf1 redirect=example.com».
- Если у вас много доменов и много почтовых серверов отправителей, распределенных географически и организационно, то можно использовать механизм «include» и отдельную зону «_spf.example.com». Как пример можно посмотреть запись для домена gmail.com – «v=spf1 redirect=_spf.google.com».
- Кроме защиты своих доменов рекомендуется защитить свою почтовую систему и пользователей, включив проверку SPF/DKIM/DMARC записей на ваших внешних почтовых серверах. Это будет хорошим дополнением даже для таких мощных программно-аппаратных комплексов, как Cisco IronPort.
- Как только полностью разберетесь с SPF, советую изучить вопрос подписи ваших электронных писем с помощью технологии DKIM и DMARC, это существенно увеличит репутацию писем.
Товарищи айтишники, не подставляйте себя и свою компанию – установите SPF-записи для всех своих доменов и MX-серверов.
Полезные сервисы
Тестирование SPF-записи
Анализ письма анти-спам фильтром SpamAssassin
Много полезных тестов (MX, SPF, Blacklist, DKIM Lookup и т.д.)
Проверка репутации почтовых серверов и доменов
Проверка домена и серверов-отправителей (здесь вы увидите кто отправляет письма от имени вашего домена)
MS Sender ID Framework SPF Record Wizard
Комментарии (30)
ValdikSS
04.11.2015 19:33+1По какой-то причине, ни в одном клиенте нет проверки SPF и DKIM по умолчанию. У меня стоит замечательное дополнение ThunderSec для Thunderbird, которое выводит огромную красную панель, если вдруг есть какие-то проблемы с SPF, DKIM и DNSBL. Сразу дает понять, кто есть кто, если сервер вдруг пропустил письмо.
ValdikSS
04.11.2015 19:34Я еще такую штуку начинал писать, но как-то забросил:
spf.valdikss.org.ru
chestor2
04.11.2015 19:46+4Я думаю, что предполагается, что анти-спам защитой должен заниматься почтовый сервер, а не почтовый клиент. Хотя, подобное дополнение почтового клиента очень интересно.
Зря забросил, это было бы полезно.ValdikSS
04.11.2015 19:49Чтобы прояснить ситуацию: дополнение ThunderSec делаю не я, и оно не заброшено, а активно развивается. А заброшен мой проверщик SPF (ссылка выше), который еще и советы дает.
achekalin
04.11.2015 19:59+3Хорошая идея, на деле потерявшая смысл из-за: необязательности ее использования, политик вида ~ вместо -, и из-за кривых рук админов вмех мастей. Лично имел радость, когда почта с нашего домена не доходила до одного из банков, админы которого настроилт проверялку spf как-то не так (притом на просьбу решить вопрос на их стороне ответ был один — мы банк, у нас все ок, ищите проблему у себя; наша spf-запись была правильной).
По факту получаем, что технолгия как бы есть, но работает вполсилы, отчего не уважаема и не набирает авторитета. С учетом ее возраста можно считать, что по-настоящему она уже не «взлетела». Увы.chestor2
04.11.2015 20:08Да, технология не новая, но все же она работает и учитывается всеми крупными почтовыми сервисами. Поэтому, SPF лучше иметь, чем не иметь. А если хочется большей надежности и новой технологии — есть DKIM/DMARC.
Интересно было бы посмотреть на заголовки писем, отчет анти-спам фильтра и spf домена, чтобы выяснить причину.achekalin
04.11.2015 21:52Да, DKIM скорее жив, чем мертв. В отличии от :)
Но верить только SPF — это как отбивать спам только по RBL: работает, но веры нет.
Rumickon
04.11.2015 21:34+1Если я поведусь на советы и пропишу "-all", не будет ли это мешать при пересылке/перенаправлении письма почтовыми хостерами? Иногда получаю dmarc-отчеты, в которых в качестве отправителя указан ip mail.ru. Письма то проходят, т. к. настроен dkim, но не всех же он есть.
chestor2
04.11.2015 21:40Если ваше письмо будет безусловно перенаправлено другому адресату, то, действительно, может возникнуть проблема, так как SPF проверяет только последний хоп, а пересылаемый сервер не будет иметь права на отправку. В данном случае можно использовать механизм SoftFail (~).
achekalin
04.11.2015 22:03Именно так все и прописывают в своих spf записях, от греха. От чего эффективность идеи и пропадает. Прописывая же ~ для того, чтобы форварды работали, мы сами себе наступаем… на идею, так сказать. Так уж лучше вообще не делать spf запись, честнее оно получится )
chestor2
04.11.2015 22:42Не согласен, все же смысл остается) Если спамер захотел использовать твой домен (с ~), то его письмо получит дополнительный «минус» в карму, и вероятности его доставки в Inbox уже меньше.
Hint
05.11.2015 02:19+5Проблема в том, что SPF проверяет только параметр Return-Path, а не From. Пользователи же видят именно From. Так что штука практически бесполезная в контексте защиты от фишинга и нужна больше для защиты от спама ответными сообщениями об ошибках.
DmitryKoterov
05.11.2015 04:37+3Вот. Золотой комментарий! Эта тема в топике вообще не рассмотрена.
Не только для защиты от спама ответными сообщениями, кстати, но еще и для того, чтобы ваш домен какой нибудь SpamHaus не забанил якобы за рассылку спама.
bes_internal
05.11.2015 04:57+5Очень сумбурная статья путающая спам и фишинг, жесткие правила и эвристику.
По порядку:
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 для других и настраивайте для своих доменов.chestor2
05.11.2015 07:29Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.
Согласен.
Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).
Это было бы правильно. В любом случае, лучше иметь -all на всех доменах второго уровня, которые не используются. На них в последствии могут «повесить» A-записи.
у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)
Реальный спам больших объемов, конечно не доставить, а вот доставить точечное письмо, думаю, можно.
Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.
Согласен. Но, пока нет DMARC лучше иметь SPF :)
Большое спасибо за столь полезный комментарий!
Gendalph
05.11.2015 17:41-1FYI: если при разборе SPF требуется >10 запросов к DNS можете считать свой SPF невалидным — Gmail его признает валидным, а вот Google Apps при роутинге в группах рассылки такие письма «съедает», это реально известный мне «артефакт». Проверить можно dmarcian'ом
FYI2: DMARC это, конечно, круто, но кто его смотрит? Ответ: да почти никто! Настраивали DMARC и почти не получали отчетов.
Итого:
— сначала настройте A и PTR записи (MX иметь хорошо, но на практике совсем не обязательно, если вы не принимаете почту)
— дальше SPF (можно сделать один общий и делать include:_spf.your-domain.tld)
— если мало — DKIM
На блеклисты можно не обращать внимания (проблемы могут быть только с A&T'шным DNSBL — эти *** игнорируют любую попытку связаться, выяснить в чем дело).
z3apa3a
05.11.2015 19:03+3К сожалению, от статьи действительно может быть больше вреда чем пользы. Есть такие аспекты:
- На доменах с «живыми» пользователями нельзя использовать потитику -all
существуют списки рассылки и редиректоры (например перенаправления с одного ящика в другой), которые не меняют адрес в SMTP-конверте. Ваши пользователи на смогут писать пользователям на адреса-редиректоры и в списки рассылки, т.к. SPF будет биться.
Политику -all можно использовать только на «тразакционных» доменах, в которых находятся только ролевые адреса.
- Для «живых» получателей нельзя реджектить письма по результатам только SPF проверки
по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
По этим двум причинам ни один Mailbox Provider не устанавливает политику -all для своих доменов и не реджектит письмо только на основании SPF. Так что ваш эксперимент с письмам от microsoft на google в общем-то был ошибочен, SPF так не работает.
- При установке SPF "-all" для поддоменов скорей всего отломается хождение NDR (отчетов о доставке письма от Mailer Daemon).
Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
- DMARC это не шифрование
это политика, в которой вы можете в явном виде указать, как следует поступать с письмами от вашего домена, которые не проходят аутентификацию. Я бы настоятельно рекомендовал вам до включения "-all" в SPF вместо "~all" сделать запись DMARC для получения отчетов. По этим отчетам вы сможете понять, какое количество валидных писем вы можете потенциально потерять.
- SPF не принесет вам профита. Внедрение SPF для вашего домена не дает вам никакой пользы.
SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
SPF защищает только адрес конверта, который не видим получателю. Об этом выше сказали. Точно так же, сам по себе не работает DKIM. Поэтому имеет смысл использовать SPF только как один из механизмов аутентификации отправителя письма в рамках политики DMARC.
chestor2
05.11.2015 20:37К сожалению, от статьи действительно может быть больше вреда чем пользы.
На доменах с «живыми» пользователями нельзя использовать потитику -all
В статье я не призываю устанавливать жесткий механизм Fail для «боевых доменов» (только для доменов, которыми не пользуются), я призываю обратить на это внимание. Проверьте SPF и DMARC-записи 10-и крупных компаний России и вы увидите, что об этом задумываются немногие. Хороший пример — www.nalog.ru/rn77/news/activities_fts/5771252 (ни SPF, ни DMARC нету).
Для «живых» получателей нельзя реджектить письма по результатам только SPF проверки
по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
Все зависит от компании и ее политик безопасности. В некоторых сферах пересылка писем с рабочего почтового ящика на персональный запрещена.
Согласен, что для реджектить такие письма не лучший вариант, но учитывать эту проверку анти-спам фильтр должен (это будет дополнительный минус балл к репутации письма).
При установке SPF "-all" для поддоменов скорей всего отломается хождение NDR (отчетов о доставке письма от Mailer Daemon).
Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
Это было учтено в статье:
SPF-записи рекомендуется создавать не только для доменов, но и для почтовых серверов, которые занимаются отправкой писем в интернет. Это необходимо, чтобы пройти HELO/EHLO Test принимающего сервера. Стандартная запись: «mx.example.com. IN TXT «v=spf1 a -all»».
DMARC это не шифрование
Так никто обратного не утверждает.
SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
Если говорить о защите от спама, я думаю, что это улучшит качество анализа, пусть и совсем немного. При том, я советую включать проверку и SPF и DKIM и DMARC.
Если говорить о подделке домена, то согласен, решать проблему нужно комплексно, но начать можно SPF :)
Спасибо полезный за комментарий!
- На доменах с «живыми» пользователями нельзя использовать потитику -all
bebebe
06.11.2015 09:35Проблема с 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"z3apa3a
07.11.2015 01:41Yahoo (3й в мире по количеству активных пользователей почтовый сервис) и AOL (5й в мире) используют p=reject уже достаточно давно.
bebebe
07.11.2015 07:13То есть получается, что пользователи не могут настроить себе редирект на другой ящик и участвовать в подавляющем большинстве рассылок? Как они живут вообще тогда, интересно.
z3apa3a
07.11.2015 13:48Редиректы будут работать, т.к. редиректы не меняют заголовков письма и не бьют DKIM-подпись (исключения были, например до недавнего времени Рамблер менял To:). Так же нормально будут работать списки рассылки, которые не меняют содержимое, тему письма и другие подписанные заголовки. Крупные списки рассылки, например Google Groups уже ведут себя корректно по отношению к DMARC, и в From: подставляют свой адрес при изменении содержимого писем, а не адрес оригинального отправителя и переподписывают письмо своим DKIM.
Вообще строгий DMARC будут вводить все крупные провайдеры, и довольно скоро, так что владельцам списков рассылки уже надо быть к этому готовыми.bebebe
09.11.2015 08:51а какие планы у mail.ru?
z3apa3a
09.11.2015 12:25p=reject используется пока только на технологических и рассылочных доменах, технически мы уже готовы к ее включению на доменах с ящиками пользователей, но необходима предварительная работа с community чтобы избежать потенциального «шока» от включения, чем мы и планируем заняться.
Прямо сейчас мы не просто поддерживаем DMARC, но и начинаем показывать уведомления на тех письмах, которые пока проходят проверку из-за p=none, но могут попасть под более строгие фильтры в будущем. Это должно сподвигнуть администраторов почтовых серверов и рассылок исправить потенциальные проблемы. Когда закончим внедрение этой фичи напишем статью о том, как все это работает и какие планы на ближайшее будущее.
bebebe
09.11.2015 12:41Проясните следующее:
Я настроил у себя p=none, получаю отчеты от разных провайдеров со сводной статистикой.
Кто-то (из пользователей) настроил у себя отправку писем с from: мой-домен.tld, при этом письмо не проходит через мои сервера и теоретически дропнется в DMARC.
Вроде как есть этот отчет, но если серьезно, то на мой взгляд, он бесполезный. Я вижу только IP последнего received и временной промежуток. Нет ни оригинального From: или To:, нет темы, нет message-id. Ничего.
Что я должен делать с этими отчетами? У меня есть только информация, что письмо прошло не через мои сервера (факт получения отчета) и IP (например, какой-то IP из пула DSL в США). Я не могу узнать даже пользователя, который отправлял письмо. Что делать дальше?
1) внедрить p=reject и тупо потерять множество писем?
2) добавить этот неизвестный IP в +ip4:x.x.x.x в DNS?
3) не внедрять DMARC вообще? Какой тогда смысл.
z3apa3a
09.11.2015 13:07На самом деле смысла много, даже с 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-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.
bebebe
09.11.2015 13:33Реальный кейс:
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, то письмо пропало бы вовсе.
На партнера повлиять нельзя (в плане настройки его серверов).
Замкнутый круг =(
alex_shpak
Для доменов третьего уровня можно использовать wildcard-записи (со звездочкой): www.openspf.org/FAQ/The_demon_question
Правда, их поддерживают не все панели управления.
chestor2
Большое спасибо, добавил в статью.