Defaults.Exposed › Laporan
Mengapa SPF Saya Gagal? Masalah 10 Pencarian SaaS untuk Pengirim Inggris dan EU (2026)
Diterbitkan 2026-07-09
Data per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang telah dinilai. Lihat cara kami menilai.
Ketika SPF gagal pada bisnis yang menggunakan alat SaaS di Inggris atau EU, penyebab paling umum adalah satu aturan RFC yang belum pernah Anda pertimbangkan: melampaui 10 pencarian DNS, SPF tidak mengembalikan “fail” — melainkan mengembalikan PermError, yang berarti rekaman diperlakukan seolah tidak ada. Setidaknya 797,263 domain sudah melewati batas tersebut. Sebanyak 2,119,539 domain lainnya berada tepat di 9–10 pencarian — satu alat baru saja bisa menjatuhkan mereka ke tebing yang sama.
Mengapa SPF rusak saat Anda menambahkan alat SaaS?
SPF bekerja dengan mendaftarkan server email yang berwenang mengirim atas nama domain Anda. Bisnis modern tidak menjalankan server email sendiri — mereka menggunakan Google Workspace untuk email internal, Mailchimp untuk kampanye, HubSpot untuk urutan penjualan, Pipedrive untuk penjangkauan CRM. Setiap platform memberi Anda baris include: untuk ditempelkan ke DNS Anda.
Masalahnya: setiap include: sendiri merupakan pencarian DNS. Dan setiap rekaman di dalam include tersebut dapat memicu lebih banyak pencarian secara rekursif. RFC 7208 §4.6.4 menetapkan batas keras sebesar sepuluh. Melampaui sepuluh, server email penerima berhenti mengevaluasi dan mengembalikan PermError — dan PermError bukan kegagalan lunak yang berakhir di spam. Artinya rekaman SPF Anda diperlakukan sebagai tidak ada. Autentikasi email gagal pada tahap SPF.
Anda tidak akan melihat ini di panel DNS Anda. Penghitung hanya aktif selama evaluasi langsung. Anda bisa memiliki tiga baris include: di rekaman yang terlihat dan masih berada dua belas pencarian lebih dalam, karena rekaman SPF setiap vendor menarik sub-include miliknya sendiri.
Berapa banyak domain yang sudah melewati batas?
Setidaknya 797,263. Itulah hitungan setelah kami menyelesaikan setiap target SPF include: yang direferensikan 100 kali atau lebih — 10,842 target berbeda yang mencakup 95.2% dari semua referensi include — dan menghitung biaya rantai penuh setiap domain. Hitungan permukaan (yang Anda temukan dengan menghitung hanya baris yang terlihat dalam rekaman) menemukan sekitar 7,958. Angka berdasarkan rantai adalah 100 kali lebih besar, karena hampir semua kerusakan tidak terlihat di dalam target include.
Situasi yang paling mungkin mempengaruhi bisnis Eropa:
| Skenario | Apa yang terjadi |
|---|---|
| Google Workspace + Mailchimp + HubSpot + satu lagi | Kemungkinan besar sudah mencapai atau melampaui 10 pencarian |
| Hosting IONOS + tiga alat SaaS apa pun | Risiko tinggi: target SPF IONOS sendiri menambahkan beberapa hop |
| Hosting OVH + dua alat transaksional + CRM | Risiko bergantung pada kedalaman SPF OVH saat evaluasi |
| Microsoft 365 saja | Risiko rendah: SPF Microsoft ringkas dan terpelihara dengan baik |
Penyedia hosting Eropa dan default SPF yang lemah
Penyedia hosting tempat Anda memulai penting — karena beberapa menetapkan default SPF yang sudah menghabiskan beberapa dari sepuluh pencarian Anda sebelum Anda menghubungkan satu alat SaaS pun.
Di antara penyedia hosting terbesar yang digunakan oleh domain Eropa dalam sensus kami:
| Penyedia | Domain yang menggunakannya | SPF ketat (-all) | DMARC diterapkan |
|---|---|---|---|
| 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 dihosting IONOS memiliki DMARC yang diterapkan, artinya mayoritas besar tidak memiliki autentikasi pengirim yang berarti sama sekali. Domain OVH lebih baik pada pengaturan SPF ketat (43.7%) tetapi masih jatuh ke 2.2% pada penerapan DMARC — SPF saja, tanpa DMARC untuk menghubungkannya ke header From:, hanya melindungi amplop, bukan yang dilihat penerima.
Microsoft 365 adalah pengecualian yang baik: 85.0% domain yang dihosting Microsoft menggunakan SPF ketat, sebagian besar karena wizard aliran email Microsoft menetapkan -all secara default. Google Workspace menetapkan ~all (softfail) secara default, meninggalkan 92% domain tanpa perlindungan ketat.
Cara mendiagnosis kegagalan SPF dalam waktu kurang dari 60 detik
Pemeriksaan tercepat adalah alat gratis yang mengevaluasi rantai pencarian penuh — bukan hanya rekaman yang terlihat. Jalankan nslookup -type=TXT yourdomain.com di baris perintah dan hitung setiap include: yang Anda lihat. Lalu cari setiap rekaman tersebut dan hitung miliknya. Jika jari Anda habis sebelum include-nya habis, Anda berada di zona bahaya.
Pendekatan yang lebih andal: periksa domain Anda di sini — pemindai mengevaluasi rantai lengkap yang telah diselesaikan, menandai PermError, dan menunjukkan mekanisme mana yang menghabiskan anggaran pencarian Anda.
Tiga hasil diagnostik:
- PermError — Anda sudah melampaui sepuluh. Setiap email yang Anda kirim gagal pemeriksaan SPF di penerima.
- Pada 9–10 pencarian — Anda berada di tepi tebing. Integrasi SaaS berikutnya akan menjatuhkan Anda.
- Softfail (~all) alih-alih hardfail (-all) — Anda di bawah batas tetapi rekaman ditetapkan terlalu permisif untuk memberikan perlindungan nyata. Lihat laporan kesalahan konfigurasi SPF untuk gambaran lengkap tentang
-allvs~all.
Cara memperbaiki SPF saat menggunakan beberapa alat SaaS
Ada tiga pendekatan, berurutan dari yang paling permanen:
1. Audit dan pangkas. Mulai dengan mendaftarkan setiap include: di rekaman Anda saat ini. Hapus platform yang sudah tidak Anda gunakan — ESP lama, alat CRM dari kontrak sebelumnya, platform yang Anda uji coba lalu tinggalkan. Ini gratis dan seringkali memulihkan beberapa pencarian. Setiap include: yang dihapus dapat menghilangkan 1–3 sub-pencarian.
2. Ratakan rekaman SPF Anda. Perataan SPF menyelesaikan semua target include: menjadi rentang IP dasarnya dan menulisnya langsung ke rekaman Anda sebagai mekanisme ip4: dan ip6:. Mekanisme IP tidak memicu pencarian, sehingga rekaman yang diratakan dapat mencantumkan puluhan sumber pengirim dan masih berada di nol pencarian. Kelemahannya: Anda perlu meratakan ulang setiap kali vendor memperbarui IP pengirim mereka, yang terjadi tanpa pemberitahuan. Sebagian besar bisnis menggunakan layanan perataan SPF berbayar (PowerDMARC, EasyDMARC, Dmarcian, dan lainnya menawarkan ini) atau membangun alur kerja pemantauan.
3. Gunakan makro SPF. Makro RFC 7208 memungkinkan Anda membangun rekaman yang melakukan satu pencarian DNS per pemeriksaan dan menjawab secara dinamis, bukan rangkaian include. Makro memerlukan dukungan hosting DNS dan beberapa upaya implementasi, tetapi merupakan solusi bersih secara arsitektural untuk organisasi dengan banyak pengirim SaaS.
Setelah memperbaiki SPF, pasangkan dengan penerapan DMARC — SPF tanpa DMARC hanya mengautentikasi pengirim amplop, bukan alamat From: header yang dilihat penerima.
Pertanyaan yang sering diajukan
Mengapa rekaman SPF saya lolos alat DNS tetapi masih gagal di header email?
Sebagian besar alat pencarian DNS hanya menghitung mekanisme yang terlihat di rekaman Anda sendiri, bukan sub-pencarian yang dipicu mekanisme tersebut. Anda bisa memiliki dua baris include: dan masih melampaui batas jika rekaman setiap vendor berisi beberapa lagi. Hanya alat pengharga rantai (atau server email penerima) yang menghitung kedalaman penuh. Periksa domain Anda untuk melihat jumlah rantai yang sebenarnya.
Apakah kegagalan SPF berarti email saya masuk ke spam?
PermError (terlalu banyak pencarian) berarti tahap SPF autentikasi mengembalikan hasil kosong — secara efektif tidak ada. DMARC mengevaluasi SPF dan DKIM; jika DKIM lolos, DMARC masih bisa lolos meskipun ada PermError SPF. Jika keduanya tidak lolos, DMARC gagal, dan hasilnya bergantung pada kebijakan DMARC Anda. Pada p=none, email tetap terkirim tetapi kegagalan dicatat. Pada p=quarantine atau p=reject, email disaring atau ditolak. Perbaiki SPF agar tidak hanya bergantung pada DKIM.
Berapa banyak pencarian yang digunakan oleh tumpukan SaaS umum? Rekaman SPF p99 dalam sensus kami sudah berada di 9 pencarian — tepat di batas — sebelum menambahkan apa pun. Rekaman Google Workspace menambahkan 3–4 pencarian; Mailchimp menambahkan 1–2; HubSpot menambahkan 1–3 tergantung konfigurasi saat ini. Tiga alat utama ditambah default penyedia hosting Anda seringkali sudah cukup untuk melampaui sepuluh.
Apakah perataan SPF aman?
Ya, asalkan Anda menjaganya tetap terkini. Perataan mengubah rantai include: menjadi rentang IP statis — jika vendor merotasi IP pengirim mereka dan Anda tidak meratakan ulang, Anda akan mulai menolak email mereka. Sebagian besar organisasi menggunakan layanan perataan terkelola yang memantau perubahan IP alih-alih mengelolanya secara manual.
SPF saya sudah seperti ini bertahun-tahun — mengapa tiba-tiba gagal? Karena vendor Anda memperbarui rekaman SPF mereka, bukan milik Anda. Setiap kali platform SaaS menambahkan rentang IP pengirim baru atau menyarangkan include lain, biaya rantai Anda naik tanpa perubahan apa pun dari pihak Anda. Batas 10 pencarian dievaluasi secara langsung saat pesan diterima, sehingga perubahan vendor pada Selasa pagi dapat merusak SPF Anda pada Selasa sore.
Apakah memperbaiki SPF meningkatkan kemampuan pengiriman email? Ini menghilangkan sumber kegagalan autentikasi, yang merupakan prasyarat pengiriman yang konsisten — terutama sejak Google dan Yahoo kini menegakkan penyelarasan DMARC untuk pengirim massal. SPF saja bukan gambaran lengkap: padukan dengan DKIM dan DMARC untuk autentikasi email penuh.
Periksa SPF Anda secara gratis
Jika Anda tidak yakin apakah rekaman SPF Anda melebihi batas pencarian — atau apakah terlalu lemah untuk melindungi domain Anda — jalankan pemeriksaan gratis. Ini mengevaluasi rantai lengkap yang telah diselesaikan dan menunjukkan persis di mana anggaran dihabiskan.
Periksa domain Anda → · Perbaiki SPF → · Laporan SPF PermError → · Laporan kesalahan konfigurasi SPF → · Model kematangan adopsi SPF → · Perbaiki DMARC → · Hanya data agregat. Data disimpan dan diproses di EU.