Bagaimana cara membuat catatan SPF untuk domain kustom?

Apa isi catatan SPF?

Catatan SPF adalah catatan TXT yang diawali v=spf1 dan dilanjutkan dengan mekanisme, masing-masing dengan kualifier opsional. RFC 7208 mendefinisikan mekanisme all, include, a, mx, ip4, ip6, exists dan ptr, serta modifier redirect. Kualifier menentukan hasil saat sebuah mekanisme cocok: + lolos (default), - gagal, ~ softfail dan ? netral.

Untuk domain yang memakai penyedia email, satu mekanisme melakukan hampir semua pekerjaan: include. Ia memberi tahu penerima untuk mengevaluasi catatan SPF dari domain penyedia dan memperlakukan kecocokan di sana sebagai kecocokan untuk domain Anda. Anda tidak pernah menyalin alamat IP dengan tangan, sehingga penyedia bisa mengganti servernya tanpa menyentuh DNS Anda. Jika Anda mengirim dari server milik sendiri, ip4 dan ip6 mendaftar alamatnya dan tidak memakan pencarian.

SPF diterbitkan sebagai catatan TXT. Satu string TXT dibatasi 255 oktet, dan catatan yang lebih panjang dipecah menjadi beberapa string yang digabung penerima tanpa spasi. Sebagian besar editor DNS melakukan pemecahan itu untuk Anda.

Mengapa sebuah domain hanya boleh memiliki satu catatan SPF?

Jika dua catatan TXT sama-sama diawali v=spf1, penerima tidak bisa memilih dan mengembalikan kesalahan permanen, sehingga setiap pesan gagal SPF. RFC 7208 menyatakan bahwa sebuah domain tidak boleh memiliki lebih dari satu catatan SPF. Proton, Mailbox.org dan Mailfence semuanya memberi saran yang sama: saat Anda menambahkan layanan, masukkan include-nya ke catatan yang sudah ada.

Penyebab umumnya adalah pindah. Anda menerbitkan catatan penyedia baru dan lupa yang lama. Buka daftar TXT, gabungkan dua baris menjadi satu, dan hapus sisanya. Saat Anda benar-benar berganti penyedia, ganti include lama alih-alih menambahkannya. Pemindahan itu sendiri dijelaskan di cara memindahkan email ke penyedia baru tanpa kehilangan email.

Apa batas 10 pencarian di SPF?

Evaluasi SPF berhenti dengan kesalahan permanen setelah 10 istilah yang melakukan pencarian DNS, jadi catatan yang membutuhkan 11 gagal untuk setiap pengirim. Istilah yang dihitung adalah include, a, mx, ptr, exists dan modifier redirect. Mekanisme all, ip4 dan ip6 tidak dihitung. RFC 7208 juga menyatakan implementasi sebaiknya berhenti setelah dua pencarian kosong, yaitu pencarian yang tidak mengembalikan apa pun atau nama domain yang tidak ada.

Sebuah include dihitung sebagai satu pencarian ditambah setiap pencarian di dalam catatan yang di-include. Satu penyedia kotak surat memang murah, tetapi tumpukan host surat, layanan buletin, meja bantuan dan formulir situs web menambah jumlahnya. Hapus dulu layanan yang tidak lagi Anda pakai. Jika sebuah alat menerbitkan alamat IP tetap, rentang ip4 dan ip6 tidak memakan apa pun. Jumlah bertingkat tepat dari setiap penyedia tidak diukur oleh Postelva, jadi uji catatan akhir Anda dengan pencarian sebelum Anda mengandalkannya, seperti ditunjukkan di cara memeriksa catatan MX, SPF, DKIM dan DMARC.

Apakah saya harus mengakhiri catatan SPF dengan ~all atau -all?

Gunakan ~all kecuali Anda mengendalikan setiap pengirim: ia menandai server lain sebagai mencurigakan tanpa meminta penerima menolak email begitu saja. Kualifier pada all adalah putusan untuk server mana pun yang tidak cocok dengan apa pun sebelumnya. -all berarti gagal, ~all berarti softfail, ?all berarti netral.

-all lebih ketat, tetapi RFC 9989 memperingatkan bahwa ia bisa membuat penerima menolak pesan sebelum DMARC berjalan, yang menyembunyikan pesan yang diteruskan dan yang seharusnya diselamatkan DKIM. Karena itu catatan yang ditampilkan Proton dan Mailbox.org berakhir dengan ~all. Menurut perbandingan Postelva tanggal 12 November 2026, ketiga penyedia dengan nilai SPF lengkap di halaman bantuan mereka (Proton Mail, Mailbox.org, Fastmail) masing-masing memakai tepat 1 include, sehingga catatan satu penyedia membayar 1 pencarian, dan dua di antaranya diakhiri ~all sementara nilai Fastmail diakhiri ?all.

Apa pun akhirannya, DMARC yang menegakkan aturan. Tetapkan kebijakan di sana, seperti dijelaskan dalam panduan menyiapkan DMARC. Ketiga catatan dibandingkan di SPF vs DKIM vs DMARC.

Apa yang diperiksa SPF, dan apa yang tidak?

SPF memeriksa server di balik envelope sender dan nama HELO, bukan alamat From pada pesan yang dilihat pembaca. Sebuah pesan bisa lolos SPF untuk domain yang tidak diperhatikan siapa pun dan tetap menampilkan domain Anda di baris From. DMARC menutup celah itu dengan mensyaratkan keselarasan antara keduanya.

SPF juga tidak bertahan saat diteruskan secara biasa, karena peneruskan mengirim dari alamat IP-nya sendiri. Aturan praktis yang bisa dikutip: SPF mengotorisasi server, satu catatan per domain, paling banyak 10 pencarian. Untuk domain yang tidak mengirim apa pun, terbitkan v=spf1 -all dan templat "tanpa email" dari Postelva; untuk domain yang mengirim dan menerima, templat DNS sekali klik untuk Proton Mail, Fastmail, Zoho Mail, Google Workspace dan Microsoft 365, plus templat SPF + DMARC dan templat "tanpa email" untuk domain yang tidak mengirim apa pun.