Saya belajar dengan cara keras apa arti SPF sebenarnya. Suatu Jumat sore saya mengubah domain produksi kami dari mode softfail ke hardfail, lupa sama sekali tentang platform acara yang kami buat beberapa bulan lalu. Email-email itu hilang begitu saja. Jumat itu mengajarkan saya sesuatu yang penting: apakah Anda benar-benar tahu dari mana semua email Anda berasal, dan apakah Anda siap menghadapi konsekuensi pengiriman jika Anda salah?

Sejak saat itu, saya memperlakukan perubahan SPF seperti pilot memperlakukan daftar periksa—metodis, dengan pengaman, dan tidak pernah terburu-buru.

Izinkan saya menjelaskan apa yang sebenarnya terjadi di balik layar. SPF (kerangka kebijakan pengirim) adalah sistem otentikasi email berbasis DNS. Anda menerbitkan catatan SPF sebagai catatan TXT DNS di domain Anda yang memberi tahu server penerima mana host yang diizinkan mengirim email atas nama Anda. Server-server tersebut memeriksa mekanisme Anda (ip4, ip6, a, mx, include) dan kualifikasi, lalu menghasilkan hasil: pass, none, neutral, softfail, hardfail, temperror, atau permerror.

Perbedaan utama terletak pada kualifikasi terminal tersebut. Softfail (~all) mengatakan "ini tampaknya tidak sah, tetapi lanjutkan dengan hati-hati." Hardfail (-all) mengatakan "hanya host yang terdaftar yang sah—blokir semuanya yang lain." Satu karakter ini mengubah cara penyedia kotak surat memperlakukan pesan Anda.

Di sinilah hal praktis mulai berlaku. Dengan softfail, Anda biasanya melihat penempatan di folder spam atau karantina. Dengan hardfail, terutama saat penyesuaian DMARC sudah diterapkan, Anda bisa mendapatkan penolakan langsung di server email. Microsoft 365 dan Outlook cenderung menggabungkan SPF dengan DKIM dan filter konten. Google dan Yahoo sangat bergantung pada DMARC dan reputasi pengirim. Jadi, softfail mungkin masuk ke Promosi; hardfail dengan penyesuaian DMARC bisa berarti pemblokiran tegas.

Saya tidak langsung beralih ke hardfail. Jalur saya selalu: netral (?all) → softfail (~all) → hardfail (-all). Saat penemuan, ketika saya tidak yakin tentang alur email lama atau rentang IP vendor, saya gunakan softfail. Ini menandai penyalahgunaan domain tanpa mengurangi pengiriman secara drastis saat saya inventarisasi semua sumber pengiriman—CRM, otomatisasi pemasaran, tiket, HR, keuangan, bahkan printer.

Setelah saya memvalidasi setiap pengirim yang diizinkan dan DKIM konsisten di mana-mana, baru saya beralih ke hardfail. Risiko yang diambil nyata: softfail memberi Anda pengiriman yang lebih baik selama inventarisasi tetapi risiko lebih tinggi bahwa phishing lolos sebagai spam alih-alih diblokir. Hardfail memberi keamanan yang lebih kuat tetapi bisa memutus email yang sah jika Anda melewatkan pengirim tertentu.

Saya pernah melihat tim melewati batas 10 pencarian DNS dengan terlalu banyak nested include. Saya pernah melihat mereka lupa vendor musiman seperti Livestorm atau webhook Prismic. Dan saya pernah menyaksikan orang menganggap DMARC akan menyelamatkan catatan SPF yang rusak—itu tidak akan, kecuali ada penyesuaian.

Pelajaran sebenarnya: perlakukan SPF, DKIM, dan DMARC sebagai satu sistem, bukan bagian terpisah. Pengalihan email memecah SPF karena IP yang terhubung berubah. Jika Anda menggunakan SRS (Sender Rewriting Scheme), Anda baik-baik saja. Jika tidak, softfail mungkin satu-satunya yang mencegah kesalahan pengiriman. Itulah mengapa saya memantau laporan agregat DMARC secara obsesif dan membaca header Authentication-Results saat sesuatu gagal.

Rollout aman saya: petakan dulu semua server email dan alur kerja, validasi DKIM di mana-mana, aktifkan DMARC pada p=none untuk telemetri, ubah SPF ke softfail dan pantau selama dua siklus pengiriman, selidiki setiap pengirim yang tidak sah, lalu lakukan uji coba kebijakan reject sebelum beralih ke hardfail.

Dalam beberapa tahun terakhir, Google dan Yahoo memperketat persyaratan otentikasi. Penegakan kebijakan semakin multi-sinyal: mode SPF, tanda tangan DKIM, kebijakan DMARC, konten, dan reputasi semuanya penting. Itulah sebabnya saya tidak pernah memperlakukan SPF secara terpisah. Hardfail SPF tanpa DKIM yang kokoh masih bisa berbalik merugikan pengiriman jika pengalihan sering dilakukan.

Kesalahan terbesar yang masih saya lihat: tim beralih ke hardfail sebelum DKIM merata, atau mereka mengandalkan softfail selamanya sementara penyerang beradaptasi dan spoofing email berkembang dalam ketidakpastian itu. Ini adalah keseimbangan, tetapi jalurnya jelas jika Anda melakukannya secara metodis.