„DMARC политиката не е активирана”: Какво имат предвид проверяващите и честната 5-минутна първа стъпка (2026)

Публикувано 2026-07-08

Данни към 2026-06-29 · методология v7. Агрегирани census данни от 261 милиона оценени домейна. Вижте как оценяваме.

„DMARC политиката не е активирана” означава едно от две различни неща: домейнът ви няма никакъв DMARC запис, или има такъв, зададен на p=none. Само 10.59% от домейните — 27,640,987 от 261,086,232 — прилагат DMARC политика, според census-а на Defaults.Exposed. Публикуването на запис за мониторинг отнема пет минути; прилагането е проект.

Това ръководство декодира предупреждението, дава ви точния TXT запис за публикуване и точно къде да го поставите, разглежда синтактичните грешки, правещи първите опити неуспешни, и поставя честни очаквания за това как изглежда първата ви седмица DMARC доклади. Умишлено не е ръководство „поправи DMARC за 5 минути” — петте минути ви дават видимост, а не защита.

Какво всъщност означава „DMARC политиката не е активирана”?

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

Какво показва проверяващият	Какво всъщност означава	Засегнати домейни (от 261,086,232 оценени)
„Не е намерен DMARC запис”	Нищо не е публикувано на `_dmarc.yourdomain`. Получателите не прилагат никаква политика и не ви изпращат никакви доклади. Вие сте невидими за собствените си имейл проблеми.	196,105,162 (75.11%)
„DMARC политиката не е активирана” / „политиката е none”	Записът съществува, но казва `p=none`: докладването е включено, защитата е изключена. Получателите доставят спуфваната поща точно като преди.	37,312,637 (14.29%)
„Политика: quarantine” или „reject”	Приложена политика. Получателите действат при неуспехи.	27,640,987 (10.59%)

Данни към 2026-06-29.

Първият ред е там, където живее по-голямата parte от интернет: 75.11% от оценените домейни не публикуват никакъв DMARC запис, а още 14.29% стоят на p=none. Обратното на последния ред е числото, имащо значение: 89.41% от домейните нямат приложена DMARC политика — от 261,086,232 оценени домейна в census-а. Ако проверяващият показва предупреждението, сте в огромното мнозинство. Това не е успокоение; това е причината спуфингът да остава евтин.

Едно пояснение, спестяващо объркване по-късно: DMARC е слоят на политиката върху SPF и DKIM, проверяван спрямо хедъра From, виждан действително от получателя. „Не е активирана” означава, че все още не сте казали на получателите какво да правят. Ако трите стойности на политиката са нови за вас, разбираемото обяснение е какво е DMARC: none, quarantine, reject.

Какво можете честно да поправите за пет минути?

Публикуване на запис. Това е цялото честно твърдение.

v=DMARC1; p=none; rua=mailto:[email protected]

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

Какво не прави: p=none не защитава нищо. Спуфваната поща се доставя точно както вчера, и проверяващ, правещ ново сканиране утре, може пак да каже „политиката не е активирана” — правилно, защото зеленото е запазено за quarantine или reject. Написали сме защо в p=none не е защита; поетапният път към политика, действително блокираща спуфинга, е от p=none до p=reject. Петминутната стъпка по-долу е как започвате; това ръководство е как завършвате.

Как да публикувате първия DMARC запис?

Стартирайте безплатното сканиране преди да докосвате DNS. Казва ви кое от двете открития действително имате — без запис срещу p=none — и дали SPF и DKIM са налице отдолу, което решава колко бързо можете да преминете към прилагане по-късно.
Изберете адрес за получаване на доклади. Специална пощенска кутия като dmarc-reports@yourdomain е добра за начало. Ако вместо това използвате услуга за анализ на доклади, вижте FAQ по-долу — адресите на трети страни имат мълчалива уловка.
Добавете TXT запис на хоста _dmarc. В повечето DNS контролни панели (вижте ръководството за настройка на DMARC в IONOS за работен пример) въвеждате _dmarc в полето за хост/им — панелът автоматично добавя вашия домейн, получавайки _dmarc.yourdomain.com. Стойност: v=DMARC1; p=none; rua=mailto:[email protected]
Верифицирайте разрешаването. dig TXT _dmarc.yourdomain.com (или всеки онлайн проверяващ) трябва да върне точно един запис, започващ с v=DMARC1. Повечето DNS промени са видими в рамките на минути; ниска TTL помага.
Направете ново сканиране. Докладът ще показва DMARC налице в режим на мониторинг — честно отражение на позицията ви: докладването е включено, прилагането е предстоящо.

Един запис покрива и поддомейните: получателите, ненамиращи запис на mail.yourdomain.com, падат назад към политиката на организационния домейн, така че не ви е нужен запис за всеки поддомейн за стартиране на мониторинга.

Какви са най-честите грешки при добавяне на записа?

Почти всеки неуспешен първи опит е едно от тях — и те имат значение, защото непарсируем запис се третира като никакъв запис. Census-ът брои 48,648 публикувани DMARC записи, непреминаващи парсирането; правописните грешки, действително публикувани от хората, са каталогизирани в census-а за DMARC правописни грешки.

Грешен хост. Записът трябва да живее на _dmarc.yourdomain.com, а не на apex-а. На основния домейн не прави нищо и проверяващите продължават да докладват „не е намерен DMARC запис”.
Двойно добавяне на домейна. Въвеждането на _dmarc.yourdomain.com в панел, автоматично добавящ домейна, дава _dmarc.yourdomain.com.yourdomain.com. Въведете само _dmarc.
Запетаи вместо точки и запетаи. Таговете се разделят с ;. Непарсируем запис се третира като никакъв запис.
Липсващ или разместен v=DMARC1. Трябва да е първият таг, изписан точно; записите, започващи с p=, не преминават парсирането.
Липсващо mailto: от rua. rua=dmarc@yourdomain е невалидно; трябва да е rua=mailto:[email protected].
Два DMARC записа. Получателите, намиращи повече от един v=DMARC1 запис, игнорират всичките — същото семейство неуспехи като при множество SPF записи.
Типографски кавички от копиране-поставяне. Извити кавички или неразривни интервали, промъкнати от документ, чупят парсирането. Препишете записа ако проверяващ казва, че е неправилен, но изглежда правилен.

Как ще изглеждат rua докладите в първата седмица?

Задайте очакванията сега, за да не заключите, че не работи:

Пристигат приблизително ежедневно, за всеки получател. Google обикновено изпраща един агрегиран доклад на 24 часа; Microsoft, Yahoo и останалите на собствените им цикли. За малък домейн, първата седмица обикновено означава шепа имейли, предимно от [email protected].
Те са компресирани XML прикачени файлове, а не таблo. Сурови, почти нечетими; безплатен парсер ги превръща в таблица с изпращачи.
Обемът следва обема на пощата ви. Ако изпращате малко поща или предимно до доставчици, неизпращащи доклади, очаквайте оскъдни данни. Две тихи седмици е нормално за домейн с малък обем — верифицирайте записа с dig вместо да приемате, че е неуспешен.
Очаквайте изненади. Повечето домейни открива изпращачи, забравени — CRM-ът, инструментът за фактуриране, формата за контакт. Всеки се нуждае от aligned SPF или DKIM преди да можете да прилагате. Ако докладите показват DMARC неуспех, докато SPF и DKIM индивидуално минават, това е проблем с alignment — вижте DMARC не минава, но SPF и DKIM минават.

И попитайте за докладите изобщо: 64.3% от домейните с DMARC запис не публикуват никакъв адрес rua=, така че не получават никакви доклади от него — census-ат на това е в DMARC публикуващи сляпо. Всичко, което научавате тук, подхранва внедряването на прилагането — мониторингът е седмица едно от този проект, а не дестинация. Паркирането на p=none за неопределено е най-честият начин домейни да попаднат в 89.41%.

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

Публикуването на p=none ще навреди ли на доставяемостта на имейла ми? Не. p=none не променя нищо в начина, по който получателите третират пощата ви — само заявява доклади. Може да помогне: изискванията на Google и Yahoo за масови изпращачи изискват поне p=none DMARC запис от изпращачи с голям обем, така че публикуването е минимум за съответствие, а не риск.

Публикувах записа — защо проверяващият все пак казва „политиката не е активирана”? Защото казва истината: политиката ви е none, а проверяващите запазват pass за quarantine или reject. Присъединихте се към домейните, мониториращи, но неприлагащи — към 2026-06-29, само 10.59% от 261,086,232 оценени домейна прилагат. Предупреждението изчезва когато завършите внедряването към прилагане.

Нужни ли са ми SPF и DKIM настроени преди да добавя DMARC? Нужен ви е поне един от тях, aligned, за пощата ви да мине DMARC — но не се нуждаете те да са перфектни преди публикуване на p=none. Мониторингът е точно начинът, по който намирате какво е счупено: 70,368,600 от 261,086,232 оценени домейна (към 2026-06-29) имат мек SPF и никакво DMARC прилагане, а докладите са начинът да разберат какво ги спира.

Мога ли да изпращам доклади до анализатор на трети страни вместо до собствената пощенска кутия? Да — но rua адресът на различен домейн изисква доставчикът да публикува запис за оторизация (yourdomain._report._dmarc.vendor.com), иначе получателите мълчаливо задържат докладите. Реномираните услуги правят това автоматично; ако докладите никога не пристигат, проверете това първо.

Изпратете доклада на собственика

Ако поправяте това за клиент или работодател, не позволявайте работата да е невидима. Пуснете отново безплатното сканиране след като записът е активен и препратете оценения доклад: показва DMARC преминаващ от отсъстващ до наблюдаван, с времево клеймо и на разбираем език — и показва какво предстои по пътя към прилагане. Собствениците все повече се нуждаят именно от това доказателство за подновявания на киберзастраховки и въпросници за сигурност на доставчици, а едностраничен оценен доклад отговаря на тези въпроси по-добре от скрийншот на DNS панел.

Проверете домейна безплатно

Вижте кое от двете открития имате — без запис или p=none — и какво е отдолу, частно и само за собственика.

Проверете домейна → · Поправете DMARC → · От p=none до p=reject → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.