Defaults.Exposed › Laporan

Laporan SPF PermError: 100× Lebih Banyak Domain Melanggar Batas 10-Pencarian Dibanding yang Ditunjukkan Hitungan Permukaan (2026)

Diterbitkan 2026-07-03

Angka per 2026-06-29 · metodologi v7, ditambah satu tahap penetapan-harga-rantai yang dijalankan 2026-07-03. Dari sensus atas 261 juta domain yang dinilai, kami me-resolve setiap target include: SPF yang dirujuk 100 kali atau lebih — 10,842 target yang mencakup 95.2% dari seluruh rujukan include — dan menghitung harga rantai yang dipertahankan tiap domain terhadap peta itu. Target ekor yang belum ter-resolve dihitung sebagai nol dan isi rantai mencerminkan hari resolusi, jadi angka utamanya adalah aproksimasi yang konservatif dan cenderung ke batas bawah: kami menyebut “setidaknya”. Hanya agregat; tidak pernah catatan satu bisnis pun. Lihat cara kami menilai.

Berapa banyak domain yang melanggar batas 10-pencarian SPF?

Setidaknya 797,263 — karena SPF punya mekanisme penghancur-diri yang tertanam dalam standarnya, dan pemicunya bersembunyi di tempat yang tak bisa dilihat pemilik. RFC 7208 §4.6.4 membatasi satu pemeriksaan SPF pada 10 pencarian DNS; melewati sepuluh, penerima berhenti dan mengembalikan PermError, dan catatan PermError tidak melindungi apa pun. Hitung hanya pencarian yang terlihat di dalam catatan itu sendiri — sebagaimana dilakukan sebagian besar perkakas, dan sebagaimana sensus kami sendiri lakukan hingga laporan ini — dan Anda menemukan sekitar 8.000 pelanggar (tepatnya 7,958). Hitung harga rantai include: yang benar-benar ditarik masuk oleh catatan-catatan itu, dan jumlahnya mencapai 797,263: kira-kira 100 kali lebih besar.

Mengapa pemilik tak bisa melihatnya datang?

Karena anggaran itu dihabiskan oleh catatan milik orang lain. include:onetool.example.com terbaca sebagai satu baris di panel DNS Anda — tetapi penerima harus mengambil catatan itu juga, dan menghitung setiap mekanisme pencarian yang ia muat, secara rekursif. Sebuah catatan dengan tiga include bisa berbiaya sebelas. Tidak ada yang berubah di zona Anda sendiri pada hari Anda melampaui batas; seorang penyedia menyematkan satu include lagi, dan SPF Anda mati tanpa peringatan.

Lebih buruk lagi, DMARC memperlakukan PermError sebagai gagal pada kaki SPF — jadi sebuah domain yang merusak SPF-nya dengan cara ini kini gagal separuh dari autentikasinya sendiri.

Apa yang ditemukan penetapan-harga-rantai

Dua kisah dalam tabel itu — yang ketiga, tepian jurang, mendapat bagiannya sendiri di bawah:

• Hitungan permukaan melewatkan ~99% dari kerusakan. Hitungan mekanisme-yang-terlihat menemukan 7,958; menghitung harga rantai menemukan 797,263. Hampir seluruh kerusakan diwarisi dari apa yang di-include oleh include tersebut.
• 112,215 dari catatan yang rusak berakhir dengan -all. Para pemiliknya melakukan segalanya dengan benar — memanjat tembok, memilih akhiran yang ketat — dan satu include kelewat menggugurkan semuanya. Tampak ketat tapi rusak adalah mode kegagalan paling kejam dalam keamanan email.

2.1 juta domain hanya berjarak satu perkakas dari jurang

Angka yang seharusnya mengkhawatirkan pembaca yang saat ini baik-baik saja: 2,119,539 domain ter-resolve tepat ke 9 atau 10 pencarian — di bawah batas hari ini, mati pada hari seseorang menghubungkan satu platform lagi. Itu kira-kira 1 dari 66 dari seluruh penerbit SPF, dan cocok dengan bentuk distribusinya: catatan SPF persentil-99 sudah berada di 9 pencarian. Mendaftar satu perkakas pemasaran lagi, menempelkan baris “cukup tambahkan include ini”-nya, dan sebuah catatan yang di bawah batas saat sarapan sudah gugur menjelang makan siang.

Salah siapa? Kian lama, salah tumpukannya

Para penyedia terbesar diam-diam telah meratakan SPF mereka — _spf.google.com milik Google dan spf.protection.outlook.com milik Microsoft kini mengembang menjadi daftar IP biasa yang berbiaya nol pencarian internal (kami memverifikasi keduanya terhadap DNS langsung selama analisis ini). Ledakannya datang dari tempat lain: rantai panel-hosting yang bersarang tiga tingkat, penyedia regional yang include-nya saja berbiaya 7–10 pencarian, dan akumulasi jujur dari SaaS — mailbox ditambah newsletter ditambah CRM ditambah helpdesk, masing-masing “cuma satu include”. Hampir tak seorang pun menambahkan pencarian kesebelas dengan sengaja. Ia tiba sebagai jumlah dari keputusan-keputusan yang masuk akal.

Cara memeriksa dan memperbaiki milik Anda — gratis

1. Hitung total Anda yang sesungguhnya — pemeriksaan gratis kami me-resolve rantai Anda, atau gunakan penghitung pencarian SPF mana pun.
2. Pangkas beban mati: perkakas yang berhenti Anda pakai, include duplikat, dan mekanisme ptr yang usang.
3. Ratakan hanya apa yang Anda kendalikan. Mengganti include yang dalam dengan blok IP-nya berhasil untuk infrastruktur Anda sendiri; IP pihak ketiga berubah tanpa pemberitahuan.
4. Beri pengirim massal sebuah subdomain. Newsletter dari news.yourdomain.com mendapat catatannya sendiri dan anggaran 10-pencariannya sendiri.

Pertanyaan yang sering diajukan

Apa itu batas 10 pencarian DNS SPF? RFC 7208 §4.6.4 mengizinkan paling banyak 10 pencarian DNS untuk mengevaluasi satu catatan SPF — menghitung pencarian di dalam setiap include: secara rekursif. Melampauinya mengembalikan PermError: catatan diperlakukan sebagai tidak valid dan tidak memberikan perlindungan.

Apa arti SPF PermError? Kesalahan evaluasi permanen — penerima tidak dapat memproses catatan Anda (terlalu banyak pencarian, catatan ganda, atau sintaks yang rusak) dan memperlakukan domain Anda seolah tidak memiliki SPF yang bisa digunakan. DMARC menghitungnya sebagai gagal pada kaki SPF.

Berapa banyak domain yang melampaui batas pencarian SPF? Setidaknya 797,263 dari 139 juta penerbit SPF, menurut tahap penetapan-harga-rantai kami — sekitar 100× dari 7,958 yang terlihat tanpa me-resolve rantai. Sebanyak 2,119,539 lagi berada di 9–10 pencarian, satu include dari batas.

Apakah PermError menghentikan email saya terkirim? Biasanya tidak — penerima melanjutkan tanpa SPF, dan surat Anda menumpang pada DKIM serta reputasi. Yang berhenti bekerja adalah perlindungan: pemalsu tak lagi ditolak, dan setiap pemeriksaan DMARC atas surat Anda kehilangan kaki SPF-nya. Ia tak terlihat sampai ia menjadi mahal.

Bagaimana cara mengurangi jumlah pencarian SPF saya? Hapus include yang tak terpakai dan ptr, ratakan infrastruktur Anda sendiri menjadi ip4:/ip6:, pindahkan pengirim massal ke subdomain, dan hitung ulang setelah setiap perkakas baru. Panduan perbaikan memandunya langkah demi langkah.

Cari tahu angka Anda yang sesungguhnya

Mekanisme yang bisa Anda lihat bukanlah jumlah pencarian Anda — angka yang ter-resolve adalah angka yang dihitung penerima, dan itu adalah pemeriksaan 30 detik.

Periksa domain Anda → · Perbaiki SPF → · Model kematangan SPF → · Dua catatan SPF = tidak ada → · Jebakan ptr → · Hanya data agregat. Data disimpan dan diproses di UE.