PTR Kaydı (Reverse DNS) Nedir? E-postada Neden Önemli?

PTR kaydı nedir?

PTR kaydı (pointer record), bir IP adresinin hangi ana makine adına ait olduğunu söyleyen DNS kaydıdır. Bu yöntemi ters DNS ya da reverse DNS diye de anarlar. A kaydı adı IP'ye çevirirken PTR kaydı IP'yi ada çevirir. E-posta sunucuları, bağlanan sunucunun kimliğini bu kayıtla doğrular.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yüzden yazıyı RFC belgelerine ve Google ile Microsoft'un resmi dokümanlarına dayandırdık. Komutları kendi sunucusunu yöneten okurlar için ekledik. Paylaşımlı hosting kullanıyorsanız çoğu adımı sağlayıcınız üstlenir, böylece sizin işiniz hafifler.

Günlük hayattan bir benzetme işe yarar. Rehber, adı numaraya çevirir; ters rehber ise numaradan adı bulur. PTR bu ters rehberin kendisidir. Bir sunucu e-posta gönderirken "ben mail.example.com'um" derse, alıcı ters rehbere bakıp numaranın gerçekten bu adı taşıyıp taşımadığını kontrol edebilir.

Web sitenizin açılması için PTR kaydı gerekmez, çünkü tarayıcılar adı IP'ye çevirir, tersini sormaz. Yani kayıt asıl e-posta gönderen sunucularda önem kazanır. Aşağıda kaydın nasıl çalıştığını, kimin tanımladığını ve nasıl kontrol edeceğinizi sırayla anlatıyoruz.

PTR kaydı ile A kaydı arasındaki fark nedir?

A kaydı bir ana makine adını IPv4 adresine, AAAA kaydı ise IPv6 adresine çevirir. PTR ise bu yönü tersine çevirir. İki kayıt aynı bilgiyi farklı uçtan anlatır, ancak ayrı DNS bölgelerinde durur ve farklı kişilerin elindedir.

En önemli fark şudur: A kaydını alan adınızın DNS panelinde siz yönetirsiniz. PTR ise IP adresinin sahibinin bölgesinde durur. Dolayısıyla alan adı sağlayıcınızda ters kayıt göremezsiniz. Aşağıdaki tablo farkları özetler.

Bu iki kayıt birbirini tamamlar. Biri tek başına yetmez, çünkü alıcı sunucu çoğu zaman ikisini birlikte karşılaştırır.

Reverse DNS in-addr.arpa ile nasıl çalışır?

IPv4 için ters sorgular özel bir alan adı ağacına gider: in-addr.arpa. RFC 1035, bu yapıyı 3.5 bölümünde anlatır. Önce IP adresinin dört sayısını ters sırada yazarsınız, sonra sonuna in-addr.arpa eklersiniz. Böylece IP adresi, DNS'in anladığı bir ada dönüşür.

Örneğin dokümantasyon bloğundan 203.0.113.25 adresini düşünün. Ters adı 25.113.0.203.in-addr.arpa olur. Sayıların ters yazılmasının nedeni, DNS'in adları sağdan sola, yani genelden özele okumasıdır. IP adreslerinde ise genel kısım soldadır. Ters çevirince iki yapı uyumlu hale gelir.

Bu ad üzerinde PTR türünde bir kayıt arandığında cevap, ana makine adı olur. Örneğin cevap mail.example.com olabilir. Sorguyu sizin bilgisayarınız ya da alıcı e-posta sunucusu, kendi çözümleyicisi üzerinden yapar.

Ters bölgenin yetkisi IP bloğunun sahibindedir. Adres blokları bölgesel kayıt kuruluşlarından sağlayıcılara, oradan müşterilere geçer. Dolayısıyla ters DNS yetkisi de aynı zinciri izler.

IPv6 için ip6.arpa ters adını nasıl yazarsınız?

IPv6 ters sorguları ip6.arpa alanına gider. RFC 3596 bu yapıyı tanımlar. IPv4'ten farkı, ayırıcı birimin onaltılık tek hane, yani nibble olmasıdır. Adresi tam açarsınız, her haneyi noktayla ayırırsınız ve ters sırada dizersiniz.

Dokümantasyon bloğundan 2001:db8::25 adresinin ters adı şöyle çıkar:

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

Elle yazmak hataya açıktır. Bu yüzden dig -x komutu, adresi sizin yerinize çevirir. Sunucunuz IPv6 üzerinden e-posta gönderiyorsa, IPv6 adresinin de kendi ters kaydı olmalıdır. Çoğu kişi yalnızca IPv4 kaydını düzeltir, sonra IPv6 üzerinden giden iletilerin neden sorun çıkardığını anlamaz.

IPv6 hazırlığı hakkında genel bilgiyi IPv6 nedir yazımızda anlattık. Sitenizin IPv6 durumunu IPv6 testi aracımızla görebilirsiniz.

PTR kaydını kim tanımlar, alan adı DNS paneli neden yetmez?

PTR kaydını IP adresinin sahibi tanımlar. Çoğu durumda bu kişi, sunucuyu kiraladığınız hosting, VPS ya da bulut sağlayıcısıdır. Alan adınızı aldığınız firmanın DNS paneli, in-addr.arpa bölgesini yönetmez. Bu yüzden orada ters kayıt oluşturmaya çalışmak sonuç vermez.

Sağlayıcılar bu yetkiyi iki yoldan verir. Bazıları panelde "reverse DNS" ya da "rDNS" adlı bir alan sunar; siz ana makine adını yazarsınız. Ama diğerleri destek talebi ister. Hangisinin geçerli olduğunu sağlayıcınızın dokümanından öğrenin.

Küçük bloklarda ek bir ayrıntı var. RFC 2317, /24'ten küçük IP bloklarında ters DNS yetkisinin nasıl devredileceğini anlatır. Dolayısıyla bu işi sağlayıcı yapar; siz genellikle yalnızca istediğiniz ana makine adını bildirirsiniz.

IP adresinin kime ait olduğunu bilmiyorsanız önce IP sorgulama aracımızla adresin hangi ağa bağlı göründüğüne bakın. Ağ sahibi, başvuracağınız kişiyi gösterir. Hosting firmalarının ağlarını nasıl yönettiğini merak ederseniz AS numarası yazımıza göz atın.

İleri ve geri eşleşme (FCrDNS) nedir?

FCrDNS, yani forward-confirmed reverse DNS, iki yönlü doğrulamadır. Önce IP adresinin PTR kaydından bir ana makine adı alırsınız. Ardından bu adın A ya da AAAA kaydına bakarsınız. Çıkan IP, başladığınız IP ile aynıysa eşleşme tamamdır.

Mantığı basittir. Yalnızca PTR'ye güvenseydik, IP'nin sahibi istediği adı yazabilirdi, örneğin başkasının alan adını. Ad tarafındaki A kaydı ise o alan adının sahibinin elindedir. İki kaydın birbirini onaylaması, sahteciliği zorlaştırır.

RFC 1912 bölüm 2.1 de bu yönde öneri verir: PTR ve A kayıtlarınız eşleşmeli, PTR bir CNAME takma adına değil, doğrudan geçerli bir A kaydına işaret etmelidir. Belge bilgilendirici niteliktedir, ancak uygulamada alıcıların beklentisiyle örtüşür.

Google'ın gönderen yönergeleri aynı eşleşmeyi açıkça ister. Gönderen IP adresinin ters kaydı bir ana makine adına dönmeli, o adın A ya da AAAA kaydı da aynı IP'yi göstermelidir. Yani tek yönlü kayıt çoğu zaman yetmez.

HELO ve EHLO adı PTR kaydıyla neden uyumlu olmalı?

E-posta sunucusu bağlanır bağlanmaz EHLO (eski adıyla HELO) komutuyla kendini tanıtır. RFC 5321, bu komutun argümanında sunucunun tam nitelikli alan adının bulunmasını ister. Ad yoksa bir IP adresi değişmezi kullanılabilir. Bu ad PTR adıyla uyuşursa sunucunuz tutarlı davranır.

Standartta ilginç bir denge var. RFC 5321'e göre alıcı, EHLO adının istemci IP'siyle uyumunu doğrulayabilir. Ancak doğrulama başarısız olursa alıcı yalnızca bu sebeple iletiyi reddetmemelidir. Standart bu bilgiyi yalnızca kayıt ve izleme için saklamanızı ister.

Uygulamada alıcıların kuralları standarttan daha sıkı olabilir. Microsoft'un resmi destek makalesi, bazı alıcı sunucuların HELO dizesindeki adın PTR ile eşleşmesini şart koştuğunu söyler. Bu nedenle en güvenli yol, üç değeri aynı hizaya getirmektir: PTR adı, A kaydı ve EHLO adı.

Postfix kullanıyorsanız ilgili ayarlar myhostname ve smtp_helo_name parametreleridir. Değerleri şu komutla görebilirsiniz:

postconf myhostname smtp_helo_name

Hangi MTA'yı kullanırsanız kullanın, ayar adını resmi dokümandan doğrulayın. MTA kavramını MTA nedir yazımızda ayrıntılı anlattık.

PTR kaydı e-postada neden bu kadar kritik?

Çünkü bu kayıt, gönderen sunucunun düzgün işletildiğine dair ucuz ama etkili bir ipucudur. Spam gönderenler çoğu zaman geçici ya da ele geçirilmiş makineler kullanır. Bu makinelerde ters DNS kaydı ya hiç yoktur ya da genel bir ad taşır. Bu yüzden alıcılar bu farkı süzgeç olarak kullanır.

Google'ın gönderen yönergeleri açık konuşur: Gönderen SMTP sunucusunun genel IP adresi, bir ana makine adına çözülen PTR kaydına sahip olmalıdır. Aynı ad, A ya da AAAA kaydıyla aynı IP'ye dönmelidir. Yönergeler ayrıca gönderen IP'ler için geçerli ters DNS kayıtları kurmanızı önerir.

Microsoft tarafında da benzer bir mantık var. Microsoft'un destek makalesine göre Microsoft 365'in gönderen IP'leri ileri-geri eşleşen kayıtlara sahiptir. Makale ayrıca bazı alıcıların HELO adı için PTR kontrolü yaptığını, bu yüzden bazı iletilerin geri dönebileceğini söyler.

Ancak şunu da net söyleyelim: PTR tek başına teslimat garantisi vermez. Alıcılar içerik, itibar ve kimlik doğrulama sinyallerini birlikte değerlendirir. PTR eksikse diğer her şey doğru olsa bile sorun yaşayabilirsiniz.

PTR kaydı eksikse alıcı e-postayı reddeder mi, spama mı atar?

İkisi de olabilir. Alıcının kuralına göre ileti bağlantı aşamasında reddedilebilir, kabul edilip spam klasörüne konabilir ya da puanı düşürülüp diğer sinyallerle birlikte değerlendirilebilir. Ancak hangisinin olacağı alıcıdan alıcıya değişir.

Belirtiler genellikle şunlardır:

• Bazı alıcılara giden iletilerde "ana makine adı IP adresiyle uyuşmuyor" ya da "ters DNS kaydı yok" türünde geri dönüş mesajları görürsünüz.
• Aynı sunucudan giden iletiler yalnızca belirli alıcılarda spama düşer.
• Yeni kurulan bir VPS'ten giden ilk iletiler beklenmedik biçimde geri döner.

Geri dönüş mesajının kodu ve metni alıcıya göre değişir. Bu yüzden kesin bir metne bakmak yerine mesajda "reverse DNS", "PTR" ya da "hostname" sözcüklerini arayın.

Böyle bir işaret görürseniz teşhise sırayla başlayın. Önce PTR'yi, ardından A kaydını, sonra EHLO adını kontrol edin. Üç değer tutarlıysa sorunun başka bir yerde olduğunu düşünebilirsiniz.

PTR kaydını dig -x ile nasıl kontrol edersiniz?

dig komutunun -x seçeneği, IP adresini sizin için ters ada çevirir ve PTR sorgusunu yapar. +short eklerseniz çıktı yalnızca cevaba iner. Dokümantasyon bloğundan örnek bir IP ile deneyelim:

dig -x 203.0.113.25 +short

Çıktı, ana makine adını noktayla biter: mail.example.com. Sondaki nokta, adın tam nitelikli olduğunu gösterir. Çıktı boşsa o IP için ters kayıt bulunamamıştır.

İkinci adımda ileri yönü doğrularsınız:

dig mail.example.com A +short

Dönen IP, başladığınız IP ile aynıysa eşleşme vardır. IPv6 için aynı komut çalışır: dig -x 2001:db8::25 +short yazmanız yeterlidir. Ayrıca sunucunuz iki protokolle de e-posta gönderiyorsa ikisini de sınayın.

Kaydın hangi sunucudan geldiğini görmek isterseniz dig -x komutuna +trace ekleyebilirsiniz. Böylece sorgunun kök sunuculardan yetkili sunucuya nasıl indiğini adım adım izlersiniz. Alan adı tarafındaki kayıtları ise DNS sorgulama aracımızla kontrol edebilirsiniz.

PTR kaydını nslookup ile nasıl sorgularsınız?

Windows kullanıyorsanız ya da dig kurulu değilse nslookup işinizi görür. IP adresini doğrudan yazarsınız ve araç ters sorguyu kendisi yapar:

nslookup 203.0.113.25

Çıktıda "name = mail.example.com" biçiminde bir satır görürsünüz. Satırın başındaki ad, IP'nin ters biçimidir. Kayıt yoksa araç "Non-existent domain" benzeri bir hata verir.

Tür belirtmek isterseniz ters adı kendiniz yazabilirsiniz:

nslookup -type=PTR 25.113.0.203.in-addr.arpa

Bu biçim, ters adın nasıl oluştuğunu anlamak için iyi bir alıştırmadır. Gündelik kullanımda ilk komut daha pratiktir. Linux ya da macOS'ta host komutu da aynı işi görür: host 203.0.113.25 yazmanız yeterlidir.

Bir noktayı unutmayın: Sorguyu yaptığınız çözümleyici önbellek tutabilir. Örneğin kaydı yeni değiştirdiyseniz eski cevabı görebilirsiniz. Bu durumda TTL süresini bekleyin ya da başka bir çözümleyiciyle tekrar deneyin.

PTR kaydını nasıl eklersiniz veya değiştirirsiniz?

Adımlar sağlayıcıdan sağlayıcıya biraz değişir, ancak mantık aynıdır. Aşağıdaki sıra, kendi VPS'ini yöneten okurlar için genel bir yol haritasıdır.

1. E-postanın gerçekte hangi IP'den çıktığını belirleyin. Sunucunun giden IP'si, paneldeki IP'den farklı olabilir; ileti başlıklarındaki Received satırlarına bakın.
2. Kullanacağınız ana makine adını seçin, örneğin mail.example.com. Kendi alan adınızın alt alanını seçmek, kimliği tutarlı kılar.
3. Alan adı DNS panelinizde bu ad için A kaydı (IPv6 varsa AAAA) oluşturun ve gönderen IP'yi gösterin.
4. Sağlayıcınızın panelinde ya da destek talebinde, IP için PTR kaydını bu ada ayarlamasını isteyin.
5. MTA'nızın EHLO adını aynı ada ayarlayın.
6. dig -x ve dig A komutlarıyla iki yönü doğrulayın.
7. Son olarak kendi test adresinize bir ileti gönderin ve başlıklardaki sonuçları okuyun.

Sağlayıcıya yazarken kısa ve net olun: "203.0.113.25 adresinin PTR kaydı mail.example.com olsun." Böylece iki taraf da tek cümleyle anlaşır. Alan adı yönetimi için kurumsal e-posta altyapısı yazımıza da bakabilirsiniz.

Paylaşımlı hosting ile VPS'te PTR kaydı nasıl farklıdır?

Fark, IP adresinin kime ait olduğundan doğar. Paylaşımlı hostingte e-posta sunucusu ve IP, sağlayıcının ortak altyapısıdır. Ters kaydı ayarlama yetkisi sizde değildir; sağlayıcı bunu kendi standartlarına göre yönetir. Böylece siz yalnızca doğru e-posta sunucusunu kullanırsınız.

VPS'te ise IP adresi size tahsis edilmiştir. Çoğu sağlayıcı bu IP için ters DNS ayarını panelde ya da destek üzerinden sunar. Ancak sorumluluk da size geçer: MTA'yı, EHLO adını ve kayıtları siz doğru tutarsınız. VPS ile bulut sunucu arasındaki farkı VPS, VDS ve bulut sunucu yazımızda anlattık.

Hosting seçerken bu farkı sormak değerlidir. Genel seçim ölçütleri için hosting seçimi yazımıza bakın.

Ortak IP ve PTR kaydı itibar riski ne demektir?

Ortak IP, birden fazla müşterinin aynı adresten e-posta gönderdiği durumdur. Alıcılar IP'nin itibarını, o adresten gelen tüm iletilerin geçmişine göre ölçer. Komşunuz spam gönderirse, kendi iletileriniz doğru olsa bile etkilenebilirsiniz.

Ters kayıt burada ikili bir rol oynar. Ortak IP'nin kaydı genellikle sağlayıcının genel adını taşır. Bu normaldir ve çoğu zaman alıcıyı rahatsız etmez. Ama bu adın sizin alan adınızla bir ilgisi yoktur; yani PTR üzerinden marka kimliği kuramazsınız.

Ancak özel IP bu durumu değiştirir. IP yalnızca size ait olduğundan itibar da size aittir. Üstelik ters kaydı kendi alan adınızın bir alt alanına yönlendirebilirsiniz. Ancak yeni bir IP'nin itibarı sıfırdan başlar; ısındırma sürecinin nasıl işleyeceğini sağlayıcınızdan ya da e-posta servisinizden öğrenin.

Önerimiz basit: Düşük hacimli işlem e-postaları için sağlayıcının ya da güvenilir bir e-posta servisinin altyapısı çoğu zaman yeterlidir. Hacim ve kontrol ihtiyacınız büyüdükçe özel IP düşünebilirsiniz.

PTR kaydında en sık yapılan hatalar nelerdir?

Hataların çoğu birkaç kalıba oturur. Bu nedenle aşağıdaki tablo, belirtileriyle birlikte kalıpları sıralar. Çözümlerin neredeyse tamamı "üç değeri hizalama" fikrine çıkar.

Son satır dikkat ister. Bir CDN ya da proxy hizmeti kullanıyorsanız, e-posta için kullandığınız adın A kaydı proxy üzerinden değil, doğrudan sunucu IP'sine çözülmelidir. Aksi halde A kaydı, gönderen IP'yi göstermez.

Tek IP'de birden fazla alan adı varsa PTR kaydı nasıl olur?

Her IP için tek bir kayıt kullanmak en sağlıklı yoldur. Bu ad, alan adlarınızın değil sunucunun kimliğidir. Aynı sunucudan example.com ve başka alan adları adına e-posta gönderiyorsanız, PTR yine sunucunun adını taşır, örneğin mail.example.com.

Alan adlarının kimliğini alıcı başka yerde doğrular. Her alan adı kendi SPF, DKIM ve DMARC kayıtlarını taşır; alıcı bu kayıtlara bakarak ileti ile gönderen alan adını eşleştirir. Yani PTR "bu sunucu kim" sorusuna, diğer kayıtlar "bu ileti kimin adına" sorusuna cevap verir.

Birden fazla kayıt bazen teknik olarak mümkündür. Ancak bazı alıcılar bunu belirsizlik sayar ve ilk gördüğü kaydı kullanır. Bu nedenle e-posta gönderen IP için tek kayıt tutmak daha güvenlidir.

Sunucuyu taşıdığınızda ya da IP değiştirdiğinizde bu bilgiyi hatırlayın. Yeni IP'nin ters kaydı, eski IP'ninkiyle birlikte gelmez. Taşıma kontrol listenize "yeni IP için PTR ve A kaydı" maddesini ekleyin.

Sağlayıcıya PTR talebini nasıl yazarsınız?

Destek talebi açıyorsanız eksiksiz bilgi vermek süreyi kısaltır. Sağlayıcı çoğu zaman aynı soruları sorar; cevapları baştan yazarsanız yazışma tek mesajda biter. Talebinizde şu bilgiler bulunsun:

• Ters kaydın tanımlanacağı IP adresi (IPv4 ve varsa IPv6).
• İstediğiniz tam nitelikli ana makine adı.
• Bu adın A ya da AAAA kaydının hazır olduğu bilgisi.
• Amacın e-posta gönderimi olduğu.
• Şu anki dig -x çıktısı.

Örnek bir talep metni şöyle olabilir:

Merhaba, 203.0.113.25 adresi için ters DNS kaydını mail.example.com olarak ayarlayabilir misiniz? A kaydı hazır ve aynı IP'yi gösteriyor. Sunucu bu adresten e-posta gönderiyor.

Sağlayıcının cevabında farklı bir ad önermesi mümkündür. Bu durumda önerilen adın A kaydını eklemeyi unutmayın. Çünkü eşleşme iki tarafın birlikte doğru olmasına bağlıdır.

PTR kaydı değişikliği ne zaman devreye girer?

Yanıt, kaydın TTL değerine ve alıcıların önbelleğine bağlıdır. TTL, bir cevabın önbellekte ne kadar kalabileceğini saniye cinsinden söyler. Sağlayıcı kaydı güncellese bile bazı çözümleyiciler eski cevabı bir süre daha verebilir.

Kesin süreyi biz veremeyiz, çünkü değer sağlayıcıdan sağlayıcıya değişir. Bunun yerine şunu yapmanızı öneririz: Kaydı değiştirmeden önce, mümkünse mevcut TTL değerini sağlayıcıdan öğrenin. Değişiklikten sonra dig -x komutunu birkaç farklı çözümleyiciyle deneyin.

Ayrıca test iletisini hemen göndermeyin. Önce iki yönlü sorgunun tutarlı çıktığından emin olun, ardından deneme yapın. Böylece yarım kalmış bir yayılmanın sonucunu yanlış yorumlamazsınız.

Ters DNS e-posta dışında nerede işe yarar?

Ters DNS yalnızca e-posta için bir şey değildir. traceroute gibi birçok ağ aracı, yoldaki IP adreslerini okunur adlara çevirmek için ters sorgu yapar. Ayrıca sunucu günlüklerinde adlar, sayı dizilerinden çok daha kolay okunur.

Bir başka bilinen kullanım, tarayıcı botlarını doğrulamaktır. Google Search Central, Googlebot'un gerçekten Google'dan gelip gelmediğini anlamak için ters DNS sorgusu ve ardından ileri sorgu yapmayı anlatır. Mantık, bu yazıdaki FCrDNS ile aynıdır.

Öte yandan arama sıralaması için PTR gerekmez. Web sitenizi ziyaret eden herkes adı IP'ye çevirir, tersini sormaz. Bu yüzden yalnızca web sitesi yayınlıyorsanız, ters DNS için endişelenmenize gerek yoktur.

PTR kaydını ne zaman kendiniz yapmamalısınız?

Dürüst olalım: Birçok durumda en iyi karar, işi hosting sağlayıcınıza bırakmaktır. Aşağıdaki durumlarda kendi kendinize uğraşmayın:

• Paylaşımlı hosting kullanıyorsanız. PTR ve e-posta sunucusu sağlayıcının yönetimindedir.
• IP adresinin kime ait olduğunu bilmiyorsanız. Önce sahibini bulun.
• Üretimdeki bir e-posta sunucusunu tek başına taşıyacaksanız. Yanlış bir ayar, tüm şirket e-postalarını etkileyebilir.
• Sunucuya SSH ile bağlanmayı ve DNS kayıtlarını okumayı bilmiyorsanız.
• Sağlayıcı ters DNS ayarını yönetmenize izin vermiyorsa. Bu yüzden destek talebi açın.

Bir yazılımcı ya da sistem yöneticisi sizinle çalışıyorsa, bu yazıdaki kontrolleri ona soru listesi olarak verebilirsiniz. Web sitesi, e-ticaret ve e-posta entegrasyonlarının birlikte tasarlanması gerekiyorsa web tasarım hizmetimiz kapsamında bu konuları da ele alıyoruz.

Küçük bir işletmeyseniz ve e-posta teslimatı kritikse, harici bir e-posta servisi kullanmayı da düşünün. Çünkü bu servislerin altyapısı, ters DNS gibi ayrıntıları sizin yerinize yönetir.

PTR kaydı SPF, DKIM ve DMARC'ın yerini tutar mı?

Hayır, tutmaz. PTR sunucunun IP kimliğini, SPF hangi IP'lerin alan adı adına gönderebileceğini, DKIM iletinin imzasını, DMARC ise bu kontroller başarısız olunca alıcının ne yapacağını anlatır. Yani dört parça birlikte çalışır.

Google'ın gönderen yönergeleri de bunu yansıtır. Yönergelerde ters DNS ayrı bir madde, e-posta kimlik doğrulaması ise ayrı bir maddedir. Kısacası biri eksikse diğeri onun yerini doldurmaz.

SPF, DKIM ve DMARC ayrıntısını bu yazıda tekrar etmiyoruz. Kayıtlarınızı SPF, DKIM ve DMARC kontrol aracımızla sınayabilirsiniz. WordPress'ten e-posta gönderen siteler için WP Mail SMTP rehberimiz pratik bir başlangıçtır.

Sıralama önerimiz şöyle: önce ters DNS ve A kaydını hizalayın, ardından SPF ve DKIM'i kurun, en son DMARC politikasını sıkılaştırın. Her adımı doğrulamadan bir sonrakine geçmeyin.

PTR kaydı için son kontrol listesi nedir?

Yayına almadan önce aşağıdaki listeyi baştan sona geçin. Üstelik her madde tek bir komutla ya da tek bir panel ekranıyla doğrulanabilir.

• Gönderen IP'yi belirlediniz ve ileti başlıklarıyla doğruladınız.
• dig -x sonucu, seçtiğiniz tam nitelikli ana makine adını veriyor.
• Bu adın A ya da AAAA kaydı aynı IP'yi gösteriyor.
• PTR bir CNAME'e değil, doğrudan A kaydı olan bir ada gidiyor.
• MTA'nın EHLO adı aynı ada ayarlı.
• IPv6 üzerinden gönderiyorsanız, IPv6 için de aynı kontrolü yaptınız.
• Posta adı proxy arkasında değil.
• SPF ve DKIM kayıtlarını da sınadınız.

Bu liste kısa görünse de e-posta teslimat sorunlarının büyük kısmını önlemenize yardım eder. Hâlâ takıldığınız bir nokta varsa sağlayıcınızın desteğine yukarıdaki sorgu çıktılarıyla başvurun. Böylece çıktılar sorunu iki mesajda çözmenize yardım eder.

Bu yazı genel bilgi içindir ve hosting sağlayıcınızın kuralları öncelik taşır. Belirli bir sağlayıcıya özel ayarlarda sağlayıcınızın verdiği değerleri kullanın.