Defaults.Exposed › Rapoarte

De ce eșuează SPF-ul meu? Problema celor 10 interogări DNS în mediile SaaS pentru expeditorii din UK și UE (2026)

Publicat 2026-07-09

Date la 2026-06-29 · metodologie v7. Date agregate din recensământ pe 261 milioane de domenii evaluate. Vezi cum evaluăm.

Când SPF eșuează pentru o companie care utilizează instrumente SaaS în UK sau UE, cea mai probabilă cauză este o singură regulă RFC la care nu a trebuit niciodată să te gândești: după depășirea a 10 interogări DNS, SPF nu returnează „fail” — returnează PermError, ceea ce înseamnă că înregistrarea este tratată ca și cum nu ar exista. Cel puțin 797,263 domenii au depășit deja această limită. Alte 2,119,539 se află exact la 9–10 interogări — un singur instrument nou le separă de aceeași prăpastie.

De ce eșuează SPF când adaugi un instrument SaaS?

SPF funcționează prin listarea serverelor de mail autorizate să trimită în numele domeniului tău. Companiile moderne nu operează propriile servere de mail — folosesc Google Workspace pentru email intern, Mailchimp pentru campanii, HubSpot pentru secvențe de vânzări, Pipedrive pentru outreach CRM. Fiecare platformă îți oferă un rând include: pe care să-l lipești în DNS.

Problema: fiecare include: este în sine o interogare DNS. Și fiecare înregistrare din interiorul acelui include poate declanșa mai multe interogări recursiv. RFC 7208 §4.6.4 stabilește un prag dur de zece. Dincolo de zece, serverul de mail receptor oprește evaluarea și returnează PermError — iar un PermError nu este un eșec moale care ajunge în spam. Înseamnă că înregistrarea ta SPF este tratată ca absentă. Autentificarea emailului eșuează la etapa SPF.

Nu vei vedea acest lucru în panoul tău DNS. Contorul se activează doar în timpul evaluării live. Poți avea trei rânduri include: în înregistrarea vizibilă și să fii totuși la doisprezece interogări în adâncime, deoarece înregistrarea SPF a fiecărui furnizor trage propriile sub-include.

Câte domenii au depășit deja limita?

Cel puțin 797,263. Acesta este numărul după ce am rezolvat fiecare țintă SPF include: referențiată de 100 sau mai multe ori — 10,842 ținte distincte acoperind 95.2% din toate referințele include — și am calculat prețul întregului lanț al fiecărui domeniu. Numărul de suprafață (ce ai găsi numărând doar rândurile vizibile dintr-o înregistrare) găsește aproximativ 7,958. Cifra calculată pe lanț este de 100 ori mai mare, deoarece aproape toate daunele sunt invizibile în interiorul țintelor include.

Situația care afectează cel mai probabil o companie europeană:

Furnizorii europeni de hosting și setările implicite slabe SPF

Furnizorul de hosting cu care ai început contează — deoarece unii setează valori implicite SPF care consumă deja câteva din cele zece interogări ale tale înainte să conectezi vreun instrument SaaS.

Dintre cei mai mari furnizori de hosting utilizați de domeniile europene din recensământul nostru:

IONOS se remarcă: 1.0% din domeniile găzduite de IONOS au DMARC impus, ceea ce înseamnă că marea majoritate nu are nicio autentificare semnificativă a expeditorului. Domeniile OVH se descurcă mai bine la setarea strictă SPF (43.7%), dar tot scad la 2.2% la impunerea DMARC — SPF singur, fără DMARC care să-l lege de antetul From:, protejează doar plicul, nu ceea ce vede destinatarul.

Microsoft 365 este excepția pozitivă: 85.0% din domeniile găzduite de Microsoft folosesc SPF strict, în mare parte deoarece expertul de flux de mail Microsoft setează -all implicit. Google Workspace setează ~all (softfail) implicit, lăsând 92% din domeniile sale fără protecție strictă.

Cum să diagnostichezi eșecul SPF în mai puțin de 60 de secunde

Cea mai rapidă verificare este un instrument gratuit care evaluează întregul lanț de interogări — nu doar înregistrarea vizibilă. Rulează nslookup -type=TXT domeniultau.com în linia de comandă și numără fiecare include: pe care îl vezi. Apoi caută fiecare dintre acele înregistrări și numără-le pe ale lor. Dacă rămâi fără degete înainte să rămâi fără include, ești în zona de pericol.

O abordare mai fiabilă: verifică-ți domeniul aici — scanerul evaluează întregul lanț rezolvat, semnalează PermError și îți arată care mecanisme consumă bugetul de interogări.

Trei rezultate diagnostice:

• PermError — deja depășești zece. Fiecare email pe care îl trimiți eșuează verificarea SPF la destinatar.
• La 9–10 interogări — ești pe marginea prăpastiei. Următoarea integrare SaaS te va împinge peste limită.
• Softfail (~all) în loc de hardfail (-all) — ești sub limită, dar înregistrarea este setată prea permisiv pentru a oferi protecție reală. Vezi raportul privind configurarea greșită SPF pentru imaginea completă despre -all vs ~all.

Cum să repari SPF când folosești mai multe instrumente SaaS

Există trei abordări, în ordinea permanenței:

1. Audit și curățare. Începe prin listarea fiecărui include: din înregistrarea ta actuală. Elimină orice platformă pe care nu o mai folosești — ESP-uri vechi, instrumente CRM din contracte anterioare, platforme pe care le-ai testat dar le-ai abandonat. Acest lucru este gratuit și adesea recuperează mai multe interogări. Fiecare include: eliminat poate elimina 1–3 sub-interogări.

2. Aplatizarea înregistrării SPF. Aplatizarea SPF rezolvă toate țintele include: în intervalele lor de adrese IP de bază și le scrie direct în înregistrarea ta ca mecanisme ip4: și ip6:. Mecanismele IP nu declanșează interogări, deci o înregistrare aplatizată poate lista zeci de surse de trimitere și să rămână totuși la zero interogări. Dezavantajul: trebuie să reaplatizezi ori de câte ori un furnizor își actualizează adresele IP de trimitere, ceea ce se întâmplă fără notificare. Majoritatea companiilor folosesc un serviciu plătit de aplatizare SPF (PowerDMARC, EasyDMARC, Dmarcian și alții oferă acest lucru) sau construiesc un flux de lucru de monitorizare.

3. Utilizarea macrocomenzilor SPF. Macrocomenzile RFC 7208 îți permit să construiești înregistrări care efectuează o singură interogare DNS per verificare și răspund dinamic, în loc de un lanț de include. Macrocomenzile necesită suport pentru hosting DNS și un anumit efort de implementare, dar reprezintă soluția arhitectural curată pentru organizațiile cu mulți expeditori SaaS.

După repararea SPF, asociaz-o cu impunerea DMARC — SPF fără DMARC autentifică doar expeditorul plicului, nu adresa From: din antet pe care o văd destinatarii.

Întrebări frecvente

De ce înregistrarea mea SPF trece verificarea în instrumentul DNS, dar tot eșuează în antetele emailului? Majoritatea instrumentelor de căutare DNS numără doar mecanismele vizibile din propria ta înregistrare, nu sub-interogările pe care acele mecanisme le declanșează. Poți avea două rânduri include: și să fii totuși peste limită dacă înregistrarea fiecărui furnizor conține câteva în plus. Doar un instrument de calculare a lanțului (sau un server de mail receptor) numără întreaga adâncime. Verifică-ți domeniul pentru a vedea numărul real din lanț.

Înseamnă eșecul SPF că emailurile mele ajung în spam? PermError (prea multe interogări) înseamnă că etapa SPF a autentificării returnează un non-rezultat — efectiv absent. DMARC evaluează atât SPF, cât și DKIM; dacă DKIM trece, DMARC poate totuși trece în ciuda PermError SPF. Dacă niciunul nu trece, DMARC eșuează, iar rezultatul depinde de politica ta DMARC. La p=none, emailul se livrează totuși, dar eșecul este înregistrat. La p=quarantine sau p=reject, emailul este filtrat sau respins. Repară SPF pentru a nu te baza exclusiv pe DKIM.

Câte interogări folosește un set tipic de instrumente SaaS? Înregistrarea SPF p99 din recensământul nostru se află deja la 9 interogări — chiar la limită — înainte de a adăuga ceva. O înregistrare Google Workspace adaugă 3–4 interogări; Mailchimp adaugă 1–2; HubSpot adaugă 1–3 în funcție de configurația lor actuală. Trei instrumente mainstream plus valoarea implicită a furnizorului tău de hosting sunt adesea suficiente pentru a depăși zece.

Este aplatizarea SPF sigură? Da, cu condiția să o menții actualizată. Aplatizarea convertește lanțurile include: în intervale IP statice — dacă un furnizor își rotește adresele IP de trimitere și tu nu reaplatizezi, vei începe să respingi mailul lor. Majoritatea organizațiilor folosesc un serviciu de aplatizare gestionat care monitorizează modificările IP în loc să o mențină manual.

SPF-ul meu a fost astfel configurat ani de zile — de ce eșuează brusc acum? Deoarece furnizorii tăi și-au actualizat înregistrările SPF, nu ale tale. De fiecare dată când o platformă SaaS adaugă un nou interval de adrese IP de trimitere sau înglobează un alt include, costul lanțului crește fără nicio modificare din partea ta. Limita de 10 interogări este evaluată live la primirea mesajului, deci o modificare a unui furnizor marți dimineața îți poate strica SPF-ul marți după-amiaza.

Repararea SPF îmbunătățește livrabilitatea emailului? Elimină o sursă de eșec al autentificării, care este o condiție prealabilă pentru livrarea consecventă — mai ales că Google și Yahoo impun acum alinierea DMARC pentru expeditorii în masă. SPF singur nu reprezintă imaginea completă: asociaz-o cu DKIM și DMARC pentru autentificarea completă a emailului.

Verifică-ți SPF-ul gratuit

Dacă nu ești sigur că înregistrarea ta SPF depășește limita de interogări — sau este setată prea slab pentru a-ți proteja domeniul — efectuează o verificare gratuită. Evaluează întregul lanț rezolvat și îți arată exact unde este cheltuit bugetul.

Verifică-ți domeniul → · Repară SPF → · Raportul SPF PermError → · Raport privind configurarea greșită SPF → · Modelul de maturitate al adoptării SPF → · Repară DMARC → · Numai date agregate. Date stocate și procesate în UE.