Apa Itu SPF Record?
SPF record (Sender Policy Framework, RFC 7208) adalah record TXT di domain Anda yang mencantumkan server mana saja yang boleh mengirim email atas nama domain tersebut. Saat pesan masuk, server penerima mencari SPF record dari domain pengirim envelope (Return-Path, bukan alamat From yang terlihat) lalu memeriksa apakah IP pengirim ada di daftar.
Satu domain hanya boleh punya satu SPF record. Dua record yang diawali v=spf1 membuat setiap cek SPF gagal dengan PermError, jadi saat menambahkan layanan baru, edit record yang sudah ada alih-alih menambah record lain. Sejak Februari 2024, Gmail dan Yahoo mensyaratkan setiap pengirim memakai SPF atau DKIM, dan pengirim massal memakai SPF, DKIM, dan DMARC sekaligus.

Cara Membuat SPF Record
Penyedia mailbox, layanan newsletter dan email transaksional, help desk, CRM, serta server atau situs web apa pun yang mengirim email dari domain Anda. Melewatkan satu pengirim adalah penyebab paling umum SPF gagal.
Pilih setiap penyedia di atas, tambahkan domain include lainnya, dan masukkan server Anda sendiri sebagai alamat IPv4 atau IPv6. Gunakan mx hanya jika server email masuk Anda juga mengirim email.
~all (soft fail) adalah titik awal yang umum. Beralihlah ke -all (fail) saat Anda yakin daftarnya sudah lengkap. Perhatikan penghitung lookup: angkanya harus tetap 10 atau kurang.
Tambahkan sebagai record TXT dengan host @ (atau subdomain yang mengirim email), menggantikan record v=spf1 yang sudah ada. Lalu pastikan hasilnya dengan Cek SPF.
Advertisement
Penjelasan Sintaks SPF Record
SPF record adalah daftar term yang dibaca dari kiri ke kanan. Term pertama yang cocok dengan IP pengirim menentukan hasilnya.
Tag versi. Harus menjadi term pertama, dan dari tag inilah penerima mengenali record TXT sebagai SPF.
Mengizinkan semua yang ada di SPF record domain lain, misalnya include:_spf.google.com. Setiap lookup di dalam record tersebut juga dihitung ke batas Anda.
Mengizinkan satu alamat atau rentang CIDR, misalnya ip4:203.0.113.10 atau ip6:2001:db8::/48. Keduanya tidak memakan DNS lookup.
Mengizinkan IP dari record A/AAAA domain atau dari host MX-nya. Praktis, tetapi masing-masing memakan satu lookup, dan mx bisa memakan hingga 10 query tambahan di dalamnya.
Apa yang dilakukan terhadap server lainnya: soft fail, fail, atau neutral. Jangan pernah mempublikasikan +all, yang membiarkan siapa pun mengirim email atas nama domain Anda.
redirect= menyerahkan seluruh pengecekan ke record domain lain. exists: dipakai bersama macro oleh beberapa pengirim besar. ptr lambat, dan RFC 7208 menyatakan agar tidak mempublikasikannya.
~all vs -all: Soft Fail atau Fail?
-all memberi tahu penerima bahwa email dari server mana pun yang tidak tercantum gagal SPF, dan banyak penerima akan menolaknya. ~all menandainya sebagai soft fail: penerima sebaiknya tidak menolaknya hanya karena itu, tetapi boleh menganggapnya mencurigakan. ?all bersifat netral dan tidak memberi perlindungan apa pun.
Panduan Google Workspace memakai ~all, sedangkan contoh Microsoft 365 dari Microsoft memakai -all. Keduanya berfungsi. Setelah Anda mempublikasikan DMARC, kebijakan DMARC (p=quarantine atau p=reject) yang menentukan nasib email yang gagal, sehingga banyak domain tetap memakai ~all agar email terusan yang sah tidak ditolak dan membiarkan DMARC yang menegakkan kebijakan. Jika domain sama sekali tidak mengirim email, publikasikan v=spf1 -all.
Advertisement
Contoh SPF Record
Salin contoh yang paling mirip dengan pengaturan Anda, atau buat sendiri dengan generator di atas. Masing-masing adalah satu record TXT di domain Anda.
v=spf1 include:_spf.google.com ~allv=spf1 include:spf.protection.outlook.com -allv=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~allv=spf1 include:zohomail.com ~allv=spf1 mx ip4:198.51.100.0/24 ip6:2001:db8::/48 -allv=spf1 -allBatas 10 DNS Lookup
RFC 7208 membatasi satu cek SPF hingga 10 DNS lookup. Setiap include, a, mx, ptr, exists, dan redirect memakan satu lookup, begitu juga setiap mekanisme tersebut di dalam record yang Anda include. ip4, ip6, dan all gratis. Cek yang membutuhkan lookup ke-11 berhenti dengan PermError, yang dihitung DMARC sebagai kegagalan SPF. Penerima juga sebaiknya mengizinkan tidak lebih dari 2 void lookup (nama yang tidak ada atau tidak mengembalikan record apa pun).
Biaya setiap penyedia tidak sama. Kami menghitung setiap include pada 5 Oktober 2026, termasuk lookup bertingkat:
_spf.google.com dan spf.protection.outlook.com langsung mencantumkan rentang IP mereka. Amazon SES, Brevo, Mailjet, Zendesk, dan Fastmail juga hanya memakan 1.
Masing-masing menunjuk ke satu record lain milik mereka sendiri.
Mailbox dari layanan hosting sering merangkai beberapa include.
Satu dari layanan ini ditambah beberapa layanan lain bisa menghabiskan seluruh jatah.
Advertisement
Cara Memperbaiki SPF Record dengan Terlalu Banyak Lookup
Hapus layanan yang tidak lagi Anda pakai. Alat newsletter lama dan akun uji coba biasanya menjadi penyebabnya.
Ganti `a` dan `mx` dengan `ip4`/`ip6` jika server Anda sendiri memiliki alamat tetap.
Pindahkan email massal ke subdomain seperti news.example.com, dengan SPF record dan jatah 10 lookup sendiri.
Periksa apakah sebuah layanan memang butuh include. Banyak pengirim memakai bounce domain mereka sendiri, sehingga SPF lolos di domain mereka dan alignment DMARC didapat dari DKIM.
Hati-hati dengan SPF flattening. Mengganti include dengan daftar IP salinan memang berfungsi, sampai penyedia mengubah IP-nya, lalu email mulai gagal tanpa peringatan.
Kesalahan SPF yang Umum
Dua SPF record di domain yang sama, misalnya satu per penyedia. Gabungkan menjadi satu.
Memakai
+all, yang mengizinkan seluruh internet.Mempublikasikan record di nama yang salah. SPF dicek pada domain pengirim envelope, dan subdomain tidak mewarisinya.
Menambahkan mekanisme setelah
all. Penerima tidak pernah mengevaluasinya, sehingga pengirim tersebut tidak diizinkan.Melupakan satu pengirim, misalnya web server yang mengirim email dari formulir kontak.
Memakai tipe record SPF lama (type 99). RFC 7208 sudah menghentikannya: publikasikan TXT saja.
Advertisement
SPF, DKIM, dan DMARC Bekerja Sama
SPF saja tidak bisa mencegah orang memalsukan alamat From yang dilihat pembaca Anda. DKIM menandatangani setiap pesan, dan DMARC mengaitkan keduanya dengan domain From yang terlihat serta memberi tahu penerima apa yang harus dilakukan jika keduanya gagal. Siapkan ketiganya:
Verifikasi record yang dipublikasikan, include bertingkatnya, dan jumlah lookup-nya.
Buat pasangan kunci DKIM dan record TXT selector._domainkey.
Susun kebijakan DMARC dengan alamat pelaporan.
Baca hasil SPF, DKIM, dan DMARC dari pesan sungguhan.