Bir e-posta spam klasörüne düştüğünde, geciktiğinde veya hiç ulaşmadığında en güvenilir bilgi kaynağı iletinin kendisidir. Her e-posta, geçtiği her sunucunun izini taşıyan bir başlık bölümü içerir.
Bu bölümü okumayı öğrenmek, teslimat sorunlarında tahmin yürütmeyi bırakıp kanıta bakmayı sağlar. Bu yazı, e-posta başlıklarının nasıl okunacağını anlatıyor.
Başlıklara Nasıl Ulaşılır?
Çoğu e-posta istemcisinde ileti üzerinden "kaynağı göster", "orijinali göster" veya "başlıkları görüntüle" seçeneği bulunur. Elde ettiğiniz metin, iletinin teknik geçmişidir.
İlk bakışta karmaşık görünür ama yapısı bellidir: en üstteki satırlar en son eklenmiştir. Yani okuma yönü aşağıdan yukarıya doğrudur — gönderenden alıcıya.
Kritik Başlıklar
| Başlık | Ne söyler |
|---|---|
| Received | İletinin geçtiği her sunucu ve zaman damgası |
| Return-Path | Zarf gönderen adresi — SPF bunu kontrol eder |
| From | Görünen gönderen — DMARC bunu kontrol eder |
| Authentication-Results | SPF, DKIM ve DMARC doğrulama sonuçları |
| DKIM-Signature | İmza bilgileri ve imzalayan alan adı |
| Message-ID | Benzersiz kimlik — log aramada kullanılır |
Teşhiste ilk bakılacak satır dördüncüsüdür. Authentication-Results, alıcı sunucunun kimlik doğrulama kontrollerinden ne sonuç aldığını tek yerde özetler.
Doğrulama Sonuçlarını Okumak
Bu başlıkta üç kontrol sonucu bulunur ve her biri farklı bir soruyu yanıtlar:
- SPF: Bu IP adresi, bu alan adı adına gönderim yapmaya yetkili mi?
- DKIM: İletinin imzası geçerli mi, içerik yolda değişmiş mi?
- DMARC: Görünen gönderen adresi, doğrulanan alan adıyla uyumlu mu?
Üçüncü madde en çok yanlış anlaşılandır. SPF ve DKIM geçse bile DMARC başarısız olabilir — çünkü DMARC, doğrulanan alan adının kullanıcıya görünen gönderen adresiyle eşleşmesini ister.
Pratik örnek: bir pazarlama platformu üzerinden gönderim yapıyorsanız, SPF doğrulaması platformun alan adı üzerinden geçebilir. Ancak kullanıcıya görünen adres sizin alan adınızsa ve aralarında uyum kurulmamışsa DMARC başarısız olur — ileti reddedilir veya spam'e düşer.
Received Satırlarıyla Gecikme Bulmak
İletiniz geç ulaştıysa, nerede beklediğini bu satırlardan bulabilirsiniz.
Yöntem basittir: her Received satırındaki zaman damgalarını karşılaştırın. İki satır arasındaki büyük fark, iletinin orada beklediğini gösterir.
Yorumlama:
- Gecikme kendi sunucunuzdaysa: Kuyruk birikmiş, kaynak yetersiz veya bir yeniden deneme yaşanmış olabilir.
- Gecikme alıcı tarafındaysa: Gri listeleme uygulanmış veya alıcı sunucu hız sınırlaması yapıyor olabilir.
- Gecikme aracı bir sistemdeyse: Güvenlik taraması veya ara sunucu işlem yapmış olabilir.
İkinci durum en yaygınıdır ve genellikle sorun değildir: gri listeleme, ilk gönderimi geçici olarak reddedip yeniden denemeyi bekler. İleti biraz gecikir ama ulaşır.
Sık Karşılaşılan Senaryolar
SPF Başarısız
Gönderen IP, alan adının SPF kaydında yetkili değil. Nedenleri: yeni bir gönderim servisi eklendi ama kayıt güncellenmedi, sunucu IP'si değişti veya kayıtta yazım hatası var.
DKIM Başarısız
İki olası neden: imza doğrulanamıyor (anahtar yanlış veya DNS kaydı eksik) ya da ileti yolda değişmiş. İkinci durum, bir ara sistemin iletiye satır eklemesiyle oluşabilir — örneğin bazı listeler veya güvenlik geçitleri.
DMARC Başarısız Ama Diğerleri Geçti
Uyum sorunu vardır. Doğrulanan alan adı, görünen gönderen adresiyle eşleşmiyordur. Üçüncü taraf servis kullanıyorsanız, kendi alan adınız adına imzalama yapacak şekilde yapılandırılmalıdır.
Hepsi Geçti Ama Spam'e Düştü
Kimlik doğrulama teslimatın yalnızca bir parçasıdır. İçerik, gönderen itibarı, alıcı davranışı ve gönderim deseni de etkilidir. Kimlik doğrulama, gerekli ama tek başına yeterli değildir.
Pratik Kullanım
Başlık analizini rutine dönüştürmek için:
- Kendinize düzenli test gönderimi yapın. Farklı sağlayıcılardaki adreslere gönderip başlıkları karşılaştırın.
- Şikâyet geldiğinde ileti kaynağını isteyin. "Ulaşmadı" bilgisi teşhis için yetersizdir; başlıklar kanıttır.
- Message-ID ile log araması yapın. Kendi sunucu loglarınızda o iletiyi bulup ne olduğunu görürsünüz.
- Değişiklik sonrası doğrulayın. DNS kaydı güncelledikten sonra bir test gönderimiyle sonucu teyit edin.
Son madde önemlidir: SPF veya DKIM kaydı değiştirdiğinizde "doğru yaptım" varsaymayın. Bir test gönderiminin başlıklarında doğrulamanın geçtiğini görün. Bu kontrol, e-posta gönderim altyapınızda yapılan her değişikliğin standart son adımı olmalıdır.
Sonuç
E-posta başlıkları, teslimat sorunlarında tahmin yürütmeyi bitiren kanıt kaynağıdır. Teşhise Authentication-Results satırından başlayın — SPF, DKIM ve DMARC sonuçlarını tek yerde verir. Gecikme araştırıyorsanız Received satırlarındaki zaman damgalarını karşılaştırın; bekleme nerede olmuşsa oradadır. Ve en çok karıştırılan noktayı hatırlayın: SPF ve DKIM geçse bile DMARC uyum nedeniyle başarısız olabilir — üçüncü taraf servisler üzerinden gönderim yapıyorsanız ilk buraya bakın.
Sıkça Sorulan Sorular (SSS)
E-posta başlıklarına nasıl ulaşırım?
Çoğu istemcide ileti üzerinden "orijinali göster", "kaynağı göster" veya "başlıkları görüntüle" seçeneğiyle. Elde ettiğiniz metinde en üstteki satırlar en son eklenmiştir; okuma yönü aşağıdan yukarıya, yani gönderenden alıcıya doğrudur.
SPF ve DKIM geçtiği hâlde DMARC neden başarısız?
DMARC, doğrulanan alan adının kullanıcıya görünen gönderen adresiyle uyumlu olmasını ister. Üçüncü taraf bir platform üzerinden gönderim yapıyorsanız SPF onların alan adı üzerinden geçebilir, ancak görünen adres sizinse uyum kurulamaz. Çözüm, servisin sizin alan adınız adına imzalayacak şekilde yapılandırılmasıdır.
İletinin nerede geciktiğini nasıl bulurum?
Received satırlarındaki zaman damgalarını karşılaştırın. İki satır arasındaki büyük fark, iletinin orada beklediğini gösterir. Alıcı tarafındaki gecikme genellikle gri listeleme veya hız sınırlamasıdır ve çoğunlukla sorun değildir.
Doğrulamalar geçtiği hâlde neden spam'e düşüyorum?
Kimlik doğrulama teslimatın yalnızca bir parçasıdır. Gönderen itibarı, içerik özellikleri, alıcı davranışı ve gönderim deseni de belirleyicidir. Doğrulama gerekli bir koşuldur ama tek başına yeterli değildir.
