PTR Kaydı: E-posta Sunucunuz Neden Reddediliyor

E-posta kendi sunucunuzdan gönderiliyor, SPF ve DKIM de ayarlanmış, ancak Gmail mesajı 550-5.7.25 ile geri gönderiyor veya doğrudan spam'e atıyor. Postfix logu hiçbir şey göstermiyor çünkü sorun sizin tarafınızda değil. Sorun, IP'nizin ters DNS'te hiçbir ada işaret etmemesi ve alıcı sunucunun gönderici kimliğini anlamak için hiçbir yolu olmamasıdır.

PTR kaydı, birisi IP'nizi ters sorguladığında dönen yanıttır. Bu olmadan, her modern anti-spam politikası sizi şüpheli görür, e-posta içeriğiniz tamamen sağlıklı olsa bile.

PTR kaydı tam olarak neyi çözer

Gmail sunucusu IP'nizden e-posta aldığında, önce bir ters sorgu yapar: dig -x 203.0.113.45 +short. Yanıt boşsa veya kendisi aynı IP'ye dönmeyen bir ada işaret ediyorsa, gönderici itibar puanı sıfırlanır. Bu kontrol SPF ve DKIM'den önce yapılır; yani doğru imza bile sizi kurtarmaz.

Çoğu kişinin bilmediği nokta: PTR Forward-Confirmed olmalıdır. Yani dig -x 203.0.113.45 mail.example.com yanıtı verdiyse, o zaman dig mail.example.com da aynı 203.0.113.45'i döndürmelidir. Bu ikisi birbirini tutmuyorsa, PTR değersizdir. Buna FCrDNS denir ve çoğu e-posta test aracı bunu ayrıca kontrol eder.

PTR'yi kim ayarlar

İşte çoğu yöneticinin takıldığı yer burasıdır. PTR'yi alan adınızın DNS panelinde siz ayarlamazsınız. PTR, IP'yi aldığınız ISP'nin veya veri merkezinin Zone dosyasındadır. Siz sadece talep edebilirsiniz.

Bir İranlı sağlayıcıdan özel sunucunuz veya VPS'niz varsa, genellikle destek talebi veya sunucu yönetim paneli üzerinden rDNS'yi ayarlayabilirsiniz. Paylaşımlı hostingdeyseniz, PTR genellikle sağlayıcının kendi sunucu adına ayarlanmıştır ve erişiminiz yoktur. Bu durumda paylaşımlı hostingde kişisel alan adından işlemsel e-posta göndermek her zaman risklidir.

Kendi yönettiğiniz sunucular için, Linux hosting kullanıyorsanız, rDNS bölümü genellikle aynı panelde ayarlanabilir.

PTR'yi pratikte ayarlama: nereden başlamalıyım

Önce sunucunuzun genel çıkış IP'sini bulun. Sunucuda şunu çalıştırın:

curl -4 ifconfig.me
ip -4 addr show scope global

Sonra mevcut PTR'nin olup olmadığını kontrol edin:

dig -x 203.0.113.45 +short
host 203.0.113.45

Çıktı boşsa, rDNS talebi vermelisiniz. Talepte şu iki şeyi tam olarak yazın: IP ve istediğiniz FQDN adı. Örneğin mail.example.com. Seçtiğiniz ad, aynı IP'ye işaret eden geçerli bir A Record'a sahip olmalıdır.

Zone dosyasında doğru kalıp

Alan adınızın Zone'unda bu kayıtlar bulunmalıdır:

mail.example.com.    IN  A     203.0.113.45
example.com.         IN  MX 10 mail.example.com.
example.com.         IN  TXT   "v=spf1 mx -all"

Ve ISP tarafında, PTR şu şekilde ayarlanmalıdır:

45.113.0.203.in-addr.arpa.  IN  PTR  mail.example.com.

Sıra önemlidir. Önce A Record'u ayarlayın, DNS'i Propagate edin, sonra PTR talebi verin. PTR'yi A Record'dan önce ayarlarsanız, FCrDNS başarısız olur ve e-posta test araçları uyarı verir.

Doğru çalıştığını nasıl doğrularım

Ayarladıktan sonra şu komutu çalıştırın:

dig -x 203.0.113.45 +short
dig mail.example.com +short

Her ikisi de birbirini doğrulamalıdır. Son test için check-auth@verifier.port25.com adresine bir e-posta gönderin. Dönen yanıt SPF, DKIM ve rDNS durumunu içerir. rDNS bölümünde did not find a PTR record yazıyorsa, henüz ayarlanmamış veya Propagation tamamlanmamış demektir.

Gerçekten gördüğüm hatalar

Burada hata yapıyorlar: PTR'yi mail Subdomain'i yerine ana alan adına ayarlıyorlar. Yani MX mail.example.com'a işaret ederken, PTR olarak example.com veriyorlar. Sonuç, FCrDNS'nin başarısız olması ve Gmail'in e-postayı hâlâ şüpheli görmesidir. Belirtisi de testlerin hepsi yeşil göstermesine rağmen e-postanın hâlâ spam'e düşmesidir.

İkinci hata: Tek IP üzerinde birden fazla alan adı, hepsi tek PTR ile. Bir sunucuda on site barındırıyorsanız ve hepsi tek IP'den e-posta gönderiyorsa, PTR yalnızca bir ada işaret edebilir. Diğer alan adları FCrDNS açısından uyumsuz hale gelir. Doğru çözüm, işlemsel e-posta gönderen her alan adı için özel IP'dir.

Daha az görülen ama acı verici olan üçüncü hata: PTR'yi ayarlıyorlar ama A Record'u sonradan değiştiriyorlar ve PTR'yi güncellemeyi unutuyorlar. Bir hafta sonra e-postalar sessizce spam'e düşüyor ve kimse nedenini anlamıyor. Sunucu IP'nizi değiştirdiyseniz, PTR'yi de tekrar kontrol edin.

PTR yeterli değil: Tam itibar zinciri

PTR zincirin sadece bir halkasıdır. PTR'niz var ama SPF'niz yoksa, hâlâ reddedilirsiniz. SPF'niz var ama DKIM imzanız yoksa, bazı alıcılar mesajı işaretler. DMARC'ınız yoksa, alan adınızdan kimin sahtecilik yaptığını anlayamazsınız.

Kurulum sırasını takip edin: Önce A Record, sonra PTR, sonra SPF, sonra DKIM, en son DMARC. Ters giderseniz, her aşama testi zorlaştırır.

PTR'yi ayarlayamadığınızda

Paylaşımlı hostingde, PTR sizin elinizde değildir. İşlemsel e-postanız varsa (iletişim formu, şifre kurtarma, sipariş onayı), iki yolunuz var: ya kendi IP'sini doğru PTR ile yöneten bir işlemsel e-posta servisi kullanın, ya da sadece e-posta göndermek için küçük bir VPS alın.

İlk yol daha hızlıdır ve daha az zahmetlidir. İkinci yol daha fazla kontrol verir ama SPF, DKIM ve DMARC'ı kendiniz yönetmelisiniz. Çoğu WordPress sitesi için ilk yol doğru seçimdir. WordPress'teyseniz ve sistem e-postalarınız ulaşmıyorsa, her şeyden önce WordPress wp-cron sorununu kontrol edin; bazen sorun aslında PTR değildir ve cron çalışmıyordur.

E-postalarınızın nereden reddedildiğini bilmek istiyorsanız, ServerNet'in ücretsiz araçları DNS testi ve kayıt kontrolü içerir. Sunucu hatalarını daha iyi anlamak için, HTTP durum kodu rehberi de iyi bir referanstır.

Sıkça sorulan sorular

SPF ve DKIM'im varken e-postalarım neden spam'e düşüyor?

Çünkü PTR'niz yok veya FCrDNS doğrulanmıyor. Alıcı sunucu, SPF ve DKIM'i kontrol etmeden önce IP'nizin kimliğini kontrol eder. PTR boşsa veya aynı IP'ye dönmeyen bir ada işaret ediyorsa, gönderici itibar puanı düşer ve mesaj spam'e gider.

dig -x IP ve dig mail.example.com ile her ikisini kontrol edin. Bu ikisinden biri boşsa veya diğeriyle uyuşmuyorsa, sorun tam oradadır.

PTR kaydını alan adımın DNS panelinde kendim mi ayarlamalıyım?

Hayır. PTR, alan adınızın DNS'inde değil, ISP'nin veya veri merkezinin Zone dosyasındadır. Siz sadece destek talebi veya sunucu paneli üzerinden rDNS talebi verebilirsiniz. Alan adınızın DNS panelinde sadece A Record, MX ve TXT ayarlarsınız.

Paylaşımlı hostingdeyseniz, genellikle rDNS'ye erişiminiz yoktur ve işlemsel e-posta servisi kullanmalısınız.

Kaç alan adı ortak bir PTR'ye sahip olabilir?

Yalnızca bir tane. PTR yalnızca bir ana makine adına işaret eder. Birden fazla alan adı tek IP'den e-posta gönderiyorsa, yalnızca PTR'nin işaret ettiği alan adı geçerli FCrDNS'ye sahiptir. Diğerleri alıcı sunucular açısından şüpheli hale gelir.

Doğru çözüm, işlemsel e-posta gönderen her alan adı için özel IP'dir. Alan adı sayısı fazlaysa, işlemsel e-posta servisi birden fazla IP yönetmekten daha ekonomiktir.

PTR'yi ayarladıktan sonra etkili olması ne kadar sürer?

Propagation genellikle kaydın TTL'sine bağlı olarak birkaç dakika ile birkaç saat arasında sürer. TTL'yi 300 saniyeye (5 dakika) ayarladıysanız, daha hızlı görürsünüz. Daha yüksek TTL'li kayıtlar için 24 saate kadar sürebilir.

Ayarladıktan sonra, check-auth@verifier.port25.com adresine bir test e-postası gönderin ve yanıtı okuyun. rDNS doğrulanmışsa, sorun başka bir yerdedir ve SPF ile DKIM'i kontrol etmelisiniz.