Як прочитати DMARC-політику компанії за десять секунд (і що вона вам не розповідає)

Один запит DNS розповідає вам, що компанія просила всі поштові сервери світу робити з підробленою поштою, відправленою від її імені. Запис є відкритим, а команда займає один рядок: dig +short TXT _dmarc.example.com. На виході буде коротка строка налаштувань, і всередині неї одна інструкція — p=none, p=quarantine чи p=reject — яка виражає перевагу власника домену, коли повідомлення, що використовує цей домен, не проходить перевірку автентифікації.

Поточна специфікація RFC 9989, опублікована в травні 2026 року як документ IETF Standards Track, замінила давнішу RFC 7489. Вона визначає три значення майже лаконічно:

• p=none — «Власник домену не висловлює жодної переваги.»
• p=quarantine — «Власник домену вважає таку пошту підозрілою. Можливо, пошта є легітимною, однак помилка перевірки створює значну тривогу.»
• p=reject — «Власник домену вважає, що будь-яка така помилка є чітким показником того, що використання назви домену є неправомірним.»

Прочитайте ці слова ще раз, тому що вони слабші, ніж більшість пояснень DMARC це допускають. Політика — це перевага, опублікована відправником для того, щоб отримувачі розглянули її. Це не інструкція, яку отримувач зобов'язаний виконати. RFC 9989 говорить про це одним реченням: «Остаточна обробка будь-якого повідомлення завжди є питанням локальної політики і залишається на розсуд отримувача пошти.» У тому самому розділі наведені обидві сторони наслідків — отримувачі «МОЖУТЬ вибрати відхилення або карантин повідомлення навіть якщо воно пройшло перевірку валідації DMARC», і вони «НЕ ПОВИННІ відхиляти повідомлення виключно через опубліковану політику 'reject'», саме тому, щоб легітимна пошта, відправлена способами, які DMARC не може описати, та розсилки не були знищені в цьому процесі.

Отже, що насправді розповідає p=none? Менше, ніж його зазвичай звинувачують. За термінами специфікації це Режим моніторингу: власник домену збирає сукупні звіти і «не висловлює переваги щодо обробки повідомлень, які не пройшли перевірку DMARC», тоді як отримувач, який розгортає DMARC, «все ще може» перевіряти використання домену. Що він не робить — це не вимикає нічого на стороні отримувача. Спам-фільтрування вашого постачальника, оцінка репутації, перевірка URL-адрес та аналіз вкладень — це окремі механізми, які працюють незалежно від того, що опублікував відправник. Підроблене повідомлення, яке надходить на домен p=none, не потрапляє до вашої поштової скринки через запис; воно просто передається отримувачу без висловленої переваги, і отримувач вирішує.

Друга половина неправильного розуміння йде в іншому напрямку. DMARC не читає небезпечну частину фішингового повідомлення. Його власна специфікація перераховує те, що навмисно виключено з розгляду, і «аналіз контенту» знаходиться на цьому списку, цими самими словами. Вона також стверджує, що DMARC «не розглядає використання візуально подібних назв доменів або зловживання RFC5322.From людиночитаємої назви відправника» — два трюки, які несуть більшість спойлированої поштової кореспонденції. А щодо значення позитивного результату: «позитивний результат DMARC сам по собі не гарантує, що доставка до поштової скринки отримувача буде безпечною або бажаною.» Належно автентифіковане повідомлення від одноразового домену проходить DMARC без проблем. DMARC відповідає на те, хто був авторизований на використання домену в заголовку From:. Не більше того.

Саме тут правила масових розсильників 2024 року регулярно неправильно звітуються, включаючи першу версію цієї статті. Вказівки Google для відправників, які розсилають 5 000 або більше повідомлень на день на облікові записи Gmail, вимагають «налаштування автентифікації електронної пошти DMARC для вашого домену відправника», а потім кажуть в тому самому дыханні: «Ваша політика забезпечення DMARC може бути встановлена на none.» Yahoo's Sender Hub, який необхідно читати окремо, а не припускати, що він копіює Google, визначає вимогу як «Опублікування дійсної політики DMARC з принаймні p=none — DMARC має пройти перевірку», і не публікує жодного числового порога обсягу. Обидва набори вимог набули чинності з лютого 2024 року. Жоден із них не змушує когось відходити від p=none. Те, що вони насправді вимагають — це автентифікація, яка узгоджується: Google вимагає, щоб «домен у заголовку From: відправника був узгоджений з доменом SPF або доменом DKIM», а Yahoo говорить, що пом'якшене вирівнювання прийнятне. Вирівнювання, а не суворість, є брамою.

Це залишає справжню причину того, чому домени знаходяться в режимі моніторингу, і вона є операційною, а не боязкою. Перехід до quarantine або reject означає спочатку пошук усіх сервісів, які розсилають пошту від вашого імені — заробітна плата, квитків, маркетинг, стіл підтримки, про який ніхто не задокументував — і автентифікацію кожного з них, щоб воно узгоджувалось. Сама специфікація визнає небезпеки, які роблять це повільним: сторонні відправники не представлені і не виключені DMARC, переадресація та розсилки можуть порушити вирівнювання не з вини відправника, і специфікація вказує отримувачам на RFC 7960 для цих режимів відмови. Організація, яка публікує p=none і читає її звіти, робить роботу в порядку, описаному специфікацією. Та, що публікує p=none і ігнорує звіти, не робить. З зовні запис сам не може вам сказати, який із цих двох ви розглядаєте.

Вам не потрібен термінал для пошуку. Безплатні засоби пошуку — dmarcian's domain checker, MXToolbox's DMARC check — отримують запис і виводять політику для вас. Зробіть це для вашого банку, вашого постачальника заробітної плати, авіакомпанії, якою ви літаєте. Просто прочитайте відповідь за її сутністю: виявлення наміру власником домену, один з багатьох факторів у рішенні, яке ваш постачальник пошти приймає самостійно, щодо одного конкретного типу підробки. Це справді корисна річ, яку можна прочитати за десять секунд. Це не рішення про те, чи буде наступне повідомлення, що стверджує, що воно від цієї марки, безпечним.

Виправлення, 20 жовтня 2026 року. Попередня версія цієї статті описувала p=none як доставку підробок до поштової скринки і p=reject як єдине налаштування, яке блокує спойлировану повідомлення, сказала, що правила масових розсильників Google і Yahoo 2024 року змушували відправників відходити від p=none, і цитувала цифру приблизно один із трьох доменів при забезпеченні. Описи політики були виправлені відповідно до RFC 9989; Google і Yahoo насправді приймають p=none, процитовані вище з їхної власної документації; і цифра забезпечення була видалена, тому що основний звіт не публікує свою вибірку або знаменник. Статя тепер також зазначає, що DMARC не розглядає.