Limita de 10 interogări SPF: diagnostic și flattening

Ce spune regula

SPF (RFC 7208) permite unui domeniu să enumere serverele care au voie să trimită e-mail folosindu-l ca expeditor de plic. Evaluarea unei înregistrări poate cere interogări DNS, iar o înregistrare ar putea înlănțui include-uri la nesfârșit, așa că §4.6.4 limitează munca. Termenii care provoacă interogări DNS sunt limitați la 10 per evaluare, iar depășirea limitei produce rezultatul permerror. Limita se aplică la destinatar, deci nu primiți niciun avertisment în momentul în care publicați înregistrarea.

Aceeași secțiune limitează și interogările vide: interogări DNS care nu returnează nicio înregistrare sau care vizează un nume inexistent. Mai mult de două astfel de interogări într-o singură evaluare înseamnă tot permerror, iar regula prinde include-urile care trimit către furnizori pe care nu îi mai folosiți. Așadar, un include uitat în înregistrare pentru un serviciu anulat poate strica SPF chiar dacă numărul total de interogări rămâne sub limită.

Ce se întâmplă când o depășiți

Un destinatar care atinge limita oprește evaluarea și returnează permerror. RFC 7208 tratează asta ca pe o problemă permanentă a înregistrării dumneavoastră, iar destinatarii o tratează în general ca pe un eșec. SPF eșuează atunci pentru fiecare mesaj, inclusiv pentru e-mailurile venite de la servere listate corect. Nu există reușită parțială: în clipa în care bugetul de interogări se epuizează, restul înregistrării nu mai este citit deloc.

Dacă aveți o politică DMARC activă, amploarea pagubei depinde de DKIM. Mesajele care poartă o semnătură DKIM aliniată trec în continuare de DMARC; cele care se bazau pe alinierea SPF eșuează și sunt puse în carantină sau respinse sub o politică de impunere. De aceea o înregistrare care a funcționat ani la rând se poate strica în ziua în care cineva adaugă încă un instrument de marketing. Echipa care face schimbarea nu este, de cele mai multe ori, aceeași cu echipa care îi suportă consecințele.

Diagnosticarea înregistrării dumneavoastră

Securitatea e-mailului rezolvă înregistrarea și fiecare include și redirect de pe serverul XGM. Afișează arborele, numără interogările așa cum o fac destinatarii, semnalează interogările vide și buclele și raportează ca avertisment înregistrările apropiate de limită, de la opt în sus. Folosiți-l înainte și după fiecare modificare a înregistrării. Așa nu mai trebuie să ghiciți cu cât a crescut numărul de interogări după o schimbare.

Puteți parcurge arborele și manual, cu dig. Interogați mai întâi înregistrarea rădăcină, apoi fiecare țintă include și numărați din nou. Pentru înregistrări mari este o muncă obositoare, dar arată exact de unde vin interogările. Dacă salvați rezultatul într-un fișier text, comparația dintre doi arbori devine simplă la următorul audit.

dig +short TXT example.com
"v=spf1 include:_spf.mail.example.net include:esp.example.net mx -all"

dig +short TXT _spf.mail.example.net
"v=spf1 include:_spf1.mail.example.net include:_spf2.mail.example.net ~all"

Auditul unei înregistrări, pas cu pas

Luați o înregistrare care a crescut de-a lungul anilor pentru example.com. SPF Checker raportează 12 interogări și permerror, deci orice mesaj care se bazează pe SPF eșuează în acest moment. Tabelul de mai jos enumeră fiecare termen cu interogările pe care le costă, inclusiv cele imbricate, și ce a găsit auditul. Scopul nu este să coborâți numărul cât mai jos, ci să păstrați sursele care chiar trimit e-mail și să le scoateți pe celelalte.

După modificări, înregistrarea rădăcină folosește patru interogări, toate de la furnizorul de căsuțe poștale, iar subdomeniul de newsletter are propria înregistrare, cu două. Formularul de contact funcționează în continuare printr-un termen ip4 fix. Nimic nu a fost aplatizat, așa că schimbările furnizorilor ajung mai departe în mod automat. Cum la rădăcină rămâne o rezervă de șase interogări, nu va fi nevoie să refaceți înregistrarea de la zero când se adaugă următorul instrument.

example.com.       IN TXT "v=spf1 include:_spf.mail.example.net ip4:192.0.2.80 -all"
news.example.com.  IN TXT "v=spf1 include:esp.example.net -all"

Înainte de a elimina un include, confirmați în rapoartele agregate DMARC că serviciul fie nu mai trimite, fie trece prin DKIM aliniat. Ghidul rapoartelor agregate arată cum se citesc acele rânduri. Eliminați-le pe rând, nu pe toate deodată, ca să identificați imediat cauza dacă ceva se strică.

SPF pentru numele HELO și pentru serverele care nu trimit e-mail

RFC 7208 definește și verificări SPF pentru numele HELO sau EHLO pe care un server îl folosește când se conectează. Destinatarii folosesc această identitate atunci când expeditorul de plic este gol, ca în mesajele de eroare returnate. Publicarea unei înregistrări mici pentru numele fiecărui server de e-mail nu vă costă nimic și menține aceste verificări trecute. Un server care cade la verificarea HELO primește, la unii destinatari, o evaluare antispam mai severă.

mail.example.com. IN TXT "v=spf1 a -all"

Numele de gazdă care nu trimit niciodată e-mail pot publica v=spf1 -all. Aici intră serverele web și alte subdomenii care apar în DNS, dar care nu au niciun motiv să fie folosite ca expeditor. Aceste înregistrări stau pe propriile nume, deci nu consumă nimic din bugetul de interogări al domeniului rădăcină. Tocmai aceste subdomenii uitate sunt alese, de cele mai multe ori, ca expeditor fals în încercările de phishing.

Soluții care nu au nevoie de flattening

1. Eliminați ce nu mai folosiți

Înregistrările vechi adună include-uri pentru instrumente anulate acum câțiva ani. Comparați fiecare include cu inventarul dumneavoastră de expeditori și cu sursele din rapoartele agregate DMARC. Un include care nu apare luni de-a rândul ca sursă care trece este un candidat la eliminare. Dacă nu sunteți sigur, amânați decizia un trimestru; dacă rapoartele rămân tăcute, îl puteți scoate liniștit.

2. Renunțați la mx și a acolo unde nu sunt necesare

mx autorizează serverele dumneavoastră de e-mail de intrare să trimită, ceea ce este corect doar dacă ele chiar trimit e-mail spre exterior. Mulți furnizori de căsuțe poștale găzduite livrează e-mailul de ieșire de pe alte servere, acoperite deja de propriul lor include. Eliminarea unui mx sau a inutil economisește câte o interogare de fiecare dată. Înainte de a le elimina, verificați în jurnale că serverele de intrare nu au trimis nimic spre exterior în ultimele luni.

3. Lăsați furnizorii să folosească propriul domeniu de bounce

SPF se verifică pe expeditorul de plic (return-path), nu pe adresa From vizibilă. Dacă un furnizor trimite cu o adresă de bounce pe propriul domeniu sau pe un subdomeniu precum bounces.example.com, SPF este evaluat pentru acel domeniu, iar înregistrarea dumneavoastră rădăcină nu mai are deloc nevoie de include-ul furnizorului. DMARC trece atunci prin DKIM semnat cu domeniul dumneavoastră. De aceea, când alegeți un furnizor nou, întrebați de la început dacă poate folosi propriul domeniu de bounce.

4. Împărțiți trimiterile pe subdomenii

Fiecare domeniu are propria înregistrare SPF și propriul buget de 10 interogări. Mutarea newsletterelor pe news.example.com și a chitanțelor pe billing.example.com scoate include-urile lor din înregistrarea rădăcină. Fiecare subdomeniu are apoi nevoie de propria configurare DKIM și moștenește politica DMARC organizațională. Împărțirea limpezește și raportarea, pentru că puteți urmări separat livrabilitatea fiecărui flux.

; before: 11 lookups at the root
example.com.       IN TXT "v=spf1 include:_spf.mail.example.net include:esp.example.net include:crm.example.net include:helpdesk.example.net mx -all"

; after: the mailbox provider stays at the root, other streams move
example.com.       IN TXT "v=spf1 include:_spf.mail.example.net -all"
news.example.com.  IN TXT "v=spf1 include:esp.example.net -all"
help.example.com.  IN TXT "v=spf1 include:helpdesk.example.net -all"

Flattening: cum funcționează și de ce este riscant

Flattening înlocuiește mecanismele include cu intervalele ip4 și ip6 la care se rezolvă în acel moment. Mecanismele de adresă nu se numără la limită, așa că o înregistrare aplatizată poate enumera mulți furnizori cu zero sau o singură interogare. Rezolvă problema numărătorii, dar copiază în DNS-ul dumneavoastră configurația altcuiva, ca un instantaneu. Odată aplatizată înregistrarea, menținerea intervalelor la zi devine responsabilitatea dumneavoastră, nu a furnizorului.

Furnizorii își schimbă intervalele de trimitere, uneori fără preaviz. O înregistrare aplatizată păstrează intervalele vechi, iar e-mailul de pe serverele noi cade la SPF până când cineva actualizează manual înregistrarea. Eșecul este tăcut: nimic din DNS nu vă spune că include-ul furnizorului s-a schimbat. Primul semn este, de obicei, reclamația unui utilizator că mesajele lui ajung în spam.

Dacă aplatizați, automatizați procesul. O sarcină programată ar trebui să rezolve include-urile originale, să compare intervalele cu înregistrarea publicată și să vă alerteze sau să actualizeze atunci când diferă. Păstrați include-urile pentru furnizorii care se schimbă des și aplatizați doar intervalele stabile pe care le controlați, cum sunt propriile dumneavoastră servere. Scrieți scriptul astfel încât să păstreze un istoric al modificărilor, ca să puteți urmări ulterior când a intrat fiecare interval în înregistrare.

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip4:203.0.113.0/24 " "ip6:2001:db8:10::/48 ip6:2001:db8:20::/48 include:_spf.mail.example.net -all"

Macrouri și servicii de găzduire SPF

Unele servicii ocolesc limita cu mecanismul exists și cu macrouri SPF. Înregistrarea conține un termen de forma exists:%{i}._spf.service.example.net, iar serviciul răspunde, pentru fiecare IP expeditor, dacă acesta este permis. Evaluarea costă o singură interogare, indiferent câți furnizori stau în spatele ei. Înregistrarea rămâne astfel fixă; chiar dacă lista de expeditori se schimbă, nu trebuie să actualizați nimic în propriul DNS.

Astfel, lista serverelor dumneavoastră autorizate se mută în DNS-ul unui terț. Poate fi o alegere rezonabilă pentru organizațiile mari, dar acceptați dependența în cunoștință de cauză: dacă serviciul pică sau este configurat greșit, SPF eșuează pentru tot e-mailul dumneavoastră. Macrourile fac în plus înregistrarea mai greu de citit și de auditat, inclusiv pentru instrumente precum SPF Checker, care numără interogarea, dar nu pot vedea lista din spatele ei. Gândiți-vă din start la planul de ieșire, pentru că într-o zi, dacă părăsiți serviciul, va trebui să mutați lista înapoi în propria înregistrare.

Urmărirea schimbărilor pe care nu le-ați făcut dumneavoastră

Include-urile sunt referințe vii. Când un furnizor își reorganizează propria înregistrare SPF, adăugând un include regional sau un interval nou de partener, numărul dumneavoastră se schimbă la următoarea evaluare făcută de un destinatar. Nu primiți nicio notificare, iar primul semn poate fi un raport DMARC plin de eșecuri SPF. Faptul că nu v-ați atins de propria înregistrare nu înseamnă, așadar, că numărul de interogări a rămas același.

O măsură simplă de siguranță este verificarea programată a numărului de interogări. Rulați evaluarea SPF zilnic, dintr-un script sau din sistemul de monitorizare, și alertați când numărul ajunge la opt sau când rezultatul nu este pass pentru un IP expeditor cunoscut. API-ul XGM returnează numărul în format JSON, ceea ce face ușoară legarea lui de monitorizarea existentă. Rularea verificării dintr-un loc independent de propria infrastructură de e-mail vă asigură că primiți alerta și atunci când aceasta cade.

count=$(curl -s -H 'Accept: application/json' https://xgm.ro/api/v1/spf/example.com | python3 -c 'import sys, json; print(json.load(sys.stdin)["lookups"])')
if [ "$count" -ge 8 ]; then echo "SPF for example.com uses $count of 10 lookups"; fi

Păstrați o copie a întregului arbore de include-uri de la fiecare verificare. Când numărul sare, compararea a doi arbori arată imediat care furnizor s-a schimbat și dacă schimbarea este permanentă sau o greșeală de partea lor, care merită semnalată. Arborii salvați vă oferă și o dovadă concretă în corespondența cu furnizorul.

Cum rămâneți sub limită

• Adăugați o verificare SPF în procesul de integrare a furnizorilor: care include, câte interogări și dacă DKIM cu domeniul dumneavoastră face include-ul inutil.
• Rulați Securitatea e-mailului după fiecare modificare DNS și păstrați cel puțin două interogări de rezervă.
• Revizuiți trimestrial rapoartele agregate DMARC și eliminați include-urile care nu mai trimit.
• Preferați alinierea DKIM pentru DMARC; SPF este un al doilea strat, nu fundamentul.
• Documentați de ce există fiecare include, într-un comentariu din depozitul DNS sau în jurnalul de modificări.

SPF mai are o a doua protecție, ușor de uitat: este permisă o singură înregistrare SPF pentru un nume. Două înregistrări TXT care încep cu v=spf1 produc permerror la fel ca prea multe interogări și apar deseori când două echipe adaugă furnizori independent una de alta. Ghidul SPF acoperă celelalte erori de sintaxă frecvente. Aceeași regulă se aplică și subdomeniilor; fiecare nume este supus separat regulii unei singure înregistrări.

Întrebări frecvente

Surse

• RFC 7208: Sender Policy Framework, §4.6.4 limitele de interogări DNS
• RFC 7208 §3.4: Dimensiunea înregistrării
• RFC 7208 §5.5: Mecanismul ptr (nu îl folosiți)
• RFC 7489: DMARC
• RFC 5737: Blocuri de adrese IPv4 rezervate pentru documentație