Defaults.Exposed › Perbaikan › Guides

"SPF Record Not Found" — Padahal Sudah Ada? 5 Penyebab Sebenarnya (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.

Jika pemeriksa mengatakan “SPF record tidak ditemukan” padahal Anda yakin sudah menerbitkannya, record tersebut biasanya tidak terlihat daripada tidak ada: 1,013,416 domain — sekitar satu dari 138 dari yang mencoba SPF — menerbitkan dua atau lebih record SPF, sebuah PermError (RFC 7208 §3.2) yang dilaporkan banyak pemeriksa sebagai tidak ditemukan, menurut sensus Defaults.Exposed dari 261 juta domain.

Ada lima penyebab nyata, semua dapat diperbaiki dalam satu sesi: host yang salah, record duplikat, tipe DNS salah atau tanda kutip rusak, nameserver tidak konsisten, atau tabrakan panjang/CNAME. Di bawah ini: tes 60 detik untuk masing-masing, dalam urutan pemeriksaan, kemudian langkah-langkah perbaikannya.

Apakah record benar-benar ada?

Mulailah dengan kemungkinan yang tidak menyenangkan, karena ini adalah yang paling umum sejauh ini: dari 261,086,232 domain yang dinilai dalam sensus Defaults.Exposed, 121,145,609 — 46.4% — tidak memiliki record SPF sama sekali. Banyak kasus “saya sudah mengaturnya” ternyata adalah record yang ditambahkan ke zona staging atau provider DNS lama yang sudah tidak lagi otoritatif. Periksa provider DNS yang ditunjuk nameserver Anda (sering bukan registrar Anda) untuk record TXT yang dimulai dengan v=spf1. Jika benar-benar tidak ada, lewati penelitian detektif dan langsung ke perbaiki record SPF Anda.

Bagaimana cara memeriksa record SPF dengan benar?

Pemeriksa web melakukan query DNS melalui resolver cache mereka sendiri. Untuk melihat kebenaran, tanyakan langsung ke nameserver otoritatif domain Anda:

# temukan nameserver otoritatif
dig NS yourdomain.com +short

# tanyakan langsung ke salah satunya untuk record TXT
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Di Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Dua aturan interpretasi. Pertama, hitung baris yang dimulai dengan v=spf1 — jumlahnya sama pentingnya dengan isinya. Kedua, pastikan Anda melakukan query nama yang benar: penerima mengevaluasi SPF terhadap domain dalam Return-Path (RFC5321.MailFrom, “envelope from”) — bukan alamat From yang dilihat penerima. Jika alat newsletter Anda memantul melalui bounce.yourdomain.com, record yang sempurna di apex bukan record yang dicari penerima.

Apa saja lima penyebab sebenarnya?

Data per 2026-06-29.

1. Apakah record berada di host yang salah?

Yang klasik: SPF ditambahkan di mail.yourdomain.com padahal email diklaim berasal dari yourdomain.com, atau sebaliknya. SPF tidak mewarisi ke bawah — record di apex tidak mengatakan apapun tentang subdomain, dan sebaliknya. Terbitkan tepat di nama yang ada di Return-Path Anda. Vendor yang mengirim dari subdomain bounce-nya sendiri memerlukan record di subdomain itu — biasanya CNAME atau TXT yang disediakan vendor (panduan setup SPF GoDaddy menunjukkan di mana field-field ini berada).

2. Apakah Anda memiliki dua record SPF?

Penyebab utama, dan pesan error paling menyesatkan dalam autentikasi email. RFC 7208 §3.2 sangat jelas: sebuah domain harus memiliki tepat satu record SPF. Dua atau lebih adalah PermError — penerima memperlakukan SPF Anda sebagai tidak berlaku. Beberapa pemeriksa melaporkan kondisi itu dengan akurat (“multiple records found”); yang lain melaporkan efek bersihnya: tidak ada record SPF yang valid ditemukan. Anda melihat record di panel dan menyimpulkan pemeriksanya rusak. Tidak — Anda memiliki satu record terlalu banyak.

Sensus menemukan 1,013,416 domain yang membawa dua atau lebih record SPF — sekitar satu dari 138 domain yang mencoba SPF — setiap domain dengan SPF yang secara efektif dinonaktifkan. Ini biasanya terjadi selama pergantian provider: wizard provider baru menambahkan record baru alih-alih mengedit yang lama. Perbaikannya adalah penggabungan, bukan record kedua: gabungkan semuanya menjadi satu baris v=spf1 … ~all dan hapus sisanya. Laporan data kami dua record SPF sama dengan tidak ada menguraikan bagaimana satu juta domain sampai di sini; jika ini terjadi setelah migrasi, lihat SPF berhenti bekerja setelah mengganti provider. Saat menggabungkan, jangan buta menggabungkan setiap include: — masing-masing menghabiskan DNS lookup terhadap batas keras 10 SPF, menukar tidak-ditemukan dengan PermError: terlalu banyak DNS lookup.

3. Apakah Anda menerbitkan tipe record yang salah — atau apakah UI merusaknya?

SPF awal memiliki tipe record DNS sendiri (tipe 99, yang dinamai “SPF”). Itu sudah tidak digunakan: RFC 7208 memerlukan TXT, dan penerima tidak melakukan query tipe 99. Beberapa panel DNS masih menawarkan “SPF” di dropdown tipe record; pilih itu dan record Anda nyata, terbentuk dengan baik, dan tidak terlihat. Periksa kolom tipe dan terbitkan ulang sebagai TXT.

Saudara yang lebih halus adalah tanda kutip. Menempel nilai yang dibungkus tanda kutip ke field yang menambahkan tanda kutipnya sendiri menghasilkan ""v=spf1 …"" — yang tidak lagi dimulai dengan v=spf1, sehingga bagi verifier tidak ada. Output dig Anda menunjukkan kebenaran; panel DNS sering menyembunyikannya secara kosmetik.

4. Apakah benar “masih menyebar”?

“Beri waktu 24–48 jam untuk menyebar” adalah saran yang paling banyak diresepkan berlebihan dalam DNS. Propagasi hanyalah cache yang kedaluwarsa: setelah TTL record habis (biasanya 1 jam, jarang lebih dari 24), setiap resolver dapat melihat jawaban baru. Masih tidak ditemukan setelah 24 jam? Propagasi bukan penyebabnya.

Dua pelaku nyata: negative caching — resolver yang mencari Anda sebelum Anda menambahkan record menyimpan jawaban “tidak ada record” hingga TTL negatif kedaluwarsa — dan nameserver tidak konsisten setelah migrasi, di mana domain masih mendaftar nameserver provider lama bersama yang baru dan separuh dunia membaca zona yang tidak lagi Anda edit. Query setiap nameserver yang terdaftar secara langsung; jika jawabannya berbeda, Anda telah menemukannya. Perbaiki delegasi NS registrar sehingga hanya provider yang benar-benar Anda edit yang otoritatif.

5. Apakah record terlalu panjang, atau diblokir CNAME?

Satu string dalam record TXT maksimal 255 karakter. Record SPF yang lebih panjang legal tetapi harus dibagi menjadi beberapa string yang dikutip dalam satu record — dan antarmuka provider DNS secara teratur merusak pemisahan, memotong nilai atau memecahnya di tengah mekanisme sehingga tidak lagi dapat di-parse. Jika record Anda panjang, periksa output dig untuk nilai yang berakhir tiba-tiba.

Terpisah, DNS melarang record TXT di nama yang sudah memiliki CNAME. Jika mail.yourdomain.com adalah CNAME ke provider Anda, Anda tidak dapat menempatkan SPF di sana juga — beberapa panel menerimanya lalu hanya melayani CNAME. Tempatkan record di tempat CNAME menunjuk (jika Anda mengontrolnya), atau restrukturisasi agar nama pengirim tidak di-CNAME. Provider dengan penanganan TXT yang bersih membuat keduanya lebih mudah — lihat panduan setup SPF Cloudflare.

Bagaimana cara memperbaikinya, langkah demi langkah?

1. Jalankan pemindaian gratis di defaults.exposed — sistem membaca DNS langsung Anda dan memberi tahu kondisi mana dari lima kondisi yang sedang Anda alami sebelum menyentuh apapun.
2. Konfirmasi nameserver mana yang otoritatif (dig NS) dan bahwa mereka semua setuju.
3. Query TXT di nameserver otoritatif untuk domain Return-Path yang tepat.
4. Hitung baris v=spf1: nol → terbitkan satu; dua atau lebih → gabungkan menjadi satu.
5. Verifikasi tipenya TXT, nilainya dimulai tepat dengan v=spf1, dan tidak ada tanda kutip atau pemotongan yang tidak sengaja.
6. Tunggu satu TTL, lalu pindai ulang untuk mengkonfirmasi record di-resolve dengan bersih di mana saja.

Pertanyaan yang Sering Diajukan

Mengapa pemeriksa mengatakan “tidak ditemukan” padahal saya bisa melihat record di panel DNS saya? Biasanya penyebab 2 atau 4: record v=spf1 kedua membuat keduanya tidak berlaku — sebuah PermError yang beberapa alat laporkan sebagai tidak ditemukan, kondisi yang 1,013,416 domain alami per 2026-06-29 — atau panel Anda bukan DNS yang benar-benar otoritatif.

Berapa lama sampai pemeriksa melihat perbaikan saya? Satu TTL — biasanya satu jam, paling lama 24. Lebih dari itu, “propagasi” bukan penjelasannya; periksa ulang lima penyebab, mulai dari konsistensi nameserver.

Haruskah saya menggunakan tipe record “SPF” yang ditawarkan panel DNS saya? Tidak. Tipe 99 sudah tidak digunakan; RFC 7208 hanya memerlukan TXT. Record tipe 99 tidak terlihat oleh penerima modern.

Record sudah ditemukan sekarang — mengapa email saya masih gagal SPF? Karena SPF diperiksa terhadap domain Return-Path, bukan header From, dan record harus benar-benar mendaftarkan server yang mengirim untuk Anda. Ditemukan adalah langkah pertama; panduan perbaiki record SPF Anda mencakup cara passing.

Apakah tidak memiliki record SPF benar-benar sering terjadi? Ya — 121,145,609 domain, 46.4% dari 261,086,232 yang dinilai dalam sensus Defaults.Exposed (per 2026-06-29), tidak menerbitkan SPF sama sekali. Tidak ditemukan adalah kondisi default internet.

Kirimkan laporan kepada pemilik

Setelah record di-resolve dengan bersih, jalankan ulang pemindaian dan teruskan laporan yang dinilai kepada pemilik bisnis atau klien yang domainnya ini. Laporan menunjukkan, dalam bahasa yang mudah dipahami, apa yang rusak, apa yang Anda perbaiki, dan di mana domain sekarang berdiri — tepat bukti yang akan diminta pada perpanjangan asuransi siber dan kuesioner keamanan pemasok. Laporan adalah tanda terima pekerjaan.

Periksa record SPF Anda gratis

Lihat kondisi mana dari lima kondisi tidak-ditemukan yang dialami domain Anda — secara privat dan hanya untuk pemilik.

Periksa domain Anda → · Perbaiki SPF → · SPF rusak setelah mengganti provider → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.