Проверка на DMARC запис

Написано и проверено от редакционния екип на BroBroGo.Последна актуализация: 2026-07-31

Какво представлява инструментът „Проверка на DMARC запис“

Инструментът Проверка на DMARC запис е специализирано решение, което анализира предоставения от вас DMARC TXT запис, за да прегледа неговите политики, настройки за съгласуваност, адреси за отчети и всички остарели стойности за проценти. Той идентифицира невалидни тагове и предоставя подробни бележки относно синтаксиса и проблемите с правилата, като ви помага да разберете как е структуриран и как се интерпретира даден DMARC запис.

Този инструмент е предназначен за администратори на пощенски домейни, които разполагат с DMARC TXT съдържание и трябва да проверят неговата структура, избора на политики и синтаксиса на адресите за отчети преди публикуване или при отстраняване на неизправности. Той е изключително полезен и за всеки, който има нужда да прегледа DMARC политиките, съгласуваността, адресите за отчети, процентите и невалидните тагове.

Анализ на въведените данни и изходни резултати

Инструментът работи с конкретни входни данни и предоставя структуриран анализ на вашия запис.

Входни данни

DMARC TXT стойност: Текстов низ, който задължително трябва да започва с v=DMARC1. Инструментът приема и обединява оградени с кавички части от DNS TXT записи.
Ограничение: Дължината на записа трябва да бъде под 20 000 знака.

Изходни резултати

След обработка на въведената стойност, инструментът показва следните раздели:

DMARC анализ (Основният раздел с резултатите).
DMARC обобщение: Обобщение на ключовите настройки:
- p: Политиката за основния домейн.
- sp: Политиката за поддомейните.
- np: Политиката за несъществуващи поддомейни.
- DKIM / SPF: Информация за съгласуваността на SPF и DKIM.
- rua / ruf: Броят на посочените адреси за отчети.
- pct (RFC 7489): Процентната стойност за остарели DMARC внедрявания.
rua / ruf: Подробности за дестинациите на отчетите:
- rua: Адреси за агрегирани отчети.
- ruf: Адреси за отчети за грешки.
Анализирани термини: Таблица, изброяваща всеки открит таг в записа:
- Термин: Името на DMARC тага.
- Стойност или квалификатор: Стойността, свързана с тага.
- Вид: Статусът на тага, който може да бъде: RFC 9989, RFC 7489, Неизвестен или ✕ DMARC.
Бележки за синтаксиса и правилата: Списък с открити проблеми или наблюдения относно синтаксиса и правилата на записа.

Правила за валидация и обработка на тагове

За да бъде един DMARC запис валиден и правилно интерпретиран от получаващите системи, той трябва да отговаря на следните правила:

Начало на записа: Записът задължително трябва да започва с чувствителната към регистъра на буквите стойност v=DMARC1. Този таг трябва да бъде първият в записа.
Поведение при липсваща политика: Ако в записа липсва тагът p, политиката на домейна автоматично се превръща в none.
Политика p=none: Тази политика служи само за мониторинг на неуспешни опити и не изисква от получателите да поставят под карантина или да отхвърлят писма, които не преминават проверките.
Тестов режим (t=y): Наличието на t=y намалява строгата политика quarantine до none, а политиката reject до quarantine по време на тестване.
Изпращане на отчети: Ако липсва валиден rua адрес, агрегирани отчети не се изискват. Тагът fo се игнорира напълно, ако липсва валиден ruf адрес за отчети за грешки.
Остарели и исторически елементи:
- Стойностите на pct се считат за исторически и ограничават покритието на политиката само за получатели, които все още следват по-старите DMARC спецификации.
- Суфиксът !size в URI адресите за отчети е остарял и съвременните получаващи системи трябва да го игнорират.
- Инструментът идентифицира исторически тагове, които получаващите системи, следващи текущия стандарт, могат да игнорират.
Йерархия на поддомейните: При липса на по-специфичен таг, политиките за поддомейни преминават по веригата от np към sp и накрая към основната политика p.

Съобщения за грешки и предупреждения за синтаксиса

По време на анализа инструментът може да генерира следните съобщения за грешки и предупреждения, съответстващи на откритите проблеми в записа:

Въведете поддържан 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 (предупреждение, че политиката изисква отчети, но не указва карантина или отхвърляне на писма).
t=y: reject → quarantine; quarantine → none (при активен тестов режим).
rua=∅ (когато липсва валиден адрес за агрегирани отчети).
fo → ∅ (ruf=∅) (когато fo се игнорира поради липса на валиден ruf адрес).
pct=‹detail›% (RFC 7489) (указва, че стойността е историческа и ограничава покритието само за стари спецификации).
Оградените с кавички части от DNS TXT бяха обединени преди анализа.
!size → ∅ (RFC 9989) (указва, че суфиксът за размер е остарял и трябва да се игнорира).

Поверителност и сигурност на данните

Вашият DMARC запис остава изцяло в браузъра ви. Инструментът BroBroGo не качва и не запазва въведените от вас данни. Въведената информация не се записва в локалното хранилище на браузъра (browser storage) и не се изпращат никакви външни заявки, свързани с анализирания запис.

Често задавани въпроси (FAQ)

Бележки за синтаксиса и правилата: p / sp / np?

При липса на по-специфичен таг, политиките за поддомейни се прехвърлят по веригата от np към sp и накрая към основната политика p. Политиката p=none служи само за мониторинг и не изисква от получателите да поставят под карантина или да отхвърлят писма. Тестовият режим t=y намалява изискванията за сигурност по време на тестове, като променя quarantine на none и reject на quarantine.

RFC 9989: pct / rf / ri?

Не. Тази страница проверява само текста, който поставите. Тя не прави DNS заявки, не разгъва записи на доставчици, не тества IP адрес на подател и не потвърждава какво ще върне получаващият пощенски сървър. Съгласно стандартите, елементи като pct, rf и ri се класифицират като исторически (RFC 7489 → RFC 9989: historic), докато np, psd и t са активни (active).

Чистият резултат доказва ли, че DMARC настройката ми работи?

Не. Тази страница проверява единствено синтаксиса и структурата на текста, който поставите. Инструментът не извършва DNS заявки в реално време, не разгъва записи на доставчици, не тества IP адреса на изпращача и не може да потвърди какви действия ще предприеме получаващият пощенски сървър при обработка на реални съобщения.