Saya belajar tentang SPF dengan cara yang keras—mengubah domain produksi dari softfail ke hardfail pada Jumat sore dan menyaksikan seluruh aliran email menghilang. Ternyata saya lupa tentang beberapa platform acara yang saya atur beberapa bulan sebelumnya. Kesalahan itu mengajarkan saya sesuatu yang sangat penting: sebelum Anda mengubah record SPF, Anda harus tahu setiap tempat email berasal, dan Anda harus siap menerima konsekuensinya jika Anda salah.



Izinkan saya menjelaskan apa yang benar-benar penting di sini. SPF (Sender Policy Framework) pada dasarnya adalah domain Anda memberi tahu server penerima: ini adalah record DNS TXT saya yang mencantumkan host mana yang secara sah dapat mengirim email atas nama saya. Ketika email tiba, penerima memeriksa record SPF Anda terhadap domain Return-Path, mengevaluasi mekanisme (ip4, ip6, a, mx, include), dan memutuskan apa yang harus dilakukan. Keputusan itu bergantung pada satu hal: kualifikasi Anda di akhir—mode yang Anda pilih.

Inilah perbedaan inti yang sering membingungkan orang. Softfail (~all) mengatakan "ini tampaknya tidak sah, tapi mungkin tidak apa-apa—berhati-hatilah." Biasanya ini memicu filter spam, bukan penolakan langsung. Hardfail (-all) mengatakan "hanya host yang saya daftar yang sah—blokir semuanya yang lain." Ini bersifat pasti, dan ketika digabungkan dengan penyelarasan DMARC, Anda mendapatkan penolakan pesan yang nyata.

Saya menganggapnya seperti staging versus produksi. Softfail adalah mode staging hati-hati saat Anda masih mencari tahu. Hardfail adalah memutuskan pemutus listrik di produksi dan menanggung konsekuensinya.

Jalur praktis yang saya ikuti adalah metodis: mulai dengan ?all untuk observasi murni, beralih ke softfail (~all) setelah Anda memantau laporan agregat DMARC, lalu beralih ke hardfail (-all) hanya setelah Anda memvalidasi setiap pengirim yang diotorisasi dan false positives Anda mendekati nol. Saya tidak pernah terburu-buru. Saya inventarisasi semuanya—CRM, otomatisasi pemasaran, tiket, HR, penagihan, bahkan hal aneh seperti printer. Saya konfirmasi vendor mana yang mendukung DKIM dan penyelarasan DMARC. Saya dokumentasikan siapa yang bertanggung jawab atas setiap perubahan.

Satu hal yang akan cepat menyusup: SPF memiliki batas 10 pencarian DNS yang keras. Saya pernah melihat orang menyusun include secara bertingkat sedalam mereka mencapai batas itu secara tiba-tiba, lalu semuanya rusak. Kurangi include Anda, utamakan rentang IP daripada rantai bersarang, dan hapus layanan yang tidak aktif. Jika pengirim massal secara konstan memutar IP, dorong mereka untuk menggunakan include yang stabil dengan SLA.

Pengalihan (forwarding) adalah jebakan lain. Ini merusak SPF karena IP yang terhubung berubah. Jika pengalihan menggunakan SRS (Sender Rewriting Scheme), Anda baik-baik saja. Jika tidak, softfail mungkin satu-satunya yang mencegah kesalahan yang tidak diinginkan. Inilah mengapa saya lebih mengandalkan DKIM dan penyelarasan DMARC untuk jalur tersebut.

Daftar pemeriksaan peluncuran dunia nyata yang telah saya perbaiki dari waktu ke waktu: petakan setiap server email dan alur kerja, validasi DKIM di mana saja, aktifkan DMARC pada p=none untuk telemetri, pindahkan SPF ke softfail dan pantau selama setidaknya dua siklus pengiriman, selidiki setiap pengirim tidak sah dan izinkan atau matikan alurnya, lalu lakukan peluncuran bertahap kebijakan reject dengan penegakan DMARC sebelum beralih ke hardfail. Langkah terakhir—hanya beralih ke hardfail ketika cakupan pengirim yang sah sudah lengkap—adalah hal yang tidak bisa dinegosiasikan.

Satu hal lagi yang saya perhatikan: Google dan Yahoo telah memperketat standar mereka secara signifikan. Penegakan kebijakan email sekarang menggabungkan mode SPF, tanda tangan DKIM, kebijakan DMARC, analisis konten, dan penilaian reputasi. Inilah sebabnya saya tidak pernah menganggap SPF secara terpisah. Hardfail SPF tanpa dukungan DKIM yang solid masih bisa menyebabkan masalah pengiriman jika pengalihan sering terjadi di lingkungan Anda.

Kesalahan terbesar yang saya lihat orang lakukan: menyusun include secara bertingkat sampai mereka melewati batas 10 pencarian, lupa vendor musiman yang mengirim sebagai domain Anda, menganggap DMARC akan menyelamatkan pengaturan SPF yang rusak, bergantung pada softfail selamanya sementara penyerang beradaptasi, atau beralih ke hardfail sebelum DKIM ada di mana-mana. Yang terakhir ini terutama—bagus untuk keamanan, sangat buruk untuk pengiriman jika pengalihan sering terjadi.

Jika Anda saat ini menggunakan softfail dan bertanya-tanya apakah harus beralih, jawabannya adalah: hanya saat Anda sudah siap. Apakah Anda sudah memvalidasi setiap pengirim? Apakah DKIM sudah selaras? Apakah false positives Anda mendekati nol? Jika jawaban ya untuk ketiganya, hardfail masuk akal. Jika tidak, bersabarlah. Softfail bukanlah keadaan permanen—itu adalah titik pemeriksaan.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
  • Hadiah
  • Komentar
  • Posting ulang
  • Bagikan
Komentar
Tambahkan komentar
Tambahkan komentar
Tidak ada komentar
  • Sematkan