PTR kaydı (reverse DNS, rDNS), bir IP adresini bir alan adına eşleyen DNS kaydıdır ve normal A kaydının tersine çalışır. E-posta sunucuları gelen bağlantının IP adresi için PTR kaydına ve bu adın aynı IP'ye geri çözülüp çözülmediğine bakar. PTR kaydı olmayan ya da tutarsız bir sunucudan giden e-postalar Gmail ve Outlook gibi servislerde reddedilir veya spam klasörüne düşer.
Kendi e-posta sunucunuzu bir VDS veya fiziksel sunucuda çalıştırıyorsanız doğru bir PTR kaydı, e-postalarınızın ulaşması için ilk şarttır. Bu yazıda PTR kaydının nasıl çalıştığını, kimin ayarladığını, nasıl kontrol edildiğini ve SPF, DKIM ve DMARC ile ilişkisini anlatıyoruz. Sunucu yönetmeden alan adınızla e-posta kullanmak istiyorsanız kurumsal e-posta hizmetinde gönderim sunucularının PTR ayarları sağlayıcının sorumluluğundadır.
PTR kaydı nasıl çalışır?
A kaydı bir adı IP adresine çevirir (mail.alanadi.com → 203.0.113.25). PTR kaydı ise ters yönde çalışır ve IP adresine karşılık gelen adı verir (203.0.113.25 → mail.alanadi.com).
Ters sorgular DNS'te özel bir alanda tutulur. IPv4 adresinin oktetleri ters çevrilip sonuna in-addr.arpa eklenir; 203.0.113.25 adresinin PTR kaydı 25.113.0.203.in-addr.arpa adında bulunur. IPv6 adresleri için aynı mantıkla ip6.arpa alanı kullanılır.
Önemli fark şudur: in-addr.arpa altındaki kayıtlar alan adınızın değil, IP adresi bloğunun sahibinin yönetimindedir. Bu yüzden PTR kaydını alan adınızın DNS panelinden ekleyemezsiniz; IP adresini size veren sağlayıcı ekler.
FCrDNS: ileri ve geri kaydın uyumu
Alıcı sunucular yalnızca bir PTR kaydının varlığına değil, ileri ve geri kaydın birbirini doğrulamasına bakar. Buna forward-confirmed reverse DNS (FCrDNS) denir:
- Gönderen IP'nin PTR kaydı bir ad döndürür: 203.0.113.25 → mail.alanadi.com
- Bu adın A kaydı aynı IP'yi döndürür: mail.alanadi.com → 203.0.113.25
Google'ın e-posta gönderici kuralları, kişisel Gmail hesaplarına e-posta gönderen herkesten gönderen IP'nin geçerli ileri ve geri DNS kayıtlarına sahip olmasını ister. Ayrıca e-posta sunucusunun bağlantı sırasında kendini tanıttığı ad (HELO/EHLO adı) ile PTR adının aynı olması yaygın bir iyi uygulamadır; birçok spam filtresi bu uyumu da kontrol eder.
PTR kaydı kim tarafından, nasıl ayarlanır?
PTR kaydını IP adresinin sahibi, yani sunucuyu kiraladığınız sağlayıcı ayarlar. Bazı sağlayıcılar panellerinde rDNS alanı sunar; bazılarında destek talebi gerekir. Sırası şöyledir:
- A kaydını oluşturun. Alan adınızın DNS'inde mail.alanadi.com için sunucunun IP adresini gösteren bir A kaydı ekleyin. Sağlayıcıların çoğu, PTR'yi ayarlamadan önce bu kaydın var olduğunu kontrol eder.
- PTR kaydını isteyin. Sağlayıcınızın panelinden veya destek ekibinden IP adresinin PTR değerini mail.alanadi.com olarak ayarlamasını isteyin.
- Sunucunun adını eşleyin. E-posta yazılımının HELO/EHLO adını aynı değere ayarlayın. Postfix'te bu ayar
myhostname, Exim'deprimary_hostnamedeğişkenidir. - Kontrol edin. Aşağıdaki komutlarla ileri ve geri sorgunun aynı sonucu verdiğini doğrulayın.
PTR kaydı nasıl kontrol edilir?
Linux veya macOS'ta dig ile ters sorgu:
dig -x 203.0.113.25 +short
# beklenen: mail.alanadi.com.
dig mail.alanadi.com A +short
# beklenen: 203.0.113.25Windows'ta aynı kontrol nslookup ile yapılır:
nslookup 203.0.113.25
nslookup mail.alanadi.comPostfix kullanıyorsanız sunucunun kendini hangi adla tanıttığını görmek için:
postconf myhostnameHELO adı yanlışsa Postfix'te /etc/postfix/main.cf dosyasındaki ayarı düzeltip yapılandırmayı yeniden yükleyin:
sudo postconf -e 'myhostname = mail.alanadi.com'
sudo systemctl reload postfixAyarı doğrulamanın pratik bir yolu, kendi sunucunuzdan Gmail'deki bir adrese test iletisi göndermektir. Gmail'de iletiyi açıp "Orijinali göster" seçeneğine tıkladığınızda başlıklarda SPF, DKIM ve DMARC sonuçlarını ve sunucunuzun kendini tanıttığı adı görebilirsiniz.
Sunucunuzun IPv6 adresi varsa ve e-posta IPv6 üzerinden de gönderiliyorsa IPv6 adresi için de PTR kaydı gerekir. Gmail, PTR ve kimlik doğrulama kurallarını karşılamayan IPv6 gönderimlerini reddeder. IPv6 PTR kaydı ayarlanamıyorsa e-posta yazılımında gönderimi IPv4 ile sınırlamak bir çözümdür; Postfix'te inet_protocols = ipv4 ayarı bunu sağlar.
PTR adı nasıl seçilmeli?
- Kendi alan adınızda bir ad kullanın: mail.alanadi.com veya mx1.alanadi.com gibi.
- Genel görünümlü adlardan kaçının: static-203-0-113-25.ornekisp.net gibi IP adresini içeren adlar, spam filtrelerinde ev veya dinamik bağlantı gibi değerlendirilebilir.
- IP başına tek PTR kaydı kullanın: Teknik olarak birden fazla PTR eklenebilse de alıcılar farklı sonuçlar alabilir; tek ve tutarlı bir ad en güvenlisidir.
- Aynı sunucudan birden çok alan adı gönderiyorsanız endişelenmeyin: PTR yalnızca sunucuyu tanıtır; her alan adının kimliğini SPF, DKIM ve DMARC kayıtları doğrular.
PTR tek başına yeterli mi? SPF, DKIM ve DMARC
Hayır. PTR, gönderen sunucunun kim olduğunu gösterir; alan adınız adına e-posta gönderme yetkisini ise diğer kayıtlar kanıtlar.
| Kayıt | Neyi gösterir? | Nerede tanımlanır? |
|---|---|---|
| PTR | IP adresinin hangi sunucuya ait olduğunu | IP sahibinin DNS'i (sağlayıcı) |
| SPF | Alan adınız adına hangi sunucuların e-posta gönderebileceğini | Alan adınızın DNS'inde TXT kaydı |
| DKIM | İletinin yolda değiştirilmediğini ve alan adınızca imzalandığını | Alan adınızın DNS'inde TXT kaydı (seçici._domainkey) |
| DMARC | SPF/DKIM başarısız olursa alıcının ne yapacağını ve raporların nereye gideceğini | Alan adınızın DNS'inde _dmarc TXT kaydı |
Google, kişisel Gmail hesaplarına e-posta gönderen herkesten en az SPF veya DKIM, günde 5.000'den fazla ileti gönderenlerden ise SPF, DKIM ve DMARC'ın birlikte kullanılmasını ister. Bu kayıtların kurulumunu kurumsal e-posta seçenekleri yazımızın kurulum bölümünde adım adım anlattık.
PTR ile ilgili sık görülen hata mesajları
| Mesaj | Anlamı |
|---|---|
Gmail: 451 4.7.23 … doesn't have a PTR record | PTR yok veya ileri kayıt eşleşmiyor; ileti geçici olarak reddedildi, sunucunuz yeniden deneyecek. |
Gmail: 550 5.7.25 … doesn't have a PTR record | Aynı sorun; ileti kalıcı olarak reddedildi. |
Gmail: 550 5.7.1 … IPv6 sending guidelines regarding PTR records | IPv6 adresinin PTR kaydı veya kimlik doğrulaması eksik. |
| Diğer sunucular: "reverse DNS lookup failed", "cannot find your hostname" | PTR kaydı yok veya PTR adının A kaydı yok. |
Bu hatalardan birini aldığınızda önce yukarıdaki dig komutlarıyla PTR ve A kaydını kontrol edin. Kayıtlar doğruysa sorun IP adresinin itibarında olabilir; bu durumda IP'nin bir kara listede olup olmadığına bakmak gerekir.
Sık sorulan sorular
PTR kaydını kendi DNS panelimden ekleyebilir miyim?
Hayır. PTR kaydı IP adresi bloğunun sahibinin DNS'inde tutulur. Alan adınızın DNS panelinde yalnızca A, MX, TXT gibi kayıtları yönetirsiniz; PTR için sunucuyu kiraladığınız sağlayıcıya başvurmanız gerekir.
Paylaşımlı hosting kullanıyorsam PTR ile uğraşmam gerekir mi?
Hayır. Paylaşımlı hostingte veya kurumsal e-posta hizmetinde e-postalar sağlayıcının sunucularından gider ve bu sunucuların PTR kayıtlarını sağlayıcı yönetir. Sizin sorumluluğunuz alan adınızın SPF, DKIM ve DMARC kayıtlarıdır.
PTR kaydı olmadan e-posta gönderebilir miyim?
Bazı küçük sunucular iletinizi kabul edebilir, ancak Gmail PTR kaydı olmayan veya ileri kaydı eşleşmeyen IP'lerden gelen iletileri reddeder. Birçok spam filtresi de bu IP'leri yüksek riskli sayar; bu yüzden e-posta gönderen her sunucu için PTR kaydı fiilen zorunludur.
PTR değişikliği ne kadar sürede geçerli olur?
Kaydın TTL değerine bağlıdır; çoğu zaman birkaç dakika ile birkaç saat arasında yayılır. Değişiklikten sonra dig ile farklı DNS sunucularından (örneğin 1.1.1.1 ve 8.8.8.8) sorgu yaparak kontrol edebilirsiniz.
Bir sunucuda birden fazla alan adı varsa PTR hangisine ayarlanmalı?
Sunucunun kendisine; genellikle ana alan adınızdaki mail.alanadi.com gibi bir ada. Diğer alan adlarından giden e-postalar, kendi SPF ve DKIM kayıtlarıyla doğrulanır.
Kendi sunucunuzda e-posta çalıştırmak PTR, kimlik doğrulama ve itibar takibini düzenli yapmayı gerektirir. Bu yükü almak istemiyorsanız kurumsal e-posta paketlerine göz atabilir, sunucunuzdaki e-posta sorunları için sunucu yönetimi hizmetinden destek alabilirsiniz.
Kaynaklar
- Gmail Help: Email sender guidelines
- Google Workspace Admin Help: SMTP errors and codes
- RFC 1035: Domain Names — Implementation and Specification
- RFC 1912: Common DNS Operational and Configuration Errors
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)