DMARC de la p=none la p=reject fără a pierde e-mailul legitim: Lansarea etapizată (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

Mutați DMARC de la p=none la p=reject în patru etape: monitorizați rapoartele rua timp de 2–4 săptămâni, reparați fiecare expeditor legitim, faceți rampa p=quarantine cu pct, apoi reject — nu săriți direct la reject. 70,368,600 din 261,086,232 domenii clasificate stau blocate la SPF soft fără aplicare DMARC, conform recensământului Defaults.Exposed.

Acesta este manualul operațional: un tabel de etape cu criterii de ieșire, înregistrarea pentru fiecare etapă, subtilitatea RFC 7489 pct care schimbă ce înseamnă „50%” la reject și tagul sp= pentru subdomenii. Dacă decideți dacă să aplicați, citiți mai întâi cele 6 etape ale maturității DMARC — acesta este cadrul; iar dacă nivelurile de politică sunt noi pentru dvs., ce înseamnă de fapt p=none, p=quarantine și p=reject este introducerea. Această pagină este acțiunea.

De ce nu puteți sări direct la p=reject?

Deoarece p=reject spune fiecărui receptor onest să respingă e-mailul care eșuează DMARC — și până nu v-ați urmărit rapoartele, nu știți ce eșuează. Aproape fiecare domeniu care pornește monitorizarea descoperă expeditori legitimi uitați: CRM-ul, instrumentul de facturare, un formular de contact. Săriți la reject în prima zi și acel e-mail nu merge la spam; dispare la momentul SMTP. Pierderea unei runde de facturi îi învață pe membrii organizației să se teamă de DMARC, iar înregistrarea se revine la p=none permanent — din 261,086,232 domenii clasificate, 37,312,637 sunt parcate exact acolo, și doar 10.59% (27,640,987) ajung vreodată la o politică aplicată.

Celălalt motiv este alinierea. DMARC trece doar când SPF sau DKIM trece și se aliniază cu domeniul From vizibil — SPF față de domeniul Return-Path (RFC5321.MailFrom), DKIM față de d= al semnăturii. Expeditorii terți de obicei trec SPF pe propriul domeniu, nu al dvs., de aceea etapa de reparare a fiecărei surse este în mare parte despre activarea DKIM cu domeniu personalizat al fiecărui vendor — detaliat în DMARC eșuează dar SPF și DKIM trec.

Care sunt cele patru etape de lansare?

Etapa	Înregistrarea de politică	pct	Ce se întâmplă cu e-mailul care eșuează	Criterii de ieșire
1. Monitorizare	`p=none; rua=mailto:…`	—	Livrat normal; primiți rapoarte agregate	2–4 săptămâni de rapoarte; fiecare expeditor din ele identificat ca legitim sau nu
2. Repararea surselor	`p=none` (nemodificat)	—	Încă livrat normal	Fiecare sursă legitimă trece DMARC aliniat (DKIM cu domeniu personalizat per expeditor); eșecurile rămase sunt doar trafic necunoscut/falsificat
3. Rampa quarantine	`p=quarantine`	10 → 25 → 50 → 100	Ponderea eșantionată merge la folderele de spam; ponderea exclusă din eșantion este tratată ca p=none (livrată)	1–2 săptămâni la pct=100 fără niciun e-mail legitim în carantină
4. Reject	`p=reject`	100	Respins la momentul SMTP; expeditorul primește un bounce, destinatarul nu vede nimic	Permanent — păstrați `rua` activ pentru totdeauna pentru a detecta noii expeditori

Date din 2026-06-29; comportamentul politicii conform RFC 7489.

Etapa 3 este locul unde domeniile se blochează sau intră în panică. Trimiterea în spam este recuperabilă — utilizatorii găsesc e-mailul, relaxați pct, reparați sursa. Respingerea nu este recuperabilă, de aceea quarantine la pct=100 care rulează curat este biletul de intrare la etapa 4.

Cum rulați lansarea, pas cu pas?

Rulați scanarea gratuită la defaults.exposed înainte de a atinge DNS-ul. Confirmă politica dvs. actuală și dacă SPF și DKIM sunt în loc dedesubt — cele două picioare pe care se bazează aplicarea.
Porniți monitorizarea dacă nu ați făcut-o. Publicarea p=none cu rua= este pasul de cinci minute din „DMARC policy not enabled”. Colectați 2–4 săptămâni de rapoarte — suficient pentru a detecta expeditorii lunari precum rundele de facturare.
Inventariați fiecare sursă din rapoarte. Sortați expeditorii în ai dvs., ai vendorilor dvs. și necunoscuți. Rapoartele brute sosesc ca XML — un instrument de procesare a rapoartelor (sau tabloul de bord al furnizorului dvs.) le transformă într-un inventar de expeditori lizibil.
Faceți fiecare sursă legitimă să treacă aliniată. Activați DKIM cu domeniu personalizat al fiecărui vendor (de obicei două înregistrări CNAME în tabloul lor de bord) astfel încât semnăturile să poarte domeniul dvs., nu al lor. Preferați DKIM pentru aliniere: supraviețuiește redirecționării, SPF nu.
Așteptați o fortnight curată. Ieșiți din etapa 2 doar când eșecurile raportate sunt exclusiv trafic pe care nu îl recunoașteți — falsificarea pe care doriți să o blocați.
Treceți la p=quarantine; pct=10 — editați înregistrarea TXT _dmarc existentă (exemplu lucrat: configurare DMARC IONOS) și urmăriți sintaxa: o greșeală de scriere în tagul de politică poate anula complet înregistrarea. Creșteți pct la 25, 50, 100 pe parcursul a 2–4 săptămâni, urmărind rapoartele și tichetele helpdesk. Ceva legitim în spam: reduceți pct, reparați sursa, reluați.
Treceți la p=reject după 1–2 săptămâni curate la pct=100. Păstrați rua= activ permanent — fiecare instrument nou pe care compania dvs. îl adoptă este un viitor expeditor care eșuează.

Ce face de fapt pct? Subtilitatea RFC 7489

pct cere receptorilor să aplice politica dvs. acelui procent din e-mailul care eșuează. Subtilitatea, din RFC 7489 §6.6.4: e-mailul exclus din eșantion nu revine la „livrat normal” — primește politica mai puțin severă imediat următoare. Sub p=quarantine; pct=25, celelalte 75% sunt tratate ca p=none și livrate. Dar sub p=reject; pct=50, celelalte 50% sunt puse în carantină, nu livrate. Nu există reject blând: din momentul în care înregistrarea dvs. spune reject, fiecare mesaj care eșuează este cel puțin trimis în spam la receptorii onești.

Folosit deliberat, acela este o caracteristică — p=reject; pct=1 se comportă ca „pune în carantină aproape totul, respinge câte puțin”, o rampă finală legitimă de urcare. Două precauții: receptorii nu implementează toți eșantionarea identic, deci tratați pct ca o reglare aproximativă; și eliminați tagul (sau setați pct=100) odată ce etapa 4 este stabilă, astfel încât înregistrarea dvs. să spună ce înțelegeți.

Ce se întâmplă cu subdomeniile — tagul sp=?

Implicit, subdomeniile moștenesc politica domeniului organizațional: p=reject la yourdomain.com acoperă și mail.yourdomain.com. Tagul sp= le permite să divergă, în direcții atât utile cât și periculoase. Util: p=quarantine; sp=reject blochează subdomeniile din care nu trimiteți niciodată în timp ce apex-ul este încă în mijlocul rampei — falsificatorii vizează deliberat subdomeniile domeniilor monitorizate. Periculos: un sp=none uitat exclude silențios fiecare subdomeniu din politica de reject pe care ați câștigat-o în șase săptămâni. Verificați-l la etapa 4; dacă un subdomeniu are cu adevărat nevoie de o politică mai relaxată, publicați o înregistrare _dmarc pe acel subdomeniu în loc să le relaxați pe toate.

NIS2 înseamnă că afacerile europene trebuie să facă asta?

DMARC funcționează identic peste tot — nimic din acest manual nu se schimbă la o frontieră UE. Ceea ce se schimbă este presiunea de conformitate. Articolul 21(2)(j) NIS2 cere entităților în perimetru să-și securizeze comunicațiile, iar Regulamentul de punere în aplicare al Comisiei (UE) 2024/2690 detaliază cerințele tehnice pentru entitățile de infrastructură digitală pe care le acoperă — Anexa sa (punctul 6.7.2(k)) cere un plan de implementare pentru implementarea standardelor moderne de securitate e-mail agreate internațional, iar punctul 6.7.2(l) cere cele mai bune practici de securitate DNS. O politică DMARC aplicată, cu SPF și DKIM dedesubt, este controlul auditabil recunoscut pentru falsificare; p=none este demonstrabil monitorizare, nu securizare. Dacă clienții dvs. sunt în perimetru, chestionarele lor de furnizori cer din ce în ce mai mult exact asta.

Întrebări frecvente

Cât durează întreaga lansare? Șase până la zece săptămâni este tipic: 2–4 săptămâni monitorizare, 1–3 săptămâni repararea surselor, 2–4 săptămâni rampa quarantine, apoi reject. Este timp calendaristic, nu efort — în mare parte așteptând rapoartele pentru a confirma fiecare modificare. Cei 89.41% din 261,086,232 domenii clasificate fără o politică aplicată (date din 2026-06-29) în mare parte nu sunt la mijlocul lansării; nu au pornit niciodată cronometrul.

Pot sări quarantine și folosi p=reject cu un pct mic? Puteți — per RFC 7489 §6.6.4, p=reject; pct=10 înseamnă 10% respins și 90% în carantină, aproximativ etapa 3 târzie. Dar p=quarantine mai întâi este mai ușor de raționat, iar receptorii variază în cât de fidel eșantionează. Indiferent, etapele 1–2 sunt non-negociabile: nicio variantă de aplicare nu este sigură cât timp expeditorii legitimi mai eșuează.

Ce se întâmplă cu e-mailul pe care nu îl pot repara — forwardere și liste de corespondență? Redirecționarea strică SPF prin design, iar unele liste de corespondență rescriu conținut, stricând și DKIM. DKIM aliniat supraviețuiește redirecționării obișnuite, ceea ce gestionează cea mai mare parte; micul reziduu este de ce există etapa quarantine — e-mailul în spam este recuperabil în timp ce evaluați. Detalii în e-mailul redirecționat eșuează SPF.

Este suficient să mă opresc la p=quarantine? Este cea mai mare parte a valorii și mult mai bine decât cele 37,312,637 domenii parcate la p=none (din 261,086,232 clasificate, date din 2026-06-29) — dar e-mailul falsificat ajunge totuși în folderele de spam, de unde oamenii îl pescuiesc. Reject este punctul final: doar 10.59% din domeniile clasificate aplică deloc, iar terminarea este ceea ce creditează verificatoarele, asigurătorii și chestionarele.

Trimiteți proprietarului raportul

Dacă rulați această lansare pentru un client sau angajator, linia de sosire este vizibilă. Re-rulați scanarea gratuită după ce p=reject se rezolvă și trimiteți raportul clasificat: domeniul trecând la o politică aplicată, cu marcaj temporal și în limbaj simplu. Acea pagină răspunde la linia de securitate e-mail din reînnoirile asigurărilor cibernetice și chestionarele furnizorilor conduse de NIS2 mai bine decât o captură de ecran a unui panou DNS — și face vizibilă șase săptămâni de muncă atentă și invizibilă persoanei care plătește pentru aceasta.

Verificați gratuit politica DMARC

Vedeți care este politica dvs. actuală — și dacă SPF și DKIM pot susține aplicarea — privat și numai pentru proprietar.

Verificați domeniul → · Corectați DMARC → · „DMARC policy not enabled” — primul pas onest → · Doar date agregate. Date stocate și procesate în UE.