Defaults.Exposed › Aruanded
Miks mu SPF ebaõnnestub? SaaS-i 10 päringu probleem Ühendkuningriigi ja ELi saatjatele (2026)
Avaldatud 2026-07-09
Andmed seisuga 2026-06-29 · metoodika v7. Koondloenduse andmed 261 miljoni hinnatud domeeni kohta. Vaadake kuidas me hindame.
Kui SPF ebaõnnestub Ühendkuningriigis või ELis SaaS-tööriistu kasutava ettevõtte jaoks, on tõenäolisim põhjus üks RFC reegel, millele te pole kunagi pidanud mõtlema: pärast 10 DNS-päringut ei tagasta SPF enam “ebaõnnestumist” — see tagastab PermError’i, mis tähendab, et kirjet käsitletakse nii, nagu seda poleks olemas. Vähemalt 797,263 domeeni on selle piiri juba ületanud. Veel 2,119,539 seisab täpselt 9–10 päringul — üks uus tööriist viib nad sama kuristiku äärele.
Miks SPF katkeb, kui lisate SaaS-tööriista?
SPF töötab nii, et loetleb meiliserveri, millel on õigus teie domeeni nimel saata. Kaasaegsed ettevõtted ei halda tavaliselt oma meiliserveri — nad kasutavad Google Workspace’i sisemiseks e-postiks, Mailchimp’i kampaaniate jaoks, HubSpot’i müügijärjestuste jaoks, Pipedrive’i CRM-i väljaande jaoks. Iga platvorm annab teile include: rea, mille DNS-i kleepida.
Probleem: iga include: on ise DNS-päring. Ja iga kirje selle include’i sees võib rekursiivselt käivitada rohkem päringuid. RFC 7208 §4.6.4 seab kümnele ranges ülempiiri. Kümne ületamisel lõpetab vastuvõttev meiliserver hindamise ja tagastab PermError’i — ning PermError ei ole pehme tõrge, mis lõpeb rämpsposti. See tähendab, et teie SPF-kirjet käsitletakse nii, nagu seda poleks. E-posti autentimine ebaõnnestub SPF-i osas.
Te ei näe seda oma DNS-i paneelil. Loendur töötab ainult reaalajas hindamise ajal. Teie nähtavas kirjes võib olla kolm include: rida ja te olete siiski kaheteistkümne päringu sügavusel, sest iga tarnija SPF-kirje tõmbab oma alamkirjeid.
Kui palju domeene on juba üle piiri?
Vähemalt 797,263. See on arv pärast seda, kui lahendati iga SPF include: sihtkoht, millele viidati 100 või rohkem korda — 10,842 erinevat sihtpunkti, mis katavad 95.2% kõigist include-viigetest — ja hinnati iga domeeni täielik ahel. Pindmiseks loendamiseks (mida leiaksite, lugedes ainult kirje nähtavaid ridu) leitakse umbes 7,958. Ahela hinnastamise arv on 100 korda suurem, sest peaaegu kogu kahju on peidus include-sihtkohtade sees.
Olukord, mis tõenäoliselt mõjutab Euroopa ettevõtet:
| Stsenaarium | Mis juhtub |
|---|---|
| Google Workspace + Mailchimp + HubSpot + üks teine | Tõenäoliselt 10 päringul või sellest üle |
| IONOS-i majutus + kolm SaaS-tööriista | Kõrge risk: IONOS-i oma SPF-sihtkoht lisab mitu vahejaama |
| OVH-i majutus + kaks transaktsioonilist tööriista + CRM | Risk sõltub OVH SPF-i sügavusest hindamise ajal |
| Ainult Microsoft 365 | Madal risk: Microsofti SPF on kompaktne ja hästi hooldatud |
Euroopa majutusteenuse pakkujad ja nõrgad SPF-vaikesätted
Majutusteenuse pakkuja, kellega alustasite, on oluline — sest mõned määravad SPF-vaikesätted, mis kulutavad juba mitu teie kümnest päringust enne ühe SaaS-tööriista ühendamist.
Meie loenduses Euroopa domeenide poolt kasutatavate suurimate majutusteenuse pakkujate hulgas:
| Pakkuja | Seda kasutavad domeenid | SPF range (-all) | DMARC jõustamine |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3% | 1.0% |
| OVH | 2,132,049 | 43.7% | 2.2% |
| Microsoft 365 | 10,205,070 | 85.0% | 21.7% |
| Google Workspace | 12,145,313 | 8.0% | 18.5% |
IONOS paistab silma: ainult 1.0% IONOS-is majutatud domeenidest omab jõustatavat DMARC-i, mis tähendab, et suur enamus ei oma üldse mõtestatud saatja autentimist. OVH domeenid toimivad range SPF-sätted puhul paremini (43.7%), kuid langevad DMARC-i jõustamisel 2.2%-ni — SPF üksi, ilma DMARC-ita, mis seob selle From:-päisega, kaitseb ainult ümbrikku, mitte seda, mida saaja näeb.
Microsoft 365 on positiivne erand: 85.0% Microsofti majutatud domeenidest kasutab ranget SPF-i, suuresti seetõttu, et Microsofti meili voo viisard seab vaikimisi -all. Google Workspace seab vaikimisi ~all (softfail), jättes 92% oma domeenidest ilma range kaitseta.
Kuidas diagnoosida SPF-tõrget vähem kui 60 sekundiga
Kiireim kontroll on tasuta tööriist, mis hindab kogu päringuahelat — mitte ainult nähtavat kirjet. Käivitage käsureal nslookup -type=TXT yourdomain.com ja loendage kõik include: read, mida näete. Seejärel otsige kõik need kirjed üles ja loendage nende omad. Kui sõrmed saavad enne include’id otsa, olete ohutsoonis.
Usaldusväärsem lähenemisviis: kontrollige oma domeeni siin — skanner hindab täielikku lahendatud ahelat, märgib PermError’i ja näitab, millised mehhanismid teie päringueelarvet tarbivad.
Kolm diagnostilist tulemust:
- PermError — olete juba kümne ületanud. Iga e-kiri, mille saadate, ebaõnnestub SPF-kontrollis vastuvõtja juures.
- 9–10 päringul — olete kuristiku serval. Järgmine SaaS-integratsioon tõukab teid üle.
- Softfail (~all) hardfail’i (-all) asemel — olete piirist all, kuid kirje on seatud liiga lubavalt, et pakkuda tõelist kaitset. Vaadake SPF-i vale konfiguratsiooni raportit täieliku pildi saamiseks
-allvs~allkohta.
Kuidas parandada SPF-i mitme SaaS-tööriista kasutamisel
Püsivuse järjekorras on kolm lähenemisviisi:
1. Audit ja pügamine. Alustage kõigi include: kirjete loetlemisest oma praeguses kirjes. Eemaldage platvormid, mida te enam ei kasuta — vanad ESP-d, CRM-tööriistad eelnevatest lepingutest, platvormid, mida katsetasite, kuid hülgasite. See on tasuta ja taastatab sageli mitu päringut. Iga eemaldatud include: võib kõrvaldada 1–3 alampäringut.
2. SPF-kirje lapendamine. SPF-lapendamine lahendab kõik include: sihtpunktid nende aluseks olevateks IP-vahemikeks ja kirjutab need otse teie kirjesse ip4: ja ip6: mehhanismidena. IP-mehhanismid ei käivita päringuid, seega võib lapendatud kirje loetleda kümneid saatmisallikaid ja siiski olla null päringul. Puudus: peate uuesti lapendama iga kord, kui tarnija uuendab oma saatmis-IP-aadresse, mis juhtub ilma etteteatamiseta. Enamik organisatsioone kasutab tasulise SPF-lapendamise teenust (PowerDMARC, EasyDMARC, Dmarcian jt pakuvad seda) või ehitab seire töövoo.
3. SPF-makrode kasutamine. RFC 7208 makrod võimaldavad teil luua kirjeid, mis teevad iga kontrolli kohta ühe DNS-päringu ja vastavad dünaamiliselt, mitte include-ahela asemel. Makrod nõuavad DNS-majutuse tuge ja mõningast juurutamisvaeva, kuid need on arhitektuuriliselt puhas lahendus paljude SaaS-saatjatega organisatsioonidele.
Pärast SPF-i parandamist ühendage see DMARC-i jõustamisega — SPF ilma DMARC-ita autendib ainult ümbrikku saatja, mitte päise From:-aadressi, mida saajad näevad.
Korduma kippuvad küsimused
Miks mu SPF-kirje läbib minu DNS-tööriista, kuid ebaõnnestub e-posti päistes?
Enamik DNS-otsingutööriistu loendab ainult teie enda kirje nähtavaid mehhanisme, mitte alampäringuid, mida need mehhanismid käivitavad. Teil võib olla kaks include: rida ja siiski olla üle piiri, kui iga tarnija kirje sisaldab veel mitu. Ainult ahela hinnastamise tööriist (või vastuvõttev meiliserver) loendab täieliku sügavuse. Kontrollige oma domeeni tegeliku ahela loenduse nägemiseks.
Kas SPF-i ebaõnnestumine tähendab, et mu e-kirjad lähevad rämpspostiks?
PermError (liiga palju päringuid) tähendab, et autentimise SPF-jalg tagastab mitteparanduse — tegelikult puudub. DMARC hindab nii SPF-i kui ka DKIM-i; kui DKIM läbib, saab DMARC siiski läbida vaatamata SPF PermError’ile. Kui kumbki ei läbi, ebaõnnestub DMARC ja tulemus sõltub teie DMARC-poliitikast. p=none korral edastatakse e-kiri siiski, kuid tõrge logitakse. p=quarantine või p=reject korral filtreeritakse e-kiri või tagastatakse. Parandage SPF, et mitte tugineda ainult DKIM-ile.
Kui palju päringuid tüüpiline SaaS-pinu kasutab? Meie loenduse p99 SPF-kirje on juba 9 päringul — otse piiril — enne midagi lisamist. Google Workspace’i kirje lisab 3–4 päringut; Mailchimp lisab 1–2; HubSpot lisab 1–3 sõltuvalt nende praegusest konfiguratsioonist. Kolm peavoolu tööriista pluss teie majutusteenuse pakkuja vaikimisi on sageli piisav kümneni jõudmiseks.
Kas SPF-i lapendamine on turvaline?
Jah, tingimusel et hoiate seda ajakohasena. Lapendamine teisendab include: ahelad staatiliseks IP-vahemikeks — kui tarnija muudab oma saatmis-IP-aadresse ja te ei lapenda uuesti, hakkate nende posti tagasi lükkama. Enamik organisatsioone kasutab hallatavat lapendamisteenust, mis jälgib IP-muudatusi, selle asemel et seda käsitsi hooldada.
Minu SPF on olnud selline aastaid — miks see nüüd äkki ebaõnnestub? Sest teie tarnijad uuendasid oma SPF-kirjeid, mitte teie omi. Iga kord, kui SaaS-platvorm lisab uue saatmis-IP-vahemiku või pesib teise include’i, tõuseb teie ahela kulud ilma teie poolt muutusteta. 10-päringu limiit hinnatakse reaalajas sõnumi vastuvõtmisel, seega võib teisipäeva hommikune tarnija muudatus purustada teie SPF-i teisipäeva pärastlõunal.
Kas SPF-i parandamine parandab e-posti edastamist? See eemaldab autentimistõrke allika, mis on järjepideva edastuse eeltingimus — eriti kuna Google ja Yahoo jõustavad nüüd DMARC-i vastavust massisaatjatele. SPF üksi ei ole kogu pilt: ühendage see DKIM-i ja DMARC-iga täieliku e-posti autentimise saavutamiseks.
Kontrollige oma SPF-i tasuta
Kui te pole kindel, kas teie SPF-kirje on üle päringulimiidi — või on seatud liiga nõrgalt teie domeeni kaitsmiseks — käivitage tasuta kontroll. See hindab täielikku lahendatud ahelat ja näitab teile täpselt, kus eelarvet kulutatakse.
Kontrollige oma domeeni → · Paranda SPF → · SPF PermError’i raport → · SPF vale konfiguratsiooni raport → · SPF kasutuselevõtu küpsuse mudel → · Paranda DMARC → · Ainult koondandmed. Andmeid hoitakse ja töödeldakse ELis.