E-posta Başlığı Analizi rehberi
Tam e-posta başlıklarını kopyalama, XGM E-posta Başlığı Analizi'nin gösterdiği atlamalar, gecikmeler ve kimlik doğrulama sonuçları, sahtecilik işaretleri.
E-posta başlıkları neler içerir
Bir iletiyi elden geçiren her posta sunucusu en üste bir Received başlığı ekler; bu başlıkta iletiyi kimden aldığı, kendi adı ve bir zaman damgası yer alır. Alıcı posta sunucusu ayrıca SPF, DKIM ve DMARC kontrollerinin sonucunu kaydeden Authentication-Results başlığını da ekler. İkisi birlikte, e-postanın sahip olabileceği en yakın teslim makbuzunu oluşturur. İleti gövdesi silinmiş olsa bile bu satırlar geçmişi taşımayı sürdürür; bu yüzden bir teslim sorununu ya da bir kimlik avı şüphesini incelerken bakılacak ilk yer, iletinin görünen içeriği değil, başlık bloğunun kendisidir.
Sağlayıcınızın sunucularından önce eklenen başlıkları başka sistemler yazmıştır ve bunlar uydurulmuş olabilir; buna karşılık kendi sağlayıcınızın eklediği başlıklara güvenilebilir. Bu yüzden inceleme genellikle en üstten, yani sağlayıcınızın eklediği atlamalardan başlar ve aşağı doğru ilerler. Belli bir noktadan sonra gördükleriniz artık doğrulanamaz, çünkü gönderen taraf istediği kadar Received satırı uydurabilir. Güvenilir bölümün nerede bittiğini bilmek, bir başlık yığınından çıkarılabilecek en değerli bilgidir.
Başlıkların tamamını kopyalamak
Posta istemcileri başlıkları varsayılan olarak gizler; bu yüzden "orijinal" ya da "kaynak" görünümüne ihtiyacınız olur. İlk satırdan ileti gövdesinin başladığı yere kadar her şeyi kopyalayın; gövdeyi de eklerseniz analiz aracı onu yok sayar. Eksik kopyalama en sık yapılan hatadır, çünkü üstteki birkaç satır atlanırsa kimlik doğrulama sonucu hiç görünmez. Kuşkuya düştüğünüzde kaynağın tamamını seçip yapıştırmak en güvenlisidir.
| İstemci | Menü |
|---|---|
| Gmail (web) | İletiyi açın, üç nokta menüsü → Orijinali göster |
| Outlook (web ve yeni Outlook) | İletiyi açın, üç nokta menüsü → Görünüm → İleti kaynağını görüntüle (ya da ileti ayrıntıları) |
| Apple Mail | Görünüm → İleti → Tüm Başlıklar ya da Ham Kaynak |
| Thunderbird | Görünüm → İleti Kaynağı |
Menü adları sürümden sürüme değişir, ama her büyük istemcide orijinal, kaynak ya da başlıklar diye etiketlenmiş bir seçenek bulunur. Bir iletiyi iletmek onun özgün başlıklarını korumaz; başkasının incelemesi gerekiyorsa iletiyi ek olarak iletin. Ekran görüntüsü de yeterli olmaz, çünkü inceleme için satırların metin hali gerekir. Mobil uygulamaların çoğunda bu görünüm hiç yoktur; böyle durumlarda aynı hesabı bir tarayıcıda ya da masaüstü istemcisinde açıp kaynağı oradan almak en kısa yoldur.
Analiz aracı nasıl kullanılır
- E-posta Başlığı Analizi aracını açın ve başlıkların tamamını yapıştırın.
- Özeti okuyun: From, Return-Path, Reply-To, Subject, Date ve Message-ID.
Authentication-Resultsbaşlığından alınan SPF, DKIM ve DMARC sonuçlarını kontrol edin.- Zamanın nerede harcandığını görmek için atlama zaman çizelgesini baştan sona izleyin ve listenin altındaki uyarıları okuyun.
- Ayrıştırılmış her başlığı, DKIM seçicisi (
header.s) ve imzalayan alan adı (header.d) dahil tamAuthentication-Resultssatırıyla birlikte almak için sonucu JSON olarak dışa aktarın.
Tarayıcınızdan çıkmaz
Kimlik doğrulama sonuçlarını okumak
Authentication-Results: mx.example.net;
dkim=pass header.i=@example.com header.s=s2026a header.b=AbCdEf12;
spf=pass (example.net: domain of bounce@example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=bounce@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com| Sonuç | Anlamı |
|---|---|
pass | Kontrol başarılı oldu |
fail | Kontrol başarısız oldu: yetkili değil (SPF), imza hatalı (DKIM) ya da hizalı değil (DMARC) |
softfail | SPF ~all eşleşti: yetkili değil, şüpheyle yaklaşın |
neutral / none | Kullanılabilir bir beyan yok ya da yayımlanmış bir kayıt yok |
temperror | Geçici bir DNS sorunu kontrolü engelledi |
permerror | Kayıt bozuk, örneğin sorgu sınırını aşan bir SPF kaydı |
Diğerlerini görünen From adresine bağlayan sonuç DMARC'tır. Bir ileti, gönderen hizmetin geri dönüş alan adı için spf=pass gösterip yine de DMARC'tan kalabilir, çünkü o alan adı hizalı değildir. DMARC rehberi hizalamayı anlatır, DKIM rehberi ise imza hatalarını ele alır. Bu yüzden tek bir pass değerine bakıp karar vermek yerine üç sonucu her zaman birlikte ve hangi alan adı için verildiklerine dikkat ederek değerlendirin.
Uyarılar ne anlama gelir
| Uyarı | Neden önemli |
|---|---|
| DMARC başarısız | From alan adı, hizalı bir SPF ya da DKIM sonucuyla doğrulanmamış; ileti sahte olabilir. |
| SPF fail ya da softfail | Gönderen sunucu, zarf alan adı tarafından yetkilendirilmemiş. |
| DKIM başarısız | İmza uyuşmuyor; ileti yolda değiştirilmiş olabilir. |
| Zarf göndericisi From alan adından farklı | E-posta hizmetlerinde yaygındır, ama sahtecilikte de görülür; DMARC sonucuna bakın. |
| Yanıtlar farklı bir alan adına gidiyor | Başka bir alan adındaki Reply-To yaygın bir kimlik avı örüntüsüdür. |
| Zaman damgası daha erken olan atlamalar | Bir sunucunun saati yanlış ya da başlıklar uydurulmuş. |
| Başlık bulunamadı | Özgün ileti kaynağının tamamını, başlıklardan başlayarak yapıştırın. |
Üç kimlik doğrulama sonucu da geçtiğinde ve From alan adı beklediğiniz alan adıysa, ileti neredeyse kesinlikle o alan adının posta sisteminden gelmiştir. p=reject yayımlayan bir alan adı için DMARC başarısız olduğunda ise büyük sağlayıcıların çoğu iletiyi zaten reddederdi; dolayısıyla böyle bir iletinin gelen kutusunda bulunması tek başına bildirilmeye değer. Bu durumda iletinin ham kaynağını saklayın, çünkü sonraki inceleme için elinizdeki tek kanıt odur.
Uyarılar birer sinyaldir, hüküm değil. Bülten platformları düzenli olarak kendi zarf göndericilerini kullanır, destek masaları da Reply-To adreslerini bilerek ayarlar. Uyarıları kimlik doğrulama sonuçlarıyla ve iletinin bağlamıyla birlikte değerlendirin. Göndereni tanıyorsanız, aynı kaynaktan gelen eski bir iletinin başlıklarıyla karşılaştırmak farkı çoğu zaman hemen ortaya çıkarır.
Teslim gecikmelerini bulmak
Analiz aracı ardışık atlamalar arasındaki süreyi ve ilkinden sonuncusuna kadar geçen toplam süreyi hesaplar. Saniyeler düzeyindeki bir gecikme normaldir, birkaç dakika spam filtrelemesinden ya da kuyruğa alınmadan gelebilir, saatler ise genellikle bir sunucunun geçici bir hatadan sonra yeniden denediği anlamına gelir. Gecikmenin ortaya çıktığı atlama, sorumlu sistemi işaret eder. Bu yüzden bir yavaşlık şikâyetinde önce en uzun aralığı bulun, ardından o aralığın hangi kurumların sunucuları arasında olduğuna bakın.
| Gecikmenin yeri | Olası neden |
|---|---|
| Gönderen sağlayıcının ilk atlamasından önce | İleti, göndericinin istemcisinde ya da uygulamasında kuyruğa alınmış |
| Gönderen sunucu ile alıcının MX sunucusu arasında | Alıcı iletiyi erteledi (greylisting, hız sınırları, geçici hatalar) |
| Alıcının sistemi içinde | İçerik taraması, eklerin yalıtılmış ortamda çalıştırılması ya da iç kuyruklar |
| Negatif gecikme | Sunucular arasındaki saat farkları ya da uydurulmuş başlıklar |
SSS
Başlıklarım bir yere yükleniyor mu?
Hayır. Analiz aracı tarayıcınızda çalışır ve yapıştırdığınız metin XGM'e gönderilmez.
Hangi Received başlığı ilk atlamadır?
En alttaki. Her sunucu kendi başlığını en üste eklediği için analiz aracı listeyi ters çevirir ve teslim sırasını gösterir.
Received başlıkları uydurulabilir mi?
İleti sağlayıcınıza ulaşmadan önce eklenen başlıklar gönderen tarafından uydurulabilir. Kendi sağlayıcınızın sunucularının eklediği başlıklar güvenilirdir.
SPF neden geçiyor da DMARC kalıyor?
SPF, zarf göndericisinin alan adı için geçmiştir; o alan adı From alan adıyla hizalı değildir. DMARC için hizalı bir SPF ya da DKIM geçişi gerekir.
DKIM seçicisini nasıl bulurum?
Authentication-Results içindeki header.s= değerine ya da DKIM-Signature başlığındaki s= değerine bakın. İkisi de yapıştırdığınız kaynakta ve analiz aracının JSON çıktısında bulunur.
Neden bildiğim sunuculardan daha fazla atlama var?
Büyük sağlayıcılar iletileri filtreleme, tarama ve depolama için birkaç iç sistemden geçirir ve her biri bir Received başlığı ekler. Sorun giderirken genellikle yalnızca kurumlar arasındaki atlamalar önemlidir.
Bir atlamadaki with alanı ne anlama gelir?
O atlamada kullanılan protokolü belirtir; örneğin ESMTPS (TLS ile SMTP) ya da ESMTPSA (TLS ve kimlik doğrulamayla). Düz SMTP ya da ESMTP ise o atlamanın şifrelenmediği anlamına gelir.
Kimlik doğrulama neden bulunamadı olarak görünüyor?
Başlıklar, o yöntemi içeren bir Authentication-Results satırı taşımıyor. Bazı istemciler bu satırı siler ya da yapıştırma o satırdan sonra başlamıştır; özgün kaynağın tamamını kopyalayın.
Göndericinin nerede olduğunu anlayabilir miyim?
Yalnızca kabaca. İlk dış atlama çoğu zaman gönderen sunucunun IP adresini gösterir; bunu IP Bilgisi ile sorgulayabilirsiniz, ama karşınıza çıkan genellikle kişinin değil bir posta sağlayıcısının adresidir.
Kimlik avı iletisiyle ne yapmalıyım?
Posta istemcinizdeki kimlik avı bildirme düğmesiyle ya da BT ekibinize bildirin. Başlık analizi sahteciliği doğrulamaya yardımcı olur, ama bağlantılara tıklamayın ve iletiyi yanıtlamayın.