Sender Policy Framework (SPF): Definisi & Cara Kerja
Sender Policy Framework (SPF) adalah protokol autentikasi email yang memungkinkan pemilik domain menentukan server mana yang berhak mengirim email atas nama domain mereka. Dengan SPF, server penerima dapat memverifikasi apakah email yang masuk berasal dari sumber yang sah atau dari pelaku yang memalsukan alamat pengirim.
Di Indonesia, email spoofing menjadi salah satu modus penipuan digital yang terus meningkat. IASC mencatat phishing mendominasi kasus fraud keuangan dengan 13.386 laporan dan kerugian Rp507 miliar. SPF adalah lapisan pertahanan pertama yang secara teknis memblokir email palsu sebelum sampai ke kotak masuk korban.
Apa Itu Sender Policy Framework (SPF) dan Mengapa Bisnis Membutuhkannya?
SPF bekerja dengan cara yang sederhana: pemilik domain mempublikasikan daftar server email yang diizinkan dalam DNS record mereka. Ketika sebuah email masuk, server penerima memeriksa DNS domain pengirim dan membandingkan IP server asal dengan daftar yang tercatat di SPF record.
Tanpa SPF, siapa pun dapat mengirim email dengan mengklaim berasal dari domain Anda. Modus ini digunakan pelaku fraud untuk mengirim email palsu yang seolah-olah berasal dari bank, lembaga keuangan, atau perusahaan teknologi resmi, lalu mengarahkan korban ke situs phishing atau formulir pengisian data palsu.
| Kondisi | Tanpa SPF | Dengan SPF |
|---|---|---|
| Email palsu dari domain Anda | Lolos ke inbox penerima | Ditandai spam atau ditolak otomatis |
| Phishing mengatasnamakan brand | Sulit dideteksi sistem penerima | Terblokir di level server email |
| Deliverability email legitimate | Risiko masuk folder spam karena reputasi domain tidak terverifikasi | Reputasi domain terjaga, deliverability meningkat |
| Audit keamanan email | Tidak ada log sumber pengiriman | Setiap pengecekan SPF tercatat untuk analisis |
Cara Kerja Sender Policy Framework dalam Proses Pengiriman Email
Proses verifikasi SPF terjadi secara otomatis di tingkat protokol dan berlangsung dalam hitungan milidetik:
Langkah 1: Email Dikirim dari Server Pengirim
Server pengirim mengirimkan email dengan header yang mencantumkan domain pengirim (contoh: @verihubs.com) dan alamat IP server asal pengiriman.
Langkah 2: Server Penerima Cek DNS SPF Record
Server penerima mengambil SPF record dari DNS domain pengirim. SPF record adalah file TXT di DNS yang berisi daftar IP atau hostname server yang diizinkan mengirim email atas nama domain tersebut.
Langkah 3: Pencocokan IP dan Keputusan
Server penerima mencocokkan IP server pengirim dengan daftar dalam SPF record. Hasilnya adalah salah satu dari tiga status:
- Pass: IP cocok, email diterima sebagai legitimate.
- Fail: IP tidak ada dalam daftar, email ditandai sebagai tidak sah.
- SoftFail: IP tidak cocok tetapi domain tidak menetapkan penolakan keras, email tetap diterima dengan tanda peringatan.
Komponen dan Mekanisme dalam SPF Record
SPF record adalah string teks di DNS yang mengandung beberapa mekanisme untuk mendefinisikan server yang diizinkan:
| Mekanisme | Fungsi | Contoh |
|---|---|---|
ip4 | Izinkan pengiriman dari alamat IPv4 spesifik | ip4:192.168.1.1 |
ip6 | Izinkan pengiriman dari alamat IPv6 spesifik | ip6:2001:db8::1 |
include | Merujuk ke SPF record domain lain (berguna untuk layanan email pihak ketiga) | include:_spf.google.com |
a | Izinkan server yang IP-nya sesuai A record domain | a:mail.verihubs.com |
mx | Izinkan server yang terdaftar sebagai MX record domain | mx |
all | Aturan akhir: -all tolak semua selain yang listed, ~all softfail | -all |
Contoh SPF record lengkap: v=spf1 ip4:203.0.113.5 include:_spf.google.com -all
Record ini mengizinkan email dari IP 203.0.113.5 dan server Google Workspace, serta menolak keras semua sumber lainnya.
Penerapan SPF untuk Keamanan Email Bisnis di Sektor Keuangan Indonesia
Fintech dan lembaga keuangan adalah target utama serangan email spoofing karena nama brand mereka memiliki tingkat kepercayaan tinggi di mata nasabah. Pelaku fraud memanfaatkan kepercayaan ini untuk mengirim email palsu berisi instruksi transfer, tautan verifikasi palsu, atau formulir pengisian data identitas.
Dalam konteks pencegahan penipuan digital, SPF berfungsi sebagai lapisan pertahanan di level komunikasi, memastikan brand email perusahaan tidak dapat disalahgunakan untuk menjangkau dan menipu nasabah.
Perusahaan yang menggunakan layanan email pihak ketiga seperti Google Workspace, Microsoft 365, atau platform marketing email perlu memastikan domain layanan tersebut tercantum dalam SPF record mereka melalui mekanisme include.
Keterbatasan SPF yang Perlu Dipahami Sebelum Implementasi
SPF efektif tetapi memiliki tiga keterbatasan yang perlu dipahami:
SPF Tidak Memverifikasi Header “From” yang Terlihat Pengguna
SPF hanya memverifikasi envelope sender (alamat teknis yang digunakan dalam protokol SMTP), bukan alamat “From” yang terlihat oleh penerima di email client. Pelaku masih bisa menampilkan alamat palsu di header “From” meskipun SPF aktif, teknik yang dikenal sebagai header spoofing.
Batas 10 DNS Lookup
SPF hanya mengizinkan maksimal 10 DNS lookup per pengecekan. Perusahaan yang menggunakan banyak layanan email pihak ketiga dan mencantumkan banyak mekanisme include berisiko melebihi batas ini, yang menyebabkan kegagalan validasi bahkan untuk email legitimate.
SPF Gagal Saat Email Diteruskan (Forwarding)
Ketika email diteruskan melalui server ketiga, IP server penerus tidak tercantum di SPF record domain asli, sehingga email akan gagal pengecekan SPF di server penerima akhir.
SPF, DKIM, dan DMARC: Tiga Pilar Autentikasi Email yang Saling Melengkapi
SPF sendiri tidak cukup untuk proteksi penuh. Tiga protokol autentikasi email harus diimplementasikan bersama untuk menutup semua celah:
| Protokol | Cara Kerja | Melindungi Dari |
|---|---|---|
| SPF | Memverifikasi server pengirim melalui DNS | Domain spoofing di level server |
| DKIM | Menandatangani email secara kriptografis | Modifikasi konten email saat transit |
| DMARC | Mendefinisikan kebijakan jika SPF atau DKIM gagal, dengan pelaporan | Header “From” spoofing, memberikan visibilitas penuh |
Kombinasi SPF + DKIM + DMARC membentuk ekosistem autentikasi email yang komprehensif. DMARC khususnya menutup celah SPF dalam kasus email forwarding dan header spoofing, sekaligus memberikan laporan harian tentang semua email yang menggunakan domain Anda. Pelajari lebih lanjut tentang cara kerja DMARC dan bagaimana protokol ini melengkapi SPF.
FAQ Sender Policy Framework (SPF)
Apakah SPF wajib untuk semua domain bisnis?
SPF tidak diwajibkan secara hukum untuk semua domain, tetapi sangat direkomendasikan. Domain tanpa SPF record memiliki reputasi email yang lemah, meningkatkan risiko email legitimate masuk ke folder spam dan membuka domain untuk disalahgunakan dalam kampanye phishing. Google dan Microsoft juga menetapkan SPF sebagai salah satu syarat deliverability email massal sejak 2024.
Bagaimana cara mengecek apakah domain saya sudah memiliki SPF record?
Gunakan tool DNS lookup seperti MXToolbox, Google Admin Toolbox, atau perintah nslookup -type=TXT yourdomain.com di terminal. Jika ada SPF record, hasilnya akan menampilkan string yang dimulai dengan v=spf1.
Apakah SPF bisa mencegah semua email phishing?
Tidak sepenuhnya. SPF mencegah domain spoofing di level teknis, tetapi tidak mencegah pelaku membuat domain baru yang mirip (typosquatting, seperti verihubs-id.com) dan mengirim email dari domain tersebut. Untuk proteksi menyeluruh, SPF perlu dikombinasikan dengan DKIM, DMARC, dan edukasi pengguna tentang modus phishing.
Berapa lama implementasi SPF untuk domain perusahaan?
Penambahan SPF record ke DNS membutuhkan waktu beberapa menit secara teknis, tetapi propagasi DNS global membutuhkan waktu hingga 48 jam. Proses perencanaan yang lebih memakan waktu adalah inventarisasi semua layanan email pihak ketiga yang digunakan perusahaan agar tidak ada sumber legitimate yang terlewat dari daftar authorized sender.
Autentikasi Email Adalah Fondasi Keamanan Identitas Digital Bisnis
SPF adalah infrastruktur keamanan dasar yang setiap bisnis digital wajib miliki. Dalam ekosistem penipuan digital yang semakin canggih, keamanan komunikasi email tidak dapat dipisahkan dari keamanan identitas digital secara keseluruhan. Brand yang email-nya mudah dipalsukan akan kehilangan kepercayaan nasabah bahkan sebelum interaksi pertama terjadi.
Keamanan komunikasi digital harus berjalan beriringan dengan keamanan identitas pengguna di setiap titik interaksi, dari email masuk hingga proses onboarding dan verifikasi KYC secara digital.
Hubungi Verihubs di sini untuk mengetahui bagaimana solusi keamanan identitas digital kami dapat melindungi bisnis Anda dari ancaman fraud di berbagai lapisan komunikasi.
