Definisi
Record SPF (record Sender Policy Framework) adalah record DNS TXT yang dipublikasikan dalam zona DNS publik domain yang mencatat alamat IP, prefix IPv6, dan nama host server email yang diizinkan mengirim email atas nama domain tersebut. Saat server email penerima menerima pesan masuk, ia melakukan kueri DNS pengirim untuk record SPF dan membandingkan alamat IP yang terhubung dengan kebijakan tersebut. Jika IP tidak terdaftar, server penerima dapat menandai pesan sebagai softfail, menolaknya langsung, atau menandainya untuk evaluasi lebih lanjut — tergantung qualifier kebijakan yang diatur pemilik domain.
SPF pertama kali diformalkan sebagai standar IETF dalam RFC 4408 (2006) dan kemudian diperbarui ke spesifikasi otoritatif saat ini dalam RFC 7208, yang diterbitkan oleh Internet Engineering Task Force (IETF) pada April 2014. SPF adalah salah satu dari tiga standar otentikasi email yang saling melengkapi bersama DKIM (DomainKeys Identified Mail) dan DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Cara Kerjanya
Proses evaluasi SPF melibatkan beberapa langkah berurutan yang dilakukan mesin SMTP server email penerima selama fase MAIL FROM dari handshake SMTP.
Pemilik domain mempublikasikan record SPF TXT di DNS. Record yang khas mengikuti sintaks ini: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Komponennya adalah: v=spf1 (pengidentifikasi versi), satu atau lebih mekanisme (include, ip4, ip6, a, mx, exists), dan qualifier akhir (+all, -all, ~all, ?all). Qualifier -all berarti hard fail — server mana pun yang tidak terdaftar secara eksplisit tidak diizinkan. Qualifier ~all (softfail) meneruskan pesan tetapi mencatat ketidaksesuaian kebijakan, biasanya digunakan selama periode migrasi.
Saat pesan tiba, MTA penerima (Mail Transfer Agent) mengekstrak domain pengirim envelope (alamat MAIL FROM, juga disebut alamat RFC5321.MailFrom) dan melakukan pencarian DNS TXT untuk _spf.<domain> atau langsung pada root domain. Library SPF mengevaluasi setiap mekanisme secara berurutan sampai ada yang cocok atau batas sepuluh pencarian DNS tercapai (batas “SPF PermError” yang didefinisikan dalam RFC 7208 bagian 4.6.4). Hasilnya — Pass, Fail, SoftFail, Neutral, TempError, atau PermError — dimasukkan ke header Received-SPF pesan dan diteruskan ke filter spam dan mesin kebijakan DMARC apa pun.
Penting untuk dicatat bahwa SPF mengotentikasi envelope sender (MAIL FROM), bukan header From yang terlihat di body pesan. Perbedaan ini berarti SPF saja tidak mencegah pemalsuan display-name di klien email, itulah sebabnya keselarasan DMARC — yang mensyaratkan hasil SPF dan/atau DKIM cocok dengan domain RFC5322.From — diperlukan untuk perlindungan lengkap.
Di Mana Anda Menemuinya
Record SPF muncul dalam konteks apa pun di mana pengiriman email dan reputasi pengirim penting. Infrastruktur email transaksional yang dioperasikan oleh layanan seperti Amazon SES, SendGrid, Mailgun, Postmark, dan SparkPost mengharuskan pemilik domain menambahkan mekanisme SPF include yang menunjuk ke infrastruktur pengirim penyedia sebelum pesan akan lulus pemeriksaan otentikasi.
Platform kontes yang mengirim email konfirmasi vote — termasuk Woobox, ShortStack, dan sistem yang dibangun khusus menggunakan Mailchimp Transactional (Mandrill) — mengandalkan domain pengirim memiliki record SPF yang valid. Penyedia mailbox termasuk Google (Gmail), Microsoft (Outlook / Exchange Online Protection), dan Yahoo Mail mengevaluasi SPF sebagai input ke dalam algoritma pengiriman mereka. Record SPF yang hilang atau salah dikonfigurasi secara substansial meningkatkan probabilitas email konfirmasi diam-diam dikirim ke folder spam atau ditolak sepenuhnya, menyebabkan vote tidak dikonfirmasi.
Panel hosting DNS dari penyedia seperti Cloudflare, AWS Route 53, GoDaddy, dan Namecheap mengekspos pengeditan record SPF TXT melalui antarmuka manajemen mereka. Tools diagnostik seperti MXToolbox SPF Lookup, Google Admin Toolbox, dan SPF Surveyor dari DMARCIAN memungkinkan pemilik domain memeriksa dan memvalidasi record yang dipublikasikan.
Contoh Praktis
Sebuah platform kontes mengirim email konfirmasi vote dari [email protected]. Domain votes.example.com memiliki record SPF v=spf1 include:sendgrid.net -all. Saat Gmail menerima pesan konfirmasi, server SMTP masuknya melakukan kueri DNS untuk record SPF votes.example.com, memperluas mekanisme include sendgrid.net, dan memeriksa IP yang terhubung terhadap daftar server resmi SendGrid. Jika IP cocok, hasil SPF adalah Pass dan pesan berlanjut ke inbox. Jika domain tidak memiliki record SPF, filter Gmail akan memperlakukan pesan sebagai tidak terotentikasi, mengurangi probabilitas penempatan inbox.
Kontes surat kabar regional mengubah penyedia email transaksionalnya dari Mailchimp ke Amazon SES tanpa memperbarui record SPF-nya. Email konfirmasi mulai gagal pemeriksaan SPF di Microsoft Outlook dan dipindah ke folder massal, menyebabkan pemilih melewatkan jendela konfirmasi. Administrator kontes mendiagnosis masalah menggunakan MXToolbox, menambahkan include:amazonses.com ke record SPF, dan pengiriman pulih dalam jendela propagasi DNS (biasanya 0–48 jam tergantung pengaturan TTL).
Konsep Terkait
SPF adalah salah satu pilar dari tumpukan otentikasi email tiga-standar: lihat DKIM untuk verifikasi tanda tangan kriptografis dan DMARC untuk lapisan kebijakan yang bertindak berdasarkan hasil SPF dan DKIM. Dampak praktis pada operasi kontes dijelaskan dalam Email Confirmation Vote, di mana pengiriman pesan konfirmasi adalah ketergantungan operasional paling kritis. BIMI (Brand Indicators for Message Identification), standar yang lebih baru yang dibangun di atas DMARC, memungkinkan pengirim terverifikasi menampilkan logo brand di penyedia mailbox yang mendukung — sinyal kepercayaan yang sedang berkembang yang tidak dibahas di sini.
