{"schema_version":"1.0","service":"Publicasta","type":"article","id":231,"slug":"dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30","title":"DMARC p=none — это мониторинг, а не защита","excerpt":"CipherCue обнаружил, что 68.4% проверенных company domains всё ещё не enforce DMARC. Решение — не паника и не одна DNS-строка, а inventory senders, alignment и аккуратный переход к quarantine/reject.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru","image":{"url":"https://publicasta.com/storage/projects/9/pages/231/2026/07/bb85c602-86e5-4f63-ab7e-017230fb9583.webp","alt":"DMARC email policy переходит от monitoring к quarantine и reject gates"},"publisher":{"id":9,"slug":"cybersecurity","name":"Кибербезопасность без паники","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-07-30T13:42:21+00:00","updated_at":"2026-07-30T13:42:21+00:00","content_markdown":"DMARC-запись может выглядеть как прогресс в email security, но почти ничего не блокировать. В этом главный смысл свежих чисел CipherCue: в выборке из 67,336 company domains, проверенных с 14 апреля по 28 июля 2026 года, 68.4% либо не имели DMARC record, либо оставались на `p=none`.\n\n ![DMARC email policy переходит от monitoring к quarantine и reject gates](https://publicasta.com/storage/projects/9/pages/231/2026/07/bb85c602-86e5-4f63-ab7e-017230fb9583.webp)\n\n Это не новая уязвимость. Это незавершённый контроль. DMARC публичен с 2012 года, а в мае 2026 IETF заменил старый RFC 7489 на RFC 9989, RFC 9990 и RFC 9991. Core protocol теперь Standards Track Proposed Standard. Проблема не в том, что о DMARC никто не слышал. Проблема в переходе от “мы собираем отчёты” к “мы просим получателей отклонять подделку нашего домена”.\n\n Спокойная версия такая: DMARC полезен, но не магия. Он помогает против конкретной вещи — exact-domain spoofing в видимом From. Он не остановит lookalike domains, display-name spoofing, compromised legitimate accounts или phishing с большой платформы, где authentication валидный. Но если ваш домен можно подделать напрямую, атакующим оставлен лишний короткий путь.\n\n DMARC работает поверх SPF и DKIM. SPF говорит, какие серверы могут отправлять за домен. DKIM подписывает письмо ключом домена. DMARC проверяет, совпадает ли authenticated identity с visible From domain, и сообщает receiving mail systems, что делать при fail.\n\n Три состояния policy простые. `p=none` — мониторить и отправлять reports. `p=quarantine` — просить отправить failing messages в spam или treat as suspicious. `p=reject` — просить отклонить failing messages. Получатели сохраняют discretion, но разница важна: `p=none` — это сигнализация, которая пишет логи, а не закрытая дверь.\n\n В snapshot CipherCue 30,362 domains, то есть 45.1%, вообще не имели DMARC record. Среди тех, кто запись имел, 15,709 были на `p=none`, 10,258 на `p=quarantine`, 10,963 на `p=reject`. CipherCue считает enforcement как `p=quarantine` или `p=reject`, поэтому 46,071 domain in sample оказался non-enforcing.\n\n Есть caveats. CipherCue прямо пишет, что это tracked entity set, а не статистически репрезентативная выборка всех компаний мира. В HN comments также справедливо спросили, сколько доменов в таких наборах parked, inactive, send-only или без нормального MX. Это не отменяет проблему, но держит формулировку честной: это большой vendor dataset с большой дырой в enforcement, не перепись всего интернета.\n\n Почему gap живёт годами? Потому что `p=reject` — не одна DNS-строка. Это inventory project.\n\n Нужно знать все легитимные источники почты: Microsoft 365 или Google Workspace, CRM, маркетинговые сервисы, billing, helpdesk, HR tools, ticketing, legacy servers, scanners, outsourced senders и забытые приложения. Каждый поток должен иметь SPF или DKIM alignment. Unknown senders надо чинить, переносить на subdomain или выключать. А отчёты должен кто-то читать.\n\n С отчётами отдельная боль. DMARC aggregate reports, теперь описанные в RFC 9990, machine-readable XML. Для automation это хорошо. Для маленькой организации, которая скопировала пример DNS record и не имеет parser, это поток файлов без понятного действия.\n\n Страх сломать почту реален. Если invoice system не проходит DKIM alignment, `p=reject` может потерять счета. Если support platform отправляет как company domain через кривой маршрут, enforcement создаст проблемы с клиентами. Никто не хочет быть человеком, который “улучшил безопасность” и сломал password resets.\n\n Microsoft в январе 2026 описывал phishing через complex routing и misconfigured spoof protections. Это хороший reminder: маршрутизация, connectors, forwarding и security gateways меняют то, как authentication выглядит у получателя. Correct configuration здесь важнее лозунгов.\n\n Практический путь скучный, но рабочий. Сначала domain inventory. Отделите primary sending domains, marketing subdomains, transactional subdomains, parked domains и домены, которые вообще не должны отправлять почту. Для no-send domains часто разумны SPF `v=spf1 -all` и DMARC `p=reject; sp=reject`.\n\n Для active domains `p=none` должен быть temporary monitoring phase. Укажите reporting address, который реально читается. Используйте DMARC reporting tool, commercial или open source. Raw XML не должен быть интерфейсом security control.\n\n Затем чините alignment. Для third-party services и forwarded mail DKIM обычно надёжнее SPF. Для каждого legitimate sender запишите owner, platform, domain/subdomain, authentication method и rollback contact. Если у sender нет владельца, это уже риск.\n\n Двигайтесь ступенчато: `p=none`, затем `p=quarantine`, затем `p=reject`. Следите за helpdesk tickets, bounce logs, deliverability dashboards и DMARC reports на каждом шаге. Тихая неделя ничего не доказывает, если failures никто не смотрит.\n\n DMARC не уберёт phishing. Но enforcement убирает дешёвый трюк, когда атакующий отправляет письмо как будто прямо с вашего домена, хотя authentication fails. Поэтому `p=none` плох как финальное состояние. Это полезный этап обучения, но плохая точка остановки.\n\n Правильная позиция — без паники и без самоуспокоения. Инвентаризировать senders, исправить broken flows, защитить no-send domains, перейти к quarantine/reject и продолжать читать reports. Защита начинается не с записи в DNS, а с доведения её до enforcement.","available_translations":[{"language":"ar","title":"DMARC p=none مراقبة وليس حماية","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ar"},{"language":"de","title":"DMARC p=none überwacht, schützt aber nicht","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=de","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=de","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=de"},{"language":"en","title":"DMARC p=none is monitoring, not protection","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=en","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=en","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=en"},{"language":"es","title":"DMARC p=none es monitoreo, no protección","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=es","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=es","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=es"},{"language":"fr","title":"DMARC p=none surveille, mais ne protège pas","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=fr"},{"language":"pl","title":"DMARC p=none monitoruje, ale nie chroni","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=pl"},{"language":"ru","title":"DMARC p=none — это мониторинг, а не защита","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru"},{"language":"zh","title":"DMARC p=none 是监控，不是保护","html_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru","html":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru","canonical":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru","markdown":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=ru","json":"https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}