SPF Record Adalah: Isi, Cara Kerja & Batas 10 Lookup

Saat Anda mengirim surat lewat kantor pos, nama pengirim di sudut kiri atas amplop diisi sendiri oleh yang mengirim. Petugas pos tidak pernah memeriksa apakah nama itu benar. Selama perangko dan alamat tujuannya sah, surat tetap diantar.

Protokol pengiriman email dirancang dengan asumsi yang sama. SMTP lahir pada awal 1980-an, ketika internet masih berupa jaringan tertutup antar-institusi yang saling mengenal. Tidak ada satu pun mekanisme bawaan yang memeriksa apakah server yang sedang mengirim benar-benar berhak memakai nama domain yang disebutkannya. Siapa pun yang punya koneksi dan sebuah server bisa mengaku sebagai pengirim dari domain mana saja.

SPF record adalah jawaban paling awal atas celah tersebut. Ia berisi daftar server yang Anda nyatakan berhak mengirim email atas nama domain Anda, diterbitkan di DNS supaya siapa pun bisa memeriksanya. Artikel ini membedah isi record itu bagian demi bagian. Anda juga akan menemukan batas sepuluh lookup yang paling sering merusaknya diam-diam, beserta kondisi nyata SPF pada 76 domain Indonesia yang kami ukur sendiri.

SPF Record Adalah Daftar Server yang Berhak Mengirim

SPF adalah singkatan dari Sender Policy Framework, sebuah standar otentikasi email yang memungkinkan pemilik domain mengumumkan server mana saja yang sah mengirim pesan atas namanya. Pengumuman itu berbentuk satu baris teks yang diterbitkan sebagai TXT record di DNS domain tersebut. Server penerima mengambil baris itu, lalu mencocokkannya dengan alamat IP yang sedang berhubungan dengannya.

Fungsi SPF record dengan demikian ada dua: menyatakan siapa yang berhak, sekaligus menyatakan apa yang harus dilakukan terhadap yang tidak berhak. Bentuknya sederhana. Sebuah SPF TXT record selalu diawali penanda versi v=spf1, diikuti daftar sumber pengirim yang sah, dan ditutup aturan penanganan untuk sumber di luar daftar. Contoh paling ringkas yang dianjurkan Google untuk pengguna Google Workspace hanya sepanjang ini:

v=spf1 include:_spf.google.com ~all

Standar yang berlaku sekarang adalah RFC 7208, terbit April 2014. Dulu sempat ada tipe DNS record khusus bernama SPF dengan kode tipe 99, tetapi tipe itu sudah tidak dipakai lagi. RFC 7208 menegaskan record SPF wajib diterbitkan sebagai TXT record biasa (tipe 16). Kalau panel DNS Anda masih menawarkan pilihan tipe "SPF", abaikan saja dan pilih TXT.

Perlu diperhatikan bahwa SPF hanya memeriksa dari mana pesan dikirim, bukan apa isinya. Pemeriksaan isi pesan adalah tugas DKIM, sedangkan penentuan tindakan atas hasil keduanya adalah tugas DMARC. Ketiganya bekerja berlapis, dan SPF adalah lapisan yang paling dasar.

Alamat yang Diperiksa SPF Bukan yang Anda Baca

Bagian ini menentukan pemahaman seluruh sisanya, dan justru paling sering disalahpahami. Setiap email membawa dua alamat pengirim yang berbeda, dan SPF hanya memeriksa salah satunya.

Alamat pertama disebut envelope sender (alamat amplop), yang diucapkan server pengirim lewat perintah SMTP MAIL FROM. Alamat ini dipakai untuk urusan pengantaran, misalnya ke mana pesan gagal kirim harus dipantulkan. Ia biasanya muncul di header Return-Path dan hampir tidak pernah ditampilkan aplikasi email. Alamat kedua adalah header From:, yaitu nama dan alamat yang benar-benar dibaca manusia di kotak masuk.

SPF memeriksa alamat amplop, bukan header From:. Konsekuensinya besar. Seseorang bisa menyusun pesan dengan alamat amplop dari domain miliknya sendiri, yang memang lolos SPF dengan sempurna. Di header yang tampil ke pembaca, ia menuliskan From: layanan@bank-terkenal.co.id. Pemeriksaan SPF menyatakan lolos, sementara yang dilihat korban tetap nama bank tersebut.

Inilah sebab SPF sendirian tidak menghentikan pemalsuan pengirim, dan sebab DMARC kemudian diciptakan. DMARC menambahkan syarat keselarasan: domain yang lolos SPF harus cocok dengan domain di header From: yang dibaca manusia. Tanpa lapisan itu, hasil SPF hanya menerangkan perjalanan teknis pesan, bukan kejujuran identitasnya.

SPF memeriksa alamat amplop MAIL FROM, sedangkan header From yang dibaca manusia sama sekali tidak diperiksa.

Membedah Isi Record: Mekanisme, Kualifier, dan Modifier

Isi record SPF tersusun dari kumpulan term (istilah) yang dipisahkan spasi. Ada dua jenis term, yaitu mekanisme dan modifier, dan setiap mekanisme boleh didahului sebuah kualifier.

Record SPF terdiri atas penanda versi v=spf1, daftar sumber sah berisi ip4 dan include, lalu aturan penutup -all.

Mekanisme: Bagian yang Menyebut Sumber

Mekanisme adalah bagian yang menyatakan sumber pengirim. Server penerima membacanya dari kiri ke kanan dan berhenti pada mekanisme pertama yang cocok dengan IP pengirim. Kolom paling kanan pada tabel berikut akan menjadi penting di bagian berikutnya.

Mekanisme include: adalah yang paling sering dipakai sekaligus paling sering menimbulkan masalah. Ia berarti "periksa juga daftar milik domain ini". Saat Anda menulis include:_spf.google.com, Anda menumpang seluruh isi record milik Google, termasuk perubahan yang mereka lakukan tanpa memberi tahu Anda. Kemudahan itu ada harganya, dan harganya dibahas dua bagian lagi.

Satu mekanisme sebaiknya Anda hindari sama sekali. RFC 7208 memberi judul harfiah "ptr (do not use)" pada bagian yang membahasnya. Alasannya, mekanisme itu lambat, kurang dapat diandalkan saat DNS bermasalah, dan membebani server nama pihak lain. Anjuran itu tampaknya sudah diikuti secara luas: dari 72 domain ber-SPF yang kami periksa, tidak satu pun memakai ptr.

Kualifier: Empat Tanda di Depan Mekanisme

Kualifier adalah satu karakter di depan mekanisme yang menentukan hasil apa yang diberikan bila mekanisme itu cocok. Ada empat, dan yang paling sering Anda temui adalah yang menempel pada all di ujung record.

1. + (pass): sumber dinyatakan sah. Ini nilai bawaan, jadi include:_spf.google.com sama artinya dengan +include:_spf.google.com.
2. - (fail): sumber dinyatakan tidak sah dan pesan sebaiknya ditolak. Sering disebut hard fail.
3. ~ (softfail): sumber kemungkinan besar tidak sah, tetapi pesan sebaiknya tetap diterima dengan tanda. Sering disebut soft fail.
4. ? (neutral): pemilik domain tidak menyatakan sikap apa pun.

Karena + adalah bawaan, menulis +all di ujung record berarti menyatakan seluruh dunia berhak mengirim atas nama domain Anda. Record semacam itu lebih berbahaya daripada tidak memasang SPF sama sekali, karena memberi restu pada pemalsu. Dari 72 domain yang kami periksa, untungnya tidak ada satu pun yang memakai +all maupun ?all.

Modifier: redirect dan exp

Modifier ditulis dengan tanda sama dengan, bukan titik dua. Ada dua yang berlaku: redirect= untuk mengalihkan seluruh pemeriksaan ke record domain lain, dan exp= untuk menunjuk domain berisi pesan penjelasan saat pemeriksaan gagal.

Perbedaan tanda baca itu bukan hal sepele. Dalam sampel kami ada satu domain yang menulis redirect: memakai titik dua alih-alih tanda sama dengan. Bagi server penerima, term itu tidak dikenali sebagai modifier maupun mekanisme, dan RFC mengatur bahwa term tak dikenal membuat seluruh record dinyatakan bermasalah. Satu karakter keliru cukup untuk membatalkan seluruh baris.

Tujuh Kemungkinan Hasil Pemeriksaan SPF

RFC 7208 mendefinisikan tepat tujuh kemungkinan hasil pemeriksaan. Mengetahui artinya membuat header pesan berhenti terasa seperti sandi.

Hasil ini muncul di header Received-SPF atau sebagai bagian spf= pada header Authentication-Results. Ada pesan panjang yang sering membingungkan, misalnya "softfail: domain of transitioning example.com discourages use of this host". Isinya sebenarnya sederhana: record domain pengirim diakhiri ~all, dan server yang mengirim tidak ada di daftarnya.

Dua hasil terakhir pantas mendapat perhatian khusus. Baik permerror maupun none membuat penerima memperlakukan pesan seolah domain Anda tidak pernah memasang SPF. Bedanya, none jujur menandakan record memang tidak ada, sementara permerror terjadi pada domain yang recordnya ada, terlihat rapi, dan pemiliknya merasa sudah aman.

Batas Sepuluh Lookup: Penyebab SPF Mati Tanpa Pemberitahuan

Di sinilah letak penyebab permerror yang paling umum. RFC 7208 mewajibkan server penerima membatasi jumlah term yang memicu pencarian DNS menjadi maksimal sepuluh untuk satu kali pemeriksaan. Aturan ini dikenal sebagai SPF DNS lookup limit. Yang dihitung adalah include, a, mx, ptr, exists, dan modifier redirect. Yang tidak dihitung adalah ip4:, ip6:, dan all.

Batas ini ada untuk alasan yang masuk akal. Tanpa pembatasan, sebuah record berisi rantai include bertingkat bisa memaksa server penerima melakukan ratusan kueri DNS hanya untuk satu pesan. Celah semacam itu dapat dipakai sebagai sarana membebani pihak lain.

Yang membuat batas ini berbahaya adalah cara kegagalannya. Ketika record Anda melewati sepuluh lookup, tidak ada pemberitahuan, tidak ada peringatan di panel DNS, dan recordnya tetap tampak benar saat dibaca mata. Yang terjadi hanyalah server penerima berhenti di tengah jalan lalu mengembalikan permerror. Sejak saat itu domain Anda berjalan tanpa perlindungan SPF, meski recordnya masih terpasang rapi.

Selain batas sepuluh lookup, RFC juga menganjurkan pembatasan void lookup — kueri yang tidak mengembalikan jawaban — menjadi maksimal dua. Batas ini lebih jarang tersentuh, tetapi bisa terpicu bila record Anda menunjuk domain yang sudah tidak aktif.

Kesalahpahaman paling umum soal batas ini adalah menganggapnya sebagai batas jumlah include. Padahal setiap include menarik seluruh isi record tujuan, termasuk include yang ada di dalamnya, dan begitu seterusnya. Sepuluh lookup dapat habis oleh dua include saja.

Contoh paling jelas datang dari sampel kami sendiri. Record milik salah satu marketplace besar Indonesia adalah yang terpendek di antara seluruh domain yang melewati batas. Panjangnya hanya 68 karakter dengan dua include:

v=spf1 include:_spf.blibli.com include:_spf-external.blibli.com -all

Dibaca sekilas, record itu terlihat sangat hemat. Namun include kedua ternyata berisi enam include lagi menuju berbagai layanan pengiriman email, dan dua di antaranya masih bercabang lagi ke dalam. Totalnya sebelas lookup, satu di atas batas. Jumlah include yang sedikit sama sekali tidak menjamin jumlah lookup yang aman.

Rantai include SPF: dua include memuat enam lagi, lalu tiga di bawahnya, total sebelas lookup, lewat batas sepuluh.

Kondisi Record SPF 76 Domain Indonesia

Untuk mengetahui seberapa sering batas itu benar-benar terlampaui, kami memeriksa record SPF 76 domain Indonesia pada 3 September 2026. Sampelnya menyebar di tujuh kelompok. Rinciannya 12 bank, 16 layanan e-commerce, fintech, dan travel, 12 domain pemerintah, 10 kampus, 7 media, 6 penyedia hosting, serta 13 korporasi dan telekomunikasi.

Setiap record diambil lewat tiga resolver DNS yang berbeda, dan hasilnya baru dipakai ketika minimal dua resolver sepakat. Jumlah lookup dihitung dengan menelusuri setiap include dan redirect sampai ke ujung rantainya, mengikuti aturan RFC 7208.

Angka-angka di atas terlihat menenangkan. Hampir seluruh domain sudah memasang SPF, tidak ada yang memakai kualifier berbahaya, dan tidak ada yang memasang record ganda. Persoalannya baru muncul saat jumlah lookup dihitung.

Lookup SPF record 72 domain Indonesia: 25 domain di 0-3, 22 di 4-7, 19 di 8-10, dan 6 melewati batas sepuluh.

Enam domain sudah melewati batas, dan tiga di antaranya adalah bank. Recordnya tetap ada, sintaksnya benar, dan tiga di antaranya bahkan memakai -all yang paling tegas. Namun record itu tidak pernah selesai dievaluasi, sehingga ketegasannya tidak berarti apa-apa.

Kasus paling ekstrem dipegang sebuah bank yang recordnya membutuhkan 25 lookup, dua setengah kali batas yang diizinkan. Penyebabnya bukan record utamanya, yang sebenarnya pas sepuluh term pemicu lookup. Salah satu include di dalamnya menunjuk sebuah domain yang isinya sepuluh mekanisme a: berjajar, sehingga satu baris itu sendirian menghabiskan sebelas lookup. Rantainya bercabang sampai empat tingkat sebelum berakhir.

Baris kedua yang perlu diperhatikan adalah kelompok 8–10 lookup, yang dihuni 19 domain atau 26 persen dari sampel. Domain-domain ini masih sah hari ini, tetapi anggarannya nyaris habis. Menambahkan satu layanan email baru, satu alat pemasaran, atau satu sistem tiket yang butuh include sendiri sudah cukup untuk mendorongnya melewati batas. Perubahan itu biasanya dilakukan oleh tim yang tidak tahu bahwa ada anggaran yang sedang dihabiskan.

Sampel 76 domain ini bukan potret statistik nasional. Domain-domain tersebut dipilih karena mewakili organisasi yang paling sering ditiru dalam penipuan email, sehingga temuannya menggambarkan kondisi kelompok yang justru paling perlu terlindungi.

Kenapa Google Menganjurkan ~all dan Microsoft -all

Saat menyusun record, pertanyaan yang hampir selalu muncul adalah penutup mana yang sebaiknya dipakai. Menariknya, dua penyedia email terbesar memberi jawaban yang berbeda di dokumentasi resmi masing-masing.

Google menganjurkan ~all. Alasannya berpihak pada keselamatan pengiriman: pesan dari sumber yang belum terdaftar tetap sampai, hanya ditandai. Bila ada sumber pengirim sah yang lupa didaftarkan, pesannya tidak langsung hilang.

Microsoft menganjurkan -all, dengan alasan yang berpijak pada cara DMARC bekerja. Dokumentasinya menjelaskan bahwa kebijakan DMARC praktis diabaikan untuk kegagalan SPF bertipe softfail apabila pesan tersebut juga tidak membawa tanda tangan DKIM. Dengan -all, DMARC punya dasar yang tegas untuk bertindak.

Keduanya benar dalam kerangka masing-masing, dan perbedaan itu ternyata terbawa ke domain-domain yang memakai layanan mereka. Saat sampel kami dipilah berdasarkan penyedia yang tercantum di record, polanya cukup jelas:

Penutup record SPF: 71 persen pengguna Google memakai ~all, 78 persen pengguna Microsoft memakai -all.

Tujuh dari sepuluh pengguna Google memakai ~all, dan hampir delapan dari sepuluh pengguna Microsoft memakai -all. Angka sekonsisten itu sulit dijelaskan sebagai kebetulan. Yang lebih masuk akal, mayoritas pemilik domain menyalin nilai yang tertulis di dokumentasi penyedianya, lalu tidak pernah meninjaunya lagi.

Rekomendasi kami cukup sederhana. Pakai ~all selama tiga sampai enam bulan pertama, sambil memasang DMARC dengan kebijakan p=none untuk mengumpulkan laporan. Setelah laporan menunjukkan seluruh sumber pengirim sah sudah terdaftar dan tidak ada lagi kegagalan yang mengejutkan, barulah ubah menjadi -all. Untuk domain yang memang tidak pernah dipakai berkirim email, langsung pasang v=spf1 -all tanpa masa transisi, karena tidak ada pengirim sah yang berisiko tertolak.

Cara Membuat SPF Record di DNS

Pemasangan SPF hanya membutuhkan akses ke pengaturan DNS domain Anda, dan seluruh prosesnya biasanya selesai dalam sepuluh menit. Bagian yang membutuhkan waktu justru langkah pertama.

Langkah #1: Kumpulkan Seluruh Sumber Pengirim

Daftarkan setiap sistem yang pernah mengirim email atas nama domain Anda. Server email utama biasanya sudah terdata. Yang paling sering terlupakan justru sumber-sumber berikut:

• Formulir kontak di website
• Sistem faktur, ERP, atau aplikasi akuntansi
• Layanan pemasaran email
• Sistem tiket dukungan pelanggan
• Aplikasi pihak ketiga yang mengirim notifikasi otomatis

Sumber yang terlewat pada langkah ini akan menjadi email yang hilang di kemudian hari. Kalau Anda ragu apakah daftarnya sudah lengkap, pasang DMARC dengan p=none lebih dulu selama beberapa minggu dan baca laporannya sebelum memperketat SPF.

Langkah #2: Susun Satu Baris Record

Gabungkan seluruh sumber tadi menjadi satu baris. Nilai resmi untuk pengguna Google Workspace adalah berikut ini:

v=spf1 include:_spf.google.com ~all

Sedangkan nilai resmi untuk pengguna Microsoft 365 adalah berikut ini:

v=spf1 include:spf.protection.outlook.com -all

Kalau Anda memakai layanan email sekaligus server sendiri, gabungkan keduanya dalam satu baris. Urutkan sumber yang paling sering dipakai di sebelah kiri, karena pemeriksaan berhenti pada kecocokan pertama:

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

Perhatikan bahwa alamat IP ditulis memakai ip4: dan tidak menghabiskan anggaran lookup sama sekali. Untuk penyedia yang alamat IP-nya jarang berubah, menuliskan IP langsung lebih hemat daripada memakai include. Namun cara ini menuntut Anda memantau sendiri bila penyedia tersebut mengubah alamatnya.

Langkah #3: Tambahkan sebagai TXT Record

Masuk ke panel pengaturan DNS domain Anda, lalu tambahkan record baru dengan tipe TXT. Isi kolom nama atau host dengan @, yang berarti domain utama. Tempelkan baris record tadi sebagai nilainya, dan atur TTL minimal 3600 detik sesuai anjuran Microsoft agar pemeriksaan tidak terganggu kedaluwarsa cache yang terlalu cepat.

Ada satu aturan yang tidak boleh dilanggar pada langkah ini. Satu domain hanya boleh punya satu record SPF. Bila ditemukan dua record berawalan v=spf1, server penerima tidak bisa menentukan mana yang berlaku dan langsung mengembalikan permerror. Saat menambahkan layanan email baru, gabungkan include barunya ke record yang sudah ada, jangan membuat record kedua.

Bila email domain Anda dikelola lewat cPanel, langkah-langkah pengisiannya beserta pengaturan DKIM sudah kami bahas terpisah di panduan mengaktifkan DKIM dan SPF di cPanel. Pengguna layanan email hosting Indowebsite umumnya sudah mendapat record dasar terpasang otomatis, sehingga yang perlu dilakukan hanya menambahkan sumber pengirim di luar server tersebut.

Langkah #4: Tunggu Propagasi dan Uji

Perubahan DNS membutuhkan waktu menyebar, umumnya antara beberapa menit sampai beberapa jam tergantung TTL sebelumnya. Setelah itu, kirim satu email uji ke alamat di layanan lain, lalu buka header pesan yang diterima dan cari baris Authentication-Results. Nilai spf=pass di sana menandakan record Anda sudah bekerja.

Cara Cek SPF Record dan Menghitung Lookup Sendiri

Memeriksa record sendiri jauh lebih cepat daripada membuka alat pemeriksa daring, dan hasilnya lebih dapat Anda percaya. Ganti domainanda.com pada perintah berikut dengan domain Anda sendiri. Pada Linux dan macOS, gunakan dig dengan menyaring keluarannya:

dig +short TXT domainanda.com | grep spf1

Pengguna Windows dapat memakai nslookup dengan menyebut tipe recordnya:

nslookup -type=TXT domainanda.com

Keluarannya adalah baris record apa adanya. Bila tidak ada baris berawalan v=spf1, domain tersebut belum memasang SPF.

Untuk menghitung lookup, telusuri record itu dari kiri ke kanan sambil menjumlahkan setiap include, a, mx, exists, dan redirect yang Anda temui. Lewati semua ip4:, ip6:, dan all. Setiap kali menemukan include, jalankan perintah yang sama pada domain tujuannya, lalu jumlahkan isinya ke total yang sedang berjalan.

dig +short TXT _spf.google.com | grep spf1

Pekerjaan ini terasa berulang, tetapi itulah persis yang dilakukan server penerima setiap kali menerima pesan dari domain Anda.

Cara Menurunkan Jumlah Lookup yang Sudah Telanjur Tinggi

Kalau hasil penghitungan tadi menunjukkan angka delapan ke atas, ada empat cara menurunkannya. Ketiga cara pertama aman, sedangkan yang keempat menuntut perawatan berkala.

1. Ganti include dengan alamat IP langsung: kalau sebuah penyedia mengumumkan blok IP yang stabil dan terdokumentasi, tulis ip4: alih-alih menumpang recordnya. Satu include yang berisi tiga include lain berubah dari empat lookup menjadi nol.
2. Pindahkan layanan pihak ketiga ke subdomain: setiap subdomain punya anggaran sepuluh lookup sendiri. Layanan pemasaran email yang dipindah ke promo.domainanda.com membawa serta seluruh include miliknya keluar dari record domain utama, sekaligus menjaga reputasi domain utama tetap terpisah.
3. Kurangi jumlah layanan pengirim: sebagian anggaran biasanya habis oleh layanan yang sudah tidak dipakai tetapi recordnya tidak pernah dibersihkan. Periksa daftar dari Langkah #1 dan buang yang sudah tidak aktif.
4. Lakukan SPF flattening: teknik mengganti seluruh include dengan hasil resolusinya berupa daftar ip4:. Cara ini paling ampuh menurunkan lookup, tetapi juga paling rapuh.

Peringatan pada poin keempat perlu diperhatikan serius. Microsoft secara eksplisit menyarankan tidak melakukan flattening pada include:spf.protection.outlook.com, karena alamat pengirimnya berubah-ubah. Hal yang sama berlaku untuk layanan awan mana pun yang alamatnya dinamis.

Kalau Anda tetap memutuskan melakukannya, perlakukan record itu sebagai konfigurasi yang punya masa berlaku. Catat include mana yang Anda ganti beserta tanggalnya, dan tinjau ulang minimal setiap tiga bulan. Alamat IP penyedia yang berubah tanpa Anda ketahui akan membuat email sah dari layanan tersebut mendadak gagal SPF. Penyebabnya sulit ditemukan, karena recordnya sendiri terlihat baik-baik saja.

Urutan penulisan juga membantu. Pemeriksaan berhenti pada kecocokan pertama. Menaruh sumber yang paling sering mengirim di sebelah kiri membuat sebagian besar pesan tidak pernah menyentuh bagian record yang mahal.

Yang Tidak Bisa Dikerjakan SPF

SPF sudah berumur lebih dari dua dekade dan batasannya sudah dikenal baik. Mengetahuinya lebih awal akan menghemat waktu Anda saat menghadapi keluhan email yang tidak sampai.

1. Tidak memeriksa nama pengirim yang dibaca manusia: seperti dijelaskan di awal, SPF hanya memeriksa alamat amplop. Pemalsuan pada header From: hanya bisa dihentikan dengan menambahkan DMARC.
2. Gagal saat pesan diteruskan otomatis: pada email forwarding, server penerus mengirim ulang pesan dari alamat IP miliknya sendiri. Alamat itu tentu tidak ada di record domain asal, sehingga pemeriksaan SPF gagal meski pesannya sepenuhnya sah.
3. Tidak menjamin isi pesan utuh: SPF hanya menyatakan sebuah server berhak mengirim. Ia tidak dapat mendeteksi bila isi pesan diubah di tengah jalan, dan pemeriksaan itu adalah tugas DKIM.
4. Tidak menentukan tindakan apa pun: SPF hanya menghasilkan penilaian. Keputusan menolak, mengarantina, atau meloloskan sepenuhnya ada di tangan server penerima, kecuali Anda memasang DMARC yang menyatakan kehendak Anda secara eksplisit.
5. Punya batas panjang dan biaya perawatan: satu string DNS dibatasi 255 karakter, sehingga record yang lebih panjang harus dipecah menjadi beberapa string. Dari sampel kami, 8 dari 72 domain sudah melewati batas itu. Record yang penuh alamat ip4: memang hemat lookup, tetapi menuntut pembaruan manual setiap kali penyedia mengubah alamatnya.

Karena itu SPF sebaiknya dipandang sebagai lapisan pertama, bukan penyelesaian. Google sendiri sejak 1 Februari 2024 mewajibkan seluruh pengirim menyiapkan SPF atau DKIM. Bagi pengirim di atas 5.000 pesan per hari ke akun Gmail, yang diwajibkan adalah keduanya beserta DMARC. Sebagai pelengkap dari sisi reputasi server, PTR record juga layak dipastikan sudah terpasang benar.

Pertanyaan yang Sering Muncul

Apa arti softfail pada header email saya? Artinya server yang mengirim pesan tersebut tidak terdaftar di record SPF domain pengirim, dan record itu diakhiri ~all. Pemilik domain menyatakan pesan semacam ini sebaiknya tidak dipercaya sepenuhnya, tetapi tidak meminta pesannya ditolak. Karena itu pesan tetap sampai, sering kali ke folder spam.

Bolehkah satu domain punya dua record SPF? Tidak boleh. Bila server penerima menemukan lebih dari satu record berawalan v=spf1, hasilnya langsung permerror dan domain Anda kehilangan perlindungan SPF sepenuhnya. Semua sumber pengirim harus digabungkan ke dalam satu baris record.

Kenapa SPF gagal padahal IP server sudah saya daftarkan? Dua penyebab paling umum. Pertama, record Anda melewati batas sepuluh DNS lookup, sehingga pemeriksaan berhenti sebelum sampai ke bagian yang memuat IP tersebut. Kedua, pesannya diteruskan lewat perantara, sehingga yang diperiksa adalah IP server penerus, bukan IP server Anda.

Apakah memasang SPF saja sudah cukup? Belum, kalau tujuannya melindungi nama domain Anda dari pemalsuan. SPF tidak memeriksa alamat yang tampil ke pembaca, sehingga pesan palsu tetap dapat lolos. Perlindungan baru terbentuk saat SPF disandingkan dengan DKIM dan DMARC.

Berapa lama record SPF baru mulai berlaku? Umumnya beberapa menit sampai beberapa jam, tergantung nilai TTL record sebelumnya. Bila Anda mengubah record yang sudah lama terpasang dengan TTL tinggi, sebagian server penerima masih memakai versi lama sampai cache mereka kedaluwarsa.

Kesimpulan

SPF record adalah satu baris TXT di DNS yang menyatakan server mana saja berhak mengirim email atas nama domain Anda. Yang diperiksanya adalah alamat pada amplop pengiriman, bukan nama pengirim yang tampil di kotak masuk. Karena itu SPF perlu disandingkan dengan DKIM dan DMARC agar benar-benar melindungi.

Hal yang paling sering merusaknya bukan kesalahan penulisan, melainkan batas sepuluh DNS lookup yang terlampaui tanpa pemberitahuan. Pengukuran kami terhadap 76 domain Indonesia menemukan 8 persen sudah melewati batas itu dan 26 persen lagi berada di ambangnya. Karena itu, setiap kali Anda menambahkan include baru, sempatkan menghitung ulang total lookup record Anda.

Semoga artikel ini membantu.