PTR Record Adalah: Fungsi, Cara Cek & Siapa yang Berhak

Setiap kali Anda mengetik alamat website di browser, nama domain diterjemahkan menjadi deretan angka alamat IP, lalu komputer Anda memakai angka itu untuk menemukan servernya. Penerjemahan inilah tugas utama DNS, dan catatan yang menanganinya disebut A record.

Namun ada situasi yang membutuhkan arah sebaliknya. Sebuah server menerima koneksi dari alamat 103.233.103.202 dan ingin tahu: mesin bernama apa yang sedang menghubungi saya? A record tidak bisa menjawabnya, karena ia hanya bekerja dari nama menuju angka.

Untuk kebutuhan itulah PTR record ada. Bagi pemilik VPS dan pengelola mail server, catatan ini kerap menjadi penentu tunggal. Email Anda sampai di inbox, atau ditolak mentah-mentah oleh Gmail.

Apa Itu PTR Record?

PTR record adalah catatan DNS yang memetakan sebuah alamat IP kembali ke nama host. Arti PTR sendiri adalah Pointer Record atau catatan penunjuk, sedangkan proses pencariannya lazim disebut reverse DNS lookup (pencarian DNS terbalik). Karena itu, pertanyaan "apa itu PTR" dan "reverse DNS adalah apa" menanyakan hal yang sama dari dua sisi. Yang pertama menanyakan catatannya, yang kedua menanyakan prosesnya.

Ada satu hal yang perlu Anda pegang sejak awal, karena hampir semua kebingungan soal PTR berakar di sini. PTR record melekat pada alamat IP, bukan pada nama domain. Yang memilikinya adalah pemegang blok IP tempat server Anda berada.

Perbedaan arah antara keduanya bisa dilihat sekilas:

Ada satu pembeda lagi dari saudara-saudaranya di keluarga catatan DNS. A record, MX record, dan CNAME berada di bawah kendali Anda selama Anda memegang domainnya. PTR tidak.

Cara Kerja PTR Record: Membalik IP Lewat Zona in-addr.arpa

DNS membaca hierarki dari kanan ke kiri. Pada nama mail.indowebsite.co.id, bagian paling kanan (id) adalah cabang tertinggi, lalu menyempit ke kiri sampai ke mail. Alamat IP bekerja sebaliknya. Pada 103.233.103.202, bagian paling kiri yang terluas, dan menyempit ke kanan sampai ke satu mesin.

Dua arah berlawanan ini tidak bisa disatukan begitu saja. Solusinya sederhana: oktet alamat IP dibalik urutannya, lalu ditempelkan ke domain khusus in-addr.arpa. Alamat 8.8.8.8 menjadi 8.8.8.8.in-addr.arpa, sedangkan 103.233.103.202 menjadi 202.103.233.103.in-addr.arpa.

Anda bisa melihat sendiri bahwa inilah yang benar-benar ditanyakan ke DNS:

dig -x 8.8.8.8 +noall +question

Perintah di atas hanya menampilkan bagian pertanyaan dari kueri, tanpa jawabannya:

;8.8.8.8.in-addr.arpa.		IN	PTR

Opsi -x pada dig bukan jenis kueri tersendiri. Ia hanya pintasan yang membalik urutan oktet dan menambahkan akhiran in-addr.arpa untuk Anda, lalu menanyakan record bertipe PTR seperti biasa.

Alur reverse DNS: 8.8.8.8 dibalik jadi 8.8.8.8.in-addr.arpa, ditanya ke pemegang blok IP, dijawab PTR dns.google.

Untuk IPv6, prinsipnya sama tetapi satuannya lebih halus. Alamatnya dipecah per empat bit (nibble), dibalik satu per satu, lalu ditempelkan ke domain ip6.arpa. Hasilnya panjang dan sulit dibaca manusia, sehingga kita menyerahkannya ke perkakas.

Siapa yang Berhak Membuat PTR Record

Inilah pertanyaan yang paling sering membuat orang buntu. Anda sudah membuka panel DNS domain, menyisir semua menu, dan tetap tidak menemukan pilihan untuk menambahkan PTR record. Bukan karena Anda melewatkannya. Pilihan itu memang tidak ada, dan tidak akan pernah ada.

Zona in-addr.arpa didelegasikan menurun mengikuti kepemilikan alamat IP, bukan kepemilikan domain. Rantainya berjenjang:

1. IANA memegang pangkal zona in-addr.arpa secara global.
2. RIR (Regional Internet Registry) menerima delegasi blok besar per kawasan. Untuk Asia Pasifik, perannya dipegang APNIC.
3. NIR dan ISP menerima delegasi blok yang lebih kecil dari RIR. Di Indonesia, tingkat ini diisi IDNIC di bawah APJII.
4. Penyedia hosting atau pemilik blok IP menerima delegasi terakhir, dan merekalah yang akhirnya bisa menuliskan PTR untuk setiap alamat.

Karena itu, "cara membuat PTR record" hampir selalu berarti "cara memintanya kepada pemegang IP Anda". Bentuk permintaannya berbeda-beda: penyedia VPS umumnya menyediakan kolom rDNS di panel, sementara penyedia lain meminta Anda membuka tiket dukungan.

Rantai delegasi in-addr.arpa menurun: IANA, RIR (APNIC), IDNIC/APJII, penyedia hosting, lalu berakhir di Anda.

Kalau email Anda lewat Google Workspace atau Microsoft 365

Sebagian besar pemilik domain tidak menjalankan mail server sendiri, dan untuk mereka jawabannya melegakan: tidak ada yang perlu dikerjakan. Saat email keluar lewat Google Workspace atau Microsoft 365, alamat IP pengirimnya milik penyedia, bukan milik Anda. PTR-nya sudah mereka atur dan sudah lolos uji dua arah.

Keduanya bisa Anda periksa sendiri:

dig +short -x 209.85.220.41    # jalur keluar Google Workspace
dig +short -x 40.107.223.41    # jalur keluar Microsoft 365

Perintah pertama menjawab mail-sor-f41.google.com, yang kedua mail-dm6nam11on2041.outbound.protection.outlook.com. Menanyakan A record dari kedua nama itu mengembalikan alamat yang sama seperti semula. Tidak ada penyedia yang mengizinkan Anda mengubahnya, dan memang tidak perlu.

Layanan pengiriman massal seperti SendGrid bergantung pada jenis alamat. Alamat bersama memakai nama penyedia seperti s.wrqvwxzv.outbound-mail.sendgrid.net. Alamat khusus yang disewa satu pelanggan boleh diarahkan ke nama pelanggan itu sendiri, dan di situlah aturan penamaan pada bagian rekomendasi mulai berlaku untuk Anda.

Yang tetap menjadi tanggung jawab Anda pada ketiga skenario itu adalah SPF, DKIM, dan DMARC. Ketiganya berbicara atas nama domain Anda, sehingga tidak bisa diserahkan ke pihak lain.

Kalau blok IP-nya milik Anda sendiri

Organisasi yang mendapat alokasi blok IP langsung dari IDNIC bisa mengelola zona reverse-nya sendiri. Syaratnya, zona tersebut sudah harus aktif di nameserver Anda sebelum diajukan. IDNIC mendelegasikan otoritasnya, tidak menjalankan DNS untuk Anda.

Delegasi IPv4 di IDNIC mengikuti batas oktet, yaitu /8, /16, dan /24. Konsekuensinya perlu diperhatikan: pemegang blok /22 tidak mendaftarkan satu zona, melainkan empat zona /24 terpisah. Untuk IPv6, batasnya mengikuti kelipatan empat bit dengan prefix bawaan /32 dan /48.

Kalau blok Anda lebih kecil dari /24

Delegasi DNS bekerja pada batas titik, sedangkan blok /26 atau /28 berada di tengah-tengah satu oktet. Secara harfiah, blok sekecil itu tidak bisa didelegasikan.

Jalan keluarnya diatur dalam RFC 2317, yang memakai CNAME di dalam pohon in-addr.arpa untuk mengarahkan tiap alamat ke zona lain yang Anda kelola. Detail teknisnya tidak perlu dikuasai, hanya akibatnya:

Inilah sebabnya penyedia hosting memberi Anda satu kolom isian "rDNS" per alamat IP, bukan zona DNS penuh. Blok yang Anda pegang biasanya terlalu kecil untuk didelegasikan secara utuh, sehingga penyedia menyimpan zonanya dan hanya membukakan nilai PTR-nya untuk Anda ubah.

Manfaat PTR Record untuk Pengiriman Email

Sebagian besar orang berkenalan dengan PTR record justru saat email mereka bermasalah. Alasannya konkret dan tertulis hitam di atas putih.

Sejak 1 Februari 2024, Google mensyaratkan setiap pengirim di atas 5.000 pesan per hari ke akun Gmail pribadi untuk memenuhi sejumlah ketentuan. Salah satunya menyebut PTR secara eksplisit. Alamat IP publik server SMTP pengirim harus memiliki PTR record yang menghasilkan sebuah hostname. Ketentuan berikutnya lebih ketat: alamat IP pengirim harus cocok dengan alamat IP dari hostname yang tertulis di PTR record tersebut.

Bagian kedua itu yang sering terlewat. Yang diperiksa bukan sekadar keberadaan PTR, melainkan konsistensi dua arah — dikenal sebagai forward-confirmed reverse DNS (FCrDNS). Uji lengkapnya berjalan seperti ini:

dig +short -x 8.8.8.8
dig +short A dns.google

Perintah pertama menghasilkan dns.google., perintah kedua menghasilkan 8.8.8.8 (bersama 8.8.4.4). Alamat awal muncul kembali di akhir, sehingga uji ini dinyatakan lolos.

Uji FCrDNS: PTR 8.8.8.8 menjawab dns.google, A record dns.google menjawab 8.8.8.8, cocok dengan awal.

Yahoo menambahkan satu lapis lagi lewat panduan pengirimnya. PTR yang dipakai harus bermakna, tidak generik, dan tidak boleh menyerupai penamaan otomatis untuk alamat IP dinamis. Hostname bergaya 103-233-103-202.pool.example.net menyampaikan pesan yang salah tentang keseriusan infrastruktur Anda.

Menariknya, kewajiban ini tidak semerata yang sering diberitakan. Pengumuman resmi Microsoft untuk pengirim volume tinggi di Outlook.com, Hotmail, dan Live.com yang berlaku Mei 2025 hanya mencantumkan tiga syarat wajib: SPF, DKIM, dan DMARC. PTR dan reverse DNS tidak disebut sama sekali di sana. Untuk Gmail, PTR bersifat mengikat; untuk Outlook, ia berguna tetapi bukan syarat tertulis.

Perlu ditegaskan bahwa PTR bukan pengganti mekanisme lain. Ia tidak memverifikasi isi pesan, dan tidak menyatakan siapa yang berhak mengirim atas nama domain Anda. Itu pekerjaan SPF, DKIM, dan DMARC yang dibahas di artikel email spoofing. PTR hanya menjawab satu pertanyaan: mesin ini mengaku bernama apa, dan apakah pengakuannya konsisten.

Kegunaan PTR Record di Luar Urusan Email

Email memang porsi terbesar, tetapi bukan satu-satunya.

1. Membaca log server jadi lebih cepat: catatan akses berisi deretan alamat IP mentah sulit ditelusuri. Dengan PTR yang rapi, baris log langsung menampilkan nama mesin asal koneksi.
2. Diagnosa jalur jaringan: perkakas seperti traceroute menampilkan nama tiap hop dari PTR. Nama itulah yang memberi tahu Anda paket sedang melewati jaringan operator mana.
3. Verifikasi crawler: bot yang mengaku sebagai crawler mesin pencari bisa diuji lewat PTR alamatnya. Kalau tidak menunjuk ke domain resmi, ia penyamar.

Sebaliknya, ada situasi ketika PTR tidak memberi Anda apa pun. Website yang menumpang hosting bersama dan tidak mengirim email dari IP sendiri tidak akan berubah performanya, naik peringkatnya, atau menjadi lebih aman. Mengurusnya baru berarti kalau Anda memegang IP publik dan mengirim email dari sana.

Cara Cek PTR Record

Pengecekan PTR record bisa dilakukan dari komputer Anda sendiri tanpa perkakas tambahan.

Langkah #1: Lewat Command Prompt di Windows

Windows menyediakan nslookup secara bawaan. Buka Command Prompt, lalu jalankan:

nslookup -type=ptr 8.8.8.8.in-addr.arpa

Alamatnya ditulis terbalik lengkap dengan akhiran in-addr.arpa. Bentuk singkat nslookup 8.8.8.8 juga bekerja, tetapi menuliskannya eksplisit membuat Anda terbiasa dengan bentuk sesungguhnya dari kueri ini.

Langkah #2: Lewat terminal di Linux atau macOS

Di Linux dan macOS, dig memberi hasil yang paling jelas. Opsi +noall +answer menyaring keluaran agar hanya menyisakan baris jawaban:

dig -x 8.8.8.8 +noall +answer

Hasilnya menampilkan satu baris utuh berisi nama terbalik, TTL, kelas, tipe record, dan nilainya:

8.8.8.8.in-addr.arpa.	74580	IN	PTR	dns.google.

Kalau Anda hanya membutuhkan nilainya, opsi +short memangkas semuanya menjadi satu baris. Alamat IP tanpa PTR akan mengembalikan keluaran kosong, bukan pesan galat. Banyak orang mengira perintahnya gagal, padahal jawabannya sudah didapat: alamat itu tidak punya PTR.

Langkah #3: Memastikan FCrDNS-nya lolos

Mengecek keberadaan PTR saja belum cukup, karena yang diperiksa penerima email adalah konsistensi dua arahnya. Satu baris berikut mengambil hasil PTR lalu langsung menanyakan A record-nya:

ip=8.8.8.8; h=$(dig +short -x $ip); echo "$h -> $(dig +short A ${h%.})"

Uji ini lolos apabila alamat yang Anda masukkan muncul kembali di sisi kanan. Kalau yang muncul alamat lain, atau tidak muncul apa-apa, di situlah letak masalahnya.

Tersedia pula layanan PTR record check daring seperti MXToolbox dan DNSChecker. Keduanya berguna untuk memeriksa dari luar jaringan Anda, memastikan hasilnya sama seperti yang dilihat server penerima.

Kelemahan dan Kesalahpahaman yang Sering Terjadi

Bagian ini justru yang paling sering menghemat waktu Anda.

PTR tidak harus sama dengan nama domain Anda. Ini kesalahpahaman nomor satu, dan paling mudah dipatahkan dengan contoh nyata. Alamat mail.indowebsite.co.id menunjuk ke 103.233.103.202, sementara PTR alamat itu berbunyi matahari.indowebsite.net — nama yang sama sekali berbeda dari domain di alamat email.

Meski begitu, matahari.indowebsite.net menunjuk balik ke 103.233.103.202, sehingga FCrDNS-nya tetap lolos. Yang diminta adalah konsistensi, bukan kesamaan nama.

Satu alamat IP praktis hanya punya satu PTR bermakna. Server hosting bersama bisa menampung ratusan domain, tetapi alamatnya tetap satu. Karena itu PTR-nya diisi hostname server, bukan nama salah satu pelanggan. Secara teknis satu alamat boleh memiliki beberapa PTR, tetapi praktik itu dihindari karena penerima tidak punya cara memilih mana yang benar.

PTR bukan mekanisme keamanan. Ia hanya menyatakan nama yang dipilih pemegang IP. Ia tidak mencegah spam, tidak mengenkripsi apa pun, dan tidak membuktikan identitas.

PTR tidak ditulis di berkas hosts. Berkas hosts hanya memengaruhi komputer Anda sendiri, sedangkan PTR harus bisa dibaca seluruh internet. Baris yang Anda tambahkan di sana tidak terlihat oleh server penerima mana pun.

Alamat rumahan dan seluler umumnya tidak punya PTR sama sekali. Kami menguji dua alamat dari rentang operator Indonesia, dan keduanya mengembalikan hasil kosong. Inilah alasan teknis kenapa menjalankan mail server dari koneksi rumah hampir selalu berakhir dengan penolakan.

Galat 1.0.0.127.in-addr.arpa di Windows Server bukan masalah PTR. Kalau dibalik, alamat itu adalah 127.0.0.1, yaitu alamat loopback. Windows sedang mencoba mendaftarkan PTR untuk alamat lokal yang memang tidak seharusnya masuk DNS publik. Perbaikannya ada di pengaturan registrasi dinamis, bukan di zona reverse Anda.

Tidak ada catatan lain yang bisa menggantikan PTR. Kalau Anda tidak bisa memperolehnya untuk alamat Anda, jalan keluarnya bukan mencari pengganti. Kirimkan email lewat alamat lain yang PTR-nya sudah beres, misalnya relay dari penyedia layanan email.

Rekomendasi Konfigurasi PTR Record

Berikut panduan yang bisa Anda pakai langsung saat menyiapkan atau memperbaiki PTR.

1. Satu PTR per alamat IP publik: isi tepat satu nilai untuk tiap alamat. Kalau Anda mengirim email dari tiga alamat IP, ketiganya membutuhkan PTR masing-masing.
2. Isi dengan FQDN, bukan nama pendek: nilainya harus berupa nama lengkap seperti mail.domainanda.com, bukan mail saja. Nama pendek tidak bisa ditelusuri dari luar jaringan Anda.
3. Pastikan hostname-nya punya A record balik: hostname yang Anda tulis di PTR wajib memiliki A record yang menunjuk kembali ke alamat yang sama. Tanpa itu, FCrDNS gagal dan syarat Google tidak terpenuhi.
4. Samakan dengan nama yang diumumkan SMTP: hostname di PTR sebaiknya sama dengan nama yang diumumkan mail server pada perintah HELO atau EHLO. Hindari pula penamaan bergaya alamat dinamis — mail.domainanda.com jauh lebih baik daripada host-103-233-103-202.example.net.
5. Beri waktu propagasi sampai 24 jam: perubahan PTR mengikuti TTL zona reverse yang dipegang penyedia, dan nilainya di luar kendali Anda. Contoh pada artikel ini menunjukkan TTL 74.580 detik, sekitar 20 jam. Jangan menyimpulkan perubahan gagal sebelum sehari penuh berlalu.

Pertanyaan yang Sering Muncul

Apa yang dimaksud dengan PTR? Arti PTR adalah Pointer Record, yaitu jenis catatan DNS yang memetakan alamat IP kembali ke sebuah nama host. Singkatan PTR juga dipakai di bidang lain di luar dunia jaringan, sehingga konteksnya perlu diperhatikan.

Apa itu record pada DNS? Record DNS adalah satu baris data di dalam zona DNS yang memberi tahu internet sesuatu tentang domain atau alamat Anda. Tiap tipe menangani satu pekerjaan: A untuk alamat IPv4, MX untuk tujuan email, CNAME untuk alias, PTR untuk pemetaan terbalik.

Apa yang dimaksud dengan address record? Address record atau A record memetakan nama domain ke alamat IPv4, dan padanannya untuk IPv6 disebut AAAA record. A record inilah lawan arah dari PTR record.

Apa fungsi MX record? MX record menunjukkan server mana yang berhak menerima email untuk sebuah domain. Perbedaannya dengan PTR terletak pada arah lalu lintasnya. MX mengatur email yang masuk ke domain Anda, sedangkan PTR memengaruhi diterima atau tidaknya email yang keluar dari server Anda.

Kesimpulan

PTR record adalah catatan DNS yang memetakan alamat IP kembali ke nama host. Ia hidup di zona in-addr.arpa milik pemegang blok IP, bukan di zona domain Anda. Karena itu kolom untuk mengisinya memang tidak ada di panel DNS domain; yang Anda lakukan adalah memintanya kepada penyedia yang memegang alamat tersebut.

Urus PTR kalau Anda memegang IP publik sendiri dan mengirim email dari sana, terutama bila volumenya di atas 5.000 pesan per hari ke Gmail. Pastikan nilainya berupa FQDN yang menunjuk balik ke alamat yang sama. Sebaliknya, kalau email Anda keluar lewat Google Workspace, Microsoft 365, atau layanan hosting, PTR sudah diurus mereka dan tidak perlu Anda sentuh.

Semoga artikel ini membantu.