Defaults.Exposed

Defaults.ExposedПоправкиGuides

DMARC p=none до p=reject без загуба на легитимен имейл: Поетапното внедряване (2026)

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

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

Преминете DMARC от p=none до p=reject в четири етапа: следете rua доклади 2–4 седмици, поправете всеки легитимен изпращач, постепенно повишете p=quarantine с pct, след това reject — никога не прескачайте директно към reject. 70,368,600 от 261,086,232 оценени домейна са задръстили при мек SPF без DMARC прилагане, според census-а на Defaults.Exposed.

Това е оперативният наръчник: таблица с етапи и критерии за излизане, записът за всеки етап, тънкостта на RFC 7489 pct, която променя какво означава „50%” при reject, и тагът sp= за поддомейни. Ако решавате дали да прилагате, прочетете първо 6-те етапа на зрялост на DMARC — това е рамката; а ако нивата на политики са нови за вас, какво действително означава p=none, p=quarantine и p=reject е въвеждащото ръководство. Тази страница е изпълнението.

Защо не може да прескочите директно до p=reject?

Защото p=reject казва на всеки спазващ получател да върне поща, неминаваща DMARC — и докато не сте гледали докладите, не знаете какво не минава. Почти всеки домейн, включващ мониторинга, открива легитимни изпращачи, за които е забравил: CRM-ът, инструментът за фактуриране, формата за контакт. Прескочете до reject на ден едно и тази поща не отива в спам; изчезва на ниво SMTP. Загубата на серия фактури учи организацията да се страхува от DMARC, и записът се връща обратно към p=none за постоянно — от 261,086,232 оценени домейна, 37,312,637 са спрели точно там, а само 10.59% (27,640,987) стигат до приложена политика.

Другата причина е alignment-ът. DMARC минава само когато SPF или DKIM минава и е aligned с видимия From домейн — SPF спрямо домейна Return-Path (RFC5321.MailFrom), DKIM спрямо d= на подписа. Изпращачите трети страни обикновено минават SPF при своя домейн, не вашия, ето защо етапът за поправяне на всеки изпращач е предимно за активиране на персонализирания DKIM за всеки доставчик — разгледано в DMARC не минава, но SPF и DKIM минават.

Какви са четирите етапа на внедряване?

ЕтапЗапис за политикаpctКакво се случва с неминаваща пощаКритерии за излизане
1. Мониторингp=none; rua=mailto:…Доставя се нормално; получавате агрегирани доклади2–4 седмици доклади; всеки изпращач в тях идентифициран като легитимен или не
2. Поправяне на изпращачиp=none (непроменено)Все още се доставя нормалноВсеки легитимен изпращач минава DMARC aligned (персонализиран DKIM за всеки доставчик); останалите неуспехи са само непознат/спуфван трафик
3. Постепенно quarantinep=quarantine10 → 25 → 50 → 100Пробовата дял отива в папки за спам; дялът извън пробата се третира като p=none (доставя се)1–2 седмици на pct=100 без нито едно легитимно писмо в quarantine
4. Rejectp=reject100Отхвърляне на ниво SMTP; изпращачът получава bounce, получателят не вижда нищоПостоянно — оставете rua включено завинаги, за да улавяте нови изпращачи

Данни към 2026-06-29; поведение на политиката по RFC 7489.

Етап 3 е там, където домейните задръстват или паникьосват. Поставянето в папка за спам е обратимо — потребителите намират пощата, разхлабвате pct, поправяте изпращача. Отхвърлянето не е обратимо, ето защо quarantine на pct=100, работещо чисто, е входният билет за етап 4.

Как да проведете внедряването, стъпка по стъпка?

  1. Стартирайте безплатното сканиране на defaults.exposed преди да докосвате DNS. Потвърждава текущата политика и дали SPF и DKIM са налице отдолу — двата крака, на които стои прилагането.
  2. Включете мониторинга, ако не сте. Публикуването на p=none с rua= е петминутната стъпка в „DMARC политиката не е активирана”. Събирайте 2–4 седмици доклади — достатъчно, за да уловите месечни изпращачи като серии фактури.
  3. Инвентаризирайте всеки изпращач в докладите. Сортирайте изпращачите на ваши, на доставчиците ви и непознати. Суровите доклади пристигат като XML — инструмент за обработка на доклади (или таблото на доставчика) ги превръща в четлив инвентар на изпращачи.
  4. Накарайте всеки легитимен изпращач да мине aligned. Активирайте персонализирания DKIM за всеки доставчик (обикновено два CNAME записа в таблото им), за да могат подписите да носят вашия домейн, а не техния. Предпочитайте DKIM за alignment: оцелява при препращане, SPF — не.
  5. Изчакайте чиста двуседмица. Излезте от етап 2 само когато докладваните неуспехи са изключително трафик, непознат за вас — спуфването, което искате да блокирате.
  6. Преминете към p=quarantine; pct=10 — редактирайте съществуващия TXT запис _dmarc (работен пример: настройка на DMARC в IONOS), и внимавайте за синтаксиса: правописна грешка в тага за политика може да анулира изцяло записа. Повишете pct до 25, 50, 100 за 2–4 седмици, следейки докладите и тикетите към helpdesk-а. Нещо легитимно в спама: намалете pct, поправете изпращача, продължете.
  7. Преминете към p=reject след 1–2 чисти седмици на pct=100. Оставете rua= включено постоянно — всеки нов инструмент, приет от компанията, е бъдещ неминаващ изпращач.

Какво прави pct в действителност? Тънкостта на RFC 7489

pct иска от получателите да прилагат политиката ви към такъв процент от неминаващата поща. Тънкостта, от RFC 7489 §6.6.4: пощата, изключена от пробата, не пада назад към „доставяй нормално” — получава следващата по-малко строга политика. При p=quarantine; pct=25, другите 75% се третират като p=none и се доставят. Но при p=reject; pct=50, другите 50% са поставени в quarantine, а не доставени. Не съществува мек reject: в момента, в който записът казва reject, всяко неминаващо съобщение е поставено минимум в папката за спам при спазващите получатели.

Използвано съзнателно, това е функция — p=reject; pct=1 се държи като „постави почти всичко в quarantine, отхвърли малка порция”, легитимна последна рампа. Два предупреждения: получателите не всички реализират пробата идентично, затова третирайте pct като груб регулатор; и премахнете тага (или задайте pct=100) щом етап 4 е стабилен, за да може записът да казва каквото означавате.

Какво да правя с поддомейните — тагът sp=?

По подразбиране поддомейните наследяват политиката на организационния домейн: p=reject на yourdomain.com покрива и mail.yourdomain.com. Тагът sp= позволява разминаване, в двете полезни и опасни посоки. Полезно: p=quarantine; sp=reject заключва поддомейни, от които никога не изпращате, докато apex-ът все още е в процес на повишаване — спуфърите умишлено се насочват към поддомейни на наблюдавани домейни. Опасно: забравен sp=none безшумно освобождава всеки поддомейн от политиката reject, спечелена с шест седмици работа. Проверявайте за него в етап 4; ако даден поддомейн наистина се нуждае от по-слаба политика, публикувайте _dmarc запис на самия поддомейн вместо да разхлабвате всичките им.

Означава ли NIS2, че европейските бизнеси трябва да направят това?

DMARC работи идентично навсякъде — нищо в наръчника не се променя на европейска граница. Което се променя е тягата за съответствие. NIS2 Член 21(2)(j) изисква от обхванатите субекти да осигурят комуникациите си, а Регламент за изпълнение на Комисията (ЕС) 2024/2690 конкретизира техническите изисквания за субектите на цифрова инфраструктура, които покрива — Приложение към него (точка 6.7.2(k)) изисква план за изпълнение за внедряване на международно признати съвременни стандарти за имейл сигурност, а точка 6.7.2(l) изисква добри практики за DNS сигурност. Приложена DMARC политика, с SPF и DKIM отдолу, е признатият одитируем контрол за спуфинг; p=none е демонстративно мониторинг, не осигуряване. Ако клиентите ви са в обхвата, въпросниците им на доставчиците все повече питат именно за това.

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

Колко дълго отнема цялото внедряване? Шест до десет седмици е типичното: 2–4 седмици мониторинг, 1–3 седмици поправяне на изпращачи, 2–4 седмици постепенно quarantine, след това reject. Това е календарно, а не усилие — предимно изчакване докладите да потвърдят всяка промяна. 89.41% от 261,086,232 оценени домейна без приложена политика (данни към 2026-06-29) предимно не са в процес на внедряване; никога не са стартирали часовника.

Мога ли да прескоча quarantine и да използвам p=reject с нисък pct? Можете — по RFC 7489 §6.6.4, p=reject; pct=10 означава 10% отхвърлени и 90% в quarantine, приблизително края на етап 3. Но p=quarantine първо е по-лесно за разсъждаване, а получателите варират в степента, с която реализират пробата. Така или иначе, етапи 1–2 не са договорими: никоя форма на прилагане не е безопасна, докато легитимните изпращачи все още не минават.

Какво да правя с пощата, която не мога да поправя — препращащи и пощенски списъци? Препращането чупи SPF по дизайн, а някои пощенски списъци презаписват съдържание, чупейки и DKIM. Aligned DKIM оцелява при обикновено препращане, което решава по-голямата част; малкият остатък е точно защо съществува етапът с quarantine — поставената в папка за спам поща е обратима, докато оценявате. Подробности в препратена поща не минава SPF.

Достатъчно ли е спирането на p=quarantine? Има по-голямата parte от стойността и е много по-добро от 37,312,637 домейна, спрели на p=none (от 261,086,232 оценени, данни към 2026-06-29) — но спуфваната поща все пак достига папките за спам, откъдето хората я изваждат. Reject е крайната цел: само 10.59% от оценените домейни прилагат изобщо, а завършването е това, което проверяващите, застрахователите и въпросниците кредитират.

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

Ако провеждате това внедряване за клиент или работодател, финалната линия е показваема. Пуснете отново безплатното сканиране след като p=reject е активен и препратете оценения доклад: домейнът преминаващ към приложена политика, с времево клеймо и на разбираем език. Тази страница отговаря на реда за имейл сигурност при подновяване на киберзастраховки и въпросниците на доставчици, задвижени от NIS2, по-добре от скрийншот на DNS панела — и прави шест седмици внимателна, невидима работа видима за човека, плащащ за нея.

Проверете DMARC политиката безплатно

Вижте каква е текущата ви политика — и дали SPF и DKIM могат да носят прилагането — частно и само за собственика.

Проверете домейна → · Поправете DMARC → · „DMARC политиката не е активирана” — честната първа стъпка → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.