DMARC: de la p=none la p=reject în 30 de zile
Un plan săptămână cu săptămână pentru a duce un domeniu de la monitorizarea DMARC la aplicarea completă, fără a vă bloca facturile sau newsletterele.
De ce aplicarea are nevoie de un plan
Publicarea p=reject este o singură modificare în DNS, exact cum este și blocarea propriului e-mail. După modificare, fiecare serviciu care trimite în numele domeniului dumneavoastră trebuie să treacă de DMARC: furnizorul de căsuțe poștale, instrumentul de newsletter, sistemul de facturare, helpdeskul, magazinul online și scannerul din birou care trimite PDF-uri. Oricare dintre ele care semnează cu propriul domeniu sau folosește propria adresă de retur nu trece de aliniere și ajunge respins.
Bucla de raportare DMARC există tocmai pentru a găsi acei expeditori înainte de aplicare. Cu p=none și o adresă rua funcțională, destinatarii trimit zilnic rapoarte agregate care listează fiecare adresă IP care trimite e-mail cu domeniul dumneavoastră în antetul From, împreună cu rezultatul verificărilor. Treceți la aplicare doar atunci când rapoartele arată că nu mai rămâne nimic legitim care să eșueze.
Înainte de a începe: inventarul expeditorilor
Notați fiecare sistem care trimite e-mail cu domeniul dumneavoastră în adresa From, împreună cu persoana care îl administrează. Rapoartele vor scoate la iveală sistemele pe care le uitați, dar o listă pregătită dinainte scurtează considerabil prima săptămână și vă spune pe cine să contactați atunci când ceva nu funcționează. Includeți și sistemele care trimit rar: o rulare de extrase de la sfârșit de an se pierde ușor într-o fereastră de două săptămâni.
| Tip de expeditor | Exemple | Modul obișnuit de aliniere |
|---|---|---|
| Furnizor de căsuțe poștale | Microsoft 365, Google Workspace | Activați semnarea DKIM cu propriul domeniu din consola de administrare |
| Marketing și newslettere | Furnizori de servicii de e-mail | Adăugați înregistrările DKIM de tip CNAME sau TXT ale furnizorului; opțional, un domeniu de retur propriu |
| E-mail tranzacțional | Resetări de parolă, chitanțe trimise de aplicația dumneavoastră | DKIM cu domeniul dumneavoastră la releu; domeniu MAIL FROM (return-path) propriu |
| Sisteme de business | CRM, helpdesk, facturare, instrumente de resurse umane | Verificarea domeniului în instrument, care adaugă de obicei și înregistrările DKIM |
| Dispozitive și scripturi | Scannere, alerte de monitorizare, joburi cron | Trimiteți prin SMTP-ul autentificat al furnizorului dumneavoastră, în loc de trimitere directă |
Verificați SPF și DKIM pentru domeniu înainte de a publica orice. Folosiți Securitatea e-mailului pentru a confirma că înregistrarea există, că rămâne sub limita de 10 interogări și că se termină cu ~all sau -all. Folosiți verificarea Sănătatea domeniului pentru o imagine de ansamblu asupra SPF, DMARC, MX și a site-ului, într-o singură rulare.
Săptămâna 1: publicați p=none și colectați rapoarte
Publicați o înregistrare de monitorizare cu o adresă pentru rapoartele agregate. O căsuță poștală dedicată sau un serviciu de rapoarte DMARC funcționează mult mai bine decât o căsuță personală: domeniile mari primesc zilnic zeci de fișiere XML comprimate. Dacă adresa se află pe un alt domeniu, acel domeniu trebuie să publice o înregistrare de autorizare, lucru pe care serviciile de rapoarte îl fac automat.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Rulați Securitatea e-mailului după modificare. Instrumentul confirmă că există exact o singură înregistrare, că politica se analizează corect și că adresele externe pentru rapoarte sunt autorizate. Rapoartele de la furnizorii mari încep de obicei într-o zi sau două și acoperă ziua UTC anterioară.
Coborâți mai întâi TTL-ul
_dmarc la o valoare scurtă, de exemplu 300 de secunde, pe toată durata tranziției. Dacă o etapă provoacă probleme, revenirea ajunge atunci la destinatari în câteva minute, nu în câteva ore.Săptămâna 2: citiți rapoartele și corectați alinierea
Grupați rândurile din rapoarte după IP-ul sursă și identificați cine deține fiecare adresă. DNS-ul invers, numele rețelei din Informații IP și volumul fac de obicei lucrurile evidente: un interval de IP-uri al ESP-ului, furnizorul dumneavoastră de căsuțe poștale sau propriile servere. Ghidul rapoartelor agregate explică fiecare câmp în parte.
| Tipar în raport | Cauză probabilă | Acțiune |
|---|---|---|
| IP-urile furnizorului, DKIM trecut, SPF trecut, ambele aliniate | Expeditor configurat corect | Nimic |
| IP-urile ESP-ului, SPF trecut, dar nealiniat, fără DKIM aliniat | ESP-ul folosește propriul domeniu de retur și semnează cu domeniul lui | Configurați DKIM cu domeniul dumneavoastră în ESP |
| IP-uri necunoscute, DKIM trecut și aliniat, SPF eșuat | E-mail redirecționat de serverul unui destinatar | Nimic; DKIM îl ține în continuare valid |
| IP-uri necunoscute, SPF și DKIM eșuate, volume mici | Uzurpare sau un sistem uitat | Confirmați că nimeni nu îl deține; aplicarea îl va bloca |
| IP-urile propriilor servere, totul eșuează | Un script sau un dispozitiv care trimite direct | Rutați-l prin SMTP autentificat, cu DKIM |
Urmăriți alinierea DKIM pentru fiecare serviciu. Alinierea SPF se rupe ori de câte ori e-mailul este redirecționat, în timp ce o semnătură DKIM cu d=example.com supraviețuiește redirecționării atâta timp cât mesajul nu este modificat pe drum. Acolo unde un serviciu nu poate semna cu domeniul dumneavoastră, luați în calcul mutarea lui pe un subdomeniu precum news.example.com, cu propria configurație de SPF, DKIM și DMARC.
selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.esp.example.net.Săptămâna 3: treceți la p=quarantine
Când rapoartele din ultima săptămână arată că expeditorii cunoscuți trec de verificări cu aliniere, schimbați politica în quarantine. E-mailul care eșuează ajunge de acum în dosarele de spam, ceea ce este vizibil pentru utilizatori, dar se poate recupera. Spuneți-le celor care administrează sistemele de trimitere și echipei de suport ce s-a schimbat, astfel încât o reclamație despre e-mail lipsă să fie legată rapid de DMARC.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"RFC 7489 definește și pct, pentru a aplica politica doar unei părți din e-mailul care eșuează, de exemplu pct=25, restul fiind tratat cu o treaptă mai blând. Poate îndulci primul pas pe un domeniu foarte mare, însă revizia DMARCbis elimină pct în favoarea unui simplu indicator de testare. Pentru majoritatea domeniilor este mai util să terminați munca de aliniere și să comutați complet.
Nu uitați de sp
sp, subdomeniile urmează p. Dacă publicați sp=none în timpul tranziției, nu uitați să îl scoateți mai târziu; Securitatea e-mailului avertizează atunci când subdomeniile sunt mai slabe decât domeniul.Săptămâna 4: treceți la p=reject
După o săptămână de carantină fără eșecuri legitime, publicați p=reject. Destinatarii care respectă politica refuză de acum mesajele care eșuează chiar în timpul tranzacției SMTP, așa că expeditorii primesc un mesaj de eroare în loc ca destinatarul să găsească mesajul în spam. Aceasta este setarea care oprește uzurparea directă a domeniului dumneavoastră.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"Păstrați rua la locul lui pentru totdeauna. Rapoartele sunt felul în care observați un instrument nou de marketing la care s-a înscris cineva, o cheie DKIM expirată la un furnizor sau o campanie de uzurpare. Verificați-le cel puțin săptămânal sau lăsați un serviciu de rapoarte să vă alerteze.
Dacă ceva se strică
Când e-mailul legitim începe să fie respins, coborâți politica cu o treaptă, reparați expeditorul și urcați din nou. Cu un TTL scurt, modificarea intră în vigoare în câteva minute. Nu ștergeți înregistrarea: asta vă lasă fără rapoartele de care aveți nevoie ca să vedeți ce nu a mers.
- Schimbați
p=rejectînp=quarantine(sauquarantineînnone). - Găsiți sursa care eșuează în cel mai recent raport agregat sau în mesajul de eroare primit.
- Activați DKIM cu domeniul dumneavoastră pentru acel serviciu sau rutați-l printr-un releu autentificat.
- Confirmați corecția cu un mesaj de test și cu Analizor de antete e-mail:
dkim=passcuheader.d=example.com. - Restabiliți politica mai strictă.
Cazuri speciale
Redirecționarea și listele de discuții
Redirecționarea rupe SPF, pentru că serverul care redirecționează nu se află în înregistrarea dumneavoastră SPF. Listele de discuții care adaugă un subsol sau schimbă subiectul rup, la rândul lor, semnătura DKIM. Destinatarii pot folosi antetele ARC (RFC 8617) adăugate de intermediari de încredere pentru a accepta totuși astfel de mesaje, dar acest lucru nu depinde de dumneavoastră; ceea ce controlați este semnarea întregului e-mail cu DKIM.
Domenii care nu trimit niciodată e-mail
Domeniile parcate și cele de protecție pot sări complet peste etape. Publicați p=reject, o înregistrare SPF de tipul v=spf1 -all și nicio înregistrare MX, iar ele nu mai pot fi folosite pentru uzurpare.
example.org. IN TXT "v=spf1 -all"
_dmarc.example.org. IN TXT "v=DMARC1; p=reject;"Domenii cu volum mic
Domeniul unei firme mici poate trimite doar câteva mesaje pe zi, așa că rapoartelor le trebuie mai mult timp ca să arate fiecare expeditor. Păstrați p=none cel puțin un ciclu complet de facturare sau până când fiecare sistem din lista de inventar a apărut într-un raport cu o verificare trecută.
Lucrul cu expeditori terți
Cele mai multe eșecuri de aliniere din a doua săptămână aparțin unui furnizor, nu propriilor servere. Vestea bună este că aproape orice serviciu serios de trimitere acceptă autentificarea cu domeniu propriu; de obicei se numește verificare de domeniu, autentificarea expeditorului sau trimitere sub marcă proprie. Setarea este adesea dezactivată implicit, pentru că are nevoie de înregistrări DNS din partea dumneavoastră.
Când contactați un furnizor, puneți întrebări precise. O cerere vagă de tipul „vă rugăm să susțineți DMARC” primește de obicei un răspuns la fel de vag, în timp ce o cerere pentru o semnătură DKIM cu d=example.com are un răspuns clar, da sau nu. Păstrați răspunsurile în inventarul de expeditori, ca următoarea persoană să știe cum este configurat fiecare serviciu.
- Puteți semna mesajele noastre cu DKIM folosind domeniul nostru (
d=example.com) și de ce înregistrări DNS aveți nevoie? - Poate expeditorul de plic (return-path, adresa de retur) să folosească un subdomeniu al nostru, precum
bounces.example.com, astfel încât SPF să se alinieze? - De ce
includeSPF aveți nevoie și câte interogări DNS consumă acesta? - Trimiteți din intervale de IP partajate și rotiți cheile DKIM? Cum suntem anunțați despre schimbările de chei?
- Putem trimite de pe un subdomeniu precum
news.example.com, dacă alinierea completă pe domeniul principal nu este posibilă?
Adăugarea unui include SPF al furnizorului nu este întotdeauna necesară. Dacă furnizorul semnează cu domeniul dumneavoastră și folosește propriul domeniu de retur, DMARC trece doar prin DKIM, iar dumneavoastră economisiți una dintre cele zece interogări SPF. Ghidul despre limita de 10 interogări SPF explică de ce contează acest buget.
Izolați riscul cu subdomenii
news.example.com și a chitanțelor de pe billing.example.com păstrează separate reputația și configurația DMARC ale fiecărui flux. O problemă la un furnizor nu mai afectează atunci e-mailul trimis de oamenii dumneavoastră de pe example.com.Subdomeniile în timpul tranziției
Subdomeniile fără o înregistrare _dmarc proprie moștenesc politica domeniului organizațional: eticheta sp, dacă există, altfel p. Moștenirea aceasta este utilă, pentru că atacatorilor le place să uzurpe nume precum secure.example.com, care par oficiale, dar nu au nicio înregistrare. Înseamnă și că tranziția dumneavoastră acoperă dintr-odată fiecare subdomeniu, inclusiv unele configurate de o echipă cu ani în urmă.
Căutați expeditorii de pe subdomenii în rapoarte: câmpul header_from arată domeniul From exact al fiecărui rând. Dacă un subdomeniu trimite e-mail care nu este pregătit pentru aplicare, dați-i o înregistrare proprie cu p=none cât timp îl reparați, în loc să slăbiți sp pentru toate subdomeniile. După reparare, ștergeți înregistrarea subdomeniului, ca acesta să urmeze din nou politica principală.
_dmarc.legacy.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Revizia DMARCbis adaugă o etichetă np pentru subdomeniile care nu există deloc în DNS. Destinatarii care o acceptă pot respinge e-mailul venit de la nume inventate precum invoice-2026.example.com, chiar dacă folosiți un sp mai blând pentru subdomeniile reale. Până când susținerea devine larg răspândită, păstrarea lui sp egal cu p vă oferă aceeași protecție.
Măsurarea progresului
O tranziție este mai ușor de condus cu câteva cifre din rezumatul săptămânal al rapoartelor. Urmăriți-le săptămână de săptămână, astfel încât o regresie, cum ar fi un furnizor care a încetat să semneze, să iasă imediat în evidență. Ele sunt și un material bun pentru o actualizare de stare adresată celor care administrează sistemele de trimitere.
| Indicator | Ținta înainte de aplicare | De ce contează |
|---|---|---|
| Ponderea e-mailului care trece de DMARC | Aproape 100% din e-mailul expeditorilor cunoscuți | Eșecurile rămase de la expeditorii cunoscuți vor fi blocate |
| Expeditori cunoscuți fără DKIM aliniat | Zero | Expeditorii care se bazează doar pe SPF eșuează când e-mailul este redirecționat |
| Surse necunoscute care trec de DMARC | Zero sau explicate | O verificare trecută de la un IP necunoscut înseamnă că cineva poate trimite în numele dumneavoastră |
| Destinatari care trimit rapoarte | Stabil de la o săptămână la alta | O scădere poate însemna că adresa rua a încetat să funcționeze |
Nu urmăriți un 100% perfect pe tot traficul. E-mailul redirecționat și încercările de uzurpare vor eșua întotdeauna, iar acest lucru este de așteptat. Cifra care trebuie să ajungă la zero este e-mailul legitim de la propriii expeditori care eșuează.
Listă de verificare
- Un inventar al serviciilor care trimit, cu un responsabil pentru fiecare.
- Înregistrare SPF validă, sub 10 interogări, care se termină cu
~allsau-all. - Semnarea DKIM cu domeniul dumneavoastră, activată pentru fiecare serviciu care o acceptă.
- O singură înregistrare DMARC, cu
ruași un TTL scurt; adresele externe pentru rapoarte, autorizate. - Cel puțin o săptămână de rapoarte analizate înaintea fiecărei schimbări de politică.
- Echipa de suport informată înainte de
quarantineși dereject. - Analiza săptămânală a rapoartelor și un pas de integrare a furnizorilor care include SPF și DKIM.
Întrebări frecvente
Pot trece direct la p=reject?
Doar pentru domeniile care nu trimit deloc e-mail sau atunci când sunteți sigur că fiecare expeditor semnează cu DKIM folosind domeniul dumneavoastră. Altfel riscați să respingeți propriile facturi sau propriile mesaje de resetare a parolei, fără niciun avertisment.
De unde știu că este sigur să trec la etapa următoare?
Atunci când o săptămână întreagă de rapoarte agregate (mai mult pentru domeniile cu volum mic) arată că fiecare IP pe care îl recunoașteți trece de DMARC, iar eșecurile rămase sunt redirecționări sau surse necunoscute despre care ați confirmat că nu aparțin nimănui.
Este suficientă alinierea SPF dacă DKIM este greu de configurat?
Este suficientă pentru ca DMARC să treacă la livrarea directă, dar SPF eșuează atunci când un destinatar redirecționează mesajul. DKIM cu domeniul dumneavoastră este cel care ține valid e-mailul redirecționat, așa că tratați expeditorii care se bazează doar pe SPF ca pe un risc de rezolvat.
Afectează p=reject e-mailul pe care îl primesc?
Nu. Înregistrarea dumneavoastră DMARC controlează felul în care alți destinatari tratează e-mailul care pretinde că vine de la domeniul dumneavoastră. Felul în care propriul server de e-mail tratează mesajele primite se configurează separat.
Am nevoie de un serviciu plătit de rapoarte DMARC?
Nu neapărat. Domeniile mici pot citi rapoartele XML direct sau cu ajutorul unui script scurt. Serviciile ajută atunci când volumele sunt mari sau când vreți alerte și istoric.
Ce ar trebui să fie căsuța rua?
O adresă dedicată, precum dmarc-reports@example.com, care să nu fie căsuța personală a cuiva, sau adresa unui serviciu de rapoarte. Rapoartele sunt frecvente, comprimate și făcute pentru a fi citite de mașini.