Публікація наосліп: більшість DMARC-записів не запитують жодних звітів

Опубліковано 2026-07-03 · оновлено 2026-07-03

Дані станом на 2026-06-29 · методологія v7. Дані перепису по кожному домену, що публікує DMARC-запис, який піддається розбору, з дедуплікацією на рівні домену. Наявність rua= вимірюється по всіх записах, тож її точне перекриття з будь-якою окремою політикою вивести неможливо — там, де ця стаття робить твердження про таке перекриття, вона наводить межі, а не точні перехресні таблиці. Усі показники є агрегованими — ми ніколи не публікуємо оцінку окремого бізнесу.

Більшість DMARC-записів не спостерігають

Із 65 мільйонів доменів, що публікують DMARC-запис, лише 23 мільйонів — 35.7% — містять тег rua=, який запитує агреговані звіти. Решта 64.3% публікує наосліп: політика присутня в записі, але ніхто не попросив повідомляти, що відбувається під нею. Це 42 мільйонів доменів із DMARC-записом, який нічого не може їм показати.

DMARC-запис без звітності — це дверний дзвінок, коли вдома нікого немає. Поштові одержувачі сумлінно перевіряють кожне повідомлення за ним — а їхні висновки, перелік усіх, хто надсилає пошту від імені вашого домену, йдуть у нікуди. Механізм працює; просто власник не слухає.

Що насправді робить `rua=`

DMARC складається з двох половин. Половина політики (p=none, quarantine або reject) вказує одержувачам, що робити з поштою, яка не проходить автентифікацію. Половина звітності — тег rua=, адреса поштової скриньки — просить одержувачів надсилати вам щоденні агреговані звіти: які сервери надсилали пошту від імені вашого домену, скільки пошти й чи пройшла вона SPF і DKIM.

Ця друга половина — це весь цикл зворотного зв’язку. Звіти — це те, як ви виявляєте платформу розсилок, яку ніхто не задокументував, інструмент для виставлення рахунків, який підключив маркетинг, тіньового відправника в іншому регіоні — перш ніж ви застосуєте примусову політику і зламаєте їх. Без rua= жодна з цих відомостей до вас так і не дійде. Додати його коштує одного редагування DNS: допишіть rua=mailto:[email protected] (або адресу служби моніторингу) до наявного запису.

Розрив між етапами 2 і 3: опубліковано й наосліп

У шести етапах зрілості DMARC етап 3 — Спостереження — починається, коли DMARC опубліковано і надходять агреговані звіти. Запис без rua= цьому не відповідає. Він перебуває в розриві між етапами 2 і 3 — опубліковано й наосліп — місці, яке модель навмисно залишає без власного номера.

Це важливо, бо кожен наступний етап залежить від звітів. Ви не можете ідентифікувати своїх відправників (етап 4) зі звітів, які ніколи не отримуєте; ви не можете безпечно застосувати примусову політику (етап 5), не знаючи своїх відправників. Сліпий запис — це не ранній крок на шляху, це аварійний з’їзд поруч із ним. І перепис свідчить, що більшість власників записів припаркувалися саме там або поруч: 57.5% усіх DMARC-записів так і не доходять до примусового виконання.

Гірше, ніж марно, бо це відчувається як прогрес

Відсутній DMARC-запис принаймні виглядає тим, чим він є: прогалиною. Сліпий запис виглядає як галочка. Хтось пройшов чек-лист відповідності, чи посібник із доставлюваності, чи однорядкове виправлення від постачальника — опублікував v=DMARC1; p=none — і сканер загорівся зеленим. Тепер організація відчуває, що просунулася далі, ніж організація без запису взагалі, тоді як функціонально перебуває в тому самому місці: жодної видимості, жодного примусового виконання, жодного шляху до того чи іншого.

Наслідок тихий і накопичувальний. Сліпі записи не збоять гучно; вони просто ніколи не генерують доказів, які виправдали б наступний крок. Через роки запис усе ще каже p=none, ніхто не може сказати, які відправники легітимні, а застосувати примусове виконання здається ризикованішим, ніж будь-коли — саме тому, що жодних звітів так і не було зібрано.

Що перепис може й чого не може сказати

Оскільки наявність rua= вимірюється по всіх 65 мільйонах записів — а не в перехресній таблиці за політикою — точну кількість записів p=none, які також сліпі, з цих граничних значень вивести неможливо. Межі все одно разючі. 37 мільйонів записів (57.4% власників записів) перебувають на p=none; лише 23 мільйонів записів у всьому переписі запитують звіти. Тож щонайбільше 23 мільйонів із тих записів p=none можуть отримувати звіти — а щонайменше 14 мільйонів із них точно ні, навіть якби кожна адреса звітності в переписі належала домену p=none. Хай як насправді складається перекриття, мільйони доменів сидять у «режимі моніторингу» з від’єднаним монітором.

Виправлення в одне редагування

Якщо ваш DMARC-запис не має тега rua=, виправлення — це одна зміна DNS, і вона безпечна на будь-якому рівні політики:

Оберіть місце призначення для звітів — поштову скриньку, яку ви справді оброблятимете, або безкоштовну/платну службу моніторингу DMARC, яка перетворює XML на щось читабельне.
Допишіть його до запису: v=DMARC1; p=none; rua=mailto:[email protected]. Якщо місце призначення — інший домен, той домен має авторизувати отримання ваших звітів (невеликий додатковий DNS-запис на його боці).
Зачекайте кілька днів, потім читайте. Звіти надходять щодня від великих одержувачів. Те, що вони показують — кожне джерело, яке надсилає пошту від імені вашого домену — це карта для решти шляху.

Тоді запис перестає бути меблями й починає бути інструментом. (Виправити DMARC →.)

Часті запитання

Що таке DMARC-звіт rua? Агрегований XML-звіт, який поштові одержувачі-учасники надсилають (зазвичай щодня) на адресу в тезі rua= вашого запису, підсумовуючи, які джерела надсилали пошту від імені вашого домену й чи пройшла вона узгодження SPF і DKIM. Він не містить вмісту повідомлень — лише інфраструктуру відправника та підрахунки проходжень/збоїв.

Чи DMARC без rua марний? Не марний — примусова політика все одно блокує підробку без нього. Але на p=none запис без rua= нічого не блокує й нічого вам не показує — його єдине завдання, що лишається, — це поставити галочку в графі мінімальної вимоги провайдерів поштових скриньок. І навіть домени з примусовим виконанням, але без звітності, втрачають виявлення дрейфу, яке тримає примусове виконання безпечним у міру появи нових відправників. p=none — це не захист у будь-якому разі — без звітів це навіть не підготовка.

Чи може rua= вказувати на будь-яку поштову скриньку? Так, зокрема на скриньку в іншому домені — більшість служб моніторингу працюють саме так. Домен-одержувач публікує невеликий верифікаційний запис, що авторизує ваші звіти. Важливо, щоб щось справді обробляло XML; поштова скринька, яку ніхто не читає, — це сліпота з додатковими кроками.

Чи розкривають агреговані звіти приватні дані? Ні. Агреговані звіти rua містять статистику джерел відправлення й автентифікації, а не тіла повідомлень чи списки одержувачів. (Окремі звіти про збої ruf= можуть містити фрагменти повідомлень, тому багато одержувачів більше їх не надсилають — саме rua має значення.)

Перевірте, чи спостерігає ваш запис

DMARC-запис, який не запитує жодних звітів, — це одне з найлегших для виправлення виявлень на всьому шляху: одне редагування DNS перетворює сліпоту на Спостереження. Ви можете перевірити приватно й безкоштовно та побачити, які з 34 перевірок ви проходите і як виправити ті, які ні.

Перевірити ваш домен → · Шість етапів зрілості DMARC → · Стовп DMARC → · Лише агреговані дані. Дані зберігаються й обробляються в ЄС.