Apa Itu Mekanisme SPF ptr — dan Mengapa Masih Ada di 950,631 Record? (2026)

Q: Apa yang harus saya gunakan sebagai pengganti ptr?

Blok ip4:/ip6: untuk server yang Anda kendalikan, atau include: yang didokumentasikan penyedia Anda. Keduanya deterministik, cepat, dan andal — segala hal yang bukan ptr.

Q: Apakah ptr dihitung terhadap batas 10-lookup SPF?

Ya — setiap ptr memakan setidaknya satu dari sepuluh DNS lookup yang akan dilakukan penerima sebelum menyerah dengan PermError. Pada record yang sudah bertumpuk dengan mekanisme include:, mekanisme mati inilah yang bisa menjadi pendorong yang membuat Anda melampaui batas.

Diterbitkan 2026-07-03

Angka per 2026-06-29 · metodologi v7. Sensus agregat mencakup 261 juta domain yang dinilai. Semua angka bersifat agregat — tidak pernah merujuk record satu bisnis tertentu. Lihat cara kami menilai.

ptr adalah mekanisme SPF yang mengotorisasi pengirim melalui reverse-DNS lookup — dan standar SPF itu sendiri sudah berkata “jangan gunakan” sejak 2014. 12 tahun berlalu, 950,631 domain masih mempublikasikannya. Itu kira-kira 1 dari 146 dari 139 juta record SPF di internet yang membawa mekanisme yang dinyatakan usang oleh spesifikasi sebelum sebagian domain tersebut bahkan didaftarkan.

Apa yang seharusnya dilakukan ptr

ptr berkata: “terima email dari server mana pun yang reverse DNS-nya kembali mengarah ke domain saya.” Kedengarannya elegan — tidak ada daftar IP yang perlu dipelihara. Dalam praktiknya, ini mengharuskan penerima melakukan reverse lookup pada IP yang terhubung, lalu mengonfirmasi-maju (forward-confirm) setiap hostname yang muncul. RFC 7208 (§5.5) menyatakannya usang dengan kata-kata yang jelas: mekanisme ini “lambat, tidak seandal mekanisme lain dalam kasus kesalahan DNS, dan membebani name server .arpa dengan kebutuhan sumber daya yang besar” — serta menginstruksikan bahwa mekanisme ini “SEBAIKNYA TIDAK digunakan.”

Mengapa masih menjadi jebakan di 2026

Tiga alasan mengapa mekanisme yang dinyatakan usang 12 tahun lalu masih penting:

Ia menghabiskan anggaran lookup Anda. Setiap ptr dihitung terhadap batas keras SPF sebesar 10 DNS lookup per pemeriksaan — batas yang, begitu terlampaui, membatalkan seluruh record dengan PermError. Mekanisme yang tidak melakukan apa pun secara andal tetap memakan anggaran yang dibutuhkan oleh mekanisme include: Anda yang sesungguhnya.
Ia gagal secara tak terduga. Reverse DNS adalah sudut yang paling jarang dipelihara di sebagian besar jaringan. Ketika lookup ptr timeout atau forward-confirm gagal, email sah Anda kehilangan SPF pass yang diandalkannya.
Sebagian penerima melewatkannya sepenuhnya. Karena standar menyatakannya usang, sebagian implementasi begitu saja mengabaikan ptr — sehingga pengirim yang seharusnya diotorisasinya tidak pernah terlindungi sejak awal.

Dari mana asalnya

Hampir tidak ada yang memilih ptr hari ini. Ia datang melalui warisan: panduan pengaturan yang ditulis pada 2009, template yang disalin dari konfigurasi server lama, sebuah record yang “berfungsi” yang dimigrasikan utuh melalui tiga kali perpindahan hosting. Itulah pola yang dilihat sensus kami pada setiap mekanisme yang usang-tetapi-hadir: nasihat lama tidak mati, ia hanya di-copy-paste. Domain yang membawa ptr bukanlah ceroboh — mereka mengikuti instruksi yang telah dipensiunkan 12 tahun lalu.

Cara memperbaikinya — gratis, lima menit

Temukan record SPF Anda (dig TXT yourdomain.com atau periksa gratis).
Jika mengandung ptr, identifikasi server mana yang mengandalkannya.
Ganti ptr dengan bentuk yang presisi: blok ip4:/ip6: untuk server yang Anda kendalikan, atau include: yang didokumentasikan penyedia Anda.
Selagi Anda di sana, pastikan record diakhiri dengan qualifier yang benar — lihat ~all vs -all.

Pertanyaan yang sering diajukan

Apa arti ptr dalam sebuah record SPF? Ia mengotorisasi server mana pun yang reverse DNS-nya kembali mengarah ke domain Anda. RFC 7208 §5.5 menyatakannya usang pada 2014 karena lambat dan tidak andal, serta mengatakan mekanisme ini SEBAIKNYA TIDAK digunakan — namun 950,631 domain masih mempublikasikannya per 2026-06-29.

Apakah mekanisme SPF ptr pernah valid? Ia masih dapat di-parse, dan sebagian penerima masih mengevaluasinya — tetapi standar menyarankan untuk tidak menggunakannya dalam segala kasus, sebagian penerima mengabaikannya, dan ia memakai salah satu dari sepuluh DNS lookup Anda. Tidak ada konfigurasi modern di mana ptr adalah jawaban yang tepat.

Apa yang harus saya gunakan sebagai pengganti ptr? Blok ip4:/ip6: untuk server yang Anda kendalikan, atau include: yang didokumentasikan penyedia Anda. Keduanya deterministik, cepat, dan andal — segala hal yang bukan ptr.

Apakah ptr dihitung terhadap batas 10-lookup SPF? Ya — setiap ptr memakan setidaknya satu dari sepuluh DNS lookup yang akan dilakukan penerima sebelum menyerah dengan PermError. Pada record yang sudah bertumpuk dengan mekanisme include:, mekanisme mati inilah yang bisa menjadi pendorong yang membuat Anda melampaui batas.

Periksa record Anda dari hantu

Sebuah mekanisme yang dinyatakan usang 12 tahun lalu, masih bercokol di DNS Anda, persis jenis hal yang tidak ada orang cari. Memeriksanya hanya butuh setengah menit.

Periksa domain Anda → · Perbaiki SPF → · Dua record SPF = tidak ada → · Model kematangan SPF → · Hanya data agregat. Data disimpan dan diproses di UE.