Перевірка DMARC-запису

Призначення інструменту «Перевірка DMARC-запису»

Інструмент «Перевірка DMARC-запису» призначений для детального аналізу текстових DMARC-записів, які надає користувач. Він розбирає структуру DMARC TXT, аналізує встановлені політики, параметри узгодження ідентифікаторів, адреси для надсилання звітів, а також застарілі відсоткові значення. Окрім цього, інструмент виявляє недійсні теги та надає зауваження щодо синтаксису й політики, допомагаючи зрозуміти структуру та особливості інтерпретації конкретного запису.

Цей інструмент буде корисним для адміністраторів поштових доменів, які мають готовий вміст DMARC TXT і прагнуть перевірити його структуру, вибір політик та синтаксис адрес звітів перед публікацією або під час усунення несправностей. Також він стане у пригоді кожному, кому необхідно детально переглянути політики DMARC, узгодження, адреси звітів, відсотки та виявити недійсні теги.

Вхідні дані та обмеження

Для початку аналізу користувач має надати такі дані:

• Значення DMARC TXT: рядок, який обов'язково має починатися з чутливого до регістру значення v=DMARC1. Інструмент підтримує роботу з частинами DNS TXT у лапках — такі фрагменти автоматично приймаються та об'єднуються перед початком аналізу.
• Обмеження за розміром: довжина введеного рядка має бути меншою за 20 000 символів.

Результати аналізу та структура виводу

Після обробки введеного запису інструмент формує кілька інформаційних блоків:

• Аналіз DMARC: головний розділ, у якому відображаються загальні результати перевірки.
• Підсумок DMARC: стислий огляд ключових параметрів DMARC:
  • Політика домену (p): політика, встановлена для основного домену.
  • Політика субдоменів (sp): політика для субдоменів.
  • Неіснуючі субдомени (np): політика, що застосовується до неіснуючих субдоменів.
  • Узгодження ідентифікаторів: інформація про налаштування узгодження для протоколів SPF та DKIM.
  • Адреси звітів: кількість визначених адрес для надсилання звітів.
  • Застаріле відсоткове значення (pct): відсоткове значення, що використовується в застарілих реалізаціях DMARC.
• Адреси призначення звітів: детальна інформація про отримувачів звітів:
  • Сукупні звіти (rua): адреси для надсилання сукупних звітів.
  • Звіти про збої (ruf): адреси для надсилання звітів про збої.
• Розібрані умови: таблиця з усіма виявленими у записі тегами:
  • Умова (Tag): назва тегу DMARC.
  • Значення або кваліфікатор: значення, закріплене за цим тегом.
  • Тип: поточний статус тегу (Active, Historic, Unknown або Invalid).
• Примітки щодо синтаксису й політики: список виявлених проблем, помилок або зауважень щодо синтаксису й логіки політики аналізованого запису.

Правила обробки тегів та логіка успадкування

Під час аналізу DMARC-запису інструмент керується такими правилами та враховує наступні особливості стандартів:

• Обов'язковий початок: запис має починатися з чутливого до регістру значення v=DMARC1, і цей тег обов'язково повинен йти першим.
• Успадкування політик субдоменів: якщо у записі відсутній конкретніший тег для субдоменів, діє правило послідовного відкату (fallback) від np до sp, а далі — до загальної політики домену p.
• Відсутність політики: якщо тег p не вказано взагалі, політика домену за замовчуванням трактується як none.
• Особливості політики none: політика p=none призначена виключно для моніторингу помилок і не містить вимоги до приймаючих серверів поміщати підозрілі листи в карантин чи відхиляти їх.
• Режим тестування (t=y): використання тегу t=y під час тестування знижує рівень суворості політик: quarantine послаблюється до none, а reject — до quarantine.
• Запити на звіти: якщо у записі немає жодної валідної адреси rua, сукупні звіти не запитуються. Тег конфігурації звітів про помилки fo повністю ігнорується, якщо не вказано коректну адресу ruf.
• Застарілі та історичні елементи:
  • Значення pct вважаються застарілими (historic) і обмежують дію політики лише для тих одержувачів, які досі використовують старі специфікації DMARC.
  • Суфікс !size в URI звітів є застарілим, і сучасні поштові системи мають його ігнорувати.
  • Інструмент маркує історичні теги, які приймаючі системи, що працюють за актуальними стандартами, можуть просто ігнорувати.

Повідомлення про помилки та зауваження

У процесі перевірки інструмент може виводити такі повідомлення про помилки та зауваження щодо синтаксису й структури:

• «Введіть підтримуваний DMARC-запис.» (якщо формат не підтримується).
• «Спочатку вставте DMARC-запис.» (якщо поле введення порожнє).
• «Цей запис незвично великий. Обмежте його 20 000 символами.».
• «Запис має починатися з v=DMARC1.» (чутливе до регістру правило).
• «Умова ‹position›: v=DMARC1 має бути першою умовою.».
• «×2: ‹tag› (‹position›)» (якщо тег дублюється).
• «name=value ✕ (‹position›)» (якщо тег оформлено неправильно і він не відповідає структурі пар ім'я=значення, розділених крапкою з комою).
• «‹tag›=∅ (‹position›)» (якщо тегу не присвоєно значення).
• «‹tag›=‹detail› ✕ (‹position›)» (у разі недійсного значення тегу).
• «URI ✕: ‹tag› (‹position›)» (якщо вказано некоректний URI для звітів).
• «Невідомо: ‹tag› (‹position›)» (якщо тег не зареєстрований і буде ігноруватися отримувачами).
• «RFC 7489 → RFC 9989: ‹tag› (‹position›)» (якщо тег є застарілим у поточному стандарті DMARC).
• «p → none» (якщо тег p відсутній, через що політика домену повертається до значення за замовчуванням none).
• «p=none» (зауваження про те, що політика p=none лише запитує звіти, але не вимагає від отримувачів карантину або відхилення листів).
• «t=y: reject → quarantine; quarantine → none» (попередження про зниження суворості політик під час тестування).
• «rua=∅» (якщо немає дійсної адреси rua, через що сукупні звіти не запитуються).
• «fo → ∅ (ruf=∅)» (якщо тег fo ігнорується через відсутність валідної адреси ruf).
• «pct=‹detail›% (RFC 7489)» (зауваження, що значення pct є історичним і обмежує покриття політики лише для отримувачів, які використовують старі специфікації).
• «Частини DNS TXT у лапках було об’єднано перед аналізом.».
• «!size → ∅ (RFC 9989)» (попередження про те, що суфікс !size в URI звітів застарів і має ігноруватися сучасними отримувачами).

Конфіденційність та обробка даних

Робота з інструментом повністю безпечна для ваших конфіденційних даних:

• Введений DMARC-запис залишається виключно у вашому браузері.
• Інструмент не завантажує і не зберігає ваш запис на серверах.
• Введені дані не записуються у локальне сховище браузера.
• Жодні зовнішні запити, пов'язані з аналізованим записом, не надсилаються в мережу.

Часті запитання (FAQ)

Примітки щодо синтаксису й політики: p / sp / np?

Якщо у записі відсутній тег політики p, застосовується автоматичний відкат до значення none. Політика p=none дозволяє лише моніторити помилки й отримувати звіти, але не дає вказівок поштовим серверам відхиляти листи чи відправляти їх у спам. Тег t=y під час тестування знижує дію політики reject до quarantine, а quarantine — до none. Для субдоменів діє логіка послідовного успадкування: за відсутності специфічних налаштувань правила застосовуються за схемою відкату від np до sp, а далі — до загальної політики p.

RFC 9989: pct / rf / ri?

Ні, цей інструмент не підтримує перевірку зовнішніх DNS-записів чи активну взаємодію з серверами. Він аналізує виключно той текст, який ви самостійно вставили у поле введення. Інструмент не робить запитів до DNS, не розгортає записи провайдерів, не здійснює перевірку IP-адрес відправників та не підтверджує відповіді поштових серверів одержувачів. Відповідно до сучасного стандарту RFC 9989, такі параметри як pct, rf та ri перейшли до статусу застарілих (historic), тоді як теги np, psd та t є активними (active).

Чи доводить результат без помилок, що моє налаштування DMARC працює?

Ні. Ця сторінка виконує лише статичний аналіз вставленого вами тексту. Вона не робить запитів до DNS, не розгортає записи провайдера, не тестує IP-адресу відправника й не підтверджує відповідь поштового сервера одержувача. Успішний аналіз без помилок свідчить лише про правильний синтаксис та структуру наданого тексту, але не гарантує його коректну роботу в реальній мережевій інфраструктурі.