Ters DNS (PTR) kaydı nedir? Nasıl eklenir ve doğrulanır?

A ve AAAA kaydı bir adı IP adresine çevirir. PTR kaydı tersini yapar: IP adresinden ada gider. RFC 1035 bu kaydı “alan adı işaretçisi” (domain name pointer) olarak tanımlar (§3.2.2, §3.3.12) ve adresten ada eşlemeyi in-addr.arpa adlı özel bir ad ağacına koyar (§3.5). Tüm kayıt türleri için DNS kayıt türleri sayfasına bakın.

Web sitesi için gerekmez. Tarayıcı alan adını IP adresine çözüp bağlanır; sayfanın açılması ters kayda bağlı değildir.

E-posta gönderen sunucu için gerekir. Önemli olan gönderen IP'dir, yani sunucunun alıcıya bağlandığı adres. Google'ın gönderen yönergeleri bu şartı kişisel Gmail hesaplarına gönderen herkese 1 Şubat 2024'ten beri koyuyor. Google'ın SSS sayfası Kasım 2025'ten beri uygulamanın sıkılaştığını söylüyor ve hata kodlarını listeliyor: PTR yoksa ya da ileri doğrulama tutmuyorsa Gmail iletiyi geçici olarak sınırlar (4.7.23) ya da engeller (5.7.25).

Gönderen IP kimin? Kendi posta sunucunuz ya da VPS'iniz varsa sizin kullandığınız IP'dir. Hosting hesabınızın posta hizmetiyle giden e-posta (iletişim formu, bülten) hosting sunucusunun IP'sinden çıkar. Google Workspace, Microsoft 365 ya da bir SMTP servisi kullanıyorsanız IP servisindir. İlk durumda kaydı siz sağlayıcıdan istersiniz; diğerlerinde IP'nin sahibi kaydı kendisi yönetir. Google, bir servisle teslim sorunu yaşayanlara servisin yönergelere uyduğunu doğrulamalarını söylüyor. Ters DNS tek başına teslimi sağlamaz: gönderen IP'nin kara listede olup olmadığına bakın, geri kalan adımlar için spam kontrol listesini izleyin.

PTR kaydı adresin kendisinde değil, adresten türetilen özel bir adda durur. IPv4'te dört sayı ters sırayla yazılır ve sona .in-addr.arpa eklenir. Ters sıra, bir adres bloğunun ortak kısmını sonda toplar; böylece blok tek bir DNS bölgesi (zone) olarak başkasına devredilebilir (RFC 1035 §3.5).

IPv6'da adres 32 onaltılık basamağa (nibble) açılır, her basamak noktayla ayrılan ayrı bir parça (etiket) olur, sıra tersine çevrilir ve sona .ip6.arpa eklenir (RFC 3596 §2.5). Örneğin 2001:db8::25 açılınca 2001:0db8:0000:0000:0000:0000:0000:0025 olur; sondan başa okunan 32 basamak ters adı verir. Elle yazmayın; Python'un ipaddress modülü hesabı yapar (Python 3.14.4, 26 Ekim 2026; belgeleme için ayrılmış 203.0.113.0/24 ve 2001:db8::/32 adresleriyle, RFC 5737 ve RFC 3849):

$ python3 -c "import ipaddress; print(ipaddress.ip_address('203.0.113.10').reverse_pointer)"
10.113.0.203.in-addr.arpa
$ python3 -c "import ipaddress; print(ipaddress.ip_address('2001:db8::25').reverse_pointer)"
5.2.0.0.0.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

Sitemizdeki IP dönüştürücü ters DNS adını tarayıcınızda hesaplar.

PTR kaydını IP bloğunun sahibi, A kaydını alan adının sahibi yazar. İkisi ayrı bölgelerdedir ve ayrı kişilerin elinde olabilir; RFC 1035 §3.5 ayrı bölgelerdeki verinin tutarsız olabileceğini söyler. Ters bölgeyi yöneten biri oraya istediği adı yazabilir, yani PTR tek başına o adın o IP'ye ait olduğunu göstermez.

İleri doğrulama bunu kapatır: PTR adı alınır, o ad için A (IPv6'da AAAA) sorulur ve yanıtlar arasında sorgulanan IP adresi aranır. Adres listedeyse iki taraf aynı şeyi söylüyor demektir. RFC 1912 §2.1 de PTR ve A kayıtlarının eşleşmesini ister ve PTR'nin takma ada (CNAME) değil, gerçek bir A kaydına işaret etmesini şart koşar.

Google bu sınamayı kural olarak koyuyor: gönderen SMTP sunucusunun genel IP adresinin ada çözülen bir PTR kaydı olmalı, aynı ad aynı IP adresine A ya da AAAA ile çözülmeli. Yönerge ayrıca ters kayıtların alan adınıza işaret etmesini söylüyor. Postfix posta sunucusunda sınama ayrı bir seçenektir (reject_unknown_client_hostname): IP'nin adı yoksa, ad çözülmüyorsa ya da ad başka adrese çözülüyorsa isteği reddeder. Seçeneği açıp açmamak alıcının kararıdır.

Bir IP adresinin ters sorgusu kökten başlar, in-addr.arpa ağacında aşağı iner ve adres bloğunun sahibinde biter. 8.8.8.8 için yol böyledir (her düzeyden bir satır seçildi; çıktı zamanla değişebilir):

$ dig +trace +nodnssec -x 8.8.8.8
in-addr.arpa.		172800	IN	NS	a.in-addr-servers.arpa.
8.in-addr.arpa.		86400	IN	NS	r.arin.net.
8.8.8.in-addr.arpa.	86400	IN	NS	ns1.google.com.
8.8.8.8.in-addr.arpa.	86400	IN	PTR	dns.google.

Kayıt, adresi taşıyan bloğun sahibinin (burada Google) ad sunucularında (name server) durur. Sizin PTR kaydınız da bu bölgelerden birinde, yani IP bloğunu yöneten kuruluşun ad sunucusundadır. Bunun sonuçları:

• Alan adınızın DNS paneli bu iş için uygun değildir. cPanel Bölge Düzenleyici, DirectAdmin DNS Yönetimi, Cloudflare ya da alan adı firmanızın paneli yalnızca ornek.com bölgesini değiştirir. Oraya ters ad yazsanız çözümleyiciler (resolver) onu sormaz; sorgu yukarıdaki yoldan gider.
• Paylaşımlı hosting: IP adresini birçok müşteri kullanır. cPanel belgesi, çoğu kullanıcının PTR kaydını doğrudan düzenleme yetkisi olmadığını, bazı sağlayıcıların müşteri panelinde ters DNS yönetimi sunduğunu ve yetki devri için sağlayıcıya başvurulması gerektiğini söyler.
• VPS, sunucu ya da ISS'den aldığınız sabit IP: sağlayıcının panelinde “reverse DNS” ya da “ters DNS” alanı arayın; yoksa destek talebi açın.
• 256 adresten küçük blok: sağlayıcı ters bölgeyi RFC 2317 yöntemiyle size devredebilir (delegation); o zaman PTR'yi kendi ad sunucunuzda yazarsınız. Bu sağlayıcının kararıdır.

IP adresinizin sahibini hosting sorgulama aracı gösterir.

Sağlayıcı kaydı eklediğinde ileri doğrulamanın hemen geçmesi için sırayla ilerleyin:

1. Posta sunucunuza bir ad verin (örnek: mail.ornek.com) ve DNS panelinizde bu adın A kaydını gönderen IP adresine yönlendirin. IPv6 kullanıyorsanız AAAA kaydını da ekleyin. Cloudflare kullanıyorsanız kaydı “DNS only” yapın.
2. Posta sunucusunun EHLO adını aynı ada ayarlayın.
3. Aşağıdaki metni sağlayıcının destek formuna ya da e-postasına yapıştırın; IP adresini ve adı kendinizinkilerle değiştirin.

Konu: 192.0.2.25 için ters DNS (PTR) kaydı talebi

Merhaba,

Hesabıma tanımlı 192.0.2.25 IP adresi için şu ters DNS (PTR) kaydının eklenmesini rica ederim:

192.0.2.25 → mail.ornek.com

Bu adresten e-posta gönderiyorum. mail.ornek.com için A kaydını kendi alan adımın DNS'ine ekledim ve 192.0.2.25 adresine çözülüyor; PTR eklenince ileri doğrulama (FCrDNS) geçecek. Bu adreste başka bir PTR kaydı varsa lütfen kaldırın, yalnızca bu ad kalsın. Kayıt eklenince bana bilgi verirseniz sevinirim.

Teşekkürler,
[Ad Soyad], [müşteri numarası ya da sunucu adı]

IPv6'dan da gönderiyorsanız metne 2001:db8::25 → mail.ornek.com satırını ekleyin. Sağlayıcı PTR'yi değiştirmiyorsa (paylaşımlı hostingte olabilir) e-postayı PTR'si düzgün bir SMTP servisi üzerinden gönderin; kontrol o zaman servisin IP'sine yapılır.

Ters DNS kaydını bir PTR sorgusuyla görürsünüz; dig için -x bayrağı ters adı sizin yerinize üretir. macOS terminalinde dig, host ve nslookup hazır gelir; Windows 10 ve 11'de komut isteminde nslookup çalışır. Çıktılar 26 Ekim 2026'da Google ve Cloudflare'ın herkese açık DNS adresleri için alındı, zamanla değişebilir. Yerel çözümleyiciye ait satırlar, süre ve başlık satırları çıkarıldı.

$ dig -x 8.8.8.8
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.		IN	PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.	85247	IN	PTR	dns.google.

$ nslookup 8.8.8.8
Non-authoritative answer:
8.8.8.8.in-addr.arpa	name = dns.google.

$ host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer dns.google.

$ dig +short -x 1.1.1.1
one.one.one.one.

$ nslookup 1.1.1.1
Non-authoritative answer:
1.1.1.1.in-addr.arpa	name = one.one.one.one.

$ host 1.1.1.1
1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.

Üçü aynı kaydı gösterir. dig çıktısındaki 85247 TTL'dir: kaydın önbellekte kalan ömrü, saniye cinsinden. “Non-authoritative answer” yanıtı yetkili sunucunun değil bir çözümleyicinin verdiğini söyler. Kaydı yeni değiştirdiyseniz eski değer önbellekten geliyor olabilir.

İleri doğrulamayı iki komutla elle yaparsınız: PTR adını alın, o adın A kaydına bakın ve sorguladığınız adresin listede olduğunu görün. Listede başka adresler de olabilir; önemli olan sorguladığınız adresin orada bulunmasıdır.

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

IPv6'da A yerine AAAA sorulur: dig +short -x 2001:4860:4860::8888 yine dns.google. verir ve dig +short AAAA dns.google bu adresi listeler (26 Ekim 2026).

Kayıt yoksa sorgu NXDOMAIN (böyle bir ad yok) döner. Belgeleme adresi 203.0.113.10'un ters kaydı yoktur, sonuç şöyle görünür:

$ host 203.0.113.10
Host 10.113.0.203.in-addr.arpa. not found: 3(NXDOMAIN)

$ nslookup 203.0.113.10
** server can't find 10.113.0.203.in-addr.arpa: NXDOMAIN

dig aynı durumda status: NXDOMAIN yazar, +short ile hiçbir şey basmaz.

Ters DNS aracı IP adresi ya da alan adı kabul eder. Alan adı yazarsanız önce A, yoksa AAAA kaydındaki ilk genel adresi sorgular ve sizi IP raporunun “Servis sağlayıcı ve kayıt” kartına götürür. Belgeleme ve özel adresler reddedilir; kendi IP'nizi yazın. Kartta ters DNS iki satırdır. 26 Ekim 2026'da 8.8.8.8 için:

Reverse DNS      dns.google
İleri doğrulama  Evet   ad aynı adrese çözülüyor

“Hayır” çıkarsa sık yapılan hatalara bakın. Sonuç yaklaşık 10 dakika önbellekte tutulur; yeni eklediğiniz kaydı hemen görmezseniz bekleyin. İleri doğrulama satırı güven skoruna katılmaz.

Kartın “Bağlantı” satırı ve rapor bandındaki “Sabit IP” / “Dinamik IP” etiketi bir tahmindir, sağlayıcının bildirdiği bir bilgi değildir. Sitemiz PTR adındaki sözcüklere bakar: “static” geçiyorsa sabit, “dyn”, “dhcp”, “pool”, “ppp” gibi sözcükler geçiyorsa dinamik der; “fiber”, “dsl”, “cable”, “mobile” gibi sözcüklerden bağlantı türünü çıkarır. Ad bu sözcüklerden hiçbirini içermiyorsa etiket çıkmaz.

DNS raporunun MX kartı da ters DNS'e bakar, ama yalnızca alan adınızın kendi adıyla başlayan MX sunucularına (örneğin mail.ornek.com); Google Workspace ya da Microsoft 365 gibi başka bir şirketin MX sunucuları için bulgu çıkmaz, çünkü o PTR kayıtlarını siz değiştiremezsiniz. MX sunucusunun IP'sinde PTR yoksa “MX sunucusunda ters DNS (PTR) eksik” hatası çıkar ve “Nasıl istenir?” bölümü sağlayıcıdan istenecek eşlemeyi (IP → ad) yazar. PTR varsa ama PTR'deki ad aynı IP'ye geri çözülmüyorsa (ileri doğrulama tutmuyorsa) “MX sunucusunun PTR adı IP adresine geri çözülmüyor” uyarısı çıkar. PTR adının MX adından farklı olması tek başına sorun sayılmaz; Google'ın tarif ettiği şart, adın yine aynı IP'ye çözülmesidir. Rapor giden posta sunucunuzu bilemez, yalnızca MX sunucularına bakar; giden posta başka bir IP'den çıkıyorsa onu Ters DNS aracıyla ayrıca sorgulayın.

PTR var ama ad çözülmüyor ya da başka adrese çözülüyor

En sık hata budur: sağlayıcı PTR'yi ekler, siz adın A kaydını eklemezsiniz ya da yanlış IP'ye yönlendirirsiniz. Gmail bu durumda 4.7.23 ya da 5.7.25 kodunu verir (PTR yok ya da PTR'nin ileri kaydı gönderen IP ile uyuşmuyor). A kaydını kendi DNS panelinizden düzeltirsiniz. Cloudflare kullanıyorsanız kaydın “Proxied” olmadığına bakın: proxy'li kayıt Cloudflare'in adreslerine çözülür, sizin IP'nize değil. Cloudflare belgesi, e-posta kayıtları gibi bazı kayıtların “DNS only” olması gerektiğini söyler.

Birden çok PTR kaydı

DNS aynı ters ada birden çok PTR yazmaya izin verir (RFC 1035 §3.5'teki örnekte bir ağ adının iki PTR'si var). Ama alıcının hangisine bakacağı belli değildir; Google'ın sayfası bu konuda bir şey söylemiyor, alıcı davranışı doğrulanamadı; raporumuz da yalnızca ilk kaydı gösterir. Gönderen IP için tek PTR bırakın. Birden çok IP'den gönderiyorsanız her IP'nin kendi PTR'si olmalı (RFC 1912 §2.1); cPanel belgesi, posta için yalnızca gönderen IP'lerin kaydını güncellemenin gerektiğini söyler.

Sağlayıcının verdiği genel ad

Birçok sağlayıcı müşteri adresleri için PTR kaydını kendisi üretir (RFC 8501 §1.1); ad adres rakamlarını ve “dyn” gibi bir sözcüğü içerir, örneğin 203-0-113-10.dyn.ornek.net. Birçoğu eşleşen A kaydını da üretir, yani ileri doğrulama geçebilir. Yine de alıcılar PTR'deki belirli sözcüklere bakıp “bu bir posta sunucusu değil” sonucuna varabilir (RFC 8501 §4). Posta için kendi adınızı isteyin.

IPv6 için PTR eksik

Sunucunuz IPv6 ile de bağlanıyorsa IPv6 adresinin ayrı bir PTR ve AAAA kaydı olmalıdır. Google, IPv6 yetkilendirme hatasının PTR'nin IPv6 için tanımlı olmamasından kaynaklanabileceğini yazar; örnek hata: 550-5.7.1: Message does not meet IPv6 sending guidelines regarding PTR records and authentication. Sağlayıcılar IPv6'da her adrese kayıt açamaz (tek bir /48 içinde 2^80 adres olabilir, RFC 8501 §1.2); gönderen adresiniz için tek tek kayıt ya da bölge devri isteyin. Joker karakterli (wildcard) PTR ileri doğrulanamaz (RFC 8501 §2.2). Başka çare yoksa posta sunucusunu yalnızca IPv4 üzerinden göndermeye ayarlayın.

EHLO adı PTR adından farklı

Posta sunucusu bağlandığında EHLO komutuyla kendini tanıtır. RFC 5321 bu adın sunucunun tam nitelikli alan adı olmasını ister; sunucunun anlamlı bir adı yoksa (örneğin adresi dinamikse ve ters kaydı yoksa) köşeli parantez içinde IP adresi, örneğin [192.0.2.25], gönderilmelidir. Alıcı EHLO adını istemcinin IP adresiyle karşılaştırabilir ama aynı RFC (§4.1.4) yalnızca bu yüzden iletinin reddedilmemesini ister. Yine de EHLO adını, PTR adını ve A kaydını aynı tutun.