Yeni kurduğun mail sunucusundan gönderdiğin ilk test maili Gmail'de spam klasörüne düştüyse ya da Outlook tarafından "550 5.7.1 rejected" ile geri geldiyse, suçlunun büyük ihtimalle eksik bir PTR kaydı olduğunu söyleyebilirim. PTR kaydı, yani ters DNS (rDNS), bir IP adresinin hangi alan adına ait olduğunu söyleyen kayıttır ve mail dünyasında neredeyse kimlik kartı işlevi görür. Alıcı sunucu bağlantıyı kabul etmeden önce "bu IP kimin?" diye sorar; cevap alamazsa ya da cevap tutarsızsa, mesajın içeriğine bile bakmadan seni reddedebilir.
Bu rehberde PTR kaydının nasıl çalıştığını, neden normal DNS kayıtlarından farklı bir yerde tutulduğunu, mevcut kaydını nasıl kontrol edeceğini, sağlayıcından nasıl talep edeceğini ve ileri-geri uyum (FCrDNS) denilen doğrulamayı nasıl sağlayacağını anlatacağım. Ayrıca Postfix ve benzeri MTA'larda HELO adının PTR ile aynı olmasının neden şart olduğuna, IPv6 tarafındaki farklara ve en sık karşılaştığım hatalara değineceğim. Sonunda test maillerinin başlıklarında Received satırının nasıl görünmesi gerektiğini de bileceksin.
PTR Kaydı Nedir, Neden Mail için Bu Kadar Kritik#
Normal DNS kayıtları soldan sağa çalışır: mail.firmaniz.com isminden 185.12.34.56 IP'sine gidersin. PTR kaydı bunun tersini yapar: 185.12.34.56 IP'sinden mail.firmaniz.com ismine gidersin. Bu ters yön, teknik olarak in-addr.arpa adlı özel bir DNS ağacında yaşar ve alan adının DNS panelinden yönetilmez. Kaydın yetkisi, IP bloğunun tahsis edildiği kuruluştadır; yani hosting ya da sunucu sağlayıcındadır. Bu, insanların en çok takıldığı noktadır: alan adı panelinde PTR kaydı ekleme alanını ararsın ve bulamazsın, çünkü orada olmaması gerekir.
Mail sunucularının bu kaydı bu kadar önemsemesinin sebebi ekonomiktir. Bir alan adı almak ve DNS'ine istediğin kaydı yazmak dakikalar sürer ve neredeyse bedavadır; ama bir IP bloğuna sahip olmak ve o bloğun ters bölgesine kayıt yazdırmak, o IP'nin gerçek bir sahibi olduğunu ve o sahibin sana kayıt açtığını gösterir. Yani PTR kaydı, "bu IP rastgele bir botnet makinesi değil, sorumluluğu bilinen bir mail sunucusudur" anlamına gelen ucuz ama etkili bir sinyaldir. Bu yüzden büyük sağlayıcıların çoğu, PTR kaydı olmayan bir IP'den gelen SMTP bağlantısını ya doğrudan reddeder ya da ciddi bir spam puanı ekler.
| Kayıt tipi | Yön | Kimde tutulur | Kim yönetir |
|---|---|---|---|
| A | İsim → IPv4 | Alan adının DNS bölgesi | Sen (DNS panelin) |
| AAAA | İsim → IPv6 | Alan adının DNS bölgesi | Sen |
| MX | Alan adı → mail sunucusu adı | Alan adının DNS bölgesi | Sen |
| PTR | IP → İsim | in-addr.arpa / ip6.arpa | IP sağlayıcın |
in-addr.arpa: Ters Bölgenin Mantığı#
Ters DNS'in işleyişini bir kez anladığında hata ayıklaman çok kolaylaşır. IPv4 adresleri en genelden en özele soldan sağa yazılır (185 en geniş blok, 56 tek makine), DNS isimleri ise tam tersi biçimde sağdan sola daralır (com en genel, mail en özel). İki sistemi birleştirmek için IP adresi ters çevrilir ve sonuna in-addr.arpa eklenir. Yani 185.12.34.56 adresinin ters DNS ismi şudur:
56.34.12.185.in-addr.arpa. 3600 IN PTR mail.firmaniz.com.
Sağlayıcının ters bölge dosyasında bu satır tam olarak bu şekilde durur. Sen bir /24 blok sahibiysen (örneğin 185.12.34.0/24) sağlayıcı bu bölgenin yetkisini senin DNS sunucularına devredebilir ve kayıtları kendin yazarsın; bu duruma "reverse delegation" denir ve genellikle kendi IP bloğu olan kurumlarda görülür. Tek bir IP kiralayan çoğu kullanıcı içinse yol basittir: sağlayıcının panelinden ya da destek talebiyle kaydı istersin.
Bu ters ağacı bilmek, kara liste sorgularının neden ters yazıldığını da açıklar. Bir IP'nin kara listede olup olmadığını sorgularken de aynı ters mantık kullanılır:
# 185.12.34.56 adresini kara liste için sorgula (IP ters çevrilir)
dig +short 56.34.12.185.zen.spamhaus.org
# Cevap dönerse IP listelenmiş demektir; boşsa temizdir.
Mevcut PTR Kaydını Kontrol Etme#
Herhangi bir işlem yapmadan önce mevcut durumu ölçmelisin. Üç farklı komutla aynı bilgiye ulaşırsın ve hepsini bilmek işine yarar:
# En kısa yol: dig'in ters sorgu kısayolu
dig -x 185.12.34.56 +short
# Beklenen çıktı:
# mail.firmaniz.com.
# Aynı sorgunun uzun hâli (ne olduğunu görmek için)
dig PTR 56.34.12.185.in-addr.arpa
# host komutu ile
host 185.12.34.56
# 56.34.12.185.in-addr.arpa domain name pointer mail.firmaniz.com.
# Windows tarafında
nslookup 185.12.34.56
dig -x boş dönüyorsa PTR kaydın yok demektir; bu durumda mail sunucun daha ilk el sıkışmada dezavantajlı başlar. Bir sonuç dönüyor ama sağlayıcının varsayılan ismi görünüyorsa (static-185-12-34-56.saglayici.net gibi) kaydın var ama sana ait değil demektir; bunu kendi mail sunucu adınla değiştirmen gerekir. Sunucunun kendi kimliğini nasıl tanıttığını da kontrol et:
# Sunucunun FQDN'i ile PTR kaydı aynı mı?
hostname -f
# mail.firmaniz.com
# SMTP bağlantısında sunucu kendini nasıl tanıtıyor?
openssl s_client -connect mail.firmaniz.com:25 -starttls smtp -quiet 2>/dev/null | head -3
Bu üç değerin —PTR kaydı, sunucunun FQDN'i ve SMTP HELO adı— birbiriyle aynı olması gerekir. Farklıysa alıcı sunucular tutarsızlık görür ve puanını düşürür.
PTR Kaydını Sağlayıcıdan Talep Etme#
Kaydı oluşturma yöntemi sağlayıcıya göre değişir ama üç ana yol vardır. Birincisi, sağlayıcının müşteri panelinde IP'nin yanındaki "rDNS" ya da "Ters DNS" alanına doğrudan yazmandır; sunucu sağlayıcılarının çoğu bunu self servis hâle getirmiştir ve kayıt dakikalar içinde yayına girer. İkincisi, destek talebiyle istemektir. Üçüncüsü, kendi IP bloğun varsa ters bölgenin sana devredilmesidir.
Destek talebi açacaksan, bilgiyi tam vermek işi tek turda bitirir. Talep metnin şu üç bilgiyi içermeli:
- Hangi IP için kayıt istiyorsun:
185.12.34.56 - Hangi isme işaret etmeli:
mail.firmaniz.com - O ismin düz A kaydının aynı IP'ye baktığının teyidi
Üçüncü maddeyi kendin doğrulamadan talep açma; çünkü ciddi sağlayıcıların çoğu, düz kaydı doğrulamadan PTR açmaz:
# Düz kaydı doğrula — PTR talebinden ÖNCE bu çalışmalı
dig +short mail.firmaniz.com A
# 185.12.34.56
Kayıt açıldıktan sonra yayılma genelde hızlıdır ama sıfır değildir; ters bölgenin TTL'i kadar beklemen gerekebilir. Kaydı kendi panelinden ekleyip birkaç dakika sonra dig -x ile teyit et. Clou.TR tarafında rDNS talebi, VDS ve sanal sunucu paketlerinde destek üzerinden karşılanır; hazır kurulu SMTP sunucu paketlerinde ise PTR kaydı kurulumun standart adımlarından biridir, sipariş formunda istediğin hostname doğrudan bu kayda yazılır.
FCrDNS: İleri-Geri Uyum ve HELO Adı#
Alıcı sunucuların uyguladığı asıl test, PTR kaydının varlığı değil tutarlılığıdır. Buna Forward-Confirmed reverse DNS (FCrDNS) denir ve iki adımdan oluşur: IP'den isme git, sonra o isimden tekrar IP'ye git; başladığın yere dönüyorsan test geçilmiştir. Elle şöyle doğrularsın:
# 1. adım: IP'den isme
dig -x 185.12.34.56 +short
# mail.firmaniz.com.
# 2. adım: isimden tekrar IP'ye
dig +short mail.firmaniz.com A
# 185.12.34.56 <-- başladığımız IP ile aynı, FCrDNS geçti
İkinci adımda farklı bir IP dönüyorsa (örneğin alan adını bir CDN arkasına aldıysan ve mail alt alan adı da proxy'ye düştüyse) test başarısız olur. Bu yüzden mail sunucusunun A kaydını asla proxy/CDN arkasına koyma; doğrudan sunucunun gerçek IP'sini göstersin.
Üçüncü bileşen HELO/EHLO adıdır. SMTP oturumu başlarken sunucun kendini bir isimle tanıtır ve bu ismin de PTR ile aynı olması beklenir. Postfix'te bunu iki parametre belirler:
# /etc/postfix/main.cf
# Sunucunun kimliği — PTR kaydıyla BİREBİR aynı olmalı
myhostname = mail.firmaniz.com
# Giden bağlantılarda kullanılacak HELO adı
smtp_helo_name = $myhostname
# Kendi alan adını yerel teslim etmek istiyorsan
mydomain = firmaniz.com
myorigin = $mydomain
Değişiklikten sonra postfix reload çalıştırıp giden bir mailin başlığını kontrol et. Doğru kurulmuş bir sistemde alıcı tarafındaki Received satırı şuna benzer:
Received: from mail.firmaniz.com (mail.firmaniz.com [185.12.34.56])
by mx.alici.com with ESMTPS id abc123
Parantez içindeki isim ile köşeli parantez içindeki IP'nin eşleşmesi, FCrDNS'in geçtiğinin görünür kanıtıdır. Eğer orada unknown [185.12.34.56] yazıyorsa PTR kaydın yok ya da çözümlenmiyor demektir. Bu testi SMTP test aracı ile üretilen komutlarla kendi terminalinden de yapabilirsin.
IPv6, Birden Fazla IP ve Sık Yapılan Hatalar#
IPv6 tarafında mantık aynı, biçim farklıdır. Adres nibble (dört bitlik) parçalarına ayrılır, ters çevrilir ve ip6.arpa altına yazılır — elle yazması zahmetlidir, bu yüzden sağlayıcı paneli kullanmak en pratik yoldur. Kritik nokta şudur: sunucun IPv6 üzerinden mail gönderiyorsa, IPv6 adresinin de PTR kaydı olmak zorundadır. Büyük sağlayıcılar IPv6 gönderimlerine IPv4'ten daha katı davranır; PTR'siz IPv6 bağlantısı çoğu zaman doğrudan reddedilir. IPv6 PTR'ini ayarlayamıyorsan, giden mailleri IPv4'e sabitlemek daha güvenli bir tercihtir:
# /etc/postfix/main.cf — giden SMTP'yi IPv4'e sabitle
inet_protocols = ipv4
smtp_address_preference = ipv4
Sunucuda birden fazla IP varsa ikinci bir tuzak devreye girer: Postfix hangi IP'den çıkacağını işletim sisteminin yönlendirme tablosuna göre seçer ve bu, PTR kaydı olan IP olmayabilir. Çıkış IP'sini açıkça sabitle:
# Giden bağlantılarda kullanılacak kaynak IP
smtp_bind_address = 185.12.34.56
Şimdi en sık gördüğüm hatalar. Birincisi, PTR kaydını alan adının DNS panelinden eklemeye çalışmak; orada eklediğin kayıt hiçbir işe yaramaz, kaydın yeri IP sağlayıcısıdır. İkincisi, PTR'i bir alan adına (firmaniz.com) değil de mail sunucusunun tam adına (mail.firmaniz.com) yazmayı ihmal etmek; kök alan adı genelde web sunucusuna baktığı için FCrDNS testi kırılır. Üçüncüsü, PTR kaydını doğru yazıp HELO adını değiştirmeyi unutmak; sunucu hâlâ localhost.localdomain ya da varsayılan bir isimle tanıtır kendini. Dördüncüsü, aynı IP'ye birden fazla PTR kaydı yazmak; teknik olarak mümkündür ama mail dünyasında kafa karışıklığı yaratır, tek ve net bir isim kullan. Beşincisi, PTR'i ayarlayıp maillerin hâlâ spam'e düştüğünü görünce vazgeçmek; PTR gerekli şarttır ama tek başına yeterli değildir — SPF, DKIM ve DMARC da kurulmalıdır. Maillerin Gmail'e ulaşmıyorsa Gmail'e mail gitmiyor yazısındaki sıralı kontrol listesi işini kolaylaştırır.
Sıkça Sorulan Sorular#
PTR kaydı ne kadar sürede aktif olur#
Sağlayıcı kaydı oluşturduktan sonra genellikle dakikalar içinde sorgulanabilir hâle gelir, ancak ters bölgenin TTL değeri kadar bir yayılma payı bırakmak gerekir. Pratikte 15 dakika ile birkaç saat arasında değişir. dig -x IP +short komutu doğru ismi dönmeye başladıktan sonra test maili göndermen en sağlıklısıdır; erken gönderilen testler eski önbelleğe takılabilir.
PTR kaydını kendi DNS panelimden ekleyebilir miyim#
Hayır, ekleyemezsin. PTR kayıtları alan adının DNS bölgesinde değil, IP bloğunun ters bölgesinde (in-addr.arpa) tutulur ve bu bölgenin yetkisi IP'yi sana tahsis eden sağlayıcıdadır. Kendi panelinde PTR alanı görsen bile oraya yazacağın kayıt, IP sorgulandığında dönmez. Doğru yol sağlayıcının panelini kullanmak ya da destek talebi açmaktır.
PTR kaydı olmadan mail gönderebilir miyim#
Teknik olarak gönderebilirsin ama teslimat oranın ciddi biçimde düşer. Büyük sağlayıcıların bir kısmı PTR kaydı olmayan IP'lerden gelen SMTP bağlantısını doğrudan reddeder, bir kısmı da yüksek spam puanı ekler. Küçük alıcı sunucular geçirse bile Gmail, Outlook ve Yahoo gibi hedeflerde ciddi sorun yaşarsın. Üretim ortamında PTR kaydı isteğe bağlı değil, gerekli şarttır.
PTR kaydımın doğru olup olmadığını nasıl kontrol ederim#
İki komut yeter. Önce dig -x 185.12.34.56 +short ile IP'den ismi al, sonra dig +short mail.firmaniz.com A ile o isimden tekrar IP'yi al. İkinci komut başladığın IP'yi dönüyorsa ileri-geri uyum (FCrDNS) sağlanmış demektir. Ek olarak giden bir mailin başlığındaki Received satırında ismin unknown yerine gerçek hostname olarak göründüğünü doğrula.
Birden fazla alan adı için tek PTR kaydı yeterli mi#
Evet, yeterlidir ve doğrusu da budur. PTR kaydı IP adresine aittir, alan adına değil. Aynı sunucudan on farklı alan adı adına mail gönderiyor olsan bile tek bir PTR kaydın olur ve bu kayıt sunucunun kendi adını (mail.firmaniz.com) göstermelidir. Alan adı bazlı kimlik doğrulama, PTR ile değil SPF ve DKIM kayıtlarıyla sağlanır.
rDNS ile SPF arasındaki fark nedir#
rDNS, IP adresinin hangi isme ait olduğunu söyler ve sunucunun kimliğiyle ilgilidir. SPF ise bir alan adının hangi IP'lerden mail gönderme yetkisi verdiğini belirtir ve gönderen alan adıyla ilgilidir. İkisi farklı soruların cevabıdır ve birbirinin yerine geçmez; sağlıklı bir kurulumda üçü de —PTR, SPF ve DKIM— aynı anda doğru yapılandırılmış olmalıdır.
Kapanış#
PTR kaydı, mail sunucusu kurulumunun en ucuz ve en yüksek getirili adımıdır: tek bir kayıt, teslimat oranını ilk günden görünür biçimde değiştirir. Aklında tutman gereken dört alışkanlık şunlar: kaydı alan adı panelinden değil IP sağlayıcından iste, PTR ile sunucunun FQDN'ini ve SMTP HELO adını birebir aynı tut, dig -x ve düz A sorgusuyla ileri-geri uyumu mutlaka doğrula ve IPv6 üzerinden mail gönderiyorsan onun da PTR kaydını ayarla, ayarlayamıyorsan gönderimi IPv4'e sabitle.
Kendi mail sunucunu barındıracak bir makineye ihtiyacın varsa VDS ve sanal sunucu paketlerimizde rDNS talebini destek üzerinden karşılıyoruz. Postfix, Dovecot ve DKIM'i kurulu hâlde teslim edilen, PTR kaydı kurulum adımlarına dahil bir sistem istiyorsan SMTP sunucu paketimiz doğrudan bu ihtiyacı hedefliyor; kurulumu ve bakımı tamamen bize bırakmak istersen sunucu yönetimi hizmetimiz DNS ve teslimat ayarlarını da kapsıyor.