Runbook SPF „Too Many DNS Lookups”: Curățarea autentificării de email pentru hosturi mici

Dacă gestionezi infrastructura de email pentru o afacere mică sau pentru un client de hosting, probabil te-ai lovit de faimoasa eroare „SPF PermError: too many DNS lookups”. Această respingere nu înseamnă că serverul tău a fost compromis sau că domeniul este pe un blacklist. Înseamnă pur și simplu că înregistrarea ta SPF (Sender Policy Framework) a devenit o mizerie supraîncărcată de declarații include: third-party, care depășește limita strictă și aplicată global de 10 lookup-uri DNS.

De fiecare dată când adaugi un serviciu nou — Microsoft 365 pentru mailul zilnic, Mailchimp pentru newslettere, Mailgun pentru marketing sau un CRM precum Zendesk — toți îți spun „doar adaugă acest include în înregistrarea ta SPF”. Dacă urmezi aceste instrucțiuni orbește, garantezi că vei depăși limita. Când un server destinatar (precum Gmail sau Yahoo) interoghează recordul tău SPF, trebuie să rezolve fiecare cerere DNS imbricată (nested). Dacă atinge 11 lookup-uri, închide conexiunea, iar emailurile tale pică alinierea DMARC.

Acest runbook nu este despre teoria infrastructurii de email; este un ghid practic pentru disecarea unei înregistrări SPF invalide, identificarea lookup-urilor ascunse și aplicarea procesului de flattening, astfel încât emailurile tale tranzacționale și de marketing să ajungă efectiv în inbox.

Înțelegerea limitei de 10 lookup-uri

Specificația SPF (RFC 7208) există pentru a preveni email spoofing-ul. Aceasta dictează exact ce adrese IP sunt autorizate să trimită mailuri în numele domeniului tău. Pentru a preveni actorii malițioși din a crea bucle DNS infinite care ar putea bloca serverele de mail (o formă de atac Denial of Service), standardul RFC impune o limită hard: un maxim de 10 lookup-uri DNS pentru a rezolva întreaga politică SPF.

Mecanismele care consumă un lookup sunt include, a, mx, ptr și exists. Mecanismele ip4, ip6 și all nu necesită interogări DNS și nu se contorizează la această limită.

Capcana constă în interogările imbricate. Dacă incluzi Microsoft 365 (include:spf.protection.outlook.com), nu consumi doar un singur lookup. Înregistrarea Microsoft include alte înregistrări, care la rândul lor includ altele. Doar Microsoft consumă adesea două sau trei din cele zece interogări disponibile. Adaugă un tool de marketing și ai depășit instant marginea prăpastiei.

Diagnosticarea unei înregistrări SPF invalide

Să analizăm un record SPF tipic, dar invalid, al unei afaceri mici găzduite pe un server virtual. Administratorul își gestionează propriul server web, folosește Microsoft 365 pentru mailul corporate, trimite newslettere prin Mailchimp și procesează chitanțe tranzacționale prin SendGrid.

v=spf1 mx a include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net -all

La prima vedere, acest record pare să aibă cinci lookup-uri (mx, a și trei include-uri). Totuși, când îl treci printr-un verificator SPF sau îl parsezi manual cu dig, realitatea este mult mai gravă.

1. mx: 1 lookup.
2. a: 1 lookup.
3. include:spf.protection.outlook.com: Aceasta se rezolvă într-o altă înregistrare care conține include:spfa.protection.outlook.com și include:spfb.protection.outlook.com. Asta înseamnă 1 lookup pentru recordul principal, plus 2 pentru cele imbricate. Total: 3 lookup-uri.
4. include:servers.mcsv.net (Mailchimp): Aceasta se rezolvă adesea în mai multe include-uri sau recorduri A în funcție de rutele lor curente. Conservator, consumă 3 până la 4 lookup-uri.
5. include:sendgrid.net: Se rezolvă în multiple sub-înregistrări. De obicei consumă 2 până la 3 lookup-uri.

Acest record cumulează cu ușurință 10-12 lookup-uri. Orice email trimis de pe acest domeniu are un risc ridicat de a fi respins cu PermError. Când administrezi domenii pentru clienți (și reține că nu deții cu adevărat domeniul, doar îl închiriezi), eșecul în monitorizarea acestor limite va genera tichete de suport imediate atunci când facturile nu se mai livrează.

Pasul 1: Eliminarea mecanismelor redundante

Primul pas în curățarea unei înregistrări SPF este eliminarea mecanismelor care nu oferă nicio valoare. Sysadminii lasă adesea a și mx în record din inerție.

Dacă serverul tău web (înregistrarea A a domeniului tău) nu trimite emailuri direct, elimină mecanismul a. Dacă folosești Microsoft 365, înregistrările tale MX pointează către Microsoft, nu către propriul tău server. IP-urile Microsoft sunt deja acoperite de include:spf.protection.outlook.com. Prin urmare, mecanismul mx este complet redundant și irosește un lookup prețios.

Prin simpla ștergere a a și mx, recuperăm instant două lookup-uri DNS.

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net -all

Pasul 2: Înlocuirea Include-urilor cu adrese IPv4/IPv6 (SPF Flattening)

Deoarece mecanismele ip4 și ip6 nu necesită lookup-uri DNS, poți înlocui un include greoi cu range-urile IP directe ale furnizorului. Acest proces este cunoscut sub numele de SPF flattening.

De exemplu, dacă ai o adresă IP dedicată pe VPS-ul tău care trimite alerte de sistem, nu folosi a. Hardcodează IP-ul direct.

Dacă un furnizor de servicii are o listă statică și documentată public de subneturi IP (cum au mulți provideri de mail tranzacțional), poți interoga înregistrarea lor include și poți extrage IP-urile. Să presupunem că interoghezi un mailer mic ipotetic și descoperi că folosește două blocuri IPv4.

dig TXT _spf.smallmailer.com +short
"v=spf1 ip4:192.168.1.0/24 ip4:10.0.0.0/8 -all"

Poți elimina include:_spf.smallmailer.com (care costă 1 lookup) și îl poți înlocui cu ip4:192.168.1.0/24 ip4:10.0.0.0/8 (care costă 0 lookup-uri).

Avertisment: Nu face flattening manual pentru provideri masivi și dinamici precum Microsoft 365 sau Google Workspace. Ei își rotesc constant blocurile de IP-uri. Dacă le hardcodezi IP-urile și ei le schimbă, emailurile tale vor eșua imediat. Fă flattening doar pentru IP-uri statice, dedicate, sau folosește servicii automatizate de dynamic flattening pentru marii jucători.

Pasul 3: Segregarea fluxurilor de mail cu subdomenii

Cea mai robustă metodă, standardul în industrie pentru sysadmini, pentru a repara un SPF supraîncărcat este să oprești trimiterea tuturor tipurilor de mailuri de pe domeniul principal (root domain). Trebuie să îți segmentezi traficul. Domeniul principal ar trebui rezervat exclusiv pentru comunicarea corporate human-to-human (ex. Microsoft 365 sau Google Workspace).

Emailurile de marketing, chitanțele tranzacționale și replicile automate din CRM ar trebui mutate pe subdomenii dedicate. Limitele SPF se aplică per domeniu/subdomeniu. Un subdomeniu are propria sa limită separată de 10 lookup-uri.

În loc să pui totul pe @example.com, configurează infrastructura astfel:

Mail Corporate (Microsoft 365): @example.com

v=spf1 include:spf.protection.outlook.com -all

Mail de Marketing (Mailchimp): @news.example.com

v=spf1 include:servers.mcsv.net -all

Mail Tranzacțional (SendGrid): @receipts.example.com

v=spf1 include:sendgrid.net -all

Procedând astfel, domeniul principal folosește acum maximum 3 lookup-uri (doar Microsoft). Subdomeniile au spațiu din plin. Mai mult, dacă echipa ta de marketing distruge reputația subdomeniului news.example.com declanșând filtrele de spam, acest lucru nu va afecta livrabilitatea emailurilor CEO-ului trimise de pe domeniul principal.

Validarea corecției

După refactorizarea înregistrărilor, trebuie să validezi configurația folosind un tool precum dig sau un verificator SPF online. Nu ghici niciodată când vine vorba de autentificare DNS. O sintaxă invalidă va duce la drop-uri imediate ale mailurilor.

Dacă rulezi o verificare pe domeniul principal optimizat, output-ul ar trebui să confirme o rută curată cu hop-uri minime:

Result: Pass
Total Lookups: 3/10
Syntax: Valid
Mechanisms: 1 (include)

Gestionarea infrastructurii de email necesită o respectare strictă a standardelor RFC și o înțelegere clară a modului în care scalează DNS-ul. Dacă ajungi să citești termenii și condițiile de găzduire pentru a afla de ce providerul tău nu îți repară livrarea mailurilor, adevărul brutal este că gestionarea DNS este aproape întotdeauna responsabilitatea clientului. Curăță-ți înregistrările, segmentează-ți traficul, iar problemele tale de deliverability vor dispărea.