Значимость 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.

    # 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:
    Пример №1. Mail-Tester. SPF не задан.
    Письмо №2:
    Пример №2. Mail-Tester. SPF задан.
    Письмо №3:
    Пример №3. Gmail. SPF не задан.

    Пример №3. Gmail. Письмо

    Пример №3. Gmail. Заголовки

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

    Советы


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

    Полезные сервисы


    Тестирование SPF-записи
    Анализ письма анти-спам фильтром SpamAssassin
    Много полезных тестов (MX, SPF, Blacklist, DKIM Lookup и т.д.)
    Проверка репутации почтовых серверов и доменов
    Проверка домена и серверов-отправителей (здесь вы увидите кто отправляет письма от имени вашего домена)
    MS Sender ID Framework SPF Record Wizard
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 33

      0
      Для доменов третьего уровня можно использовать wildcard-записи (со звездочкой): www.openspf.org/FAQ/The_demon_question
      Правда, их поддерживают не все панели управления.
        0
        Большое спасибо, добавил в статью.
        +1
        По какой-то причине, ни в одном клиенте нет проверки SPF и DKIM по умолчанию. У меня стоит замечательное дополнение ThunderSec для Thunderbird, которое выводит огромную красную панель, если вдруг есть какие-то проблемы с SPF, DKIM и DNSBL. Сразу дает понять, кто есть кто, если сервер вдруг пропустил письмо.
          0
          Я еще такую штуку начинал писать, но как-то забросил:
          spf.valdikss.org.ru
            +4
            Я думаю, что предполагается, что анти-спам защитой должен заниматься почтовый сервер, а не почтовый клиент. Хотя, подобное дополнение почтового клиента очень интересно.
            Зря забросил, это было бы полезно.
              0
              Чтобы прояснить ситуацию: дополнение ThunderSec делаю не я, и оно не заброшено, а активно развивается. А заброшен мой проверщик SPF (ссылка выше), который еще и советы дает.
          +3
          Хорошая идея, на деле потерявшая смысл из-за: необязательности ее использования, политик вида ~ вместо -, и из-за кривых рук админов вмех мастей. Лично имел радость, когда почта с нашего домена не доходила до одного из банков, админы которого настроилт проверялку spf как-то не так (притом на просьбу решить вопрос на их стороне ответ был один — мы банк, у нас все ок, ищите проблему у себя; наша spf-запись была правильной).

          По факту получаем, что технолгия как бы есть, но работает вполсилы, отчего не уважаема и не набирает авторитета. С учетом ее возраста можно считать, что по-настоящему она уже не «взлетела». Увы.
            0
            Да, технология не новая, но все же она работает и учитывается всеми крупными почтовыми сервисами. Поэтому, SPF лучше иметь, чем не иметь. А если хочется большей надежности и новой технологии — есть DKIM/DMARC.
            Интересно было бы посмотреть на заголовки писем, отчет анти-спам фильтра и spf домена, чтобы выяснить причину.
              0
              Да, DKIM скорее жив, чем мертв. В отличии от :)

              Но верить только SPF — это как отбивать спам только по RBL: работает, но веры нет.
            +1
            Если я поведусь на советы и пропишу "-all", не будет ли это мешать при пересылке/перенаправлении письма почтовыми хостерами? Иногда получаю dmarc-отчеты, в которых в качестве отправителя указан ip mail.ru. Письма то проходят, т. к. настроен dkim, но не всех же он есть.
              0
              Если ваше письмо будет безусловно перенаправлено другому адресату, то, действительно, может возникнуть проблема, так как SPF проверяет только последний хоп, а пересылаемый сервер не будет иметь права на отправку. В данном случае можно использовать механизм SoftFail (~).
                0
                Именно так все и прописывают в своих spf записях, от греха. От чего эффективность идеи и пропадает. Прописывая же ~ для того, чтобы форварды работали, мы сами себе наступаем… на идею, так сказать. Так уж лучше вообще не делать spf запись, честнее оно получится )
                  0
                  Не согласен, все же смысл остается) Если спамер захотел использовать твой домен (с ~), то его письмо получит дополнительный «минус» в карму, и вероятности его доставки в Inbox уже меньше.
              +5
              Проблема в том, что SPF проверяет только параметр Return-Path, а не From. Пользователи же видят именно From. Так что штука практически бесполезная в контексте защиты от фишинга и нужна больше для защиты от спама ответными сообщениями об ошибках.
                +3
                Вот. Золотой комментарий! Эта тема в топике вообще не рассмотрена.

                Не только для защиты от спама ответными сообщениями, кстати, но еще и для того, чтобы ваш домен какой нибудь SpamHaus не забанил якобы за рассылку спама.
                  0
                  Для этого есть DMARC
                    0
                    И еще:
                    An SPF-compliant domain publishes valid SPF records as described in
                    Section 3. These records authorize the use of the relevant domain
                    names in the «HELO» and «MAIL FROM» identities by the MTAs specified
                    therein.

                    https://tools.ietf.org/html/rfc7208#section-2.1

                    Тут же говорится про MAIL FROM?
                      0
                      Return-Path это заголовок письма, в который при локальной доставке в ящик подставляется содержимое SMTP конверта MAIL FROM, поэтому, хотя это и не совсем одно и то же, термины часто используются как эквивалентные, чтобы не путать с From: (RFC5322.From) — заголовком письма.
                    +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 для других и настраивайте для своих доменов.
                      0
                      Если вы заходили на 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 :)

                      Большое спасибо за столь полезный комментарий!
                      –1
                      FYI: если при разборе SPF требуется >10 запросов к DNS можете считать свой SPF невалидным — Gmail его признает валидным, а вот Google Apps при роутинге в группах рассылки такие письма «съедает», это реально известный мне «артефакт». Проверить можно dmarcian'ом
                      FYI2: DMARC это, конечно, круто, но кто его смотрит? Ответ: да почти никто! Настраивали DMARC и почти не получали отчетов.

                      Итого:
                      — сначала настройте A и PTR записи (MX иметь хорошо, но на практике совсем не обязательно, если вы не принимаете почту)
                      — дальше SPF (можно сделать один общий и делать include:_spf.your-domain.tld)
                      — если мало — DKIM
                      На блеклисты можно не обращать внимания (проблемы могут быть только с A&T'шным DNSBL — эти *** игнорируют любую попытку связаться, выяснить в чем дело).
                        +3
                        К сожалению, от статьи действительно может быть больше вреда чем пользы. Есть такие аспекты:
                        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.


                          0
                          К сожалению, от статьи действительно может быть больше вреда чем пользы.
                          На доменах с «живыми» пользователями нельзя использовать потитику -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 :)

                          Спасибо полезный за комментарий!
                          0
                          Проблема с 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"
                          
                            0
                            Yahoo (3й в мире по количеству активных пользователей почтовый сервис) и AOL (5й в мире) используют p=reject уже достаточно давно.
                              0
                              То есть получается, что пользователи не могут настроить себе редирект на другой ящик и участвовать в подавляющем большинстве рассылок? Как они живут вообще тогда, интересно.
                                0
                                Редиректы будут работать, т.к. редиректы не меняют заголовков письма и не бьют DKIM-подпись (исключения были, например до недавнего времени Рамблер менял To:). Так же нормально будут работать списки рассылки, которые не меняют содержимое, тему письма и другие подписанные заголовки. Крупные списки рассылки, например Google Groups уже ведут себя корректно по отношению к DMARC, и в From: подставляют свой адрес при изменении содержимого писем, а не адрес оригинального отправителя и переподписывают письмо своим DKIM.
                                Вообще строгий DMARC будут вводить все крупные провайдеры, и довольно скоро, так что владельцам списков рассылки уже надо быть к этому готовыми.
                                  0
                                  а какие планы у mail.ru?
                                    0
                                    p=reject используется пока только на технологических и рассылочных доменах, технически мы уже готовы к ее включению на доменах с ящиками пользователей, но необходима предварительная работа с community чтобы избежать потенциального «шока» от включения, чем мы и планируем заняться.

                                    Прямо сейчас мы не просто поддерживаем DMARC, но и начинаем показывать уведомления на тех письмах, которые пока проходят проверку из-за p=none, но могут попасть под более строгие фильтры в будущем. Это должно сподвигнуть администраторов почтовых серверов и рассылок исправить потенциальные проблемы. Когда закончим внедрение этой фичи напишем статью о том, как все это работает и какие планы на ближайшее будущее.
                                0
                                Проясните следующее:
                                Я настроил у себя 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 вообще? Какой тогда смысл.
                                  0
                                  Простите, промахнулся с ответом, он чуть ниже.
                              0
                              На самом деле смысла много, даже с 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-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.
                                0
                                Реальный кейс:

                                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, то письмо пропало бы вовсе.

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

                                Only users with full accounts can post comments. Log in, please.