PTR Kaydı Nedir? VPS İçin Ters DNS ve E-posta Ayarları

PTR Kaydı ve E-posta İçin Ters DNS

VPS veya dedicated bir sunucuda kendi e‑posta altyapınızı kurduğunuz anda ilk karşılaştığınız duvarlardan biri “rDNS / PTR kaydınız yok” uyarısı oluyor. Alıcı e‑posta sunucuları, gönderen IP’nin reverse DNS kaydını kontrol ederek hangi hostname’e işaret ettiğini değerlendirebilir. Bu eşleşme, tek başına alan adı sahipliğini kanıtlamaz. İşte bu ters yönlü çözümleme PTR (Pointer) kaydı ile çalışıyor.

Basitçe: Normal DNS’te bir alan adını (örneğin mail.ornek.com) IP’ye çevirirsiniz. PTR ise bunun tam tersini yapar; IP adresinden alan adına gider. E‑posta tarafında eksik veya tutarsız PTR, alıcının politikasına göre reddedilme ya da spam olarak değerlendirilme nedenlerinden biri olabilir; doğru PTR ise tek başına gelen kutusuna teslimi garanti etmez.

Bu yazıda, PTR (reverse DNS) kaydının tam olarak ne olduğunu, DNS seviyesinde nasıl çalıştığını, VPS IP’niz için adım adım nasıl ayarlamanız gerektiğini ve e‑posta teslim edilebilirliği üzerindeki etkisini örneklerle açıklayacağız. Ayrıca sağlayıcı üzerinden PTR yönetiminde izlenecek yolu ve sık yapılan hataları nasıl önleyebileceğinizi ele alacağız.

PTR (Reverse DNS) Kaydı Tam Olarak Nedir?

PTR kaydı, bir IP adresinin hangi hostname’e (alan adına) işaret ettiğini söyleyen DNS kayıt türüdür. Forward DNS’te A ve AAAA kayıtları alan adı → IP ilişkisini tutarken, PTR bu ilişkiyi IP → alan adı yönünde tutar. Bu yüzden PTR kayıtları genellikle “reverse DNS”, “rDNS” veya “ters DNS” olarak da anılır.

Örnek bir ilişki şöyle görünür:

• Forward DNS: mail.ornek.com → 203.0.113.10 (A kaydı)
• Reverse DNS (PTR): 203.0.113.10 → mail.ornek.com (PTR kaydı)

Eğer bu ilişki iki yönlü doğru bir şekilde kurulmuşsa, buna genellikle FCrDNS (Forward Confirmed reverse DNS) denir. Alıcı sunucular ve spam filtreleri, IP’nizi değerlendirirken bu iki yönlü eşleşmeyi kontrol edebilir.

PTR Kaydı Nerede Tutulur?

Önemli bir nokta: PTR kaydı, normalde alan adınızın DNS bölgesinde değil, IP bloklarının yönetildiği özel reverse DNS bölgelerinde tutulur. Örneğin:

• IPv4 için: in-addr.arpa alanı (örneğin 10.113.0.203.in-addr.arpa)
• IPv6 için: ip6.arpa alanı (uzun, heksadesimal ve ters yazılmış haliyle)

Bu reverse DNS bölgeleri genellikle IP’leri tahsis eden operatör veya hosting sağlayıcı tarafından yönetilir. Yani PTR kaydını çoğu zaman doğrudan kendi DNS panelinizden ekleyemezsiniz; IP’yi aldığınız sağlayıcıdan talep etmeniz veya sağlayıcınızın sunduğu özel rDNS arayüzünü kullanmanız gerekir.

Neden Özellikle E‑Posta Sunucuları İçin Kritik?

Web trafiğinde PTR kaydınız olmasa da siteniz genelde çalışır. Ancak söz konusu SMTP, yani e‑posta trafiği olduğunda işler değişir. Modern spam filtreleri, sizden gelen bağlantıyı değerlendirirken bir dizi sinyal toplar:

• IP’nizin PTR kaydı var mı?
• PTR kaydındaki hostname geçerli bir alan adına mı işaret ediyor?
• Bu hostname tekrar çözüldüğünde (forward DNS) aynı IP’ye dönüyor mu?
• PTR kaydınız “dynamic-203-0-113-10.isp.net” gibi dinamik/ev tipi görünüyor mu, yoksa “mail.ornek.com” gibi kurumsal mı?

Gmail’in gönderen yönergeleri geçerli forward ve reverse DNS kayıtlarını şart koşar; PTR yalnızca olası bir spam puanı sinyali olarak düşünülmemelidir. Bu konuda daha geniş çerçeveyi görmek için SPF, DKIM, DMARC ve rDNS ile e‑posta teslim edilebilirliğini adım adım yükseltme rehberimize mutlaka göz atmanızı öneririm.

HELO/EHLO ve PTR Tutarlılığı

SMTP oturumu başladığında sunucunuz karşı tarafa bir HELO veya EHLO hostname’i bildirir. Örneğin:

EHLO mail.ornek.com

Alıcı sunucunun politikasına göre şu kontroller uygulanabilir:

1. Bağlanan IP adresinin PTR kaydını sorgular.
2. PTR’dan çıkan hostname ile EHLO’da verdiğiniz hostname uyuşuyor mu diye bakar.
3. PTR hedefinin ilgili A veya AAAA yanıtı, bağlantıyı kuran IP’yi içeriyor mu (FCrDNS kontrolü)?

Eksik PTR veya forward DNS ile doğrulanamayan bir PTR hedefi, alıcının politikasına göre reddedilmeye ya da spam değerlendirmesine yol açabilir. HELO/EHLO ile PTR adının farklı olması ise tek başına FCrDNS’in başarısız olduğu anlamına gelmez; bu adların eşitliğine ilişkin kontroller alıcıya bağlıdır.

Kara Liste (RBL) ve PTR İlişkisi

RBL (Realtime Blackhole List) ve itibar servislerinin listeleme ölçütleri farklıdır. Bir PTR adının görünümü, IP’nin dinamik olup olmadığını veya kara listede yer aldığını tek başına kanıtlamaz. Aşağıdaki durumları ayrı değerlendirin:

• PTR adında adsl-*, dialup-*, dynamic-* gibi parçalar bulunması bir adlandırma ipucudur; IP’nin tahsis türünü sağlayıcıdan doğrulayın.
• PTR hedefinin forward DNS ile gönderen IP’ye dönmemesi ise ayrıca giderilmesi gereken bir DNS tutarsızlığıdır.

Örneğin Spamhaus PBL, ağ politikası gereği alıcıların MX sunucularına doğrudan e‑posta göndermemesi gereken IP aralıklarını listeler; statik ve dinamik adresleri kapsayabilir. PTR adını değiştirmek bu politikayı veya listelemeyi kendiliğinden kaldırmaz. Kendi mail sunucunuz için hem forward/reverse DNS eşleşmesini hem de gönderen IP’nin doğrudan SMTP kullanımına uygunluğunu kontrol edin.

PTR Kaydı DNS Seviyesinde Nasıl Çalışır?

PTR’ın nasıl ayarlanacağını anlatmadan önce, mantığını netleştirmek işi çok kolaylaştırıyor. Forward DNS tarafını zaten biliyorsunuz; alan adı sizin DNS’nizde, A/AAAA kayıtlarını siz yönetiyorsunuz. Reverse tarafta ise top çoğu zaman IP sağlayıcısında.

IPv4 için Reverse DNS (in-addr.arpa)

IPv4 adresleri için reverse DNS; IP’nin oktetlerinin ters yazıldığı bir yapıda tutulur. Örnek IP’yi ele alalım:

203.0.113.10

Bu IP için PTR sorgusunda kullanılan DNS adı şöyle görünür:

10.113.0.203.in-addr.arpa

Bu adı kapsayan reverse DNS bölgesinin yetkili sunucularını genellikle IP bloğunu yöneten operatör veya hosting sağlayıcı işletir; yetki başka bir kuruma da devredilebilir. Bölgede şöyle bir PTR kaydı yer alır:

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.ornek.com.

IPv6 için Reverse DNS (ip6.arpa)

IPv6’da yapı daha uzundur ama mantık aynıdır. Örneğin:

2001:db8:abcd:0012::1

Reverse sorgu adı oluşturulurken IPv6 adresi, kısaltılmış sıfırlar açılarak 32 heksadesimal haneye tamamlanır; haneler ters sırada ve aralarına nokta konularak ip6.arpa önüne eklenir. IPv6 PTR yönetiminin panelden mi yoksa destek talebiyle mi yapılacağı sağlayıcıya bağlıdır. IPv6 e‑posta teslimiyle ilgili daha derin bir bakış için IPv6 ile e‑posta teslimi, PTR, HELO, SPF ve RBL’ler rehberimizi inceleyebilirsiniz.

Neden PTR’ı Kendi DNS Panelimde Göremiyorum?

Çünkü alan adının sahibi siz olsanız da, IP bloğunun sahibi genellikle hosting sağlayıcınızdır. Alan adıyla ilgili kayıtlar (A, AAAA, MX, TXT, CNAME vs.) sizin DNS bölgenizde tutulur. Ancak PTR kayıtları IP bloğunu yöneten kurumun reverse DNS bölgelerinde saklanır. Dolayısıyla:

• A kaydınızı siz yönetirsiniz.
• PTR kaydınızı çoğu zaman sağlayıcı yönetir, siz talep edersiniz.

Bu ayrımı bilmek, hem doğru yerden iş istemek hem de hataları daha hızlı teşhis etmek için çok önemlidir. Eğer DNS kayıt tiplerine genel bir bakışa ihtiyacınız varsa, DNS kayıtları A’dan Z’ye rehberimize de göz atabilirsiniz.

VPS IP’niz İçin PTR (Reverse DNS) Nasıl Ayarlanır?

Şimdi pratiğe geçelim. Elinizde bir VPS veya dedicated sunucu olduğunu varsayalım ve bu sunucudan mail.ornek.com alan adıyla e‑posta göndermek istiyorsunuz. Buradaki alan adları ve IP’ler anlatım amaçlı örneklerdir; kendi yönettiğiniz hostname’i ve alıcının gördüğü gerçek gönderici IP’yi kullanın. NAT veya SMTP relay varsa bu IP, VPS’in yerel adresinden farklı olabilir. İzlemeniz gereken adımlar genel olarak şöyledir:

1. Adım: Kullanacağınız Hostname’i Belirleyin

İlk adımda, IP’nize atanacak hostname’e karar vermelisiniz. En yaygın tercih:

• mail.ornek.com
• veya smtp.ornek.com

Bazı senaryolarda server1.ornek.com gibi daha genel bir isim de kullanabilirsiniz, ancak e‑posta tarafında mail. veya smtp. prefiksleri sunucunun rolünü yöneticiler için daha anlaşılır kılar; tek başına spam filtrelerinde avantaj sağladığı varsayılmamalıdır.

Ayrıca bu hostname’i, sunucunuzun sistem hostname’i (Linux’ta hostnamectl çıktısı vb.) olarak da tanımlamanız tavsiye edilir. Ancak sistem hostname’ini değiştirmek, MTA’nın HELO/EHLO adının mutlaka değişeceğini garanti etmez. Postfix’te dışarıya bildirilen adı smtp_helo_name belirler ve varsayılan değeri $myhostname’dir; kullandığınız MTA’nın etkin ayarını ayrıca doğrulayın.

2. Adım: Önce A (ve Gerekirse AAAA) Kaydını Oluşturun

Sağlayıcınız, PTR talebini kabul etmeden önce hostname’in forward DNS’inin gönderen IP’ye işaret etmesini isteyebilir. PTR değişikliğinden bağımsız olarak, e‑posta testinden önce iki yönü de doğrulayın:

• mail.ornek.com için bir A kaydı oluşturun ve alıcının gördüğü gerçek gönderici IPv4 adresine yönlendirin.
• IPv6 üzerinden e‑posta gönderiyorsanız, aynı hostname’in AAAA kaydına gerçek gönderici IPv6 adresini ekleyin.

Bu adımı atlamanız durumunda, reverse DNS yapılsa bile FCrDNS sağlanamadığı için bazı alıcılar yine sorun çıkarabilir. Bu ilişkiyi doğru kurmak, ileride SPF, DKIM, DMARC gibi diğer ayarlarda da işinizi kolaylaştırır. Detaylı bir kimlik doğrulama kurulumu için SPF, DKIM ve DMARC yapılandırma rehberimize göz atabilirsiniz.

3. Adım: Mevcut PTR Kaydını Kontrol Edin

PTR ayarınıza başlamadan önce IP’nizde halihazırda ne olduğunu görmeniz iyi olur. Aşağıdaki komutlarda örnek IP adresini kendi sunucunuzun IP adresiyle değiştirin:

Linux/Mac Terminalinden:

dig -x 203.0.113.10 +short

# veya

nslookup 203.0.113.10

Boş bir çıktı tek başına PTR kaydının bulunmadığını kanıtlamaz; sorgunun durum kodunu ve hata çıktısını da kontrol edin. Ayrıntılar için aynı dig sorgusunu +short olmadan inceleyebilirsiniz. Aşağıdaki çıktı yalnızca varsayımsal bir örnektir; DCHost’un varsayılan PTR biçimi olarak doğrulanmış değildir:

203-0-113-10.dchost.net.

Bu tür bir ad, sağlayıcının verdiği varsayılan PTR olabilir. E‑posta gönderimi için önemli olan, PTR hedefinin forward DNS ile gönderen IP’ye dönmesidir; yalnızca varsayılan bir ad olması değişiklik zorunluluğu doğurmaz.

Windows Komut Satırından:

nslookup 203.0.113.10

Sonuç bölümünde “Name” satırında gördüğünüz hostname, mevcut PTR kaydını gösterir.

4. Adım: PTR Güncelleme Talebi veya Panel Üzerinden Ayar

Burada süreç, kullandığınız sağlayıcının sunduğu arayüze ve IP tahsis modeline göre değişir. Olası yönetim yöntemleri şunlardır:

• VPS ve dedicated sunucularda: Sağlayıcı panelde PTR/Reverse DNS düzenleme alanı sunuyorsa ilgili IP için hostname’i buradan girebilirsiniz. Böyle bir alan yoksa PTR değişikliği için sağlayıcının destek sürecini öğrenin.
• Colocation: IP bloğunu tahsis eden kuruluşla, reverse DNS delegasyonu yapılıp yapılamayacağını veya PTR taleplerinin kuruluş tarafından yönetilip yönetilmediğini netleştirin.

PTR talebinde bulunurken mutlaka şunları net yazın:

• Hangi IP için PTR istediğiniz (IPv4 ve/veya IPv6)
• Hangi hostname’e işaret etmesini istediğiniz (örn. mail.ornek.com)

Değişikliğin yetkili DNS sunucularına uygulanması sağlayıcının işlem sürecine bağlıdır. Çözümleyiciler eski olumlu yanıtı veya daha önce alınmış “kayıt yok” yanıtını önbellekte tutabilir. Bu nedenle internet genelinde sabit bir 1–4 saatlik yayılma süresi varsaymayın; yetkili kayıt ile kullanılan çözümleyicinin yanıtını karşılaştırın.

5. Adım: Doğrulama ve Testler

PTR güncellemesi yapıldıktan sonra mutlaka doğrulama yapın:

1. Reverse kontrol: dig -x IP +short komutunda IP yerine gerçek gönderici adresini kullanın; mail.ornek.com. çıktısını görün.
2. Forward kontrol: dig mail.ornek.com A +short ve varsa AAAA sorgusuyla IP’ye geri döndüğünüzden emin olun.
3. E‑posta testi: Sunucudan Gmail/Outlook gibi servislere test maili atın ve ham header’larda “Received:” satırlarını, HELO ismini ve IP/PTR/hostname tutarlılığını inceleyin.

Eğer kendi mail sunucunuzu sıfırdan kuruyorsanız, VPS’te Postfix + Dovecot + rspamd ile e‑posta sunucusu kurulum rehberimizde PTR, SPF, DKIM ve IP ısıtma (warming) süreçlerini uçtan uca bir senaryo içinde bulabilirsiniz.

Doğru PTR Tasarımı: En İyi Uygulamalar

Teknik olarak PTR kaydını “bir şekilde” ayarlamak kolay. Ancak işin püf noktası, spam filtreleri ve itibar servisleri gözünde makul ve tutarlı bir kimlik oluşturmak. Uygulanabilecek bazı pratik tavsiyeler şöyle:

1. IP Başına Tek PTR Kullanın

DNS standardı teoride bir IP için birden fazla PTR’ye izin verse de, pratikte bu tavsiye edilmez. Birden fazla PTR, hangi hostname’in sunucunun kimliği olarak kullanılacağını belirsizleştirebilir. Bu yüzden:

• Her IP için tek PTR belirleyin.
• Farklı domain’ler için mail gönderecekseniz, genellikle hepsini aynı hostname üzerinden (örneğin mail.ornek.com) gönderebilirsiniz.

2. Yönetilebilir ve Açıklayıcı Bir Hostname Seçin

PTR’da kullanılacak hostname mümkün olduğunca:

• Okunabilir ve anlamlı olsun (mail.ornek.com, smtp1.ornek.com vb.).
• Yönetebildiğiniz bir alan adı altında olsun.
• PTR hedefi takma ad yerine doğrudan A veya AAAA kaydı bulunan bir hostname olsun; ilgili adres ailesindeki yanıt gönderen IP’yi içersin.

Bu düzen, IP ile hostname arasında doğrulanabilir bir ilişki kurar; tek başına güvenilirlik veya gelen kutusuna teslim garantisi değildir.

3. FCrDNS (Forward Confirmed reverse DNS) Sağlayın

FCrDNS, PTR hedefinin A veya AAAA yanıtında başlangıçtaki IP’nin bulunmasıdır. HELO/EHLO adını da aynı hostname olarak kullanmak, sunucu kimliğini tutarlı tutan bir tasarım tercihidir:

• PTR: IP → mail.ornek.com
• A/AAAA: mail.ornek.com → IP
• HELO/EHLO: mail.ornek.com

Örneğin HELO/EHLO adı server.ornek.com, PTR hedefi mail.ornek.com ise bu fark tek başına FCrDNS’in başarısız olduğu anlamına gelmez. FCrDNS için mail.ornek.com adının ilgili A veya AAAA yanıtında gönderen IP’nin bulunması gerekir. HELO/EHLO adının geçerliliği ayrı değerlendirilir; aynı adı kullanmak yönetimi ve sorun gidermeyi kolaylaştıran bir tasarım tercihidir.

4. SPF, DKIM ve DMARC ile Birlikte Düşünün

PTR tek başına mucize yaratmaz; SPF, DKIM ve DMARC ile birlikte anlam kazanır. İdeal senaryoda:

• SPF politikası, gönderen IP’yi zarf MAIL FROM veya ilgili HELO kimliği için yetkilendirmeli.
• DKIM anahtarınız DNS’te yayınlanmış, imzalarınız geçerli olmalı.
• DMARC kaydınız yayınlanmış olmalı; DMARC geçişi için başarılı SPF veya DKIM kimliklerinden en az biri görünür From alan adıyla hizalanmalı.

Tamamını tek seferde uçtan uca kurgulamak için e‑posta teslim edilebilirliğini adım adım yükseltme rehberimiz iyi bir referans olacaktır.

5. Yüksek Hacimli Gönderimlerde IP Isıtma ve Ayrı IP’ler

Eğer transactional (sipariş onayı, şifre sıfırlama vb.) ve pazarlama (bülten, kampanya) e‑postalarını birlikte gönderiyorsanız, itibar yönetimi için bazen ayrı IP ve PTR kullanmak mantıklıdır. Örneğin:

• mail1.ornek.com → transactional
• mail2.ornek.com → bülten / kampanya

Gönderim türleri ayrı IP’ler üzerinden yürütülürse IP itibarını ve hacmini ayrı izlemek kolaylaşabilir; ortak alan adı, içerik veya gönderim uygulamalarından kaynaklanan sorunlar yine iki akışı da etkileyebilir. Ayrı IP kullanımı tek başına itibar yalıtımı sağlamaz. Yeni gönderici IP’lerde hacmi kontrollü artırın ve teslim sonuçlarını izleyin.

Sık Yapılan Hatalar ve Sorun Giderme

PTR ayarını yaptığınız halde e‑postalarınız hâlâ spam klasörüne gidiyorsa, aşağıdaki kontrollerle başlayabilirsiniz. Liste tüm nedenleri kapsamaz; IP/alan adı itibarı ve gönderim uygulamaları da önemlidir.

1. PTR Var Ama Forward DNS Yok veya Yanlış

Kontrol edilecek bir sorun: IP → hostname (PTR) var ama hostname’in ilgili A/AAAA yanıtında gönderen IP yok. FCrDNS bu durumda sağlanmaz; yanıtın başka IP’ler de içermesi ise tek başına hata değildir. Çözüm:

• Önce A/AAAA kayıtlarını doğru IP’ye işaret edecek şekilde oluşturun.
• Sonra PTR’nin gerçekten bu hostname’e döndüğünü doğrulayın.

2. PTR Adını IP’nin Gönderim Politikasıyla Karıştırmak

“dynamic-203-0-113-10.isp.net” benzeri bir PTR, tek başına IP’nin dinamik olduğunu, PBL’de bulunduğunu veya e‑postanın reddedileceğini göstermez. Bazı alıcı filtreleri adlandırma kalıplarını sinyal olarak değerlendirebilir; bu, bir IP politika listesinin üyeliğiyle aynı şey değildir.

• Önce gerçek ret yanıtındaki liste adını ve IP’yi inceleyin; ilgili listenin resmî sorgulama ve politika açıklamasını kontrol edin.
• Spamhaus PBL söz konusuysa, adresin statik olması tek başına doğrudan gönderime izin verildiğini göstermez. Ağ sağlayıcısının gönderim politikasını da doğrulayın.
• IP’nin doğrudan alıcı MX sunucularına göndermesi uygun değilse, sağlayıcınızın veya uygun bir e‑posta hizmetinin kimlik doğrulamalı SMTP relay/smarthost seçeneğini kullanın.

Kendi alan adınızda açıklayıcı bir hostname seçmek yönetimi kolaylaştırabilir; ancak PTR’ı yeniden adlandırmak PBL kaydını silmez ve gelen kutusuna teslim sağlamaz. PBL’den çıkarılma talebi ancak listenin koşullarını karşılayan, size tahsisli statik bir IP’de gerçek bir çıkış mail sunucusu çalıştırıyorsanız değerlendirilmelidir; uygun forward/reverse DNS ve sunucu dışındaki cihazların dışarı port 25 kullanmasının engellenmesi de gerekir. Güncel uygunluk ve işlem adımlarını Spamhaus’un açıklamasından kontrol edin.

3. Bir IP İçin Birden Fazla PTR Talep Etmek

“Tek IP’den 3–4 domain için mail atıyorum, hepsi için ayrı PTR tanımlatayım” düşüncesini ele alalım. Bu durumda:

• Her gönderen domain için ayrı PTR tanımlamak yerine ortak bir sunucu hostname’i kullanabilirsiniz.
• Her domain’in SPF, DKIM ve DMARC yapılandırmasını ise ayrıca değerlendirin.

Bu yüzden IP başına tek PTR, forward DNS’te ise bir IP’ye işaret eden birden fazla A kaydı (veya tek A kaydı) kullanmak daha temiz bir yaklaşımdır.

4. PTR Doğru Ama SPF/DKIM/DMARC Eksik

PTR’ı doğru kurduğunuz halde sorun devam ediyorsa, SPF, DKIM ve DMARC yapılandırmasını da kontrol edin. Özellikle DMARC politikası p=reject veya p=quarantine iken ne SPF ne de DKIM üzerinden başarılı ve hizalanmış bir kimlik elde edilememesi ciddi teslim sorunlarına yol açabilir. Bu tip durumlarda DMARC raporlarını ve alıcıların kimlik doğrulama sonuçlarını incelemek ve SMTP hata kodları ve bounce mesajlarını yorumlama rehberimizden yararlanmak sorunu hızlıca daraltmanızı sağlar.

5. IPv6 PTR’larını Unutmak

Giderek daha fazla alıcı IPv6 üzerinden bağlantı kabul etmeye başladı. Eğer sunucunuzda IPv6 etkin ve MTA’nız IPv6 IP’sini de kullanıyorsa:

• IPv6 için de PTR (ip6.arpa) tanımlandığından emin olun.
• PTR hedefinin AAAA yanıtında gönderimde kullanılan IPv6 adresinin bulunduğunu doğrulayın; HELO/EHLO adı için de bu hostname’i kullanmak yönetimi kolaylaştırır.

IPv6’yı devreye alırken DNS ve PTR tarafında nelere dikkat etmeniz gerektiğini, IPv6 ile e‑posta teslimi rehberimizde daha detaylı anlattık.

Hosting Sağlayıcısıyla PTR Yönetimini Planlamak

PTR yönetiminde panel, destek talebi veya reverse DNS delegasyonu seçeneklerinden hangisinin kullanılabildiğini IP’yi tahsis eden kuruluşla netleştirin. VPS, dedicated ve colocation için uygulanabilecek hazırlık sırası şöyledir:

• VPS veya dedicated sunucu aldığınızda, projeye göre kullanacağınız ana hostname’i en başta netleştirin (örn. server1.ornek.com veya mail.ornek.com).
• Önce alan adınızın DNS’inde A/AAAA kayıtlarını doğru IP’lere işaret edin.
• Ardından sağlayıcının belgelediği panel veya destek süreci üzerinden bu IP’ler için PTR talebinde bulunun.
• E‑posta altyapısı kuruyorsanız, aynı anda SPF, DKIM ve DMARC planını da yapın; hepsini beraber kurgulamak daha sağlıklı.

Daha bütüncül bir e‑posta altyapısı kurmak istiyorsanız; IP ısıtma, itibar yönetimi, DNS kayıtları ve log analizini bir arada ele alan teslim edilebilirliği artırma rehberimiz ile VPS’te e‑posta sunucusu kurulum rehberimizi birlikte okumanızı tavsiye ederim.

PTR, DNS Tutarlılığı ve Gönderim Politikasını Birlikte Kontrol Edin

SMTP protokolü PTR kaydını her bağlantı için zorunlu kılmaz; buna karşılık Gmail gibi alıcılar geçerli forward ve reverse DNS ister. Kendi VPS veya dedicated sunucunuzdan e‑posta gönderiyorsanız doğru PTR, alıcıların gereksinimlerini karşılamanın bir parçasıdır. SPF, DKIM, DMARC, gönderim itibarı ve alıcı politikaları ayrıca değerlendirilir; bu kontrollerden hiçbiri tek başına gelen kutusunu garanti etmez.

Gönderen IP’nin PTR hedefi, ilgili A veya AAAA yanıtında aynı IP’ye dönmelidir. HELO/EHLO adını bu hostname ile tutarlı yönetmek operasyonu kolaylaştırır; bu tercih FCrDNS’in tanımı değildir. PTR, alan adı sahipliğini veya meşru içerik gönderildiğini kanıtlamaz. IP’nin doğrudan SMTP gönderimine izin veren politikası ile her gönderen alan adının SPF, DKIM ve DMARC ayarlarını ayrı kontrol edin.

Hangi hostname’i kullanacağınızdan veya PTR’ı nasıl talep edeceğinizden emin değilseniz, yukarıdaki DNS ve e‑posta rehberlerini inceleyin. DCHost’tan hizmet almayı planlıyorsanız PTR değişikliklerinin yöntemi, dışarı SMTP erişimi ve IP seçeneklerini ekiple netleştirin. Değişikliklerden sonra DNS yanıtlarını, alıcı hata mesajlarını ve kontrollü teslim testlerini izleyerek sonucu değerlendirin.