Kısa cevap: SMTP oturumundaki sunucu adı, IP’nin PTR kaydı ve gönderen alan adının SPF/DKIM doğrulaması farklı kimlik katmanlarıdır. Bir hata mesajında bu terimlerden birinin geçmesi, diğer bütün ayarların bozuk olduğu anlamına gelmez. Doğru başlangıç, tam yanıtı ve gönderim yolunu birlikte kaydetmektir.
İleti başlığıyla SMTP oturumunu ayırın
Ekranda görünen şirket adı ile SMTP bağlantısını yapan makinenin adı aynı olmak zorunda değildir. IETF SMTP standardı, EHLO/HELO ile oturumdaki istemci tanıtımını tarif eder. Bu adın hangi yazılımdan geldiğini posta yöneticisi belirlemelidir. Outlook’un görünen ad alanını değiştirerek sunucu kimliğini düzelttiğinizi düşünmeyin. Önce e-postanın kurumsal SMTP’den mi yoksa web uygulamasından mı çıktığını öğrenin.
Bir kontrol tablosu hazırlayın
Tabloda giden IP, IP’nin reverse DNS sonucu, SMTP sunucu adı, zarf göndereni ve ileti üzerindeki From alanı ayrı satırlarda bulunsun. Gizli veya kişisel bilgileri yalnız gerekli ölçüde paylaşın. Gönderen adı ve başlık rehberi bu farkı gündelik örneklerle açıklar. Bir web sitesinin barındığı IP’nin, e-postayı gönderen IP olduğunu varsayarak destek talebi açmayın; dış SMTP hizmeti kullanılıyor olabilir.
Önce alıcının neyi reddettiğini okuyun
Geri dönen iletide kod, açıklama ve reddeden sunucu bilgisi vardır. 4xx ve 5xx rehberi geçici ve kalıcı yanıtları okumaya yardımcı olur. Mesaj açıkça reverse DNS diyorsa ilgili IP’yi inceleyin; alan adı doğrulamasına işaret ediyorsa o kaynakları değerlendirin. Bütün DNS kayıtlarını birden değiştirmek doğru ayarı da bozabilir. Yanıtın tarihi, hangi test mesajına ait olduğunu anlamak için önemlidir.
SPF ve DKIM’i kendi amacıyla değerlendirin
SPF, DKIM ve DMARC rehberindeki kayıtları mevcut gönderim hizmetlerinize göre doğrulayın. Teslimat hatası var diye aynı alan adına ikinci bir SPF kaydı eklemeyin; birden fazla SPF kaydı yazısı bu ayrı hatayı açıklar. Sunucu kimliği sorunu ile alan adı adına izin verilen gönderim kaynağı aynı yapılandırma değildir. Bir düzeltmenin diğerini otomatik çözeceğini varsaymayın.
Her düzeltmeden sonra yeni kanıt alın
Posta yöneticisi bir ayarı düzelttiğinde aynı test yolundan yeniden gönderim yapın. Yeni sonuçta eski hatanın mı başka bir kontrolün mü kaldığını inceleyin. Test için hassas müşteri verisi kullanmayın. SMTP bağlantı ayarları rehberi, istemci bağlantısını sunucular arası teslimattan ayırır. Son raporda bağlantı kuruldu, mesaj kabul edildi ve alıcıda görüldü sonuçlarını ayrı yazın; bütün aşamaları tek “gönderildi” kelimesine sığdırmayın.
Bu konunun diğer kontrolleri
- PTR ve Reverse DNS Nedir? E-posta Sunucusunda İleri ve Geri Eşleşme
- PTR Kaydını Kim Değiştirir? Paylaşımlı IP’de Neden Kendi Alan Adınızı Yazamazsınız?
Sıkça Sorulan Sorular
EHLO adı e-posta adresim midir?
Hayır. SMTP oturumunda istemci sunucunun kullandığı kimlik ile görünen gönderici adresi farklı kavramlardır. İlgili ayarı hangi posta hizmetinin yönettiğini öğrenin.
SPF kaydı eklemek PTR hatasını giderir mi?
Aynı kayıt türü değildir. Birden fazla problem birlikte bulunabilir; tam hata mesajını ve giden IP’yi incelemeden her teslimat sorununa yeni SPF kaydı eklemeyin.
Alıcı sunucu mesajı kabul ettiyse gelen kutusunda mıdır?
Kabul yanıtı ve gelen kutusuna yerleşme ayrı aşamalardır. Mesajın spam klasörüne düşmesi veya sonradan işlenmesi ayrıca değerlendirilebilir; tek sonucu bütün teslimata genellemeyin.
Destek ekibine göndereceğim test mesajında neler olmalı?
Hassas veri içermeyen kısa bir konu ve gövde kullanın. Gönderim zamanı, hangi uygulamanın kullanıldığı ve alıcıdaki tam sonuç kayda eklensin. Reddedildiyse hata kodunu kopyalayın; kabul edildiyse hangi klasörde görüldüğünü belirtin. Görünen şirket adını değiştirmek yerine teknik çıkış yolunun değişip değişmediğini kontrol edin. Aynı testin webmail ile uygulama üzerinden farklı sonuç vermesi yararlı bir ipucudur, ancak tek başına hangi kaydın yanlış olduğunu kanıtlamaz. Yorum yerine bu farkı yöneticiye iletin.