Ghid de securitate e-mail

Ce verifică Securitatea e-mailului

Serverele destinatare decid dacă un mesaj care pretinde că vine de la domeniul dumneavoastră este autentic citind câteva înregistrări DNS. Securitatea e-mailului le citește pe toate pentru un singur domeniu: SPF listează serverele care au voie să trimită, DKIM publică cheile care semnează mesajele, DMARC spune destinatarilor ce să facă atunci când ambele eșuează și unde să raporteze, MTA-STS și TLS-RPT protejează și monitorizează criptarea dintre serverele de e-mail, iar BIMI vă poate afișa logoul după ce DMARC este aplicat.

Acest ghid înlocuiește ghidurile separate SPF Checker și DMARC Checker: ambele instrumente fac acum parte din Securitatea e-mailului, iar secțiunile lor urmează mai jos.

Cum folosiți Securitatea e-mailului

1. Deschideți Securitatea e-mailului și introduceți domeniul din adresa From, de exemplu example.com. Un URL sau o adresă de e-mail lipită este redusă la domeniu.
2. Opțional, introduceți un selector DKIM. Este eticheta s= din antetul DKIM-Signature al unui mesaj trimis de dumneavoastră; selectoarele frecvente sunt încercate oricum.
3. XGM rezolvă înregistrarea SPF cu fiecare include și redirect, caută _dmarc (revenind la domeniul părinte) și verifică autorizarea a până la trei adrese externe de raportare.
4. În paralel, serverul XGM încearcă selectoarele DKIM, citește înregistrările MTA-STS, TLS-RPT și BIMI și descarcă prin HTTPS fișierul de politică MTA-STS.
5. Citiți scorul și tabelul zonelor, apoi parcurgeți constatările, cele mai grave întâi. Constatările care au o reparație afișează o înregistrare de copiat la furnizorul DNS.
6. Partajați rezultatul prin link permanent (/tools/email-security?d=example.com), exportați-l sau deschideți fila Raport complet pentru raportul cu scor de pe server, cu recomandări prioritizate.

Dacă o interogare DNS expiră, instrumentul spune asta în loc să raporteze o înregistrare lipsă, iar zona respectivă rămâne în afara scorului. O nouă rulare reușește de obicei.

Scorul și foaia de parcurs DMARC

Fiecare zonă primește o stare: trecut aduce ponderea întreagă, necesită atenție aduce jumătate, iar eșuat sau neconfigurat nu aduce nimic. DMARC la p=none și MTA-STS în mod de testare contează drept necesită atenție, pentru că monitorizează în loc să protejeze. Scorul este o orientare rapidă pentru compararea domeniilor și urmărirea progresului, nu o certificare.

Sub scor, foaia de parcurs DMARC arată unde se află domeniul pe drumul obișnuit: publicați p=none cu o adresă de raportare, treceți la p=quarantine după ce fiecare expeditor legitim se aliniază, apoi la p=reject. Ghidul de la p=none la p=reject parcurge lansarea săptămână cu săptămână.

Ce este DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) leagă cele două metode mai vechi de autentificare a e-mailului de adresa pe care oamenii o văd efectiv. SPF verifică ce servere pot trimite pentru expeditorul din plic, iar DKIM verifică o semnătură criptografică adăugată de sistemul expeditor. Niciuna nu se uită singură la antetul From vizibil.

DMARC închide această breșă. Un mesaj trece DMARC atunci când SPF sau DKIM trece și domeniul care a trecut este aliniat cu domeniul From. Proprietarul domeniului publică o politică ce spune destinatarilor ce să facă la eșec și adrese care primesc rapoarte despre tot e-mailul trimis cu domeniul respectiv.

Destinatarii nu sunt obligați să urmeze politica, iar furnizorii mari de căsuțe poștale o combină cu propriile semnale de spam. În practică p=reject este respectat de furnizorii mari și este cea mai puternică protecție pe care o puteți publica împotriva falsificării directe a domeniului.

De ce contează DMARC

Fără DMARC, oricine poate trimite mesaje cu domeniul dumneavoastră în antetul From și nu aflați niciodată. Phishingul care imită facturi, resetări de parolă sau directori se bazează exact pe asta. O înregistrare DMARC schimbă și felul în care este judecat propriul e-mail: mesajele autentificate și aliniate sunt mai ușor de acceptat de destinatari.

Din februarie 2024, Google și Yahoo cer expeditorilor în masă (aproximativ 5.000 sau mai multe mesaje pe zi către utilizatorii lor) să publice o înregistrare DMARC, cu p=none ca minim, alături de SPF și DKIM. Orice domeniu care trimite e-mail beneficiază de aceeași configurație, iar domeniile care nu trimit deloc ar trebui să publice p=reject, ca să nu poată fi abuzate.

Cum citiți fiecare etichetă DMARC

O înregistrare DMARC este o listă de perechi tag=value separate prin punct și virgulă. Înregistrarea trebuie să înceapă cu v=DMARC1, iar p este obligatorie; prin convenție vine imediat după v. Etichetele necunoscute sunt ignorate de destinatari, de aceea o greșeală de scriere dezactivează în tăcere o setare.

Grupul de lucru DMARC de la IETF revizuiește standardul, efort numit adesea DMARCbis. Revizia adaugă etichete precum np pentru subdomenii inexistente și înlocuiește pct cu un indicator de testare t. XGM recunoaște aceste etichete, deci nu le raportează ca necunoscute.

Verdictele din instrument

Greșeli DMARC frecvente și cum le reparați

Două înregistrări DMARC

Se întâmplă de obicei când asistentul de configurare al unui furnizor nou adaugă o înregistrare lângă una veche. Reparația este să le contopiți într-o singură înregistrare; reparația propusă de instrument arată un punct de plecare curat.

Înregistrarea este publicată chiar pe domeniu

O înregistrare TXT cu v=DMARC1 la example.com nu face nimic. Trebuie să fie la _dmarc.example.com. Unele panouri DNS adaugă automat numele zonei, deci acolo scrieți doar _dmarc ca nume de gazdă.

Rapoartele către alt domeniu sunt aruncate

Dacă rua=mailto:reports@dmarc-service.example.net iese din domeniul dumneavoastră, domeniul destinatar trebuie să publice o înregistrare prin care acceptă rapoartele. Serviciile de raportare fac de obicei asta pentru clienții lor, dar o căsuță găzduită chiar de dumneavoastră pe alt domeniu are nevoie de adăugarea manuală.

example.com._report._dmarc.dmarc-service.example.net. IN TXT "v=DMARC1"

Rămânerea la p=none ani de zile

p=none este o fază de măsurare, nu o destinație. După ce rapoartele agregate arată că expeditorii legitimi trec cu aliniere, treceți la quarantine și apoi la reject. Ghidul de la p=none la p=reject parcurge asta în etape.

Politică mai slabă pentru subdomenii

p=reject; sp=none lasă fiecare subdomeniu deschis falsificării, iar atacatorii folosesc nume precum billing.example.com exact din acest motiv. Eliminați sp sau dați-i aceeași valoare ca p, în afară de cazul în care un subdomeniu chiar are nevoie de o politică mai blândă cât timp îl reparați.

Exemple de înregistrări DMARC

Înlocuiți example.com și adresa de raportare cu valorile proprii. Păstrați rua în fiecare etapă: fără rapoarte nu puteți ști ce va bloca aplicarea.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Când instrumentul propune un pas următor pentru o înregistrare existentă, păstrează fiecare altă etichetă publicată deja, precum sp, ruf sau fo, și schimbă doar politica.

Ce este SPF

Sender Policy Framework (RFC 7208) este o înregistrare TXT care începe cu v=spf1 și listează cine poate trimite e-mail pentru un domeniu. Când un server primește un mesaj, se uită la expeditorul din plic, adresa folosită în comanda SMTP MAIL FROM, și verifică dacă IP-ul care se conectează este permis de înregistrarea acelui domeniu. Rezultatul este pass, fail, softfail, neutral, none, temperror sau permerror.

Expeditorul din plic nu este adesea adresa pe care o văd oamenii. Serviciile de newsletter și de ticketing folosesc de obicei propriul domeniu de bounce, deci SPF trece pentru ele fără să spună nimic despre adresa From. DMARC leagă cele două cerând ca domeniul SPF să fie aliniat cu domeniul From.

Cum citiți o înregistrare SPF

O înregistrare este o listă de mecanisme evaluate de la stânga la dreapta, fiecare cu un calificator opțional. Primul mecanism care se potrivește cu IP-ul expeditor decide rezultatul, deci ordinea contează doar pentru calificatorul care se aplică. O înregistrare ar trebui să se termine cu all, ca să decidă ce se întâmplă cu tot ce nu este listat.

Ce înseamnă constatările SPF

Numărătoarea de căutări avertizează la opt. Asta lasă loc pentru ziua în care un furnizor adaugă un include imbricat în propria înregistrare și vă crește numărul fără nicio schimbare de partea dumneavoastră. Ghidul limitei de 10 căutări explică cum îl reduceți.

Ce domeniu verificați pentru SPF

SPF este evaluat pentru expeditorul din plic, deci domeniul corect de verificat este cel din antetul Return-Path al unui mesaj livrat. Pentru e-mailul trimis direct de la furnizorul de căsuțe poștale este de obicei propriul domeniu. Pentru newslettere, sisteme de ticketing și instrumente de facturare este adesea un domeniu de bounce precum bounces.example.com sau un domeniu al serviciului.

Deschideți un mesaj recent de la fiecare sistem, uitați-vă la Return-Path și Authentication-Results și verificați pe rând fiecare domeniu din plic. Analizor de antete e-mail arată ambele câmpuri și rezultatul SPF înregistrat de destinatar. Dacă rezultatul este pass pentru un domeniu care nu este al dumneavoastră, SPF funcționează pentru serviciu, dar nu contează la DMARC pentru dumneavoastră.

Destinatarii verifică SPF și pentru numele HELO al serverului care se conectează atunci când expeditorul din plic este gol, ca la mesajele de bounce. Numele gazdelor de e-mail precum mail.example.com ar trebui deci să aibă o mică înregistrare SPF proprie, de exemplu v=spf1 a -all.

Greșeli SPF frecvente

Adăugarea unei a doua înregistrări pentru un furnizor nou

Instrucțiunile de configurare spun adesea „adăugați această înregistrare TXT”, iar o a doua înregistrare v=spf1 apare lângă prima. Contopiți în schimb noul include în înregistrarea existentă.

; wrong: two records
example.com. IN TXT "v=spf1 include:_spf.mail.example.net -all"
example.com. IN TXT "v=spf1 include:esp.example.net -all"

; right: one record
example.com. IN TXT "v=spf1 include:_spf.mail.example.net include:esp.example.net -all"

Greșeli de scriere care strică totul

inlcude:, ip4:192.0.2.0/33 sau lipsa unui două puncte sunt erori de sintaxă. Destinatarii returnează permerror pentru toată înregistrarea, nu doar pentru termenul stricat, deci o singură greșeală dezactivează SPF pentru tot e-mailul.

Bazarea doar pe SPF

SPF eșuează când un mesaj este redirecționat, pentru că serverul care redirecționează nu este în înregistrare. Configurați semnarea DKIM cu domeniul dumneavoastră la fiecare expeditor, ca DMARC să treacă în continuare. Ghidul DMARC explică cum se combină cele două.

Uitarea domeniilor care nu trimit niciodată e-mail

Domeniile parcate ar trebui să publice v=spf1 -all împreună cu o înregistrare DMARC p=reject. Fără ele, domeniul este ușor de folosit la falsificare, pentru că destinatarii nu au ce să verifice.

Autorizarea a mult mai mult decât folosiți

Intervalele mari, precum un /16 întreg copiat din documentație veche, sau un include pentru un întreg furnizor de găzduire permit fiecărui client al acelei rețele să treacă SPF în numele dumneavoastră. Listați cele mai înguste intervale sau include-ul specific pe care îl documentează serviciul și revizuiți-le când schimbați găzduirea.

DKIM: cum găsiți selectorul și evaluați cheia

DKIM semnează fiecare mesaj cu o cheie privată și publică cheia publică în DNS sub un selector: selector1._domainkey.example.com. Nimic din DNS nu listează selectoarele folosite de un domeniu, așa că Securitatea e-mailului încearcă 24 de nume folosite de furnizorii mari și de serviciile de trimitere (de exemplu google, selector1, selector2, k1, s1 și mandrill), plus selectorul introdus de dumneavoastră. O scanare care nu găsește nimic nu dovedește că DKIM lipsește, deci contează drept necesită atenție, nu drept eșec.

Pentru fiecare cheie găsită, instrumentul decodează cheia publică și raportează tipul și dimensiunea ei. RFC 8301 interzice cheile RSA mai scurte de 1024 de biți și recomandă 2048; o cheie de 1024 de biți este un avertisment. Indicatorul t=y marchează o cheie în mod de testare, care le permite destinatarilor să ignore semnătura, iar un p= gol marchează o cheie revocată după o rotație.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Ghidul selectoarelor DKIM și al rotației cheilor explică cum publicați chei de 2048 de biți care încap în DNS și cum le rotiți fără să stricați semnăturile mesajelor aflate în tranzit.

MTA-STS și TLS-RPT

Serverele de e-mail criptează cu STARTTLS doar când ambele părți îl oferă, iar un atacator aflat pe traseul din rețea poate elimina oferta. MTA-STS vă lasă să declarați că serverele dumneavoastră de e-mail acceptă întotdeauna TLS cu un certificat valid. Are două părți: o înregistrare TXT la _mta-sts.example.com cu un id și un fișier de politică servit prin HTTPS la mta-sts.example.com.

Securitatea e-mailului descarcă politica așa cum o fac serverele expeditoare: prin HTTPS, cu validarea certificatului și fără să urmeze redirecționări, așa cum cere RFC 8461 §3.3. Verifică version, mode, max_age și dacă fiecare gazdă MX publicată se potrivește cu o linie mx. În modul enforce, o gazdă MX neacoperită de politică este critică, pentru că expeditorii care respectă MTA-STS vor refuza livrarea către ea.

version: STSv1
mode: testing
mx: mx1.example.com
mx: *.mail.example.com
max_age: 604800

TLS-RPT cere serverelor expeditoare să raporteze zilnic eșecurile TLS la adresa din _smtp._tls.example.com. Publicați-l înainte de a muta MTA-STS din testare în enforce, ca să vedeți problemele înainte ca mesajele să fie refuzate. Ghidul MTA-STS și TLS-RPT acoperă configurarea pas cu pas.

BIMI

BIMI publică la default._bimi.example.com un logo pe care unii furnizori de căsuțe poștale îl afișează lângă mesajele autentificate. Este opțional și are cea mai mică pondere în scor. Furnizorii afișează logoul doar când DMARC este aplicat cu p=quarantine sau p=reject, logoul este un fișier SVG Tiny PS servit prin HTTPS și, pentru Gmail și Apple Mail, în a= este listat un Verified Mark Certificate sau un Common Mark Certificate.

Securitatea e-mailului raportează o înregistrare lipsă ca notă, nu ca problemă, și avertizează când există o înregistrare BIMI fără ca DMARC să fie aplicat. Dacă merită costul certificatului se discută în Ghidul BIMI și VMC.

Întrebări frecvente

Surse

• RFC 7489: autentificarea, raportarea și conformitatea mesajelor pe bază de domeniu (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: semnături DomainKeys Identified Mail (DKIM)
• Google: ghid pentru expeditorii de e-mail
• Grupul de lucru IETF DMARC (proiectele DMARCbis)
• RFC 7208 §4.6.4: limitele de interogări DNS
• RFC 7489: alinierea identificatorilor DMARC
• RFC 5321: Simple Mail Transfer Protocol (MAIL FROM)
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460: raportare TLS pentru SMTP
• RFC 8301: actualizarea algoritmilor criptografici și a utilizării cheilor pentru DKIM
• BIMI Group: ghid de implementare