Defaults.Exposed › Remedieri › Guides

SPF eșuează pentru instrumentele SaaS? De ce se întâmplă și ordinea reparării — Ediție Europa (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.

Când un instrument SaaS „eșuează SPF”, înregistrarea dvs. nu este de obicei problema: e-mailul eșuează alinierea DMARC, sau lanțul de include a depășit limita de 10 interogări DNS a SPF. 2,119,539 din 138,927,207 domenii care publică SPF stau la 9–10 interogări — la un include SaaS distanță de marginea abruptă — conform recensământului Defaults.Exposed pe 261,086,232 domenii.

Mai jos: cum să determinați care dintre cele două probleme o aveți, apoi ordinea reparării — scanați mai întâi, găsiți domeniul de la care trimite cu adevărat instrumentul, treceți furnizorul la DKIM cu domeniu personalizat și adăugați un include SPF doar unde ajută cu adevărat — plus detaliile pentru HubSpot, Salesforce, Mailchimp și SendGrid.

De ce eșuează e-mailul de la un instrument SaaS în SPF?

Trei tipare acoperă aproape fiecare caz:

Date din 2026-06-29.

Rândul cu bold este locul unde se află cei mai mulți oameni. Adăugarea de linii include: pentru fiecare instrument nu rezolvă asta — și fiecare linie vă aduce mai aproape de al doilea rând: cel puțin 797,263 domenii au depășit deja limita de 10 interogări, iar SPF-ul lor returnează acum un PermError care nu protejează nimic. Numerele complete în raportul SPF PermError.

Față de ce domeniu verifică SPF de fapt?

Nu cel din antetul From. Receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom, cunoscut și ca adresa de bounce sau envelope-from) — antetul From pe care îl vede destinatarul dvs. nu joacă niciun rol în verificarea SPF în sine.

Acest singur fapt explică cele mai multe „eșecuri SPF ale SaaS”. Platforma dvs. de marketing trimite cu un Return-Path ca [email protected]; SPF este verificat față de vendor.com și trece fără probleme. Apoi DMARC întreabă dacă domeniul verificat SPF se potrivește cu domeniul From al dvs. Nu se potrivește, deci piciorul SPF al DMARC eșuează, iar tabloul de bord spune „SPF eșuează”. Editarea propriei înregistrări SPF nu poate remedia asta — înregistrarea dvs. nu a fost niciodată consultată.

Care este ordinea reparării?

1. Rulați mai întâi scanarea gratuită. Vă spune dintr-o privire dacă SPF-ul dvs. lipsește, este duplicat, depășește limita de interogări sau este în regulă, și unde se situează DMARC — înainte de a atinge DNS-ul.
2. Găsiți Return-Path-ul pe care îl folosește cu adevărat instrumentul. Trimiteți-vă un e-mail de test de la instrument și citiți antetul Return-Path (și Authentication-Results) din mesajul brut. Aceasta vă spune în ce rând al tabelului de mai sus vă aflați.
3. Activați DKIM cu domeniu personalizat al furnizorului. Fiecare instrument SaaS serios oferă „autentificarea domeniului”: câteva înregistrări CNAME care permit semnarea DKIM ca domeniul dvs. Semnătura se aliniază cu domeniul From, deci DMARC trece prin DKIM — durabil și chiar când e-mailul este redirecționat. Aceasta este remedierea care durează.
4. Adăugați include-ul SPF al furnizorului doar dacă folosește return-path-ul dvs. — ați activat domeniul de bounce personalizat sau trimite cu adevărat cu domeniul dvs. în envelope. Un include pentru un furnizor care buncăiește prin propriul domeniu nu cumpără nimic și cheltuiește bugetul de interogări.
5. Numărați interogările DNS înainte de a salva. Limita este de 10 interogări rezolvate, include-urile contează recursiv, și 2,119,539 domenii stau deja la 9–10 — p99 din recensământ este 9. Aproape de margine? Eliminați mai întâi include-urile pentru instrumentele pe care nu le mai folosiți. Tocmai ați schimbat furnizorii de e-mail? Verificați dacă există o a doua înregistrare rămasă — două înregistrări SPF înseamnă un PermError.
6. Re-scanați și confirmați. SPF trecut pe domeniul corect, DKIM aliniat, DMARC trecând. Referința completă se află la cum să corectați SPF; prezentările furnizorilor ca SPF pe GoDaddy și DMARC pe IONOS acoperă clicurile din panoul DNS.

Ce ar trebui să faceți pentru HubSpot, Salesforce, Mailchimp și SendGrid?

HubSpot. Conectați domeniul de trimitere în setările HubSpot și publicați cele două CNAMEs DKIM pe care le emite (hs1-… / hs2-…). Aceasta aliniază DKIM cu domeniul From. Nu aveți nevoie de un include SPF HubSpot dacă nu ați configurat HubSpot să folosească propriul dvs. domeniu de bounce.

Salesforce. Creați o cheie DKIM în Salesforce Setup și publicați perechea CNAME pe care o generează. Dacă Salesforce trimite cu return-path-ul organizației dvs., adăugați include:_spf.salesforce.com și configurați domeniul de bounce — acesta este singurul CRM mare unde include-ul SPF este deseori cu adevărat necesar.

Mailchimp. Autentificați domeniul și publicați CNAMEs DKIM k2 / k3. Alinierea Mailchimp este numai DKIM — nu mai există un include SPF de adăugat, iar adăugarea unuia dintr-un tutorial vechi doar irosește interogări.

SendGrid. Completați autentificarea domeniului („automated security”): trei CNAMEs care gestionează atât DKIM cât și return-path-ul pe propriul subdomeniu. Nu este necesar niciun include SPF. Dintre cele 740,321 domenii al căror SPF autorizează sendgrid.net, doar 18.0% au DMARC aplicat (date din 2026-06-29) — cei mai mulți expeditori SendGrid se opresc cu un pas înainte.

Zendesk și orice altceva: același tipar. Găsiți pagina „autentificarea domeniului” a instrumentului, publicați CNAMEs-urile DKIM și atingeți SPF doar dacă instrumentul documentează că folosește return-path-ul dvs.

SPF-ul este diferit pentru afacerile europene?

Nu — SPF, DKIM și DMARC funcționează identic peste tot. Ceea ce diferă în Europa este contextul: cine întreabă și ce au făcut deja vecinii dvs.

ccTLD-ul dvs. stabilește bara locală. ccTLD-urile europene publică SPF cu rate mult mai mari decât .com, dar domeniile care termină treaba — o politică DMARC aplicată deasupra — sunt minoritare peste tot:

Date din 2026-06-29. Franța: 13.65% DMARC aplicat; Italia: 5.24%.

Valorile implicite ale gazdei europene contează. 4,346,526 domenii autorizează serverele de e-mail EU ale IONOS (_spf-eu.ionos.com) în SPF-ul lor — și doar 0.3% se termină cu -all strict, cu 1.0% DMARC aplicat. Cele 2,132,049 ale OVH se descurcă mai bine la strictețe (43.7%), dar doar 2.2% aplică DMARC (date din 2026-06-29). Dacă nu ați atins niciodată înregistrarea, stați pe acele valori implicite.

Autoritățile de reglementare numesc acum acest lucru. Articolul 21(2)(j) NIS2 impune entităților în perimetru să-și securizeze comunicațiile, iar Regulamentul de punere în aplicare al Comisiei (UE) 2024/2690 precizează măsurile de securitate a e-mailurilor și DNS. Autentificarea e-mailului este elementul concret și verificabil — și, neobișnuit pentru conformitate, gratuit de remediat.

Privind rezidența datelor: scanerul și recensământul Defaults.Exposed rulează în AWS eu-west-1, publicăm doar cifre agregate, iar o scanare verifică doar domeniul pe care îl solicitați.

Întrebări frecvente

Verificatorul meu SPF spune „pass” dar tabloul de bord al instrumentului spune că SPF eșuează — de ce? Verificatorul a testat înregistrarea dvs.; receptorul a testat domeniul Return-Path pe care l-a folosit cu adevărat instrumentul, apoi DMARC l-a comparat cu domeniul From al dvs. Acesta este un eșec de aliniere, nu un eșec de înregistrare — remediat cu DKIM cu domeniu personalizat al furnizorului, nu cu editări SPF.

Ar trebui să adaug include-ul SPF pentru fiecare instrument pe care îl folosim? Nu. Fiecare include cheltuiește o parte din bugetul de 10 interogări al SPF, recursiv: 2,119,539 din 138,927,207 domenii care publică SPF stau la 9–10 interogări, și cel puțin 797,263 sunt peste — SPF-ul lor returnează PermError și nu protejează nimic (date din 2026-06-29).

Include-ul remediază și DMARC? Numai dacă instrumentul trimite cu return-path-ul dvs., astfel încât SPF trece și se aliniază. Pentru cele mai multe instrumente SaaS nu o face — de aceea DKIM aliniat, nu SPF, este piciorul care face DMARC să treacă pentru e-mailul SaaS.

Este aceasta o cerință legală în UE? Pentru entitățile în perimetrul NIS2, Articolul 21(2)(j) și Regulamentul de punere în aplicare (UE) 2024/2690 fac din securitatea e-mailului o obligație. Chiar și în afara perimetrului, asigurătorii și chestionarele clienților întreabă din ce în ce mai mult — și din 2026-06-29, niciun ccTLD european nu ajunge la o treime din domeniile sale la o politică DMARC aplicată (29.43% în .nl în cel mai bun caz; 5.24% în .it).

Trimiteți proprietarului raportul

Odată ce CNAMEs-urile sunt active, re-rulați scanarea și trimiteți raportul clasificat proprietarului afacerii sau clientului. Acesta arată, în limbaj simplu, ce eșua, ce ați reparat și unde se situează acum domeniul — exact dovada de care au nevoie pentru reînnoirea asigurării sau chestionarul de securitate al clienților, în scris, nu pe cuvântul dvs.

Verificați gratuit domeniul

Vedeți exact care picior din SPF, DKIM și DMARC eșuează — privat și numai pentru proprietar.

Verificați domeniul → · Corectați SPF → · SPF PermError: „prea multe interogări DNS” → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.