Rutin Cek PTR Record Tiap Ganti IP Server agar Email Tidak Ditolak

Situasinya biasanya begini. Server sudah pindah ke IP baru, website jalan normal, record A dan MX sudah diperbarui, tapi email keluar mulai kena bounce atau masuk folder spam di penerima tertentu. Kalau dicek, SPF dan DKIM lolos. Penyebab yang sering terlewat ada di arah sebaliknya, yaitu reverse DNS. IP baru belum punya PTR record yang mengarah ke hostname mail server, atau PTR-nya masih berisi nama generik bawaan provider. Artikel ini membahas apa yang sebenarnya dicek server penerima, kenapa PTR hampir selalu tertinggal saat migrasi, dan cara memutuskan seberapa rutin pengecekan ini perlu dilakukan di lingkunganmu.

Apa yang sebenarnya dicek server penerima

PTR record adalah kebalikan dari record A. Record A menjawab pertanyaan hostname ini IP-nya berapa. PTR menjawab IP ini milik hostname apa. Saat server kita membuka koneksi SMTP ke server penerima, yang terlihat pertama kali oleh penerima adalah IP kita, belum domain kita. Banyak filter lalu melakukan reverse lookup ke IP itu. Pengecekan yang lebih ketat disebut forward-confirmed reverse DNS (FCrDNS). Urutannya ada dua langkah:

Penerima melakukan lookup PTR pada IP pengirim dan mendapat sebuah hostname, misalnya mail.example.com.
Penerima melakukan lookup A (atau AAAA untuk IPv6) pada hostname tersebut. Hasilnya harus berisi IP pengirim yang sama.

Kalau kedua arah cocok, IP itu dianggap punya identitas yang konsisten. Kalau PTR kosong, menunjuk ke hostname yang tidak resolve, atau menunjuk ke hostname yang IP-nya berbeda, banyak penerima menganggapnya sinyal buruk. Sebagian langsung menolak di level SMTP. Sebagian lagi tetap menerima email tapi menurunkan skornya, sehingga email masuk spam. Ada satu lapisan lagi yang sering ikut diperiksa, yaitu nama yang dipakai server kita saat menyapa lewat perintah HELO/EHLO. Di Postfix nama ini biasanya diambil dari myhostname, di Exim dari primary_hostname. Tidak semua penerima mewajibkan nama HELO sama persis dengan PTR. Tapi kalau ketiganya selaras (HELO, PTR, dan record A hostname), kita menghilangkan satu alasan email dicurigai.

Kenapa PTR hampir selalu tertinggal saat ganti IP

Penyebab utamanya adalah soal kepemilikan. Record A, MX, SPF, dan DKIM tinggal di zona DNS domain kita, jadi kita bisa mengubahnya sendiri di DNS manager atau cPanel. PTR tidak tinggal di situ. PTR berada di reverse zone milik pemilik blok IP. Untuk IPv4, reverse zone ini berada di bawah in-addr.arpa, dan untuk IPv6 di bawah ip6.arpa. Pada kebanyakan VPS dan dedicated server, pemilik blok IP itu adalah provider, bukan kita. Akibatnya ada beberapa pola yang sering muncul:

Saat migrasi, semua record di zona domain disalin dengan rapi, tapi PTR tidak ikut karena memang tidak ada di zona itu.
IP baru dari provider biasanya sudah punya PTR default berupa nama generik. PTR-nya ada, jadi lookup tidak kosong, tapi isinya bukan hostname mail server kita dan tidak lolos FCrDNS.
Hostname server diganti saat migrasi, tapi PTR dan HELO masih memakai nama lama.
Server mendapat IPv6 di lokasi baru. MTA mulai mengirim lewat IPv6, padahal PTR hanya disetel untuk IPv4.

Pola terakhir ini paling membingungkan saat troubleshooting. Pengecekan PTR untuk IPv4 terlihat benar, tapi email tetap ditolak karena koneksi keluar ternyata memakai IPv6. Header bounce atau log MTA biasanya menunjukkan IP mana yang dipakai. Itu hal pertama yang perlu dilihat. Dari sisi support, pertanyaan yang paling sering muncul kira-kira begini: kenapa saya tidak bisa menambah PTR di DNS zone editor? Jawabannya memang tidak bisa dari situ. PTR diatur lewat panel provider, lewat tiket, atau lewat delegasi reverse zone kalau kamu mengelola blok IP sendiri. Caranya berbeda per provider, jadi cek dokumentasi provider masing-masing.

Cara memeriksa PTR dan forward-confirmed rDNS

Pengecekannya cukup dengan dig, dan semuanya read-only. Ganti contoh IP dan hostname di bawah dengan milikmu.

BASH

# 1. Reverse lookup: IP ini mengarah ke hostname apa?
dig -x 203.0.113.10 +short
# contoh format output: mail.example.com.

# 2. Forward lookup: hostname tadi mengarah ke IP yang sama?
dig mail.example.com A +short
# contoh format output: 203.0.113.10

# 3. Kalau server punya IPv6 dan MTA bisa mengirim lewat IPv6, cek juga
dig -x 2001:db8::10 +short
dig mail.example.com AAAA +short

# 4. Bandingkan dengan resolver publik agar tidak tertipu cache lokal
dig @1.1.1.1 -x 203.0.113.10 +short

Cara membaca hasilnya:

Langkah 1 kosong artinya belum ada PTR.
Langkah 1 berisi nama generik artinya masih memakai PTR default provider.
Langkah 1 benar tapi langkah 2 menunjuk ke IP lain artinya FCrDNS gagal. Biasanya ini terjadi karena record A hostname masih mengarah ke IP lama.

Setelah PTR diubah di provider, hasilnya tidak selalu langsung terlihat. Waktunya tergantung TTL reverse zone yang diatur pemilik blok IP. Karena itu langkah 4 berguna untuk memastikan yang kamu lihat bukan hasil cache resolver lokal. Satu catatan lagi: cek juga hostname yang dipakai MTA saat HELO, lalu pastikan nama itu sama dengan hasil langkah 1. Lokasi pengaturannya tergantung setup. Bisa langsung di konfigurasi Postfix atau Exim, bisa juga lewat pengaturan hostname di control panel.

Cek sekali, checklist perubahan IP, atau monitoring terjadwal

Kalau caranya sudah jelas, pertanyaan berikutnya adalah seberapa sering ini perlu dicek. Ada tiga pendekatan yang masuk akal. Tidak ada yang selalu paling benar. Pilihannya tergantung seberapa sering IP berubah dan seberapa mahal kalau email gagal terkirim.

Pendekatan	Cocok untuk	Kelemahan
Cek sekali setelah migrasi	Satu server, IP jarang berubah, volume email kecil	Bergantung pada ingatan. Mudah terlewat di migrasi berikutnya
Masuk checklist setiap perubahan IP atau hostname	Tim support atau admin yang rutin migrasi, re-provision VPS, atau pindah node	Perlu disiplin dan checklist yang benar-benar dipakai
Monitoring terjadwal	Banyak IP pengirim, email transaksional penting, banyak orang bisa mengubah infrastruktur	Perlu dibangun dan dirawat. Alert harus jelas siapa yang menindaklanjuti

Cek sekali sudah cukup kalau kamu mengelola satu VPS yang jarang disentuh. Risikonya bukan di teknis, tapi di jeda waktu. Migrasi berikutnya mungkin baru terjadi lama kemudian, dan saat itu tidak ada yang ingat bahwa PTR perlu diurus terpisah. Checklist perubahan IP adalah titik tengah yang biasanya paling sepadan. Begitu ada kejadian yang menyentuh IP, misalnya migrasi, ganti hostname, tambah IP pengirim, atau aktifkan IPv6, cek PTR dan FCrDNS ikut menjadi satu baris di daftar. Baris itu sebaiknya diletakkan bersama langkah DNS lain seperti menyiapkan record di nameserver baru sebelum cutover, yang dibahas di Pre-populating DNS Records on New Nameservers Before Registrar Cutover. Dengan begitu cek PTR tidak dianggap urusan terpisah yang gampang dilupakan. Monitoring terjadwal masuk akal kalau email adalah bagian inti layanan, misalnya notifikasi transaksi, reset password, atau invoice, atau kalau jumlah IP pengirim sudah terlalu banyak untuk dicek manual. Bentuknya tidak perlu rumit. Script kecil yang menjalankan dua lookup di atas untuk setiap IP pengirim, lalu memberi peringatan kalau hasilnya tidak cocok, sudah menutup sebagian besar kasus. Yang sering kurang justru kejelasan siapa yang menerima peringatan itu.

Pertanyaan yang menentukan pilihan

Alih-alih memilih berdasarkan selera, jawab beberapa pertanyaan ini. Seberapa sering IP atau hostname berubah? Kalau hampir tidak pernah, cek sekali saat setup dan saat migrasi sudah cukup. Kalau perubahan terjadi rutin, misalnya re-provisioning, pindah node, atau failover, checklist adalah syarat minimum. Seberapa mahal kalau email gagal terkirim? Untuk email newsletter yang tertunda sehari, dampaknya terbatas. Untuk email reset password atau konfirmasi pembayaran, kegagalan yang tidak terdeteksi berarti pengguna terkunci atau transaksi menggantung. Semakin mahal dampaknya, semakin masuk akal memasang monitoring. Siapa yang bisa mengubah PTR, dan berapa lama prosesnya? Kalau PTR bisa diubah sendiri lewat panel provider, perbaikannya cepat dan pengecekan reaktif masih bisa ditoleransi. Kalau harus lewat tiket ke provider, ada jeda tambahan. Dalam kondisi ini lebih baik PTR diminta sebelum IP baru dipakai untuk mengirim email, bukan setelah bounce mulai berdatangan. Apakah server punya IPv6? Kalau ya, jumlah yang perlu dicek bertambah. Pilihannya ada dua: setel PTR untuk IPv6 juga, atau pastikan MTA memang hanya mengirim lewat IPv4. Mana yang lebih cocok tergantung kebutuhan. Yang penting keputusannya dibuat dengan sengaja, bukan kebetulan. Seberapa terbiasa tim dengan DNS? Untuk tim yang masih belajar, checklist tertulis lebih aman daripada monitoring yang alert-nya tidak dipahami. Monitoring yang terus berbunyi tanpa ada yang tahu cara menindaklanjutinya lama-lama hanya akan diabaikan. Kalau mau aturan praktis, menurutku begini: anggap PTR sebagai bagian dari IP, bukan bagian dari domain. Setiap kali IP pengirim berubah, cek reverse lookup dan forward lookup-nya sebelum server mulai mengirim email, untuk IPv4 dan IPv6 kalau keduanya aktif, lalu pastikan nama HELO ikut selaras. Mulailah dari satu baris di checklist migrasi. Naikkan ke monitoring terjadwal hanya kalau jumlah IP atau pentingnya email memang membutuhkannya.