PTR Kaydı ve Reverse DNS Nedir

Günlük olarak kullandığımız DNS, bir alan adını IP adresine çevirir; sirketiniz.com yazarsınız, tarayıcınız 1.2.3.4 adresine gider. Bu işleme "ileri DNS" (forward DNS) denir ve internetin görünen yüzüdür. Ancak bu yolun tam tersini yapan, çoğu kullanıcının hiç farkında olmadığı bir kayıt türü daha vardır: elinizde bir IP adresi varken "bu IP hangi hostname'e ait?" sorusunu cevaplayan PTR kaydı. IP adresinden alan adına giden bu ters yolculuğa reverse DNS (ters DNS, rDNS) denir ve özellikle kendi sunucunuzdan e-posta gönderiyorsanız, gelen kutusuna ulaşıp ulaşmamanız çoğu zaman bu tek kayda bağlıdır.

PTR kaydı arka planda çalışan sessiz bir bileşendir; web sitesi ziyaretçileriniz onu hiç görmez, ama alıcı posta sunucuları, log analiz araçları ve pek çok güvenlik sistemi onu ilk kontrol ettikleri şeylerden biri olarak kullanır. Bu rehberde PTR kaydının teknik olarak nasıl çalıştığını, in-addr.arpa bölgesinin ne olduğunu, kaydı neden sizin değil sunucu sağlayıcınızın ayarladığını ve doğru bir PTR'nin e-posta teslim edilebilirliğiyle spam skoru üzerindeki somut etkisini adım adım ele alacağız. DNS mantığına hiç aşina değilseniz, devam etmeden önce DNS nedir yazısına göz atmanız her şeyi çok daha anlaşılır kılacaktır.

PTR Kaydı Nedir ve İleri DNS'ten Farkı Nedir?#

PTR (pointer) kaydı, bir IP adresini bir hostname'e (alan adına) eşleyen DNS kaydıdır. Yani A kaydının tam tersini yapar: A kaydı mail.sirketiniz.com → 1.2.3.4 derken, PTR kaydı 1.2.3.4 → mail.sirketiniz.com der. Bir IP adresini alıp karşılığında bir alan adı döndürdüğü için bu işleme "ters çözümleme" (reverse resolution) denir.

Bu iki yön birbirinden tamamen bağımsız tutulur ve otomatik olarak senkronize olmaz. Bir alan adı için A kaydı oluşturmanız, o IP'nin PTR kaydını kendiliğinden oluşturmaz. Bunun teknik sebebi, iki kaydın farklı DNS bölgelerinde ve genellikle farklı kurumların kontrolünde durmasıdır. İleri kayıtları alan adınızın DNS'inde siz yönetirsiniz; ters kayıtları ise IP bloğunun sahibi (yani sunucu/hosting sağlayıcınız) yönetir. Aradaki farkı bir tabloyla netleştirelim:

Kritik nokta şudur: bir sunucunun her ikisine de ihtiyacı olabilir ama biri var diye diğeri otomatik gelmez. Doğru kurulmuş bir sistemde ileri ve ters kayıt birbirini işaret eder; bu simetriye ilerleyen bölümde değineceğiz.

in-addr.arpa Bölgesi ve Ters Çözümlemenin Mekaniği#

Ters DNS'in nasıl çalıştığını anlamak için önce şu soruya cevap vermek gerekir: DNS ağaç yapısında bir IP adresini nasıl "aratırsınız"? DNS, alan adlarını sağdan sola doğru hiyerarşik olarak çözer (com → sirketiniz → mail). IP adresleri ise soldan sağa doğru genelden özele gider (1 bloğu → 1.2 → 1.2.3 → 1.2.3.4). Bu iki yönü uyumlu hale getirmek için IP adresi tersine çevrilir ve özel bir kök alan adı olan in-addr.arpa'ya eklenir.

Örneğin 192.0.2.10 IP adresinin PTR sorgusu için gerçekte sorgulanan ad şudur:

10.2.0.192.in-addr.arpa

Dikkat edin: IP'nin oktetleri ters sıraya alınmıştır (192.0.2.10 → 10.2.0.192) ve sonuna in-addr.arpa eklenmiştir. Bu sayede DNS, IP bloklarını tıpkı normal alan adları gibi hiyerarşik olarak devredebilir: bir sağlayıcı 2.0.192.in-addr.arpa bölgesinin yetkisini alır ve o blok içindeki tek tek IP'lerin PTR kayıtlarını bu bölgede tutar. Ters çözümlemenin bölge dosyasındaki bir kaydı şuna benzer:

; 2.0.192.in-addr.arpa bölgesi içinde
10   IN   PTR   mail.sirketiniz.com.
11   IN   PTR   web.sirketiniz.com.

IPv6 adresleri için aynı mantık geçerlidir, yalnızca kök alan adı ip6.arpa olur ve adres ters sırayla, yarım baytlık (nibble) noktalarla yazılır. Bu ayrıntı çoğu kullanıcı için gizli kalır; önemli olan sonuçtur: bir IP'nin PTR kaydını sorgulamak, aslında in-addr.arpa (veya ip6.arpa) bölgesinde o IP'ye karşılık gelen PTR kaydını okumaktır.

PTR Kaydını Kim Ayarlar? (Sağlayıcının Rolü)#

Bu, kullanıcıların en çok yanıldığı noktadır: PTR kaydını alan adınızın DNS panelinden ekleyemezsiniz. Çünkü in-addr.arpa bölgesi alan adınıza değil, IP adresinize aittir; IP adresini de siz değil, sunucu/hosting sağlayıcınız tahsis eder. Dolayısıyla ters DNS kaydının yetkisi (delegasyonu) sağlayıcının elindedir. Zincir en tepede bölgesel internet kayıt kuruluşlarına (Avrupa ve çevresi için RIPE NCC) kadar uzanır; onlar IP bloğunu sağlayıcıya, sağlayıcı da bir kısmını size devreder.

Pratikte bu üç farklı senaryoya dönüşür:

• Paylaşımlı hosting kullanıyorsanız PTR kaydıyla hiç uğraşmanız gerekmez. Sunucu IP'si sağlayıcıya aittir ve genellikle sunucunun ana hostname'ine (örneğin mailserver.hostingfirmasi.com) çözümlenecek şekilde önceden ayarlanmıştır. Mailleriniz zaten bu IP üzerinden gittiği için PTR uyumu sizin adınıza sağlanır.
• VPS, VDS veya sunucu kiraladıysanız IP'nin kontrolü büyük ölçüde sizde olsa da PTR kaydı hâlâ sağlayıcının yetki alanındadır. Çoğu ciddi sağlayıcı, panelde bir "reverse DNS" veya "rDNS" alanı sunar; oraya istediğiniz hostname'i (mail.sirketiniz.com) yazarsınız, sağlayıcının sistemi de bunu in-addr.arpa bölgesine işler. Panelde böyle bir alan yoksa, kaydı bir destek talebiyle istersiniz.
• Kendi IP bloğunuzu (PI/PA blok) yönetiyorsanız sağlayıcı in-addr.arpa alt bölgesinin yetkisini tamamen size devredebilir; bu durumda PTR kayıtlarını kendi ad sunucunuzda tutarsınız. Bu ileri seviye bir kurulumdur ve genellikle kurumsal müşteriler için geçerlidir.

Clou.TR'de sunucu hizmeti alan müşteriler PTR/rDNS ayarını sunucu yönetimi desteğiyle ya da doğrudan panelden yapabilir; bir VDS veya sanal sunucu kiraladıysanız IP'nizin ters DNS kaydını mail hostname'inize eşlemek birkaç dakikalık bir işlemdir.

PTR ve E-posta Teslim Edilebilirliği#

PTR kaydının en somut ve en kritik etkisi e-posta dünyasındadır. Alıcı posta sunucuları (Gmail, Outlook, Yandex ve kurumsal mail geçitleri), bir SMTP bağlantısı geldiğinde daha ilk saniyelerde gönderen IP'nin PTR kaydına bakar. Mantık basittir: meşru, düzgün yapılandırılmış bir mail sunucusunun neredeyse her zaman bir PTR kaydı vardır; oysa dinamik IP'lerden veya ele geçirilmiş cihazlardan mail saçan spam kaynaklarının çoğunda ya PTR yoktur ya da anlamsız, jenerik bir değere sahiptir (host-1-2-3-4.dynamic.isp.net gibi).

Bu yüzden PTR kaydının durumu, mailinizin spam skoruna doğrudan yansır. SpamAssassin gibi filtreleme motorlarında bir maile eklenen puanlar bunu net gösterir:

# SpamAssassin kural örnekleri (gönderen IP değerlendirmesi)
RDNS_NONE          1.3   # Gönderen IP'nin hiç PTR kaydı yok
RDNS_DYNAMIC       1.9   # PTR değeri "dinamik/dynamic/dhcp" gibi görünüyor
HELO_DYNAMIC_IPADDR 2.0  # HELO adı IP'nin kendisi ya da jenerik

Bu puanlar tek başına maili spam'e düşürmeye yetmese de, eşik değere (genellikle 5.0) doğru birikir. PTR'si olmayan bir sunucu daha kapıdan girer girmez 1-2 puan "borçlu" başlar. Bazı büyük sağlayıcılar ise daha da katıdır: PTR kaydı olmayan IP'lerden gelen bağlantıyı tamamen reddederler. Alıcı sunucunun log'unda tipik olarak şu satırı görürsünüz:

550 5.7.1 Client host rejected: cannot find your reverse hostname

Bu mesaj, "senin IP'nin ters DNS'i yok, bu yüzden seninle konuşmuyorum bile" demektir; mailiniz spam'e bile düşmez, hiç kabul edilmez. Bu nedenle kendi sunucunuzdan doğrudan mail gönderiyorsanız, PTR kaydı SPF/DKIM/DMARC kadar temel bir gerekliliktir. Bu üç alan-adı-seviyesi kaydı henüz kurmadıysanız, PTR'yi tamamlayan bu kayıtları da mutlaka yapılandırın; ayrıntılar için SPF, DKIM ve DMARC rehberi yazısına bakın.

FCrDNS ve HELO/EHLO Uyumu — İşin İnce Detayı#

PTR kaydının "var olması" tek başına yetmez; tutarlı ve simetrik olması gerekir. Ciddi alıcı sunucular yalnızca "bir PTR var mı?" diye sormaz, aynı zamanda o PTR'nin gösterdiği hostname'in geri dönüp aynı IP'ye çözülüp çözülmediğine de bakar. Bu ikili kontrole FCrDNS (Forward-Confirmed reverse DNS) denir. Simetri şöyle çalışır:

1. Ters yön: 1.2.3.4 IP'sinin PTR kaydı → mail.sirketiniz.com
2. İleri yön: mail.sirketiniz.com A kaydı → 1.2.3.4

İki yön aynı IP'de buluşuyorsa FCrDNS geçer ve sunucunuz güvenilir sayılır. İleri kayıt eksikse veya farklı bir IP'yi işaret ediyorsa, PTR kaydı olsa bile FCrDNS başarısız olur ve maddi olarak PTR'siz bir sunucudan çok daha iyi durumda olmazsınız. Bu yüzden PTR'yi ayarlarken A kaydını da aynı hostname için oluşturmayı unutmayın; bu, sizin DNS panelinizde yaptığınız iş olduğundan sağlayıcıdan bağımsızdır.

Üçüncü bir uyum katmanı daha vardır: mail sunucunuzun SMTP el sıkışmasında kendini tanıttığı HELO/EHLO adı. En temiz kurulumda bu üçü aynı hostname'de birleşir:

# Postfix'te HELO adını PTR ile hizalayın
# /etc/postfix/main.cf
myhostname = mail.sirketiniz.com
smtp_helo_name = mail.sirketiniz.com

Yani PTR mail.sirketiniz.com diyorsa, sunucu SMTP diyaloğunda da kendini mail.sirketiniz.com olarak tanıtmalı ve bu adın A kaydı da aynı IP'yi göstermelidir. Bu üçlü uyum (PTR = HELO = ileri A kaydı) sağlandığında sunucunuz alıcı gözünde "kurallara göre yapılandırılmış, sorumlu bir gönderici" profiline oturur ve teslim oranınız gözle görülür şekilde artar.

PTR Kaydını Kontrol Etme ve Talep Etme#

Mevcut PTR kaydınızı kontrol etmek için komut satırından tek bir sorgu yeterlidir. dig ile ters sorgu şöyle yapılır:

# IP'nin PTR kaydını sorgula (-x ters sorgu bayrağıdır)
dig -x 192.0.2.10 +short
# Beklenen çıktı: mail.sirketiniz.com.

# Windows'ta veya dig yoksa nslookup ile
nslookup 192.0.2.10

# host komutuyla da mümkündür
host 192.0.2.10

Simetriyi (FCrDNS) doğrulamak için ters sorgunun döndürdüğü hostname'i alıp ileri yönde de sorgulayın; ikisi aynı IP'de buluşmalıdır:

# 1) Ters yön: IP → hostname
dig -x 192.0.2.10 +short          # → mail.sirketiniz.com.

# 2) İleri yön: hostname → IP
dig +short mail.sirketiniz.com    # → 192.0.2.10  (aynı IP olmalı)

Kayıt boş dönüyorsa (henüz ayarlanmamışsa) ya da jenerik bir değer gösteriyorsa, sağlayıcınızdan düzeltmesini istersiniz. Bir destek talebinde net olmak süreci hızlandırır; şu bilgileri iletin:

• Ayarlanacak IP adresi (örneğin 192.0.2.10)
• İstenen PTR değeri, yani hostname (örneğin mail.sirketiniz.com)
• IPv6 kullanıyorsanız ilgili IPv6 adresi ve hedef hostname

Bir örnek talep metni: "Sunucumun 192.0.2.10 IP adresi için reverse DNS (PTR) kaydının mail.sirketiniz.com olarak ayarlanmasını rica ederim. İleri A kaydını kendi tarafımda oluşturdum." Panelde doğrudan bir rDNS alanı varsa, hostname'i oraya yazıp kaydetmeniz yeterlidir; değişiklik in-addr.arpa bölgesine yayıldıktan sonra (genellikle dakikalar içinde, en geç birkaç saatte) dig -x ile yeni değeri görürsünüz. Yayılma mantığı ileri DNS'tekiyle aynıdır; ayrıntılar için DNS nedir yazısındaki propagasyon bölümü yol gösterir.

IPv6 ve Birden Fazla Domain Barındıran Sunucular#

IPv6 adresleri için PTR mantığı değişmez ama biçim farklılaşır: kök ip6.arpa olur ve adres nibble nibble ters yazılır. Örneğin 2001:db8::1 adresinin ters sorgusu, tek bir uzun etikete dönüşür:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Bunu elle yazmanız gerekmez; dig -x 2001:db8::1 sizin için doğru sorguyu üretir. Modern posta sunucuları IPv6 üzerinden de mail gönderdiğinden, IPv6'lı bir sunucuda hem IPv4 hem IPv6 PTR kaydının ayarlı olması önemlidir; birinin eksik olması, mailin o protokol üzerinden gittiğinde reddedilmesine yol açabilir.

Tek bir sunucuda birden çok alan adı barındırıyor ve hepsinden mail gönderiyorsanız akılda tutulması gereken bir sınır vardır: bir IP adresinin yalnızca bir tane anlamlı PTR kaydı olur. Yani 1.2.3.4 IP'sini aynı anda hem mail.siteA.com'a hem mail.siteB.com'a işaret ettiremezsiniz (teknik olarak birden çok PTR mümkün olsa da alıcılar tek ve tutarlı değer bekler). Doğru yaklaşım, sunucuya nötr bir mail hostname'i (mail.sirketiniz.com gibi) vermek, tüm alan adlarının maillerini bu tek hostname üzerinden göndermek ve PTR ile HELO'yu bu hostname'e sabitlemektir. Alan adları SPF/DKIM ile ayrı ayrı doğrulanmaya devam eder; PTR ise sunucu seviyesinde tek ve sabit kalır. Çok sayıda alan adından yüksek hacimli mail gönderiyorsanız, her birine ayrı bir IP tahsis etmek (böylece her IP'nin kendi temiz PTR'si ve itibarı olması) daha sağlıklı bir mimaridir.

Yaygın Hatalar ve Çözümleri#

• PTR kaydını alan adı DNS panelinden eklemeye çalışmak — DNS Zone Editor'da PTR türü görünse bile buradan eklediğiniz kayıt işe yaramaz; ters DNS in-addr.arpa bölgesine aittir ve yalnızca IP sahibi (sağlayıcı) tarafından ayarlanır. Doğru yol, sağlayıcı paneli veya destek talebidir.
• PTR var ama ileri A kaydı yok (FCrDNS başarısız) — Sağlayıcı PTR'yi mail.sirketiniz.com'a ayarladı ama siz o hostname için bir A kaydı oluşturmadınız. İki yön birbirini doğrulamadığı için mailler yine şüpheli görülür. Çözüm, DNS panelinizde mail.sirketiniz.com → sunucu IP'si A kaydını eklemektir.
• HELO adı PTR ile uyumsuz — Sunucu kendini localhost.localdomain veya IP'nin kendisiyle tanıtıyorsa, PTR doğru olsa bile puan kaybedersiniz. Postfix/Exim yapılandırmasında myhostname/smtp_helo_name değerini PTR ile aynı hostname'e sabitleyin.
• Jenerik/dinamik PTR — Sağlayıcının varsayılan olarak bıraktığı 1-2-3-4.static.saglayici.net gibi bir değer, "dinamik IP" filtrelerini tetikleyebilir. Kendi mail hostname'inize (mail.sirketiniz.com) değiştirmesini isteyin.
• Değişiklik hemen yansımadı diye panikleme — Ters DNS değişiklikleri de yayılma (propagasyon) gerektirir. Birkaç dakika ile birkaç saat arasında sürebilir; dig -x ile doğrulamadan önce biraz bekleyin ve sonucu birkaç farklı çözümleyiciden kontrol edin.

Sıkça Sorulan Sorular#

PTR kaydını neden kendi DNS panelimden ekleyemiyorum?#

Çünkü PTR kaydı alan adınızın bölgesinde değil, IP adresinin ait olduğu in-addr.arpa bölgesinde durur ve o bölgenin yetkisi IP'yi size tahsis eden sunucu sağlayıcısındadır. Alan adınızın DNS panelinde A, MX, TXT gibi kayıtları siz yönetirsiniz ama IP bloğunun ters kaydını yönetme yetkisi sağlayıcıya aittir. Bu yüzden PTR değişikliği için ya sağlayıcının panelindeki rDNS alanını kullanmanız ya da bir destek talebi açmanız gerekir.

PTR kaydı olmadan e-posta gönderebilir miyim?#

Teknik olarak gönderebilirsiniz ama mailleriniz büyük ihtimalle ya spam klasörüne düşer ya da hiç kabul edilmez. Gmail ve Outlook gibi büyük alıcılar, PTR kaydı olmayan sunuculardan gelen bağlantıları ya doğrudan reddeder ya da spam skoruna belirgin bir ceza puanı ekler. Kendi sunucunuzdan doğrudan mail gönderiyorsanız PTR kaydı pratikte zorunludur; paylaşımlı hostingde ise bu ayar zaten sağlayıcı tarafından yapılmış olur.

PTR kaydımın doğru olduğunu nasıl kontrol ederim?#

Komut satırında dig -x IP_ADRESI +short (veya nslookup IP_ADRESI) çalıştırarak IP'nizin hangi hostname'e çözüldüğünü görebilirsiniz. Sonuç, mail sunucunuzun hostname'iyle aynı olmalı. Ardından o hostname'i ileri yönde dig +short hostname ile sorgulayıp aynı IP'ye dönüp dönmediğini doğrulayın; iki yön aynı IP'de buluşuyorsa FCrDNS sağlanmış ve kaydınız düzgün demektir.

rDNS ile PTR aynı şey mi?#

Evet, pratikte aynı şeyi ifade ederler. "Reverse DNS" (rDNS, ters DNS) bir IP adresini hostname'e çevirme işleminin genel adıdır; PTR kaydı ise bu çevrimi mümkün kılan somut DNS kayıt türüdür. Yani rDNS sonucunu üreten şey, arka planda o IP için tanımlı olan PTR kaydıdır. Günlük konuşmada "IP'nin rDNS'i" ile "IP'nin PTR kaydı" birbirinin yerine kullanılır.

Bir IP'ye birden fazla PTR kaydı ekleyebilir miyim?#

Teknik olarak DNS birden fazla PTR kaydına izin verse de bu önerilmez; alıcı sistemlerin çoğu bir IP için tek ve tutarlı bir hostname bekler. Aynı IP'den birden çok alan adına ait mail gönderiyorsanız, her domaine ayrı PTR vermek yerine sunucuya tek bir nötr mail hostname'i (mail.sirketiniz.com gibi) atayıp tüm maili bunun üzerinden göndermek en temiz çözümdür. Farklı domainler yine SPF ve DKIM ile ayrı ayrı doğrulanır; PTR sunucu seviyesinde sabit kalır.

PTR kaydını değiştirdikten sonra ne kadar sürede aktif olur?#

Ters DNS değişiklikleri de tıpkı ileri DNS gibi yayılma süresine tabidir; genellikle birkaç dakika içinde, bazen kayıtların TTL değerine bağlı olarak birkaç saate kadar sürebilir. Sağlayıcı panelinden değişikliği yaptıktan sonra hemen sonuç beklemeyin; kısa bir süre bekleyip dig -x IP_ADRESI ile yeni değeri doğrulayın. Farklı çözümleyicilerden farklı sonuç görürseniz, bu genellikle yayılmanın henüz tamamlanmadığını gösterir.

Kapanış#

PTR kaydı, internetin çoğu zaman görünmeyen ama e-posta güvenilirliğinin belkemiğini oluşturan sessiz bir bileşenidir. IP adresinizi doğru hostname'e çeviren, ileri A kaydıyla simetrik (FCrDNS) ve HELO adıyla uyumlu bir PTR kaydı, mailinizin gelen kutusuna ulaşmasıyla spam klasöründe kaybolması arasındaki farkı belirler. Alan adı seviyesindeki SPF, DKIM ve DMARC kadar temel olan bu IP seviyesi kaydı, kendi sunucunuzdan mail gönderiyorsanız asla atlanmamalıdır.

İşin en güzel yanı, çoğu kullanıcının bu konuyla hiç uğraşmasına gerek olmamasıdır. Bir Clou.TR web hosting paketinde sunucunun PTR kaydı zaten düzgün ayarlıdır; siz yalnızca SPF ve DKIM'i eklersiniz. Kendi sunucunuzu veya bir VDS yönetiyor ve doğrudan mail gönderiyorsanız, IP'nizin ters DNS kaydını mail hostname'inize eşlemek için sunucu yönetimi desteğimizden yararlanabilirsiniz. Teslim edilebilirlik sorunlarını kökten çözmek için PTR'yi tamamlayan SPF, DKIM ve DMARC kayıtlarını da yapılandırmayı unutmayın; ekibimiz kurulumun her adımında yanınızda olmaktan memnuniyet duyar.