SPF în practică: identificarea tuturor expeditorilor

Modulul 4: Livrabilitate: SPF, DKIM și DMARC în practică · Timp de citire: 12 minute

Obiectiv de învățare: După această lecție veți putea identifica toate serviciile care trimit e-mailuri în numele domeniului dumneavoastră, le veți putea reuni într-o singură înregistrare SPF, veți putea număra recursiv căutările până la limita de zece și veți putea alege în cunoștință de cauză între ~all și -all.

Noțiuni cheie: inventarul expeditorilor, expeditorul de pe plic (envelope sender, Return-Path), o singură înregistrare SPF, include, redirect, limita de 10 căutări DNS (RFC 7208 paragraful 4.6.4), căutări fără rezultat (void lookups, maximum 2), numărare recursivă, permerror, flattening, SPF pentru subdomenii, SPF pe un domeniu care nu trimite e-mailuri, ~all și -all

O scurtă recapitulare

O înregistrare SPF este o înregistrare TXT pe domeniul dumneavoastră care începe cu v=spf1 și enumeră ce servere au voie să trimită e-mailuri în numele domeniului dumneavoastră. Structura, caracterele + - ~ ? și cele trei greșeli cele mai cunoscute (două înregistrări, +all, mai mult de zece căutări) sunt explicate în cursul de DNS, lecția 4.3. Citiți mai întâi acea lecție dacă SPF este un subiect nou pentru dumneavoastră. Această lecție tratează partea dificilă: în practică, aproape nimeni nu știe cu exactitate cine trimite e-mailuri în numele domeniului său.

Pasul 1: inventarul

SPF funcționează doar dacă toți expeditorii sunt incluși. Dacă uitați unul, e-mailurile acestuia vor ajunge în spam sau vor fi refuzate de îndată ce înăspriți DMARC. Parcurgeți așadar această listă. La o companie mică obișnuită veți găsi rapid cinci sau șase:

Două metode bune pentru a-i identifica:

1. Citirea antetelor. Trimiteți-vă din fiecare sistem un e-mail (o factură, o resetare de parolă, un newsletter de test) și verificați în antete câmpurile Return-Path și Authentication-Results (lecția 1.5). Acolo veți vedea prin ce domeniu și ce server a sosit.
2. Rapoartele DMARC. Setați DMARC pe p=none cu o adresă pentru rapoarte (lecția 4.4). După câteva săptămâni veți vedea în rapoarte (lecția 4.5) fiecare server care a trimis e-mailuri în numele domeniului dumneavoastră, inclusiv cele pe care le uitaserăți. Acesta este cel mai de încredere inventar.

Nu orice serviciu trebuie să apară în SPF-ul dumneavoastră

Aici apar adesea erori. SPF verifică expeditorul de pe plic (Return-Path), nu adresa de la câmpul De la. Multe servicii de newsletter și de trimitere expediază cu un Return-Path pe propriul lor domeniu, de exemplu bounce-123@mail.mailer.example. Destinatarul verifică atunci înregistrarea SPF a domeniului mailer.example, nu pe a dumneavoastră. O instrucțiune include pentru acel serviciu în înregistrarea dumneavoastră nu face atunci nimic, decât să consume o căutare.

Ceea ce îi trebuie de fapt acelui serviciu pentru a trece de DMARC este o semnătură DKIM cu domeniul dumneavoastră (lecția 4.3) sau un subdomeniu propriu de Return-Path, al dumneavoastră (de exemplu bounce.example.com ca înregistrare CNAME către serviciul respectiv). Citiți așadar în documentația serviciului ce vă solicită. Dacă spune "adăugați include: în SPF-ul dumneavoastră", faceți acest lucru. Dacă spune doar "creați aceste înregistrări CNAME pentru DKIM și domeniul de bounce", atunci nu trebuie modificat nimic în înregistrarea dumneavoastră principală. Modulul 7 revine pe larg asupra acestui subiect.

Pasul 2: o singură înregistrare, și numărare corectă

Toți expeditorii merg într-o singură înregistrare. Să presupunem că inventarul dumneavoastră arată astfel: serverul de e-mail al furnizorului dumneavoastră de găzduire, Microsoft 365 pentru câțiva angajați, programul dumneavoastră de contabilitate și un helpdesk. Atunci înregistrarea devine, de exemplu:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Câte căutări reprezintă acest lucru? Numărați fiecare a, mx, include, exists, ptr și redirect și numărați apoi și tot ce se află în înregistrările din spatele fiecărui include:

La 11, destinatarul returnează o eroare de tip permerror: întreaga înregistrare SPF nu mai contează atunci, pentru niciun expeditor. E-mailurile trimise de pe propriul dumneavoastră server de e-mail vor fi astfel evaluate mai prost pentru că helpdesk-ul consumă trei căutări. Iar partea înșelătoare este că înregistrarea dumneavoastră poate fi astăzi 9 și mâine 11, fără ca dumneavoastră să fi schimbat ceva, pur și simplu pentru că un serviciu și-a extins propria înregistrare.

În plus: maximum două căutări fără rezultat

RFC 7208 menționează și void lookups: căutări care nu produc niciun rezultat (numele nu există sau nu are înregistrare SPF ori de adresă). Mai mult de două astfel de căutări duc de asemenea la o eroare permerror. Acest lucru se întâmplă mai ales cu include-uri vechi, provenite de la servicii pe care nu le mai folosiți și care și-au eliminat înregistrarea, sau cu un a: către un server care nu mai există. Așadar, faceți curățenie.

Pasul 3: revenirea sub limita de zece

Dacă depășiți zece, există patru soluții, de la cea mai bună la cea mai puțin recomandată:

1. Eliminați ce nu este necesar. Servicii pe care nu le mai folosiți. Servicii care trimit cu propriul lor Return-Path (vezi mai sus) și care, prin urmare, nu trebuie să apară în SPF-ul dumneavoastră. a, dacă site-ul dumneavoastră web nu trimite el însuși e-mailuri. mx, dacă MX-ul dumneavoastră indică spre un serviciu care deja apare cu un include în înregistrarea dumneavoastră.
2. Folosiți un subdomeniu. Lăsați un serviciu să trimită de pe nieuws.example.com sau factuur.example.com. Acel subdomeniu primește propria sa înregistrare SPF, care conține doar acel serviciu, și nu contează în cele zece ale domeniului dumneavoastră principal. Alinierea în DMARC (lecția 4.4) funcționează implicit și pentru subdomenii.
3. Folosiți ip4: și ip6: pentru propriile dumneavoastră servere fixe. Acestea nu costă nicio căutare. Faceți acest lucru doar pentru adresele pe care le gestionați dumneavoastră și care nu se schimbă.
4. Flattening (înlocuirea tuturor includes cu adresele IP aflate în prezent în spatele lor). Acest lucru reduce numărul la 0, dar înregistrarea nu mai este corectă de îndată ce un serviciu își schimbă adresele, iar serviciile mari fac acest lucru în mod regulat. Faceți acest lucru doar cu un instrument care actualizează automat, iar de preferință deloc.

redirect sau include?

redirect= spune: folosiți înregistrarea SPF a acelui alt domeniu în loc de aceasta. Costă o singură căutare, la fel ca un include. Este util dacă aveți multe domenii care trebuie să primească exact aceeași politică: v=spf1 redirect=_spf.example.com pe fiecare domeniu, iar înregistrarea reală într-un singur loc. O înregistrare cu redirect= nu poate avea all, deoarece atunci redirect-ul este ignorat. Chiar Gmail îl folosește: gmail.com are v=spf1 redirect=_spf.google.com.

Pasul 4: ~all sau -all?

Recomandarea acestui curs, identică cu cea din cursul de DNS:

• Începeți cu ~all (softfail). E-mailurile de pe un server care nu apare în înregistrarea dumneavoastră sunt considerate suspecte, dar de obicei nu sunt refuzate imediat. Dacă uitați un expeditor, prejudiciul este limitat.
• Treceți la -all (fail) când sunteți sigur că toți expeditorii sunt incluși, de exemplu după ce ați analizat câteva săptămâni rapoartele DMARC și nu mai există surse necunoscute.

Împreună cu DMARC, diferența este mai mică decât se crede adesea. DMARC decide pe baza principiului "SPF sau DKIM a reușit și este aliniat". Un softfail înseamnă pentru DMARC pur și simplu "nereușit". Protecția reală provine așadar dintr-o politică DMARC strictă, nu din -all. Unii destinatari refuză deja la -all, înainte de evaluarea DMARC; acesta este un motiv pentru a alege -all abia atunci când înregistrarea dumneavoastră este cu adevărat completă.

Un domeniu care nu trimite niciodată e-mailuri

Aveți domenii care nu trimit niciodată e-mailuri (un nume de marcă vechi, un domeniu pentru greșeli de tastare)? Protejați-le atunci împotriva utilizării abuzive cu:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Aici -all este corect chiar de la început: nimeni nu are voie să trimită e-mailuri. Ultima linie este un null MX (RFC 7505): "acest domeniu nu primește e-mailuri". Chiar example.com este configurat exact așa.

În practică: cum arată într-un panou

La un pachet de găzduire WebOké este implicit setat v=spf1 a mx include:webawere.nl ~all. Dacă adăugați un serviciu, modificați această înregistrare (în DirectAdmin: DNS Management, creionul din dreptul înregistrării SPF, câmpul Include Domain; în Contul meu WebOké: asistentul SPF din fila DNS). Lăsați include:webawere.nl atâta timp cât e-mailul sau site-ul dumneavoastră funcționează prin acele servere. La alți furnizori, include-ul implicit are un alt nume, dar principiul este același: completați, nu creați o a doua înregistrare.

Rezumat

• Faceți mai întâi un inventar al tuturor expeditorilor; rapoartele DMARC și antetele vă ajută în acest sens.
• Un serviciu cu propriul Return-Path nu trebuie inclus în SPF-ul dumneavoastră; acesta are nevoie de DKIM cu domeniul dumneavoastră.
• Numărați recursiv: fiecare include, a, mx, exists, ptr și redirect, inclusiv în interiorul includes. Peste zece, sau mai mult de două căutări fără rezultat, înseamnă permerror.
• Reveniți sub limita de zece prin curățare și utilizarea subdomeniilor; flattening doar cu întreținere automată.
• Începeți cu ~all, treceți la -all când sunteți sigur. Domeniile care nu trimit niciodată e-mailuri: -all, DMARC reject și null MX.

Quiz

Exercițiu

Exercițiu Z4.2: Numărarea recursivă a SPF-ului domeniului dumneavoastră. Introduceți propriul dumneavoastră domeniu (sau sidn.nl dacă nu aveți un domeniu propriu). Numărați mai întâi dumneavoastră câte căutări DNS costă înregistrarea SPF, inclusiv tot ce se află în interiorul includes, și introduceți numărul, împreună cu terminația înregistrării (~all, -all, ?all sau +all). Programul numără în timp real pentru verificare, inclusiv căutările fără rezultat, și afișează arborele.

Exercițiu O4.2: Inventarul dumneavoastră de expeditori. Folosind tabelul din această lecție, întocmiți o listă cu toate sistemele care trimit e-mailuri în numele domeniului dumneavoastră. Notați pentru fiecare: prin ce server sau serviciu, dacă trebuie să apară în SPF-ul dumneavoastră (cu Return-Path propriu sau nu) și dacă semnează cu DKIM folosind domeniul dumneavoastră. Trimiteți-vă din cel puțin două sisteme câte un e-mail de test și notați din antete domeniul Return-Path și domeniul DKIM (d=).

Pentru aprofundare

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.

• Curs gratuit de DNS 4.3: SPF: cine are voie să trimită e-mailuri în numele domeniului dumneavoastră?
• Manual DirectAdmin 5.7: Configurarea și completarea SPF
• Modul de funcționare a înregistrării SPF în DNS Înregistrarea SPF (Sender Policy Framework) este o înregistrare de tip TXT în DNS, prin care specificați ce servere de e-mail au permisiunea să trimită mesaje în numele domeniului dumneavoastră. Astfel, serverele de primire a e-mailurilor pot verifica dacă un mesaj provine într-adevăr de la o sursă autorizată sau dacă este posibil să fie vorba de spam ori phishing. Când cineva trimite un e-mail, serverul de primire verifică înregistrarea SPF din DNS pentru domeniul expeditorului. Dacă adresa IP a serverului de trimitere se regăsește în lista din înregistrarea SPF, mesajul este considerat valid. În caz contrar, mesajul poate fi marcat drept spam sau respins, în funcție de setările serverului de primire. O înregistrare SPF arată, de exemplu, astfel: v=spf1 include:_spf.webokee.com ~all În acest exemplu: - v=spf1 indică versiunea SPF utilizată. - include:_spf.webokee.com specifică faptul că serverele incluse în acest domeniu au permisiunea de a trimite e-mailuri în numele dumneavoastră. - ~all indică modul în care trebuie tratate mesajele provenite de la servere neautorizate (în acest caz, un avertisment ușor, denumit „soft fail”). Dacă utilizați mai multe servicii de e-mail, este important să combinați toate sursele autorizate într-o singură înregistrare SPF, deoarece sunt permise doar una sau mai multe înregistrări TXT de tip SPF per domeniu, dar o singură linie v=spf1 funcțională. Dacă doriți ajutor la configurarea sau verificarea înregistrării SPF pentru domeniul dumneavoastră, echipa noastră de asistență vă stă cu plăcere la dispoziție.
• Adăugarea sau modificarea înregistrării SPF în DirectAdmin
• Manual WebOké 5.5: Asistenți DNS: MX, SPF, DMARC, CAA și SRV
• RFC 7208 (SPF), paragraful 4.6.4 (limite) și 6.1 (redirect); RFC 7505 (null MX)