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

Cara memperbaiki SPF (Sender Policy Framework)

SPF adalah baris teks di pengaturan domain Anda yang menentukan layanan email mana saja yang berhak mengirim email atas nama bisnis Anda. Tanpa SPF, siapa pun di seluruh dunia bisa mengirim email yang seolah-olah berasal dari Anda — dan email asli Anda justru lebih mudah masuk ke folder spam pelanggan.

Intinya bagi bisnis Anda: Siapa pun bisa mengirim email yang mengatasnamakan bisnis Anda — kepada pelanggan, karyawan, dan pemasok — berupa tagihan palsu, permintaan perubahan rekening, dan lain sebagainya. Di sisi lain, penawaran dan tagihan asli Anda lebih berisiko masuk spam, sehingga transaksi terhenti tanpa Anda sadari.

Kerugian yang dapat ditimbulkan

Penipu mengirim email ke pelanggan Anda berupa tagihan 'dari Anda' dengan nomor rekening milik mereka sendiri, dan pelanggan membayarnya. Anda baru mengetahuinya berminggu-minggu kemudian ketika pelanggan menanyakan barang yang sudah dibayar — dan kini reputasi Anda yang dipertaruhkan, bahkan mungkin tanggung jawab hukum.
Penawaran, tagihan, dan balasan email Anda diam-diam masuk ke folder spam pelanggan karena penyedia email besar tidak bisa memverifikasi bahwa email itu benar-benar dari Anda. Transaksi gagal dan Anda tidak pernah tahu alasannya.
Penipu menyamar sebagai pemilik atau staf keuangan Anda dan mengirim email ke karyawan meminta pembayaran mendesak atau transfer dana — pesan itu terlihat benar-benar berasal dari domain Anda, sehingga seseorang akhirnya mengirimkan uang.
Tim IT atau keamanan calon klien besar memeriksa domain Anda, melihat tidak ada perlindungan pengirim, lalu membatalkan kerja sama atau meminta Anda memperbaikinya sebelum kontrak ditandatangani — berujung gagalnya transaksi atau penundaan berminggu-minggu.
Anda mengira sudah terlindungi karena ada SPF record — padahal diatur sebagai 'soft fail' tanpa enforcement apa pun, atau diam-diam rusak, sehingga email palsu tetap lolos.

Mengapa ini penting. Memalsukan alamat 'from' pada email sangat mudah dan tidak memerlukan biaya apa pun bagi penyerang. SPF adalah cara tercepat dan termurah untuk mempersulit pemalsuan domain Anda sekaligus menjaga agar email sah Anda tidak masuk spam. Google dan Yahoo kini secara aktif membuang atau menolak email dari domain yang tidak terautentikasi, sehingga ini bukan lagi pilihan — ini adalah syarat dasar agar email Anda terkirim.

Singkatnya

Saat ini, jika SPF tidak diatur dengan benar, siapa pun di seluruh dunia bisa mengirim email yang tampak berasal dari bisnis Anda. Mereka bisa mengirim tagihan palsu ke pelanggan Anda, mengirim permintaan pembayaran palsu ke karyawan Anda, dan menghubungi pemasok Anda seolah-olah mereka adalah Anda — dan pesannya akan terlihat asli, karena tidak ada di domain Anda yang mengatakan sebaliknya.

SPF (Sender Policy Framework) adalah solusinya. Ini adalah satu baris teks di pengaturan DNS domain Anda yang mencantumkan layanan email mana saja yang benar-benar boleh mengirim email atas nama Anda. Penyedia email penerima — Gmail, Outlook, semua — memeriksa daftar itu sebelum memutuskan apakah pesan itu asli. Tanpa daftar, atau daftar yang lemah, mereka tidak punya acuan.

Halaman ini mencakup dua hal yang keduanya harus benar: apakah SPF record ada sama sekali, dan apakah pengaturannya cukup ketat untuk benar-benar berfungsi.

Dampak finansial yang perlu diketahui

Berikut adalah cara nyata sehari-hari di mana SPF yang hilang atau lemah berujung pada kerugian uang dan kepercayaan. Kami tidak menyebut nama bisnis nyata — ini adalah pola yang kami lihat dari data.

Pengalihan tagihan palsu. Seorang kriminal mengirimkan tagihan yang terlihat persis seperti milik Anda ke pelanggan Anda, dengan rekening bank milik mereka sendiri. Pelanggan membayarnya. Pertama kali Anda mendengarnya adalah ketika mereka menagih pesanan yang belum datang. Kini ada pelanggan marah, pembayaran yang masuk ke rekening kriminal, dan percakapan sulit tentang siapa yang menanggung kerugian.
Penipuan CEO/keuangan. Seseorang mengirim email ke staf akuntansi Anda “dari” pemilik: “Tolong bantu proses pembayaran ini sebelum akhir hari ini.” Karena pesan itu benar-benar tampak berasal dari domain Anda, tidak ada yang curiga. Uang pun keluar.
Dampak tersembunyi pada ketercapaian email. Penawaran dan tagihan Anda mulai masuk ke folder spam pelanggan karena Gmail dan Yahoo tidak bisa memverifikasi bahwa email itu benar-benar dari Anda. Anda tidak mendapat pesan error — transaksi hanya tiba-tiba terhenti. Anda kehilangan bisnis tanpa bisa melihatnya terjadi.
Kontrak yang gagal. Tim pengadaan atau keamanan klien besar melakukan pemeriksaan dasar pada domain Anda saat proses orientasi. Mereka melihat tidak ada autentikasi pengirim dan menandai Anda sebagai risiko. Dalam skenario terbaik, Anda harus bergegas memperbaikinya di bawah tekanan tenggat; dalam skenario terburuk, mereka memilih kompetitor yang lolos pemeriksaan.
Gelombang kerusakan merek. Domain Anda digunakan dalam kampanye phishing yang menyasar publik. Orang-orang yang tertipu kini tidak mempercayai setiap email dengan nama Anda — bahkan penawaran dan pembaruan asli Anda diabaikan atau dilaporkan.

Benang merah dari semua ini: penyerang tidak mengeluarkan biaya apa pun, dan bisnis Anda yang menanggung kerugian dan menerima kecaman.

Penjelasan teknis

Ketika email tiba, server email penerima ingin mengetahui satu hal: apakah ini benar-benar dari siapa yang diklaim? SPF menjawab sebagian pertanyaan itu.

Anda menerbitkan sebuah baris teks pendek di pengaturan DNS domain Anda — sebuah “TXT record” — yang menyebutkan layanan email yang diizinkan mengirim atas nama Anda. Misalnya:

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

Dalam bahasa sederhana, artinya: “Email asli dari kami berasal dari server Google dan server SendGrid — tolak semua yang lain yang mengaku dari kami.”

Dua bagian yang menentukan nilai Anda:

Apakah record ada? Ini yang terpenting (memiliki bobot terbesar dari semua pemeriksaan email tunggal). Tanpa record, penerima tidak punya daftar untuk diperiksa, sehingga pemalsuan identitas terbuka lebar. Ada juga kegagalan tersembunyi: jika domain Anda memiliki dua atau lebih SPF record, aturannya menyatakan semua tidak valid — sehingga Anda praktis tidak memiliki SPF sama sekali, meski terlihat ada.
Apakah kebijakannya cukup ketat? Record bisa ada tapi tetap tidak berguna. Akhiran — mekanisme “all” — adalah instruksi kepada penerima:
- -all (hard fail) — tolak semua yang tidak ada di daftar. Terkuat. Nilai penuh.
- ~all (soft fail) + DMARC diatur ke reject — pengaturan modern yang direkomendasikan. Perlindungan setara hard fail tanpa risiko email yang diteruskan memantul. Nilai penuh.
- ~all + DMARC diatur ke quarantine — dapat diterima, sedikit lebih lemah; pindahkan DMARC ke reject untuk perlindungan penuh.
- ~all sendiri (tanpa enforcement DMARC) — lemah. Ini berarti “kemungkinan palsu, tetap dikirimkan.” Email palsu tetap lolos. Ini adalah jebakan yang banyak bisnis terjebak di dalamnya dengan mengira sudah terlindungi.
- ?all (netral) — tidak memberikan perlindungan.
- +all — berbahaya secara aktif: memberi tahu dunia bahwa siapa pun boleh mengirim sebagai Anda. Jangan pernah gunakan ini.

Ada satu kegagalan tak terlihat lagi: SPF hanya diizinkan memicu hingga 10 pencarian DNS saat dievaluasi. Terlalu banyak entri include: dan record melampaui batas itu, di mana penerima menganggap semuanya rusak — dan Anda kembali ke tanpa perlindungan. Ini adalah masalah diam-diam yang umum bagi bisnis yang menggunakan banyak alat marketing dan SaaS.

Seperti apa “baik” itu: tepat satu SPF record, mencantumkan setiap layanan yang secara sah mengirim email atas nama Anda, diakhiri dengan -all (atau ~all dipasangkan dengan DMARC di p=reject), dan tetap nyaman di bawah batas 10 pencarian.

Cara memperbaikinya (gratis, ~10 menit)

Berikan bagian ini kepada siapa pun yang mengelola domain atau website Anda — dan catat bahwa perbaikannya gratis. Ini adalah perubahan pada pengaturan DNS, bukan produk yang dibeli. Kami hanya mengenakan biaya untuk memantau agar tetap benar dari waktu ke waktu, bukan untuk melakukan perubahan.

Langkah 1 — Daftarkan semua layanan yang mengirim email atas nama Anda. Ini adalah bagian yang sering salah. Tuliskan semuanya: penyedia email (Google Workspace, Microsoft 365, dll.), plus alat newsletter, CRM, helpdesk, platform e-commerce, aplikasi faktur/akuntansi, dan sistem pemesanan. Jika ada layanan yang mengirim email dengan nama Anda dan Anda melupakannya, SPF Anda akan memblokir emailnya ketika Anda memperketat kebijakan.

Langkah 2 — Terbitkan satu TXT record di domain utama Anda. Gabungkan baris “include” untuk semua pengirim Anda menjadi satu record. Per platform umum:

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 sesuai wilayah)

Record gabungan terlihat seperti:

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

Cara menambahkannya, per penyedia:

Cloudflare: DNS → Records → Add record → Type TXT, Name @, Content = nilai di atas.
Microsoft 365 / Google admin: mereka menerbitkan string include yang tepat untuk digunakan di wizard pengaturan mereka; salin ke dalam TXT record host DNS Anda.
GoDaddy / kebanyakan host: DNS management → Add → TXT, Host/Name @, Value = record tersebut.

Langkah 3 — Mulai aman, lalu tegakkan. Saat mengonfirmasi daftar pengirim sudah lengkap, terbitkan dengan ~all (soft fail) agar tidak ada yang sah yang terblokir. Setelah mengonfirmasi semua email asli masih mengalir, perketat ke -all (hard fail) — atau lebih baik, pertahankan ~all dan tambahkan kebijakan DMARC p=reject, yang merupakan pasangan modern yang direkomendasikan.

Langkah 4 — Pastikan Anda hanya memiliki SATU record. Jika SPF record lama sudah ada, edit itu daripada menambahkan yang kedua. Dua record v=spf1 saling membatalkan dan membuat Anda tidak terlindungi.

Langkah 5 — Perhatikan jumlah pencarian. Jika Anda memiliki banyak pengirim, Anda bisa melampaui batas 10 pencarian. Jika itu terjadi, konsolidasikan — beberapa penyedia menawarkan “SPF flattening,” atau hapus pengirim yang tidak lagi digunakan.

Langkah 6 — Periksa ulang domain Anda untuk mengonfirmasi sekarang sudah lolos, dengan record yang ada dan kebijakan yang ketat.

Kesalahan umum

Dua SPF record. Kegagalan diam-diam yang paling umum. Menambahkan record baru alih-alih mengedit yang sudah ada membatalkan keduanya. Harus ada tepat satu.
Berhenti di ~all dan mengira sudah selesai. Soft fail tanpa DMARC di belakangnya adalah titik tengah yang lemah — terlihat sudah dikonfigurasi tapi hampir tidak melindungi Anda. Pergi ke -all, atau pasangkan ~all dengan DMARC p=reject.
Melupakan pengirim. Memperketat ke -all sebelum mencantumkan aplikasi faktur, CRM, atau alat newsletter Anda akan mulai memblokir email sah Anda sendiri. Daftarkan semua terlebih dahulu.
Melampaui batas 10 pencarian. Setiap include: bisa berantai ke pencarian lebih banyak. Terlalu banyak dan record dianggap rusak. Jaga agar tetap ringkas.
Menggunakan +all. Ini secara eksplisit mengizinkan seluruh internet untuk mengirim sebagai Anda. Ini lebih buruk dari tidak memiliki record sama sekali. Jangan pernah menerbitkannya.

Posisi dalam ekosistem email

SPF adalah fondasi, tapi ini hanya satu dari tiga lapisan. DKIM menambahkan tanda tangan kriptografis yang membuktikan pesan tidak dimanipulasi, dan DMARC adalah instruksi yang mengikat SPF dan DKIM bersama serta memberi tahu penerima apa yang harus dilakukan dengan email yang gagal — termasuk memblokir pemalsuan nama “from” yang terlihat oleh pelanggan Anda. Perbaiki SPF terlebih dahulu (ini adalah kemenangan tercepat dan memiliki bobot terbesar), kemudian tambahkan DKIM dan DMARC untuk menutup pintu sepenuhnya. Ketiga perbaikan ini gratis.

Atur di host Anda

Langkah demi langkah untuk penyedia populer:

FAQ

Saya tidak paham teknis — bisakah saya menangani ini sendiri?

Anda tidak perlu memahami detailnya. Perubahan ini hanya satu atau dua baris yang ditambahkan ke pengaturan domain Anda, dilakukan oleh siapa pun yang mengelola website atau penyedia IT Anda. Berikan bagian 'Cara memperbaikinya' di bawah kepada mereka — biasanya hanya butuh beberapa menit, dan gratis. Kami hanya mengenakan biaya untuk memantau agar pengaturan tetap benar dari waktu ke waktu.

Kami sudah punya SPF record — apa itu belum cukup?

Belum tentu. Memiliki record adalah setengah langkah pertama; mengatur dengan ketat adalah setengah lagi. Record yang diakhiri '~all' (soft fail) tanpa DMARC di belakangnya memberi tahu server penerima 'ini mungkin palsu, tapi tetap dikirimkan' — perlindungan yang hampir tidak ada. Dua SPF record, atau satu yang melebihi batas pencarian, dianggap rusak dan tidak memberi perlindungan sama sekali meski terlihat ada. Kedua bagian harus benar.

Apakah memperbaiki ini bisa mengganggu pengiriman email saya sendiri?

Bisa, jika record tidak mencantumkan semua pengirim sah — misalnya aplikasi faktur atau alat newsletter yang mengirim email atas nama Anda. Itulah mengapa pendekatan aman adalah dengan mencantumkan semua layanan yang mengirim email terlebih dahulu, menerbitkan dengan '~all' sambil memastikan tidak ada yang terlewat, baru kemudian memperketat ke hard fail. Dilakukan dalam urutan itu, tidak akan ada gangguan.

Apa perbedaan antara '~all' dan '-all', dan mana yang harus kami gunakan?

'-all' (hard fail) memberi tahu penerima untuk menolak apa pun yang tidak ada di daftar — pengaturan terkuat. '~all' (soft fail) berarti 'kemungkinan tidak sah, tapi tetap diterima.' Rekomendasi terbaik saat ini adalah '~all' dikombinasikan dengan kebijakan DMARC 'reject' — pasangan ini memberikan perlindungan setara '-all' tanpa risiko email yang diteruskan memantul. '~all' sendiri tanpa DMARC adalah konfigurasi lemah yang harus dihindari.

Apakah SPF akan menghentikan semua pemalsuan email sepenuhnya?

Tidak — ini adalah lapisan pertama yang penting, bukan satu-satunya jawaban. SPF menentukan server mana yang boleh mengirim untuk Anda, tapi tidak memberi tahu penerima apa yang harus dilakukan ketika pesan gagal, dan tidak mencakup nama 'from' yang terlihat oleh pengguna. Untuk menutup pemalsuan sepenuhnya, Anda juga butuh DKIM dan DMARC. SPF adalah langkah pertama tercepat dengan dampak terbesar, jadi mulai dari sini, lalu tambahkan keduanya.

Berapa lama sampai berlaku, dan apakah ada biayanya?

Perubahan DNS biasanya berlaku dalam hitungan menit hingga beberapa jam. Perbaikannya sendiri selalu gratis — hanya mengedit pengaturan di penyedia DNS Anda. Siapa pun yang mengatakan perlu membeli produk berbayar untuk menambah SPF record adalah keliru.