SPF ~all vs -all: Softfail atau Hardfail — Pilihan dari 139 Juta Record (2026)

Q: Apakah SPF ~all atau -all yang lebih baik?

Tidak ada yang mutlak lebih baik. ~all dengan kebijakan DMARC yang menegakkan adalah pola yang direkomendasikan pedoman Google — perlindungan setara di penerima yang mengevaluasi DMARC tanpa merusak surat yang diteruskan. -all cocok untuk pengirim yang terkontrol ketat. ~all sendirian — kondisi semua domain softfail kecuali 1 dari 11 — adalah opsi yang lemah.

Q: Apa arti SPF softfail?

~all memberi tahu penerima bahwa surat dari server yang tidak terdaftar kemungkinan tidak sah tetapi tetap harus diterima, biasanya dengan kecurigaan. Ia menjadi perlindungan nyata hanya ketika sebuah kebijakan DMARC bertindak atas kegagalan itu; lihat SPF tanpa DMARC.

Diterbitkan 2026-07-03

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Semua angka bersifat agregat — kami tidak pernah mempublikasikan record milik bisnis individu. Lihat cara kami menilai.

Setiap record SPF berakhir dengan sebuah mekanisme “all” — putusan atas surat dari mana pun yang tidak ada dalam daftar Anda — dan internet secara luar biasa memilih yang lunak: 55.8% dari 139 juta domain yang mempublikasikan SPF berakhir dengan ~all (softfail), berbanding 39.3% yang berakhir dengan -all (hardfail). Satu karakter memisahkan “tolak pemalsuan” dari “mungkin sebuah pemalsuan — kirimkan saja”. Mana yang tepat untuk Anda bergantung pada pengaturan kedua yang jarang dikonfigurasi oleh sebagian besar pemilik.

Apa sebenarnya yang disampaikan ~all dan -all kepada penerima?

-all (hardfail): “Tolak surat dari mana pun yang lain.” Sebuah penolakan tegas.
~all (softfail): “Surat dari tempat lain mungkin tidak sah — terima saja, mungkin tandai.” Sebuah gestur mengangkat bahu.
?all (neutral): “Tidak ada pendapat.” Dipilih oleh 3.0% penerbit; perlindungan hanya secara nama.
+all: “Siapa pun boleh mengirim atas nama saya.” Dipublikasikan oleh 36,014 domain, dan lebih buruk daripada tanpa record — masalah keset selamat datang punya laporannya sendiri.

Kalau begitu, apakah ~all salah? Hanya jika ia sendirian — dan hampir selalu begitu

Softfail punya argumen modern yang bisa dipertahankan: pedoman pengirim Google, dan sebagian besar praktik deliverability bersamanya, sama-sama mengarah pada ~all yang dipasangkan dengan kebijakan DMARC yang menegakkan (p=reject). Pasangan ini melindungi sebaik -all di setiap penerima yang mengevaluasi DMARC — yang kini mencakup semua penyedia kotak surat besar — tanpa memantulkan keras surat sah yang diteruskan, korban klasik dari -all. Dalam konfigurasi itu, gestur mengangkat bahu menjadi bergigi: DMARC menyuplai putusan yang enggan diberikan SPF.

Tetapi pasangan itulah intinya, dan inilah yang ditambahkan sensus yang tidak bisa disampaikan panduan setup: dari 77,484,057 record softfail di internet, hanya 7.1 juta — sekitar 1 dari 11 — yang memiliki kebijakan DMARC yang menegakkan di belakangnya. Untuk 70.4 juta domain lainnya, ~all persis seperti yang terdengar. Record mereka mengidentifikasi pemalsuan lalu meloloskannya.

Bukankah mandat 2024 sudah memperbaiki ini?

Tidak — dan perbedaannya lebih penting daripada yang disiratkan sebagian besar liputan. Google dan Yahoo mulai mewajibkan autentikasi dari pengirim massal pada Februari 2024, disusul Microsoft pada Mei 2025: SPF atau DKIM yang lolos dan selaras, ditambah sebuah record DMARC minimal p=none. Mandat itu tidak sampai mewajibkan penegakan — sebuah domain dengan ~all, record p=none, dan DKIM yang selaras memenuhi syarat sepenuhnya, dan tetap sepenuhnya bisa dipalsukan. Mandat itu menormalkan dokumen administratif, bukan perlindungannya. Wilayah tengah yang tidak menegakkan itu — patuh, dipublikasikan, bisa dipalsukan — persis merupakan celah yang diukur sensus ini, dan ia adalah populasi terbesar dalam keamanan email.

Jadi, dengan apa record Anda seharusnya berakhir?

Anda mengirim surat dan penerusan itu penting (buletin, milis, alias): ~all dengan DMARC p=reject di belakangnya — pasangan yang direkomendasikan di atas.
Anda mengirim surat dari setup yang terkontrol ketat: -all berfungsi dan menyatakan kebijakannya di dalam record itu sendiri. Petakan pengirim Anda dulu — akhiran ketat pada record yang belum dipetakan merusak surat asli, atau lebih buruk.
Domain tidak pernah mengirim: -all plus p=reject, hari ini juga. Tidak ada yang sah untuk dilindungi, jadi tidak ada yang bisa rusak.

Akhiran mana pun yang Anda pilih, pelajaran satu baris dari sensus tetap berlaku: qualifier hanya sepenting apa yang menegakkannya. Di mana posisi Anda pada tangga itu bisa diukur.

Pertanyaan yang sering diajukan

Apakah SPF ~all atau -all yang lebih baik? Tidak ada yang mutlak lebih baik. ~all dengan kebijakan DMARC yang menegakkan adalah pola yang direkomendasikan pedoman Google — perlindungan setara di penerima yang mengevaluasi DMARC tanpa merusak surat yang diteruskan. -all cocok untuk pengirim yang terkontrol ketat. ~all sendirian — kondisi semua domain softfail kecuali 1 dari 11 — adalah opsi yang lemah.

Apa arti SPF softfail? ~all memberi tahu penerima bahwa surat dari server yang tidak terdaftar kemungkinan tidak sah tetapi tetap harus diterima, biasanya dengan kecurigaan. Ia menjadi perlindungan nyata hanya ketika sebuah kebijakan DMARC bertindak atas kegagalan itu; lihat SPF tanpa DMARC.

Apakah hardfail -all akan merusak email saya yang diteruskan? Bisa: penerusan mengirim ulang surat Anda dari server penerus, yang tidak tercantum dalam SPF Anda, dan sebuah hardfail mengundang penolakan sebelum DKIM atau DMARC ikut menilai. Risiko itulah alasan keberadaan pasangan ~all + p=reject.

Apakah Google dan Microsoft mewajibkan -all sekarang? Tidak. Mandat pengirim massal mewajibkan autentikasi yang selaras dan lolos serta sebuah record DMARC minimal p=none — tanpa penegakan, tanpa qualifier tertentu. Penolakan Google atas surat massal yang tidak patuh sudah aktif; Microsoft telah mengarahkan kegagalan ke folder junk dan bergerak menuju penolakan langsung. Kepatuhan bukanlah perlindungan.

Periksa dengan apa record Anda berakhir — dan apa yang berdiri di belakangnya

Dua pencarian memberi tahu Anda keduanya, gratis, dalam 30 detik. Jika Anda salah satu dari 70.4 juta gestur mengangkat bahu yang tidak menegakkan, perbaikannya adalah sebuah record DNS, bukan sebuah pembelian.

Periksa domain Anda → · Perbaiki SPF → · Perbaiki DMARC → · Model kematangan SPF → · Peta +all → · Hanya data agregat. Data disimpan dan diproses di UE.