Defaults.Exposed › Pembaikan › SPF (Sender Policy Framework)

Cara memperbaiki SPF (Sender Policy Framework)

SPF ialah satu baris dalam tetapan domain anda yang menyenaraikan perkhidmatan mel mana yang dibenarkan menghantar e-mel bagi pihak perniagaan anda. Tanpanya, sesiapa sahaja di dunia boleh menghantar e-mel yang kelihatan datang dari anda — dan e-mel tulen anda sendiri lebih berkemungkinan tersimpan dalam folder spam pelanggan.

Kesimpulan untuk perniagaan anda: Sesiapa boleh menghantar e-mel dengan menyamar sebagai perniagaan anda — kepada pelanggan, kakitangan, dan pembekal — invois, permintaan pertukaran pembayaran, semuanya. Pada masa yang sama, sebut harga dan invois sebenar anda lebih mudah dihantar ke folder spam, menyebabkan urusan perniagaan terhenti secara senyap.

Apakah kos yang boleh timbul

Seorang penipu menghantar e-mel kepada pelanggan anda dengan invois 'dari anda' yang menggunakan butiran bank mereka sendiri, dan mendapat bayaran. Anda hanya tahu berapa minggu kemudian apabila pelanggan menanya di mana barang mereka — dan kini nama baik anda, serta mungkin liabiliti anda, yang terjejas.
Sebut harga, invois, dan balasan anda secara senyap masuk ke folder spam pelanggan kerana pembekal mel besar tidak dapat mengesahkan ia benar-benar dari anda. Urusan perniagaan menjadi sejuk dan anda tidak pernah tahu punca sebenarnya.
Penipu menyamar sebagai pemilik atau orang kewangan anda dan menghantar e-mel kepada kakitangan meminta pembayaran segera atau kad hadiah — mesej itu benar-benar kelihatan datang dari domain anda, jadi seseorang membuat bayaran.
Prospek besar menjalankan semakan IT atau keselamatan ke atas domain anda, melihat tiada perlindungan penghantar, dan sama ada menarik diri atau meminta anda membetulkannya sebelum mereka menandatangani — menyebabkan anda kehilangan peluang perniagaan atau mengalami kelewatan berminggu-minggu.
Anda fikir anda dilindungi kerana rekod SPF wujud — tetapi ia ditetapkan kepada 'soft fail' tanpa apa-apa yang menguatkuasakannya, atau ia rosak secara senyap, jadi mel palsu masih boleh tiba.

Mengapa ia penting. Memalsukan alamat 'dari' dalam e-mel adalah sangat mudah dan tidak memerlukan kos daripada penyerang. SPF ialah cara paling murah dan cepat untuk menjadikan domain anda lebih sukar untuk disasar dan memastikan mel sah anda tidak tersimpan dalam spam. Google dan Yahoo kini secara aktif menjunk atau menolak mel dari domain yang tidak disahkan, jadi ini bukan lagi pilihan — ia adalah keperluan asas supaya e-mel anda dihantar langsung.

Versi ringkas

Sekarang, melainkan anda telah menetapkan SPF dengan betul, sesiapa sahaja di dunia boleh menghantar e-mel yang kelihatan datang dari perniagaan anda. Mereka boleh menghantar invois palsu kepada pelanggan anda, permintaan pembayaran palsu kepada kakitangan anda, dan menghantar e-mel kepada pembekal anda seolah-olah mereka adalah anda — dan mesej itu akan kelihatan tulen, kerana tiada apa-apa pada domain anda yang menyatakan sebaliknya.

SPF (Sender Policy Framework) ialah penyelesaiannya. Ia adalah satu baris teks dalam tetapan DNS domain anda yang menyenaraikan perkhidmatan mel mana yang sebenarnya dibenarkan menghantar e-mel sebagai anda. Pembekal mel penerima — Gmail, Outlook, semua sekali — menyemak senarai itu sebelum memutuskan sama ada mesej adalah tulen. Tiada senarai, atau senarai yang lemah, dan mereka tidak mempunyai apa-apa untuk dijadikan rujukan.

Halaman ini meliputi dua perkara yang mesti betul: sama ada rekod SPF wujud langsung, dan sama ada ia ditetapkan cukup ketat untuk melakukan tugasnya.

Apa yang ini boleh koskan anda

Ini adalah cara harian, dunia nyata apabila rekod SPF yang hilang atau lemah menjadi kehilangan wang dan kepercayaan. Kami tidak pernah menamakan perniagaan sebenar — ini adalah corak yang kami lihat merentas data.

Pengalihan invois. Penjenayah menghantar e-mel kepada pelanggan anda yang kelihatan persis seperti datang dari anda, melampirkan invois sebenar dengan akaun bank mereka sendiri. Pelanggan anda membayarnya. Perkara pertama yang anda dengar ialah pertanyaan tentang di mana pesanan itu — kini ada pelanggan yang marah, bayaran yang pergi kepada penjenayah, dan perbualan sukar tentang siapa yang menanggung kerugian.
Penipuan Ketua Pegawai Eksekutif/kewangan. Seseorang menghantar e-mel kepada akauntan anda “dari” pemilik: “Tolong segera — boleh awak proses pembayaran ini sebelum akhir hari?” Kerana mesej itu benar-benar kelihatan datang dari domain anda, ia tidak mencetuskan naluri sesiapa. Wang meninggalkan syarikat.
Cukai penghantaran senyap. Sebut harga dan invois anda mula masuk ke folder spam pelanggan kerana Gmail dan Yahoo tidak dapat mengesahkan ia benar-benar dari anda. Anda tidak mendapat notis lantunan, anda tidak mendapat ralat — urusan perniagaan hanya senyap. Anda kehilangan perniagaan dan anda tidak dapat melihatnya berlaku.
Kontrak yang hilang. Pasukan perolehan atau keselamatan klien yang lebih besar menjalankan semakan asas ke atas domain anda sebagai sebahagian daripada onboarding. Mereka melihat tiada pengesahan penghantar dan menanda anda sebagai risiko. Dalam kes terbaik, anda bergegas untuk membetulkannya di bawah tekanan tarikh akhir; dalam kes terburuk, mereka pergi ke pesaing yang lulus.
Gelombang pencemaran jenama. Domain anda digunakan dalam kempen pancingan data yang ditujukan kepada orang ramai. Orang yang terbakar kini tidak mempercayai setiap e-mel dengan nama anda — jadi tawaran dan pembaharuan tulen anda pun diabaikan atau dilaporkan.

Benang yang merentasi semua ini: penyerang tidak membelanjakan apa-apa, dan perniagaan anda menanggung kos dan tanggungjawab.

Apa yang ia sebenarnya

Apabila e-mel tiba, pelayan mel penerima ingin mengetahui satu perkara: adakah ini benar-benar dari orang yang didakwa? SPF menjawab sebahagian daripada soalan itu.

Anda menerbitkan sebaris teks pendek dalam tetapan DNS domain anda — “rekod TXT” — yang menamakan perkhidmatan mel yang dibenarkan menghantar bagi pihak anda. Sesuatu seperti:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Dalam istilah mudah, itu bermaksud: “Mel tulen dari kami datang dari pelayan Google dan pelayan SendGrid — tolak apa-apa yang lain yang mendakwa sebagai kami.”

Dua bahagian yang penting untuk gred anda:

Adakah rekod wujud? Ini adalah perkara utama (ia membawa paling banyak berat daripada mana-mana semakan e-mel tunggal). Tiada rekod bermakna penerima tidak mempunyai senarai untuk disemak, jadi peniruan adalah terbuka luas. Terdapat juga mod kegagalan halus di sini: jika domain anda mempunyai dua atau lebih rekod SPF, peraturan menyatakan semua daripadanya tidak sah — jadi anda secara berkesan tiada SPF langsung, walaupun kelihatan ada.
Adakah dasar cukup ketat? Rekod boleh wujud tetapi masih tidak berkesan. Penghujung — mekanisme “all” — adalah arahan kepada penerima:
- -all (hard fail) — tolak apa-apa yang tidak ada dalam senarai. Paling kuat. Markah penuh.
- ~all (soft fail) + DMARC ditetapkan kepada reject — persediaan moden yang disyorkan. Perlindungan setara dengan hard fail, tanpa risiko mel yang dipanjangkan melantun. Markah penuh.
- ~all + DMARC ditetapkan kepada quarantine — boleh diterima, sedikit lebih lemah; pindahkan DMARC ke reject untuk perlindungan penuh.
- ~all sahaja (tanpa penguatkuasaan DMARC) — lemah. Ini bermaksud “mungkin palsu, hantar juga.” Mel palsu masih boleh melalui. Ini adalah perangkap di mana banyak perniagaan fikir mereka dilindungi.
- ?all (neutral) — tidak memberikan perlindungan.
- +all — berbahaya secara aktif: ia memberitahu dunia sesiapa boleh menghantar sebagai anda. Jangan sekali-kali gunakan ini.

Terdapat satu lagi kegagalan tidak kelihatan: SPF hanya dibenarkan mencetuskan hingga 10 carian DNS apabila ia dinilai. Terlalu banyak entri include: dan rekod melebihi had itu, di mana penerima menganggap keseluruhan perkara rosak — dan anda kembali kepada tiada perlindungan. Ini adalah masalah biasa dan senyap bagi perniagaan yang menggunakan banyak alat pemasaran dan SaaS.

Apa yang “baik” kelihatan: tepat satu rekod SPF, menyenaraikan setiap perkhidmatan yang sah menghantar mel sebagai anda, berakhir dengan -all (atau ~all dipasangkan dengan DMARC pada p=reject), dan kekal selesa di bawah had 10 carian.

Cara membetulkannya (percuma, ~10 minit)

Berikan bahagian ini kepada sesiapa yang menguruskan domain atau laman web anda — dan perhatikan bahawa pembetulan adalah percuma. Ia adalah perubahan kepada tetapan DNS, bukan produk yang anda beli. Kami hanya mengenakan bayaran untuk memantau bahawa ia kekal betul dari masa ke masa, bukan untuk membuat perubahan.

Langkah 1 — Senaraikan setiap perkhidmatan yang menghantar e-mel sebagai anda. Inilah bahagian di mana orang tersalah. Tulis semua: pembekal peti mel anda (Google Workspace, Microsoft 365, dll.), ditambah dengan mana-mana alat surat berita, CRM, helpdesk, platform e-dagang, aplikasi invois/perakaunan, dan sistem tempahan. Jika perkhidmatan menghantar mel dengan nama anda dan anda terlupakannya, SPF anda akan menyekat melnya apabila anda mengetatkan dasar.

Langkah 2 — Terbitkan satu rekod TXT pada domain akar anda. Gabungkan baris “include” untuk semua penghantar anda ke dalam satu rekod. Mengikut platform biasa:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (atau domain yang sesuai dengan rantau)

Rekod gabungan kelihatan seperti:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Di mana untuk menambahnya, mengikut pembekal:

Cloudflare: DNS → Records → Add record → Type TXT, Name @, Content = nilai di atas.
Microsoft 365 / Google admin: mereka menerbitkan rentetan include tepat untuk digunakan dalam wizard persediaan mereka; salin ke dalam rekod TXT hos DNS anda.
GoDaddy / kebanyakan hos: pengurusan DNS → Add → TXT, Host/Name @, Value = rekod.

Langkah 3 — Mulakan selamat, kemudian kuatkuasa. Semasa anda mengesahkan senarai penghantar anda lengkap, terbitkan dengan ~all (soft fail) supaya tiada yang sah disekat secara tidak sengaja. Setelah anda mengesahkan semua mel tulen anda masih mengalir, ketatkan kepada -all (hard fail) — atau, lebih baik, kekalkan ~all dan tambah dasar DMARC p=reject, yang merupakan pasangan moden yang disyorkan.

Langkah 4 — Pastikan anda mempunyai tepat SATU rekod. Jika rekod SPF lama sudah wujud, edit yang itu dan bukannya menambah yang kedua. Dua rekod v=spf1 saling membatalkan dan membiarkan anda tidak dilindungi.

Langkah 5 — Perhatikan kiraan carian. Jika anda mempunyai ramai penghantar, anda boleh melebihi had 10 carian. Jika itu berlaku, gabungkan — sesetengah pembekal menawarkan “SPF flattening,” atau buang penghantar yang tidak lagi anda gunakan.

Langkah 6 — Semak semula domain anda untuk mengesahkan ia kini lulus, dengan rekod hadir dan dasar ketat.

Kesilapan biasa

Dua rekod SPF. Kegagalan senyap yang paling biasa. Menambah rekod baru dan bukannya mengedit yang sedia ada membatalkan kedua-duanya. Mesti ada tepat satu.
Berhenti pada ~all dan menganggap anda selesai. Soft fail tanpa DMARC di belakangnya adalah tanah tengah yang lemah — ia kelihatan dikonfigurasi tetapi hampir tidak melindungi anda. Sama ada pergi ke -all, atau pasangkan ~all dengan DMARC p=reject.
Terlupa seorang penghantar. Mengetatkan kepada -all sebelum menyenaraikan aplikasi invois, CRM, atau alat surat berita anda akan mula menyekat mel sah anda sendiri. Senaraikan semua dahulu.
Melebihi had 10 carian. Setiap include: boleh berantai kepada lebih banyak carian. Terlalu banyak dan rekod dianggap rosak. Pastikan ia ringkas.
Menggunakan +all. Ini secara eksplisit membenarkan seluruh internet menghantar sebagai anda. Ia lebih teruk daripada tidak mempunyai rekod. Jangan sekali-kali menerbitkannya.

Ke mana ini sesuai

SPF adalah asas, tetapi ia adalah satu daripada tiga lapisan. DKIM menambah tandatangan kriptografi yang membuktikan mesej tidak diubah, dan DMARC adalah arahan yang menghubungkan SPF dan DKIM bersama-sama dan memberitahu penerima apa yang sebenarnya perlu dilakukan dengan mel yang gagal — termasuk menyekat peniruan nama “dari” kelihatan yang pelanggan anda lihat. Betulkan SPF dahulu (ia adalah kemenangan tercepat dan membawa paling banyak berat), kemudian tambah DKIM dan DMARC untuk menutup pintu sepenuhnya. Ketiga-tiga pembetulan adalah percuma.

Sediakan pada hos anda

Langkah demi langkah untuk pembekal popular:

Soalan Lazim

Saya bukan orang teknikal — bolehkah saya menangani perkara ini sendiri?

Anda tidak perlu faham butirannya. Perubahan itu hanyalah satu atau dua baris yang ditambah pada tetapan domain anda, dilakukan oleh sesiapa yang menguruskan laman web atau pembekal IT anda. Berikan mereka bahagian 'Cara membetulkannya' di bawah — ia biasanya mengambil masa beberapa minit sahaja, dan percuma. Kami hanya mengenakan bayaran untuk memantau bahawa ia kekal betul dari masa ke masa.

Kami sudah ada rekod SPF — bukankah itu bermakna kami dilindungi?

Tidak semestinya. Mempunyai rekod ialah separuh pertama; menetapkannya secara ketat ialah separuh kedua. Rekod yang berakhir dengan '~all' (soft fail) tanpa DMARC di belakangnya memberitahu pelayan penerima 'ini mungkin palsu, tetapi hantar juga' — yang memberikan perlindungan minima. Dua rekod SPF, atau satu yang melakukan terlalu banyak carian, dianggap rosak dan tidak memberikan anda sebarang perlindungan walaupun kelihatan wujud. Kedua-dua bahagian mesti betul.

Adakah pembetulan ini akan memutuskan e-mel saya sendiri secara tidak sengaja?

Ia boleh berlaku jika rekod tersebut terlepas satu penghantar sah — misalnya aplikasi invois atau alat surat berita yang menghantar mel menggunakan nama anda. Itulah sebabnya pendekatan selamat adalah menyenaraikan setiap perkhidmatan yang menghantar mel sebagai anda terlebih dahulu, menerbitkan dengan soft '~all' semasa anda mengesahkan tiada yang terlepas, kemudian mengetatkan kepada hard fail. Dilakukan mengikut urutan itu, ia tidak akan memutuskan apa-apa.

Apakah perbezaan antara '~all' dan '-all', dan yang mana patut kami gunakan?

'-all' (hard fail) memberitahu penerima untuk menolak apa-apa yang tidak ada dalam senarai anda — tetapan paling kuat. '~all' (soft fail) bermaksud 'mungkin tidak sah, tetapi terima juga.' Cadangan amalan terbaik moden ialah '~all' digabungkan dengan dasar DMARC 'reject' — pasangan itu memberikan perlindungan yang sama dengan '-all' tanpa risiko mel yang dipanjangkan melantun. '~all' sahaja, tanpa DMARC menguatkuasakannya, adalah konfigurasi lemah yang perlu dielakkan.

Adakah SPF akan menghentikan semua penipuan e-mel dengan sendirinya?

Tidak — ia adalah lapisan pertama yang penting, bukan jawapan penuh. SPF menyatakan pelayan mana yang boleh menghantar untuk anda, tetapi ia tidak memberitahu penerima apa yang perlu dilakukan apabila mesej gagal, dan ia tidak merangkumi nama 'dari' yang kelihatan oleh pengguna. Untuk mengunci peniruan sepenuhnya, anda juga memerlukan DKIM dan DMARC. SPF adalah langkah pertama yang paling cepat dan memberi impak tertinggi, jadi mulakan di sini, kemudian tambah dua yang lain.

Berapa lama ia berkuat kuasa, dan adakah ia memerlukan kos?

Perubahan DNS biasanya berkuat kuasa dalam beberapa minit hingga beberapa jam. Pembetulan itu sendiri sentiasa percuma — ia hanya mengedit tetapan di pembekal DNS anda. Sesiapa yang memberitahu anda bahawa ia memerlukan produk berbayar untuk menambah rekod SPF adalah tersalah.