Defaults.Exposed › Remedieri › Guides

„Înregistrare SPF negăsită" — dar aveți una? Cele 5 cauze reale (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.

Dacă un verificator spune „SPF record not found” (înregistrare SPF negăsită), dar sunteți sigur că ați publicat una, înregistrarea este de obicei invizibilă, nu lipsă: 1,013,416 domenii — aproximativ una din 138 dintre cele care încearcă SPF — publică două sau mai multe înregistrări SPF, o eroare PermError (RFC 7208 §3.2) pe care multe verificatoare o raportează ca negăsită, conform recensământului Defaults.Exposed pe 261 milioane de domenii.

Există cinci cauze reale, toate rezolvabile într-o singură ședință: gazdă greșită, înregistrare duplicată, tip DNS greșit sau ghilimele distorsionate, servere DNS inconsistente sau o coliziune de lungime/CNAME. Mai jos: testul de 60 de secunde pentru fiecare, în ordinea în care trebuie verificate, urmat de pașii de remediere.

Sunteți sigur că înregistrarea există cu adevărat?

Începeți cu posibilitatea mai puțin flatantă, deoarece este cea mai frecventă: dintre cele 261,086,232 domenii clasificate în recensământul Defaults.Exposed, 121,145,609 — 46.4% — nu au deloc o înregistrare SPF. Multe cazuri de tipul „dar am configurat asta” se dovedesc a fi o înregistrare adăugată într-o zonă de staging sau la un furnizor DNS vechi care nu mai este autoritar. Verificați furnizorul DNS la care pointează serverele dvs. DNS (deseori nu registrarul) pentru o înregistrare TXT care începe cu v=spf1. Dacă nu există cu adevărat, renunțați la ancheta detectivistică și mergeți direct la corectați înregistrarea SPF.

Cum verificați corect o înregistrare SPF?

Verificatoarele web interoghează DNS-ul prin intermediul propriului resolver cu cache. Pentru a vedea adevărul, solicitați direct serverul DNS autoritar al domeniului dvs.:

# găsiți serverele DNS autoritare
dig NS yourdomain.com +short

# solicitați direct unul dintre ele înregistrările TXT
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Pe Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Două reguli de interpretare. În primul rând, numărați liniile care încep cu v=spf1 — numărul contează la fel de mult ca și conținutul. În al doilea rând, verificați că ați interogat numele corect: receptorii evaluează SPF față de domeniul din Return-Path (RFC5321.MailFrom, „envelope from”) — nu adresa From pe care o văd destinatarii. Dacă instrumentul dvs. de newsletter trimite mesaje prin bounce.yourdomain.com, o înregistrare perfectă la apex nu este înregistrarea pe care o consultă receptorii.

Care sunt cele cinci cauze reale?

Date din 2026-06-29.

1. Înregistrarea este la gazda greșită?

Clasicul: SPF adăugat la mail.yourdomain.com când mail-ul pretinde că vine de la yourdomain.com, sau invers. SPF nu se moștenește în jos — o înregistrare la apex nu spune nimic despre subdomenii, și vice-versa. Publicați la exact numele din Return-Path. Un furnizor care trimite de la propriul subdomeniu de bounce are nevoie de o înregistrare pe acel subdomeniu — de obicei un CNAME sau TXT pe care îl furnizează vânzătorul (ghidul de configurare SPF pe GoDaddy arată unde se află aceste câmpuri).

2. Aveți două înregistrări SPF?

Cauza principală și cel mai înșelător mesaj de eroare din autentificarea e-mailului. RFC 7208 §3.2 este direct: un domeniu trebuie să aibă exact o înregistrare SPF. Două sau mai multe constituie o PermError — receptorii tratează SPF-ul dvs. ca nul. Unele verificatoare raportează această stare cu acuratețe („multiple records found”); altele raportează efectul net: no valid SPF record found. Vedeți o înregistrare în panoul dvs. și concluziați că verificatorul este defect. Nu este — aveți o înregistrare prea mult.

Recensământul a găsit 1,013,416 domenii cu două sau mai multe înregistrări SPF — aproximativ una din 138 dintre domeniile care încearcă SPF — fiecare cu SPF efectiv dezactivat. Se întâmplă de obicei în timpul schimbării de furnizor: expertul noului furnizor adaugă o înregistrare nouă în loc să o editeze pe cea veche. Remedierea este o îmbinare, niciodată o a doua înregistrare: combinați totul într-o singură linie v=spf1 … ~all și ștergeți restul. Raportul nostru de date două înregistrări SPF înseamnă niciuna explică detaliat cum au ajuns un milion de domenii aici; dacă a început după o migrare, consultați SPF a încetat să funcționeze după schimbarea furnizorului. Când îmbinați, nu concatenați orbește fiecare include: — fiecare costă interogări DNS față de limita strictă de 10 a SPF, înlocuind negăsit cu un PermError: prea multe interogări DNS.

3. Ați publicat tipul greșit de înregistrare — sau interfața UI l-a distorsionat?

SPF-ul timpuriu avea propriul tip de înregistrare DNS (tipul 99, numit literal „SPF”). A fost depreciat: RFC 7208 impune TXT, iar receptorii nu interoghează tipul 99. Unele panouri DNS oferă în continuare „SPF” în meniul derulant al tipului de înregistrare; alegeți-l și înregistrarea dvs. este reală, bine formată și invizibilă. Verificați coloana de tip și re-publicați ca TXT.

Varianta mai subtilă este ghilimelarea. Lipirea unei valori înconjurate de ghilimele într-un câmp care adaugă propriile ghilimele produce ""v=spf1 …"" — care nu mai începe cu v=spf1, deci pentru un verificator nu există. Ieșirea dvs. dig arată adevărul; panoul DNS o ascunde deseori cosmetic.

4. Chiar se mai propagă?

„Acordați-i 24–48 de ore să se propage” este sfatul cel mai supraprescris în DNS. Propagarea înseamnă doar expirarea cache-urilor: odată ce TTL-ul înregistrării a expirat (de obicei 1 oră, rareori mai mult de 24), orice resolver poate vedea noul răspuns. Încă negăsită după 24 de ore? Propagarea nu este cauza.

Cei doi vinovați reali: cache negativ — un resolver care v-a căutat înainte să adăugați înregistrarea memorează în cache răspunsul „fără înregistrare” până când TTL-ul negativ expiră — și servere DNS inconsistente după o migrare, unde domeniul listează în continuare serverele DNS ale vechiului furnizor alături de cele noi, și jumătate din lume citește o zonă pe care nu o mai editați. Interogați direct fiecare server DNS listat; dacă răspunsurile diferă, l-ați găsit. Corectați delegarea NS a registrarului astfel încât doar furnizorul pe care îl editați efectiv să fie autoritar.

5. Înregistrarea este prea lungă sau blocată de un CNAME?

Un singur șir dintr-o înregistrare TXT are maximum 255 de caractere. Înregistrările SPF mai lungi sunt legale, dar trebuie împărțite în mai multe șiruri între ghilimele într-o singură înregistrare — iar interfețele furnizorilor DNS eșuează frecvent la împărțire, trunchiind valoarea sau rupând-o la jumătatea unui mecanism, astfel încât nu mai poate fi analizată. Dacă înregistrarea dvs. este lungă, verificați ieșirea dig pentru o valoare care se termină abrupt.

Separat, DNS interzice o înregistrare TXT la un nume care are deja un CNAME. Dacă mail.yourdomain.com este un CNAME la furnizorul dvs., nu puteți pune și SPF acolo — unele panouri îl acceptă și apoi servesc doar CNAME-ul. Puneți înregistrarea acolo unde pointează CNAME-ul (dacă îl controlați), sau restructurați astfel încât numele de trimitere să nu fie un CNAME. Furnizorii cu gestionare curată a TXT fac ambele mai ușoare — consultați ghidul de configurare SPF pe Cloudflare.

Cum îl reparați, pas cu pas?

1. Rulați scanarea gratuită la defaults.exposed — citește DNS-ul dvs. activ și vă spune în care dintre cele cinci stări vă aflați, înainte de a atinge orice.
2. Confirmați care servere DNS sunt autoritare (dig NS) și că toate sunt de acord.
3. Interogați TXT la serverul DNS autoritar pentru domeniul exact Return-Path.
4. Numărați liniile v=spf1: zero → publicați una; două sau mai multe → îmbinați în una.
5. Verificați că tipul este TXT, valoarea începe exact cu v=spf1 și că nu s-au strecurat ghilimele greșite sau trunchieri.
6. Așteptați un TTL, apoi re-scanați pentru a confirma că se rezolvă corect peste tot.

Întrebări frecvente

De ce verificatorul spune „not found” când pot vedea înregistrarea în panoul DNS? De obicei cauza 2 sau 4: o a doua înregistrare v=spf1 le anulează pe amândouă — o PermError pe care unele instrumente o raportează ca negăsită, starea în care se află 1,013,416 domenii din 2026-06-29 — sau panoul dvs. nu este DNS-ul care este efectiv autoritar.

Cât durează până când verificatoarele văd corectura? Un TTL — de obicei o oră, cel mult 24. Dincolo de asta, „propagarea” nu este explicația; reverificați cele cinci cauze, începând cu consistența serverelor DNS.

Ar trebui să folosesc tipul de înregistrare „SPF” pe care îl oferă panoul DNS? Nu. Tipul 99 este depreciat; RFC 7208 impune doar TXT. O înregistrare de tip 99 este invizibilă pentru receptorii moderni.

Înregistrarea este găsită acum — de ce mai eșuează SPF-ul pentru e-mailurile mele? Deoarece SPF este verificat față de domeniul Return-Path, nu antetul From, iar înregistrarea trebuie să listeze efectiv serverele care trimit în numele dvs. Găsit este primul pas; ghidul corectați înregistrarea SPF acoperă trecerea.

Este chiar atât de frecventă lipsa unei înregistrări SPF? Da — 121,145,609 domenii, 46.4% din cele 261,086,232 clasificate în recensământul Defaults.Exposed (din 2026-06-29), nu publică deloc SPF. Negăsit este starea implicită a internetului.

Trimiteți proprietarului raportul

Odată ce înregistrarea se rezolvă corect, re-rulați scanarea și trimiteți raportul clasificat proprietarului afacerii sau clientului al cărui domeniu este acesta. Acesta arată, în limbaj simplu, ce era stricat, ce ați reparat și unde se situează acum domeniul — exact dovada de care vor fi solicitați la reînnoirile de asigurare cibernetică și la chestionarele de securitate ale furnizorilor. Raportul este chitanța pentru muncă.

Verificați gratuit înregistrarea SPF

Vedeți în care dintre cele cinci stări de negăsire se află domeniul dvs. — privat și numai pentru proprietar.

Verificați domeniul → · Corectați SPF → · SPF stricat după schimbarea furnizorului → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.