SPF ~all lawan -all: Softfail atau Hardfail — Apa yang Dipilih oleh 139 Juta Rekod (2026)

Q: Adakah SPF ~all atau -all lebih baik?

Kedua-duanya tidak, secara universal. ~all dengan dasar DMARC yang menguatkuasakan ialah corak yang disyorkan oleh garis panduan Google — perlindungan setara di penerima yang menilai DMARC tanpa merosakkan mel yang dimajukan. -all sesuai untuk pengirim yang dikawal ketat. ~all bersendirian — keadaan semua kecuali 1 daripada 11 domain softfail — ialah pilihan yang lemah.

Q: Apakah maksud SPF softfail?

~all memberitahu penerima bahawa mel daripada pelayan yang tidak disenaraikan mungkin tidak sah tetapi masih patut diterima, biasanya dengan syak wasangka. Ia menjadi perlindungan sebenar hanya apabila dasar DMARC bertindak ke atas kegagalan itu; lihat SPF tanpa DMARC.

Diterbitkan 2026-07-03

Angka setakat 2026-06-29 · metodologi v7. Data banci agregat merentasi 261 juta domain yang digredkan. Semua angka adalah agregat — kami tidak pernah menerbitkan rekod sesuatu perniagaan individu. Lihat cara kami menggred.

Setiap rekod SPF berakhir dengan mekanisme “all” — keputusan ke atas mel dari mana-mana sumber yang tiada dalam senarai anda — dan internet secara majoritinya telah memilih yang lembut: 55.8% daripada 139 juta domain yang menerbitkan SPF berakhir dengan ~all (softfail), berbanding 39.3% yang berakhir dengan -all (hardfail). Satu aksara memisahkan “tolak pemalsuan” daripada “mungkin pemalsuan — hantar juga”. Yang mana satu betul untuk anda bergantung pada tetapan kedua yang kebanyakan pemilik tidak pernah konfigurasikan.

Apakah yang sebenarnya diberitahu oleh ~all dan -all kepada penerima?

-all (hardfail): “Tolak mel dari mana-mana tempat lain.” Satu penolakan tegas.
~all (softfail): “Mel dari tempat lain mungkin tidak sah — terima sahaja, mungkin tandakan ia.” Satu angkat bahu.
?all (neutral): “Tiada pendapat.” Dipilih oleh 3.0% penerbit; perlindungan hanya pada nama.
+all: “Sesiapa sahaja boleh menghantar sebagai saya.” Diterbitkan oleh 36,014 domain, dan lebih teruk daripada tiada rekod — masalah tikar-selamat-datang mempunyai laporannya sendiri.

Adakah ~all salah, kalau begitu? Hanya jika ia bersendirian — dan ia hampir selalu bersendirian

Softfail mempunyai hujah moden yang boleh dipertahankan: garis panduan pengirim Google, dan kebanyakan amalan kebolehsampaian bersamanya, menumpu pada ~all yang dipasangkan dengan dasar DMARC yang menguatkuasakan (p=reject). Gandingan ini melindungi sebaik -all di setiap penerima yang menilai DMARC — yang kini merangkumi semua penyedia peti mel utama — tanpa melantun-keras mel sah yang dimajukan, mangsa klasik -all. Dalam konfigurasi itu, angkat bahu itu mempunyai taring: DMARC membekalkan keputusan yang enggan diberikan oleh SPF.

Tetapi gandingan itulah maksud keseluruhannya, dan inilah apa yang ditambah oleh banci yang panduan persediaan tidak dapat berikan: daripada 77,484,057 rekod softfail di internet, hanya 7.1 juta — kira-kira 1 daripada 11 — mempunyai dasar DMARC yang menguatkuasakan di belakangnya. Untuk 70.4 juta domain yang lain, ~all adalah tepat seperti bunyinya. Rekod mereka mengenal pasti pemalsuan itu dan melambaikannya masuk.

Bukankah mandat 2024 telah membetulkan ini?

Tidak — dan perbezaan ini lebih penting daripada yang dicadangkan oleh kebanyakan liputan. Google dan Yahoo mula mewajibkan pengesahan daripada pengirim pukal pada Februari 2024, dengan Microsoft menyusul pada Mei 2025: SPF atau DKIM yang lulus dan sejajar, ditambah rekod DMARC pada minimum p=none. Mandat itu terhenti sebelum mewajibkan penguatkuasaan — sebuah domain dengan ~all, rekod p=none dan DKIM yang sejajar mematuhi sepenuhnya, dan kekal boleh dipalsukan sepenuhnya. Mandat itu menormalkan kerja kertas, bukan perlindungan. Bahagian tengah yang tidak dikuatkuasakan itu — patuh, diterbitkan, boleh dipalsukan — adalah tepatnya jurang yang diukur oleh banci ini, dan ia adalah populasi terbesar dalam keselamatan e-mel.

Jadi rekod anda patut berakhir dengan apa?

Anda menghantar mel dan pemajuan penting (surat berita, senarai mel, alias): ~all dengan DMARC p=reject di belakangnya — gandingan yang disyorkan di atas.
Anda menghantar mel daripada persediaan yang dikawal ketat: -all berfungsi dan menyatakan dasar itu dalam rekod itu sendiri. Petakan pengirim anda dahulu — pengakhiran ketat pada rekod yang tidak dipetakan merosakkan mel sebenar, atau lebih teruk.
Domain itu tidak pernah menghantar: -all ditambah p=reject, hari ini. Tiada apa-apa yang sah wujud untuk dilindungi, jadi tiada apa-apa untuk dirosakkan.

Yang mana pengakhiran anda pilih, pengajaran satu baris banci itu tetap sah: kelayakan itu hanya penting sebanyak apa yang menguatkuasakannya. Di mana anda berdiri pada tangga itu boleh diukur.

Soalan lazim

Adakah SPF ~all atau -all lebih baik? Kedua-duanya tidak, secara universal. ~all dengan dasar DMARC yang menguatkuasakan ialah corak yang disyorkan oleh garis panduan Google — perlindungan setara di penerima yang menilai DMARC tanpa merosakkan mel yang dimajukan. -all sesuai untuk pengirim yang dikawal ketat. ~all bersendirian — keadaan semua kecuali 1 daripada 11 domain softfail — ialah pilihan yang lemah.

Apakah maksud SPF softfail? ~all memberitahu penerima bahawa mel daripada pelayan yang tidak disenaraikan mungkin tidak sah tetapi masih patut diterima, biasanya dengan syak wasangka. Ia menjadi perlindungan sebenar hanya apabila dasar DMARC bertindak ke atas kegagalan itu; lihat SPF tanpa DMARC.

Adakah hardfail -all akan merosakkan e-mel saya yang dimajukan? Boleh: pemajuan menghantar semula mel anda daripada pelayan pemaju, yang tidak disenaraikan oleh SPF anda, dan hardfail menjemput penolakan sebelum DKIM atau DMARC mengambil kira. Risiko itulah sebab gandingan ~all + p=reject wujud.

Adakah Google dan Microsoft mewajibkan -all sekarang? Tidak. Mandat pengirim pukal mewajibkan pengesahan yang sejajar dan lulus serta rekod DMARC pada minimum p=none — tiada penguatkuasaan, tiada kelayakan tertentu. Penolakan Google terhadap mel pukal yang tidak patuh telah aktif; Microsoft telah membuang kegagalan ke dalam sampah dan bergerak ke arah penolakan langsung. Pematuhan bukanlah perlindungan.

Semak apa yang rekod anda akhiri — dan apa yang menyokongnya

Dua carian memberitahu anda kedua-duanya, percuma, dalam 30 saat. Jika anda salah satu daripada 70.4 juta angkat bahu yang tidak dikuatkuasakan itu, pembaikannya ialah rekod DNS, bukan pembelian.

Semak domain anda → · Baiki SPF → · Baiki DMARC → · Model kematangan SPF → · Peta +all → · Data agregat sahaja. Data disimpan dan diproses di EU.