Defaults.Exposed › Perbaikan › Guides

SPF PermError: Cara Memperbaiki "Too Many DNS Lookups" Tanpa Merusak Email Anda (2026)

Diterbitkan 2026-07-08

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Lihat cara kami menilai.

Setidaknya 797,263 domain melanggar batas 10 lookup DNS SPF, menurut sensus Defaults.Exposed dari 261,086,232 domain — dari 139 juta penerbit SPF. Lewat dari sepuluh lookup, penerima berhenti dan mengembalikan PermError: SPF Anda batal, dan DMARC menghitung PermError sebagai kegagalan.

Perbaikannya memiliki urutan yang ketat, dan sebagian besar panduan membaliknya. Hitung lookup nyata yang di-resolve; hapus include yang mati dan tidak digunakan — itu saja memperbaiki sebagian besar record; pindahkan pengirim massal ke subdomain dengan anggaran SPF mereka sendiri; ratakan hanya sebagai upaya terakhir, dan hanya dengan perataan ulang otomatis, karena perataan statis membusuk dan diam-diam merusak pengiriman.

Apa arti “SPF PermError: too many DNS lookups”?

RFC 7208 §4.6.4 membatasi setiap pemeriksaan SPF pada 10 lookup DNS. Lewat dari sepuluh, penerima berhenti dan mengembalikan PermError — seluruh record diperlakukan sebagai rusak, bukan hanya bagian yang melebihi anggaran. Bagian yang sama menambahkan batas kedua yang kurang dikenal: paling banyak 2 “void lookup” (query yang tidak mengembalikan jawaban atau NXDOMAIN), sehingga beberapa entri include: yang mati untuk layanan yang dibatalkan bisa membatalkan SPF Anda sendiri.

Konsekuensinya lebih buruk dari “tidak ada SPF”: DMARC memperlakukan PermError sebagai kegagalan SPF, sehingga domain yang merusak SPF-nya sendiri tidak terautentikasi pada leg SPF dari setiap evaluasi DMARC. Jika DKIM tidak dikonfigurasi atau rusak saat transit, email itu sekarang langsung gagal DMARC.

Satu angka sensus menunjukkan betapa kerasnya mode kegagalan ini: 112,215 domain menerbitkan record -all yang ketat yang batal karena overflow lookup — dari 54,655,923 domain yang menerbitkan -all sama sekali. Pemiliknya melakukan bagian yang sulit — memilih ending yang ketat — dan satu include terlalu banyak mematikan seluruh record. Mereka terlihat ketat; mereka rusak. Untuk gambaran data lengkap, lihat laporan SPF PermError.

Mengapa SPF saya rusak padahal saya tidak mengubah apapun?

Karena anggaran sebagian besar dihabiskan oleh record orang lain. Setiap include: dievaluasi secara rekursif, dan setiap mekanisme lookup di dalamnya dihitung terhadap sepuluh Anda. Satu baris di panel DNS Anda bisa menghabiskan empat atau lima lookup setelah di-resolve. Provider menyarangkan satu include lagi, dan SPF Anda mati tanpa satu perubahan pun di zona Anda.

Platform besar bukan masalahnya: Google dan Microsoft keduanya telah meratakan SPF mereka sendiri — _spf.google.com dan spf.protection.outlook.com berkembang ke daftar IP biasa yang menghabiskan nol lookup internal (diverifikasi terhadap DNS langsung, Juli 2026). Pembengkakan di dunia nyata berasal dari rantai include panel hosting yang bersarang beberapa lapisan, dan dari penumpukan SaaS yang wajar — kotak surat plus newsletter plus CRM plus helpdesk, masing-masing “hanya satu include”. Tidak ada yang menambahkan lookup kesebelas dengan sengaja; ia tiba sebagai jumlah dari keputusan yang wajar. Itulah mengapa tepi jurang begitu ramai: 2,119,539 domain berada tepat di 9–10 lookup yang di-resolve — sekitar 1 dari 66 semua penerbit SPF, baik-baik saja hari ini, batal pada hari seseorang menempelkan satu include lagi. Record SPF persentil ke-99 sudah me-resolve ke 9 lookup. Jika stack Anda berat SaaS, panduan SPF gagal untuk alat SaaS mencakup versi per-vendor.

Bagian mana dari record SPF yang dihitung sebagai lookup DNS?

Hitung total yang di-resolve, bukan baris yang terlihat. Empat include bisa jadi empat lookup atau empat belas.

Bagaimana cara memperbaiki “too many DNS lookups” tanpa merusak email?

1. Jalankan pemindaian gratis sebelum menyentuh DNS. Ini me-resolve rantai include penuh Anda dan menampilkan jumlah lookup nyata, sehingga Anda memperbaiki masalah sebenarnya — bukan record seperti yang muncul di panel Anda. (Jika dikatakan Anda tidak memiliki SPF sama sekali, itu kegagalan berbeda — lihat “SPF record not found”.)
2. Hapus include yang mati dan tidak digunakan terlebih dahulu. Alat yang Anda tinggalkan pada 2023, include host lama yang bertahan setelah migrasi, duplikat, mekanisme ptr apa pun. Include yang mati doubly beracun: mereka membakar anggaran lookup dan merupakan sumber biasa dari void lookup. Sebagian besar record yang melebihi anggaran kembali di bawah 10 pada langkah ini saja. Jika record Anda masih membawa mekanisme provider sebelumnya, ikuti panduan pembersihan migrasi.
3. Periksa apakah setiap include yang tersisa melakukan sesuatu. Penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom), bukan header From — dan banyak alat SaaS menempatkan bounce domain mereka sendiri di Return-Path, sehingga include mereka di record Anda tidak melakukan apapun selain menghabiskan anggaran. Pertahankan include hanya untuk layanan yang menggunakan domain Anda sebagai Return-Path; untuk sisanya, aktifkan DKIM domain kustom vendor sebagai gantinya.
4. Pindahkan pengirim massal ke subdomain. Newsletter dari news.yourdomain.com, email transaksional dari mail.yourdomain.com. Setiap subdomain mendapatkan record SPF sendiri dengan anggaran 10 lookup yang segar, dan masalah di satu aliran berhenti mengalir ke yang lain.
5. Hanya setelah itu pertimbangkan perataan — dan hanya perataan otomatis. Lihat di bawah.
6. Pindai ulang untuk mengkonfirmasi Anda dengan nyaman di bawah 10 — bidik ruang lebih, bukan 10 persis, atau Anda baru saja bergabung kembali dengan 2.1 juta domain di tepi jurang. Kemudian kerjakan apapun lagi yang ditandai pemindaian di halaman perbaiki SPF.

Haruskah saya meratakan record SPF saya?

Perataan menggantikan include dengan blok ip4:/ip6: mendasarnya, yang menghabiskan nol lookup. Ini berfungsi — dan dilakukan dengan tangan, ini adalah pemadaman pengiriman dengan penundaan.

Provider merotasi IP pengiriman secara rutin dan tidak mengumumkannya kepada siapapun. Daftar IP statis benar pada hari Anda menempelkannya dan diam-diam salah dalam beberapa bulan — dan karena kegagalan muncul sebagai orang lain tidak menerima email Anda, Anda mengetahuinya terlambat. Jika pemangkasan dan subdomain membawa Anda di bawah batas, berhentilah di sana; jangan pernah menyalin blok IP pihak ketiga ke record Anda secara manual sebagai perbaikan permanen.

Pertanyaan yang Sering Diajukan

Apakah SPF PermError berarti email saya berhenti terkirim? Tidak secara instan — itulah yang membuatnya berbahaya. DMARC menghitung PermError sebagai kegagalan SPF, sehingga pengiriman sepenuhnya bergantung pada DKIM; jika DKIM hilang atau rusak saat transit, Anda gagal DMARC. Dari 139 juta penerbit SPF dalam sensus kami (per 2026-06-29), setidaknya 797,263 berada dalam kondisi ini — sebagian besar tanpa mengetahuinya.

Record saya hanya memiliki empat include — bagaimana bisa melebihi 10 lookup? Include dihitung secara rekursif: semua yang ada di dalam setiap include (dan di dalam include-nya) dibebankan ke anggaran Anda, sehingga empat baris yang terlihat bisa me-resolve ke empat belas lookup. Hitung dengan alat resolving, bukan secara kasat mata — me-resolve rantai adalah bagaimana laporan PermError kami menemukan ~100× lebih banyak domain yang rusak dari yang ditampilkan hitungan permukaan.

Saya mengakhiri record saya dengan -all — bukankah saya sudah terlindungi? Hanya jika record dievaluasi. Sensus kami (per 2026-06-29) menemukan 112,215 domain yang record -all ketatnya batal karena overflow lookup. Qualifier yang ketat pada record PermError tidak melindungi apapun.

Apakah batasnya 10 lookup per include atau untuk seluruh record? Seluruh evaluasi: RFC 7208 §4.6.4 membatasi pemeriksaan lengkap pada 10, ditambah paling banyak 2 void lookup. Setiap subdomain memiliki record dan anggaran sendiri — itulah mengapa langkah 4 berfungsi.

Apakah entri ip4 dan ip6 dihitung terhadap batas? Tidak — mekanisme IP tidak menghabiskan apapun, itulah tepatnya mengapa perataan mengurangi jumlah.

Kirimkan laporan kepada pemilik

Jika Anda memperbaiki ini untuk klien atau perusahaan, selesaikan pekerjaan dengan bukti. Jalankan ulang pemindaian gratis setelah perubahan Anda dan teruskan laporan yang dinilai kepada pemilik bisnis: bahasa mudah dipahami, bertanggal, PermError hilang. Itulah artefak yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner keamanan pelanggan berikutnya — perbedaan antara “saya mengubah beberapa record DNS” dan sebelum-dan-sesudah yang terdokumentasi.

Periksa domain Anda gratis

Lihat jumlah lookup nyata yang di-resolve Anda — dan semua lainnya SPF, DKIM dan DMARC — secara privat dan hanya untuk pemilik.

Periksa domain Anda → · Perbaiki SPF → · SPF gagal untuk alat SaaS → · Siapkan SPF di GoDaddy → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.