Pemeriksa dan Generator SPF Record

Cara memeriksa SPF record

1. Ketik nama domain pada kolom di atas. Alamat email lengkap juga bisa digunakan; alat ini otomatis mengambil bagian domainnya saja.
2. Klik Periksa SPF record. Pemeriksaan membaca record aktif di DNS publik persis seperti yang dilakukan server email penerima.
3. Baca ringkasannya terlebih dahulu. Ringkasan menunjukkan apakah record valid, memiliki peringatan, atau rusak.
4. Tinjau daftar masalah yang ditemukan jika ada. Setiap item menjelaskan perubahan yang perlu dilakukan.
5. Di bagian bawah, setiap komponen record diuraikan beserta jumlah DNS lookup yang digunakannya. Buka include untuk melihat layanan apa yang diizinkan.

Tautan di bilah alamat browser menyimpan hasil pemeriksaan ini sehingga Anda dapat membagikannya kepada rekan tim atau penyedia hosting DNS Anda. Harap perhatikan batasannya: server penerima memverifikasi SPF berdasarkan alamat IP server pengirim pesan. Alat ini tidak memiliki pesan email nyata untuk dianalisis, sehingga memeriksa integritas record itu sendiri di DNS. Alat ini tidak dapat mengevaluasi makro dinamis yang berubah sesuai IP pengirim.

Apa itu SPF record?

SPF record adalah TXT record pada DNS suatu domain yang memuat daftar server yang diizinkan mengirim email atas nama domain tersebut. SPF merupakan singkatan dari Sender Policy Framework, dengan ketentuan standar yang diatur dalam RFC 7208. Domain yang menggunakan Google Workspace umumnya memiliki record seperti ini :

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

v=spf1 menandai bahwa ini adalah SPF record. include:_spf.google.com mengesahkan seluruh server dari daftar resmi Google. ~all menginstruksikan server penerima untuk menandai email dari server lain sebagai mencurigakan.

Saat email masuk, server penerima mengambil nama domain dari alamat bounce teknis (disebut Return-Path atau envelope sender). Server membaca SPF record domain tersebut dan memastikan apakah IP pengirim terdaftar. SPF tidak memeriksa alamat From yang tampak di kotak masuk. Karena itu SPF bekerja berdampingan dengan DKIM dan DMARC. Untuk memahami perpaduan ketiganya, baca panduan lengkap SPF, DKIM, dan DMARC.

Sejak Februari 2024, Gmail mewajibkan SPF atau DKIM bagi semua pengirim, serta keduanya bagi pengirim email massal. Yahoo menerapkan aturan serupa.

Arti setiap bagian dalam SPF record

SPF record terdiri dari serangkaian istilah yang dipisahkan oleh spasi. Server penerima membaca dari kiri ke kanan dan berhenti pada istilah pertama yang cocok dengan server pengirim.

Setiap mekanisme dapat diawali kualifikator yang menentukan status saat ada kecocokan. + berarti Pass (lolos) dan merupakan bawaan jika tidak ditulis. - berarti Fail (gagal mutlak), ~ berarti Softfail (gagal ringan), dan ? berarti Neutral (netral). Oleh karena itu all biasanya ditulis sebagai -all, ~all, atau ?all.

Penulisan tidak membedakan huruf besar dan kecil: Include: berfungsi sama persis dengan include:. RFC 7208 merekomendasikan mengakhiri setiap record dengan all atau redirect. Tanpa penutup ini, server yang tidak terdaftar akan berstatus netral.

Batas ketat 10 DNS lookup

Setiap istilah include, a, mx, ptr, exists, dan redirect mewajibkan server penerima melakukan kueri resolusi DNS. RFC 7208 membatasi jumlah ini maksimal 10 lookup per evaluasi. Lookup di dalam include bersarang turut dihitung, sehingga satu include bisa menghabiskan beberapa lookup. ip4, ip6, dan all tidak menggunakan lookup. Jika sebuah record membutuhkan lebih dari 10 lookup, server penerima akan berhenti dan menghasilkan Permerror sehingga pemeriksaan SPF gagal.

Batas ini sangat mudah terlampaui. Kami mengukur biaya lookup layanan populer di DNS publik: Google Workspace memerlukan 1 lookup, Microsoft 365 memerlukan 1 lookup, Salesforce 2, Mailgun 5, dan Freshdesk 7. Perusahaan pengguna Google Workspace yang menambahkan Mailgun dan Freshdesk sudah mencapai 13 lookup. Riset tahun 2024 tentang SPF record pada domain .com, .net, .org, dan .se menunjukkan 6,5% domain melebihi batas 10 lookup, di mana include dari hanya dua penyedia hosting menyumbang 83,7% kasus tersebut.

Biaya lookup juga dapat berubah sewaktu-waktu. Include Google sebelumnya membutuhkan 4 lookup hingga Desember 2025, saat Google menyederhanakan include bersarang menjadi daftar tunggal. Banyak panduan dan generator lama masih menyebut angka 4. Pemeriksa kami menghitung jumlah lookup aktif sebenarnya secara langsung di DNS.

Melebihi batas tidak selalu membuat seluruh email gagal secara merata. Seperti yang dijelaskan Microsoft, server penerima mengevaluasi mekanisme dari kiri ke kanan dan berhenti pada kecocokan pertama. Email dari layanan yang ditulis di awal mungkin lolos, sedangkan layanan di bagian akhir akan gagal. Ini membuat masalah pengiriman terkesan acak jika Anda tidak menghitung lookup seluruh record.

Terdapat pula batasan kedua: kueri kosong (void lookups), misalnya include yang mengarah ke domain yang sudah kedaluwarsa. RFC 7208 mewajibkan server penerima berhenti setelah menemukan 2 void lookup berturut-turut.

Cara menjaga agar tetap di bawah 10 DNS lookup

1. Hapus include dari layanan email marketing atau pihak ketiga yang sudah tidak Anda gunakan.
2. Hapus include yang sudah tidak diwajibkan oleh penyedia layanan. Mailchimp, Postmark, Brevo, dan Klaviyo tidak lagi memerlukan include di domain utama Anda. SendGrid dan Amazon SES mengirim melalui subdomain terpisah. Lihat daftarnya di bawah.
3. Gunakan mekanisme ip4 dan ip6 untuk server email Anda sendiri alih-alih mekanisme a atau mx. RFC 7208 merekomendasikan urutan ini dan alamat IP tidak memakai DNS lookup.
4. Kirim email promosi atau transaksional menggunakan subdomain khusus, misalnya info.domainanda.com. Setiap subdomain memiliki SPF record sendiri dengan jatah 10 lookup masing-masing.

Beberapa penyedia menawarkan fitur SPF flattening, yang mengganti include dengan daftar alamat IP langsung. Ini menghemat lookup, namun rentang IP penyedia rutin berubah sehingga record statis bisa usang. Microsoft melarang flattening untuk layanan cloud dinamis dan menyarankan audit berkala setiap kuartal jika Anda menggunakannya.

Include SPF untuk Google Workspace, Microsoft 365, dan layanan lainnya

Berikut nilai include resmi dari dokumentasi setiap penyedia layanan beserta jumlah DNS lookup yang diukur di DNS publik per 12 Oktober 2026. Selalu pastikan dengan dokumentasi akun Anda karena beberapa layanan menggunakan subdomain regional tertentu.

HubSpot memberikan include unik untuk setiap akun dengan akhiran hubspotemail.net. Salin nilai tersebut dari pengaturan email HubSpot Anda. Nilai ini menggunakan 1 lookup.

Layanan yang umumnya tidak memerlukan SPF include

Verifikasi SPF diperiksa pada alamat Return-Path teknis dan bukan pada alamat From yang tampil di inbox. Sebagian besar platform pengiriman email saat ini menggunakan domain bounce mereka sendiri atau subdomain CNAME khusus. Menambahkan include mereka ke domain utama hanya membuang kuota DNS lookup tanpa memberi proteksi tambahan.

• Mailchimp. Mailchimp mengelola otentikasi via record CNAME untuk DKIM.
• Postmark. Postmark mengirim email dari domain Return-Path miliknya sendiri.
• Brevo. Brevo tidak membutuhkan SPF pada domain utama kecuali menggunakan IP dedicated.
• Klaviyo. Klaviyo tidak mewajibkan include SPF pada domain utama.
• SendGrid. SendGrid memasang SPF pada subdomain khusus saat proses otentikasi domain.
• Amazon SES. SES hanya membutuhkannya jika Anda menyetel subdomain MAIL FROM kustom.

Pemeriksa kami akan menyoroti include yang tidak diperlukan ini jika ditemukan di dalam record Anda.

Cara membuat SPF record baru

Gunakan tab Buat di atas sebagai generator SPF interaktif. Centang layanan yang mengirimkan email atas nama domain Anda, dan alat ini akan menyusun sintaks yang tepat sembari memantau jumlah DNS lookup. Jika domain Anda sudah memiliki record, muat terlebih dahulu agar Anda dapat melengkapinya tanpa menimpa konfigurasi yang sudah ada. Berikut langkah-langkahnya :

1. Daftar semua layanan yang mengirim email dari domain Anda: paket email kantor, buletin berita, CRM, help desk, penagihan, dan formulir website. Laporan DMARC sangat membantu menemukan pengirim yang terlewat.
2. Dapatkan nilai include dari panduan masing-masing layanan atau centang di alat ini. Untuk server mandiri, cantumkan alamat IP mereka.
3. Pilih aturan penutup: ~all atau -all. Bagian berikutnya menjelaskan perbedaan dampaknya.
4. Publikasikan sebagai satu TXT record pada root domain Anda (biasanya dilambangkan dengan @ pada panel DNS). Jika sudah ada record yang diawali v=spf1, perbarui record tersebut alih-alih membuat yang baru.
5. Tunggu beberapa menit hingga DNS menyebar dan periksa kembali domain tersebut dengan SPF checker ini.

Setiap subdomain yang mengirim email membutuhkan SPF record sendiri karena subdomain tidak otomatis mewarisi record domain utama. Domain atau subdomain yang tidak pernah mengirim email harus dilindungi dengan: v=spf1 -all. RFC 7208 menyebut ini sebagai praktik terbaik untuk mencegah spoofing. NCSC Inggris juga merekomendasikan penambahan kebijakan DMARC p=reject dan Null MX record pada domain yang tidak aktif.

Record yang melebihi 255 karakter harus dibagi menjadi beberapa string bertanda kutip di dalam TXT record yang sama. Server penerima akan menggabungkan string tersebut tanpa spasi, sehingga spasi pemisah harus disertakan di dalam tanda kutip. Periksa panduan DNS hosting Anda mengenai penulisan string panjang.

~all atau -all: akhiran mana yang sebaiknya dipilih

Penyedia email terkemuka memiliki rekomendasi yang berbeda :

• Google merekomendasikan ~all (Softfail).
• M3AAWG, asosiasi penyedia email global, menyarankan ~all agar server penerima tidak menolak pesan sebelum evaluasi DMARC selesai.
• Microsoft merekomendasikan -all (Fail), asalkan DKIM dan DMARC sudah dikonfigurasi dengan benar.

Kelemahan dari -all adalah beberapa server penerima langsung menolak pesan di sesi awal SMTP sebelum memeriksa DMARC. Standar RFC 9989 (standar DMARC 2026) mencatat bahwa pesan yang ditolak lebih awal ini tidak pernah masuk dalam laporan agregat DMARC, sehingga mempersulit pelacakan kendala pengiriman email yang sah.

Dalam praktiknya, ~all adalah pilihan paling aman untuk domain aktif, terutama saat Anda masih menginventarisasi semua pengirim email Anda. Jika DMARC Anda disetel ke quarantine atau reject, DMARC yang akan menentukan tindakan akhir. Gunakan -all pada domain cadangan yang tidak pernah mengirim email. Jangan pernah memakai +all (mengizinkan seluruh internet) dan hindari ?all (setara dengan tidak ada proteksi).

Arti hasil pemeriksaan SPF record

Server email penerima menggunakan terminologi standar untuk mengklasifikasikan hasil pemeriksaan SPF pada header Authentication-Results dan laporan DMARC :

Error umum pada SPF record dan solusinya

Sebuah analisis pada 12 juta domain populer tahun 2023 menemukan SPF pada 56,5% domain dan 2,9% di antaranya memiliki error fatal. Kesalahan paling umum adalah include yang mengarah ke domain tanpa SPF, disusul oleh terlampauinya batas 10 DNS lookup.

Dua SPF record pada domain yang sama

Kerap terjadi saat menambahkan layanan baru dan panduan menyebutkan “tambahkan TXT record ini”, lalu dibuat record baru alih-alih mengedit yang sudah ada. Dua SPF record otomatis menghasilkan Permerror. Gabungkan semua mekanisme ke dalam satu TXT record yang dimulai dengan v=spf1 dan diakhiri satu aturan all.

Include mengarah ke domain tanpa SPF

Jika include mengarah ke domain yang tidak memiliki SPF record valid, seluruh pengujian gagal dengan Permerror. Ini sering dipicu salah ketik atau layanan yang sudah tutup. Hapus atau perbarui nilai include tersebut.

+all, ?all, atau tanpa aturan all di akhir

+all mengizinkan seluruh server di internet dan menghilangkan fungsi keamanan. ?all atau lupa menulis aturan all menghasilkan status netral. Selalu akhiri record dengan ~all atau -all.

Penggunaan mekanisme ptr

RFC 7208 secara tegas melarang mekanisme ptr. Mekanisme ini lambat, menghabiskan jatah lookup, dan rentan gagal saat DNS bermasalah. Ganti dengan mekanisme ip4 dan ip6 langsung.

Kesalahan ketik dan tanda baca

Spasi setelah titik dua, penulisan IPv4 yang tidak lengkap, atau istilah yang tidak dikenal akan menimbulkan Permerror. Kesalahan tersembunyi seperti include=example.com dengan tanda sama dengan akan diabaikan sebagai modifier asing sehingga layanan tersebut tidak pernah diotorisasi. Pemeriksa kami langsung mendeteksi masalah ini.

Tiga mitos umum seputar SPF record

• “SPF record tidak boleh menggunakan huruf besar.” RFC 7208 menyatakan bahwa mekanisme dan nama domain tidak membedakan huruf besar dan kecil.
• “SPF record maksimal hanya boleh 255 karakter.” Batas 255 karakter berlaku untuk tiap string dalam DNS TXT record. Record yang lebih panjang dipecah menjadi beberapa string bersambung.
• “Maksimal hanya boleh ada 10 include.” Batas 10 berlaku untuk total resolusi DNS lookup yang dihasilkan secara rekursif, bukan jumlah kata include yang tertulis.

Peran SPF dalam ekosistem autentikasi email

Status lulus pada SPF memiliki keterbatasan. Dalam penelitian 2023, 34,7% domain secara tidak langsung mengizinkan lebih dari 100.000 alamat IP. Selain itu, SPF kerap gagal saat email diteruskan (forwarding) secara otomatis karena IP server penerus tidak tercantum di record Anda.

DKIM mengatasi celah ini dengan menyematkan tanda tangan kriptografi pada isi pesan yang tetap utuh saat diteruskan. DMARC menyatukan keduanya dengan memastikan domain From cocok dengan domain yang divalidasi oleh SPF atau DKIM, serta memberi instruksi kepada penerima jika email gagal divalidasi. Konfigurasikan perlindungan lainnya dengan generator DKIM dan generator DMARC. Gunakan pencarian MX untuk memverifikasi server penerima Anda.

Autentikasi juga tidak mencegah pengiriman email ke alamat yang tidak aktif atau salah ketik yang berujung bounce. Bersihkan alamat individual dengan pemeriksa email atau bersihkan seluruh basis data kontak Anda dengan validasi email massal. Untuk ringkasan praktis bagi tim Anda, baca penjelasan lengkap mengenai SPF record di glosarium.