Defaults.Exposed › Remedieri › Guides

SPF PermError: Cum să remediați „Prea multe interogări DNS" fără a perturba e-mailul (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

Cel puțin 797,263 domenii depășesc limita de 10 interogări DNS a SPF, conform recensământului Defaults.Exposed pe 261,086,232 domenii — din 139 milioane de publicatori SPF. Dincolo de zece interogări, un receptor se oprește și returnează PermError: SPF-ul dvs. este nul, iar DMARC numără un PermError ca eșec.

Remedierea are o ordine strictă, iar cele mai multe ghiduri o inversează. Numărați interogările reale rezolvate; ștergeți include-urile inactive și nefolosite — aceasta singură remediază majoritatea înregistrărilor; mutați expeditorii în masă pe subdomenii cu propriul buget SPF; aplatizați doar ca ultimă soluție și doar cu re-aplatizare automată, deoarece aplatizarea statică se degradează și perturbă silențios livrarea.

Ce înseamnă „SPF PermError: prea multe interogări DNS”?

RFC 7208 §4.6.4 limitează fiecare verificare SPF la 10 interogări DNS. Dincolo de zece, receptorul se oprește și returnează PermError — întreaga înregistrare este tratată ca defectă, nu doar partea care depășește bugetul. Aceeași secțiune adaugă un al doilea plafon mai puțin cunoscut: cel mult 2 „interogări nule” (interogări care nu returnează răspuns sau NXDOMAIN), deci câteva intrări include: moarte pentru servicii anulate pot anula SPF-ul de sine stătător.

Consecința este mai gravă decât „fără SPF”: DMARC tratează un PermError ca un eșec SPF, deci un domeniu care își strică propriul SPF este neautentificat pe piciorul SPF al fiecărei evaluări DMARC. Dacă DKIM nu este configurat sau se defectează în tranzit, acel e-mail eșuează acum DMARC complet.

Un număr din recensământ arată cât de crudă este această modalitate de eșec: 112,215 domenii publică o înregistrare -all strictă care este nulă din cauza depășirii interogărilor — din cele 54,655,923 domenii care publică -all în total. Proprietarii lor au făcut partea grea — au ales terminarea strictă — și un include în plus a oprit întreaga înregistrare. Par stricți; sunt defecți. Pentru imaginea completă a datelor, consultați raportul SPF PermError.

De ce s-a stricat SPF-ul meu fără să fi schimbat nimic?

Deoarece bugetul este cheltuit în mare parte de înregistrările altora. Fiecare include: este evaluat recursiv, iar fiecare mecanism de interogare din interior se contabilizează față de cele zece ale dvs. O linie din panoul DNS poate costa patru sau cinci interogări odată rezolvată. Un furnizor mai cuibărește un include, și SPF-ul dvs. moare fără o singură modificare în zona dvs.

Platformele mari nu sunt problema: Google și Microsoft și-au aplatizat ambele propriul SPF — _spf.google.com și spf.protection.outlook.com se extind la liste simple de IP costând zero interogări interne (verificat față de DNS activ, iulie 2026). Exploziile din lumea reală vin din lanțuri de include ale panoului de găzduire cuibărite pe mai multe niveluri și din stivuirea onestă de SaaS — căsuță poștală plus newsletter plus CRM plus helpdesk, fiecare „doar un include”. Nimeni nu adaugă a unsprezecea interogare intenționat; ajunge ca sumă a deciziilor rezonabile. De aceea marginea abruptă este atât de aglomerată: 2,119,539 domenii stau la exact 9–10 interogări rezolvate — aproximativ 1 din 66 din toți publicatorii SPF, bine astăzi, nule în ziua în care cineva lipește un alt include. Înregistrarea SPF la percentila 99 se rezolvă deja la 9 interogări. Dacă stiva dvs. este intensivă în SaaS, ghidul SPF care eșuează pentru instrumente SaaS acoperă versiunea furnizor cu furnizor.

Care părți dintr-o înregistrare SPF contează ca interogări DNS?

Numărați totalul rezolvat, nu liniile vizibile. Patru include-uri pot fi patru sau paisprezece interogări.

Cum remediez „prea multe interogări DNS” fără a perturba e-mailul?

1. Rulați scanarea gratuită înainte de a atinge DNS-ul. Rezolvă întregul lanț de include și vă arată numărul real de interogări, astfel reparați problema reală — nu înregistrarea cum apare în panoul dvs. (Dacă spune că nu aveți deloc SPF, este un eșec diferit — consultați „Înregistrare SPF negăsită”.)
2. Ștergeți mai întâi include-urile inactive și nefolosite. Instrumentul pe care l-ați abandonat în 2023, include-ul vechii gazde care a supraviețuit unei migrări, duplicatele, orice mecanism ptr. Include-urile moarte sunt dublu toxice: consumă bugetul de interogări și sunt sursa obișnuită a interogărilor nule. Majoritatea înregistrărilor suprabugetate revin sub 10 numai în acest pas. Dacă înregistrarea dvs. mai conține mecanismele unui furnizor anterior, urmați ghidul de curățare a migrației.
3. Verificați dacă fiecare include rămas face ceva. Receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom), nu antetul From — și multe instrumente SaaS pun propriul domeniu de bounce pe Return-Path, deci include-ul lor în înregistrarea dvs. nu face nimic în afară de a cheltui bugetul. Păstrați include-uri doar pentru serviciile care folosesc domeniul dvs. ca Return-Path; pentru restul, activați în schimb DKIM cu domeniu personalizat al furnizorului.
4. Mutați expeditorii în masă pe subdomenii. Newsletter-uri din news.yourdomain.com, e-mailuri tranzacționale din mail.yourdomain.com. Fiecare subdomeniu primește propria înregistrare SPF cu un buget proaspăt de 10 interogări, iar o problemă dintr-un flux nu mai sângerează în celelalte.
5. Abia atunci luați în considerare aplatizarea — și doar aplatizarea automată. Vedeți mai jos.
6. Re-scanați pentru a confirma că sunteți confortabil sub 10 — urmăriți marja, nu exact 10, altfel v-ați alăturat din nou celor 2.1 milioane de domenii de la marginea abruptă. Apoi rezolvați orice altceva semnalează scanarea pe pagina corectați SPF.

Ar trebui să aplatizez înregistrarea SPF?

Aplatizarea înlocuiește include-urile cu blocurile subiacente ip4:/ip6:, care costă zero interogări. Funcționează — și realizată manual, este o întrerupere de livrare cu acțiune întârziată.

Furnizorii rotesc IP-urile de trimitere în mod regulat și nu anunță nimeni. O listă statică de IP-uri este corectă în ziua în care o lipiți și tăcut greșită în câteva luni — și deoarece eșecul apare ca alții care nu vă primesc e-mailul, aflați cu întârziere. Dacă eliminarea și subdomeniile vă aduc sub limită, opriți-vă acolo; nu copiați niciodată blocurile IP ale unui terț în înregistrarea dvs. ca soluție permanentă.

Întrebări frecvente

Un SPF PermError înseamnă că e-mailul meu nu mai este livrat? Nu imediat — de aceea este periculos. DMARC numără un PermError ca eșec SPF, deci livrarea depinde în totalitate de DKIM; dacă DKIM lipsește sau se defectează în tranzit, eșuați DMARC. Dintre 139 milioane de publicatori SPF din recensământul nostru (din 2026-06-29), cel puțin 797,263 se află în această stare — cei mai mulți fără să știe.

Înregistrarea mea are doar patru include-uri — cum poate depăși 10 interogări? Include-urile sunt numărate recursiv: tot ce se află în interiorul fiecărui include (și în interiorul include-urilor sale) este taxat din bugetul dvs., deci patru linii vizibile se pot rezolva în paisprezece interogări. Numărați cu un instrument de rezolvare, nu vizual — rezolvarea lanțurilor este modul în care raportul nostru PermError a găsit ~100× mai multe domenii defecte decât arată numărătorile de suprafață.

Îmi termin înregistrarea cu -all — sigur sunt protejat? Numai dacă înregistrarea se evaluează. Recensământul nostru (din 2026-06-29) a găsit 112,215 domenii ale căror înregistrări -all stricte sunt nule din cauza depășirii interogărilor. Un calificator strict pe o înregistrare PermError nu protejează nimic.

Limita este de 10 interogări per include sau pentru întreaga înregistrare? Întreaga evaluare: RFC 7208 §4.6.4 limitează verificarea completă la 10, plus cel mult 2 interogări nule. Fiecare subdomeniu are propria înregistrare și buget — de aceea funcționează pasul 4.

Intrările ip4 și ip6 contează spre limită? Nu — mecanismele IP nu costă nimic, ceea ce este exact motivul pentru care aplatizarea reduce numărul.

Trimiteți proprietarului raportul

Dacă reparați acest lucru pentru un client sau angajatorul dvs., terminați munca cu dovezi. Re-rulați scanarea gratuită după modificări și trimiteți raportul clasificat proprietarului afacerii: limbaj simplu, datat, PermError dispărut. Acesta este artefactul de care vor avea nevoie pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al clienților — diferența dintre „am schimbat niște înregistrări DNS” și un înainte-și-după documentat.

Verificați gratuit domeniul

Vedeți numărul real rezolvat de interogări — și orice altceva referitor la SPF, DKIM și DMARC — privat și numai pentru proprietar.

Verificați domeniul → · Corectați SPF → · SPF care eșuează pentru instrumente SaaS → · Configurați SPF pe GoDaddy → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.