Defaults.Exposed › Laporan
Mengapa SPF Saya Gagal? Masalah 10 Carian SaaS untuk Penghantar UK dan EU (2026)
Diterbitkan 2026-07-09
Data setakat 2026-06-29 · metodologi v7. Data bancian agregat merangkumi 261 juta domain yang telah dinilai. Lihat cara kami menilai.
Apabila SPF gagal bagi perniagaan yang menggunakan alat SaaS di UK atau EU, punca yang paling berkemungkinan ialah satu peraturan RFC yang tidak pernah anda fikirkan sebelum ini: selepas 10 carian DNS, SPF tidak mengembalikan “fail” — ia mengembalikan PermError, yang bermaksud rekod itu dilayan seolah-olah ia tidak wujud. Sekurang-kurangnya 797,263 domain sudah melepasi had tersebut. Sebanyak 2,119,539 domain lain pula berada tepat pada 9–10 carian — satu alat baharu sahaja sudah cukup untuk menjatuhkan mereka ke gaung yang sama.
Mengapa SPF rosak apabila anda menambah alat SaaS?
SPF berfungsi dengan menyenaraikan pelayan mel yang diberi kuasa menghantar bagi pihak domain anda. Perniagaan moden tidak menjalankan pelayan mel sendiri — mereka menggunakan Google Workspace untuk e-mel dalaman, Mailchimp untuk kempen, HubSpot untuk jujukan jualan, Pipedrive untuk penjangkauan CRM. Setiap platform memberikan baris include: untuk anda tampal ke dalam DNS anda.
Masalahnya: setiap include: sendiri merupakan carian DNS. Dan setiap rekod di dalam include tersebut boleh mencetuskan lebih banyak carian secara rekursif. RFC 7208 §4.6.4 menetapkan had keras sebanyak sepuluh. Selepas sepuluh, pelayan mel penerima berhenti menilai dan mengembalikan PermError — dan PermError bukan kegagalan lembut yang berakhir di spam. Ia bermaksud rekod SPF anda dilayan sebagai tidak wujud. Pengesahan e-mel gagal pada tahap SPF.
Anda tidak akan melihat ini dalam panel DNS anda. Pembilang hanya aktif semasa penilaian langsung. Anda boleh mempunyai tiga baris include: dalam rekod yang kelihatan dan masih berada dua belas carian lebih dalam, kerana rekod SPF setiap vendor menarik sub-include miliknya sendiri.
Berapa banyak domain yang sudah melebihi had?
Sekurang-kurangnya 797,263. Itulah kiraan selepas kami menyelesaikan setiap sasaran SPF include: yang dirujuk 100 kali atau lebih — 10,842 sasaran berbeza yang merangkumi 95.2% daripada semua rujukan include — dan menghitung kos rantaian penuh setiap domain. Kiraan permukaan (yang anda temui dengan mengira hanya baris yang kelihatan dalam rekod) menemukan kira-kira 7,958. Angka berdasarkan rantaian adalah 100 kali lebih besar, kerana hampir semua kerosakan tersembunyi di dalam sasaran include.
Situasi yang paling mungkin menjejaskan perniagaan Eropah:
| Senario | Apa yang berlaku |
|---|---|
| Google Workspace + Mailchimp + HubSpot + satu lagi | Kemungkinan besar mencapai atau melebihi 10 carian |
| Pengehosan IONOS + mana-mana tiga alat SaaS | Risiko tinggi: sasaran SPF IONOS sendiri menambah beberapa hop |
| Pengehosan OVH + dua alat transaksional + CRM | Risiko bergantung pada kedalaman SPF OVH semasa penilaian |
| Microsoft 365 sahaja | Risiko rendah: SPF Microsoft ringkas dan diselenggara dengan baik |
Pembekal pengehosan Eropah dan nilai lalai SPF yang lemah
Pembekal pengehosan tempat anda bermula adalah penting — kerana sesetengahnya menetapkan nilai lalai SPF yang sudah menggunakan beberapa daripada sepuluh carian anda sebelum anda menghubungkan sebarang alat SaaS.
Antara pembekal pengehosan terbesar yang digunakan oleh domain Eropah dalam bancian kami:
| Pembekal | Domain yang menggunakannya | SPF ketat (-all) | DMARC dikuatkuasakan |
|---|---|---|---|
| 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 menonjol: 1.0% domain yang dihoskan IONOS mempunyai DMARC yang dikuatkuasakan, yang bermaksud majoriti besar tidak mempunyai sebarang pengesahan penghantar yang bermakna. Domain OVH lebih baik pada tetapan SPF ketat (43.7%) tetapi masih jatuh kepada 2.2% pada penguatkuasaan DMARC — SPF sahaja, tanpa DMARC untuk menghubungkannya ke pengepala From:, hanya melindungi sampul, bukan apa yang dilihat penerima.
Microsoft 365 adalah pengecualian yang baik: 85.0% domain yang dihoskan Microsoft menggunakan SPF ketat, sebahagian besarnya kerana wizard aliran mel Microsoft menetapkan -all secara lalai. Google Workspace menetapkan ~all (softfail) secara lalai, meninggalkan 92% domainnya tanpa perlindungan ketat.
Cara mendiagnosis kegagalan SPF dalam masa kurang dari 60 saat
Semakan terpantas ialah alat percuma yang menilai rantaian carian penuh — bukan hanya rekod yang kelihatan. Jalankan nslookup -type=TXT yourdomain.com di baris arahan dan kira setiap include: yang anda lihat. Kemudian cari setiap rekod tersebut dan kira rekod yang ada. Jika jari anda habis sebelum include-nya tamat, anda berada dalam zon bahaya.
Pendekatan yang lebih boleh dipercayai: semak domain anda di sini — pengimbas menilai rantaian yang telah diselesaikan sepenuhnya, menandai PermError, dan menunjukkan mekanisme mana yang menghabiskan belanjawan carian anda.
Tiga hasil diagnostik:
- PermError — anda sudah melebihi sepuluh. Setiap e-mel yang anda hantar gagal semakan SPF di penerima.
- Pada 9–10 carian — anda berada di tepi gaung. Integrasi SaaS seterusnya akan menjatuhkan anda.
- Softfail (~all) bukannya hardfail (-all) — anda di bawah had tetapi rekod ditetapkan terlalu permisif untuk memberikan perlindungan sebenar. Lihat laporan salah konfigurasi SPF untuk gambaran penuh tentang
-allberbanding~all.
Cara memperbaiki SPF apabila menggunakan beberapa alat SaaS
Terdapat tiga pendekatan, mengikut urutan kekalnya:
1. Audit dan pangkas. Mulakan dengan menyenaraikan setiap include: dalam rekod semasa anda. Buang mana-mana platform yang tidak lagi anda gunakan — ESP lama, alat CRM dari kontrak terdahulu, platform yang anda uji tetapi tinggalkan. Ini percuma dan selalunya memulihkan beberapa carian. Setiap include: yang dibuang boleh menghapuskan 1–3 sub-carian.
2. Ratakan rekod SPF anda. Perataan SPF menyelesaikan semua sasaran include: menjadi julat IP asasnya dan menulisnya terus ke dalam rekod anda sebagai mekanisme ip4: dan ip6:. Mekanisme IP tidak mencetuskan carian, jadi rekod yang diratakan boleh menyenaraikan berpuluh-puluh sumber penghantar dan masih berada pada sifar carian. Kelemahannya: anda perlu meratakan semula setiap kali vendor mengemas kini IP penghantar mereka, yang berlaku tanpa notis. Kebanyakan perniagaan menggunakan perkhidmatan perataan SPF berbayar (PowerDMARC, EasyDMARC, Dmarcian, dan lain-lain menawarkan ini) atau membina aliran kerja pemantauan.
3. Gunakan makro SPF. Makro RFC 7208 membolehkan anda membina rekod yang melakukan satu carian DNS setiap semakan dan menjawab secara dinamik, berbanding rantaian include. Makro memerlukan sokongan pengehosan DNS dan beberapa usaha pelaksanaan, tetapi merupakan penyelesaian yang bersih dari segi seni bina untuk organisasi dengan ramai penghantar SaaS.
Selepas memperbaiki SPF, padankan dengan penguatkuasaan DMARC — SPF tanpa DMARC hanya mengesahkan penghantar sampul, bukan alamat From: pengepala yang dilihat penerima.
Soalan lazim
Mengapa rekod SPF saya lulus alat DNS tetapi masih gagal dalam pengepala e-mel?
Kebanyakan alat carian DNS hanya mengira mekanisme yang kelihatan dalam rekod anda sendiri, bukan sub-carian yang dicetuskan oleh mekanisme tersebut. Anda boleh mempunyai dua baris include: dan masih melebihi had jika rekod setiap vendor mengandungi beberapa lagi. Hanya alat pengharga rantaian (atau pelayan mel penerima) yang mengira kedalaman penuh. Semak domain anda untuk melihat kiraan rantaian sebenar.
Adakah kegagalan SPF bermaksud e-mel saya masuk ke spam?
PermError (terlalu banyak carian) bermaksud tahap SPF pengesahan mengembalikan tiada hasil — secara praktikalnya tiada. DMARC menilai kedua-dua SPF dan DKIM; jika DKIM lulus, DMARC masih boleh lulus walaupun ada PermError SPF. Jika kedua-duanya gagal, DMARC gagal, dan hasilnya bergantung pada polisi DMARC anda. Pada p=none, e-mel masih dihantar tetapi kegagalan dilog. Pada p=quarantine atau p=reject, e-mel ditapis atau ditolak. Perbaiki SPF agar anda tidak bergantung pada DKIM sahaja.
Berapa banyak carian yang digunakan oleh tindanan SaaS biasa? Rekod SPF p99 dalam bancian kami sudah berada pada 9 carian — tepat pada had — sebelum menambah apa-apa. Rekod Google Workspace menambah 3–4 carian; Mailchimp menambah 1–2; HubSpot menambah 1–3 bergantung pada konfigurasi semasa mereka. Tiga alat arus perdana ditambah lalai pembekal pengehosan anda selalunya sudah mencukupi untuk melepasi sepuluh.
Adakah perataan SPF selamat?
Ya, dengan syarat anda memastikannya terkini. Perataan menukar rantaian include: kepada julat IP statik — jika vendor memutar IP penghantar mereka dan anda tidak meratakan semula, anda akan mula menolak mel mereka. Kebanyakan organisasi menggunakan perkhidmatan perataan terurus yang memantau perubahan IP berbanding menyelenggaranya secara manual.
SPF saya sudah begini selama bertahun-tahun — mengapa ia tiba-tiba gagal? Kerana vendor anda mengemas kini rekod SPF mereka, bukan milik anda. Setiap kali platform SaaS menambah julat IP penghantar baharu atau menyarangkan include lain, kos rantaian anda meningkat tanpa sebarang perubahan dari pihak anda. Had 10 carian dinilai secara langsung semasa penerimaan mesej, jadi perubahan vendor pada Selasa pagi boleh merosakkan SPF anda menjelang Selasa petang.
Adakah membaiki SPF meningkatkan kebolehantaran e-mel? Ia menghapuskan sumber kegagalan pengesahan, yang merupakan prasyarat untuk penghantaran yang konsisten — terutamanya sejak Google dan Yahoo mula menguatkuasakan penjajaran DMARC untuk penghantar pukal. SPF sahaja bukan gambaran penuh: padukan dengan DKIM dan DMARC untuk pengesahan e-mel yang lengkap.
Semak SPF anda secara percuma
Jika anda tidak pasti sama ada rekod SPF anda melebihi had carian — atau ditetapkan terlalu lemah untuk melindungi domain anda — jalankan semakan percuma. Ia menilai rantaian yang telah diselesaikan sepenuhnya dan menunjukkan tepat di mana belanjawan digunakan.
Semak domain anda → · Baiki SPF → · Laporan SPF PermError → · Laporan salah konfigurasi SPF → · Model kematangan penerimaan SPF → · Baiki DMARC → · Data agregat sahaja. Data disimpan dan diproses di EU.