CipherCue проверила DNS-записи 67 336 доменов из своей отслеживаемой выборки в период с апреля по июль 2026 года. У 45,1% запись DMARC отсутствует вовсе. Из тех, кто её всё-таки завёл, 42,5% так и сидят на p=none, то есть лишь собирают отчёты, но не просят отклонять или помещать в спам письма, не прошедшие проверку. Полноценное отклонение (p=reject) настроили только 16,3% от всех изученных доменов. В сухом остатке: 68,4% либо не имеют записи DMARC, либо держат её в режиме простого мониторинга без принудительной политики.
Главная причина, почему p=none становится вечным, а не временным – лавина обезличенных отчётов. Каждая запись с флагом отчётности получает ежедневные агрегированные сводки (rua=) обо всех источниках, которые отправляли почту от имени этого домена. Переход к политике принуждения требует пройти по этому списку и для каждого отправителя решить, наш он или чужой. CipherCue выгрузила адреса rua= из почти 37 тысяч записей и обнаружила 10 268 уникальных доменов-получателей. Лишь малая часть принадлежит крупным игрокам вроде Proofpoint, Cloudflare, dmarcian, Valimail, Brevo или Postmark. Гораздо больше там одноразовых хешированных ящиков и ни о чём не говорящих адресов. Администратор видит кучу IP‑адресов и строк без очевидного владельца – это исследовательская задача, которую бесконечно откладывают.
В разбивке по странам Польша лидирует по доле доменов совсем без DMARC (64,6%). У США и Великобритании самая высокая доля p=reject (22,2% и 25,5%). Италия выделяется низкой долей отсутствующих записей (40,9%) и самой высокой долей p=none (36,8%) – похоже, там много начали процесс и остановились на стадии отчётов.
Что касается соседних технологий, SPF есть у 72,7% доменов, DMARC – у 54,9%, BIMI – лишь у 2,6%, MTA-STS – у 1,4%. DNSSEC в этой выборке не прошёл полную проверку цепочки, CipherCue фиксирует 0% прошедших валидацию, хотя это скорее особенность жёсткой проверки, а не абсолютное отсутствие.
Стандарт DMARC обновился в мае 2026 года: RFC 7489 заменили три новых документа – RFC 9989 (основной протокол), RFC 9990 (агрегированная отчётность) и RFC 9991 (отчётность об ошибках). Впервые DMARC получил статус предложенного стандарта IETF Standards Track. Ключевое техническое изменение – поиск организационного домена для поддоменов: вместо опоры на внешний Public Suffix List теперь используется обход DNS‑дерева вверх. MTA-STS уже стал полноценным стандартом Интернета с 2018 года, а BIMI по‑прежнему остаётся индивидуальным черновиком без формального статуса IETF, что отчасти объясняет его скромные 2,6% внедрения.
Ни SOC 2, ни ISO 27001:2022 не требуют DMARC как конкретный поименованный контроль. Организации могут внедрить его в рамках риск‑ориентированного подхода к защите электронной почты, но аудиторы не проверяют его наличие как обязательный пункт.
Живой пример из набора данных – британский производитель продуктов питания Cranswick. Его запись DMARC стоит в p=none, а отчёты шлются сразу на три разных адреса: dmarc_agg@vali.email, на ящик в eu.cp-dmarc.com и на хешированный адрес в rua.easydmarc.eu. Свести воедино три разных потока отчётов, чтобы понять, кто реально отправляет почту для домена, – ровно та работа, которую никто не хочет делать перед тем, как включить принудительную политику. CipherCue сейчас предлагает инструмент SenderLedger, который как раз и группирует обезличенные IP‑адреса и строки из отчётов в именованные сущности отправителей.