Popüler araçlar

Tema

E-posta Başlık Analizi

E-posta başlık analizi için başlıkları yapıştırın: e-postanın izlediği yolu, her atlamanın ne kadar sürdüğünü ve sağlayıcınızın SPF, DKIM ve DMARC kontrollerinin ne dediğini görün.

Tarayıcınızda okunur · yalnızca herkese açık sunucu IP'leri sorgulanır, gönderen alan adı ise siz isterseniz · hiçbir şey saklanmaz

Başlıklarınız cihazınızdan çıkmaz. Yalnızca sonucun altında listelenen IP adresleri ve alan adları sorgulanır.

Neler göreceksiniz

  • Gerçekte kimin gönderdiği, yalnızca sağlayıcınızın kendi kontrollerine göre
  • Yoldaki her sunucu, her birindeki gecikme ve TLS kullanıp kullanmadığı
  • SPF, DKIM, DMARC ve ARC ile bunların From adresiyle eşleşip eşleşmediği
  • Benzer görünen alan adları, sahte sonuçlar ve diğer işaretler, her biri kanıtıyla
  • Microsoft 365, Gmail ve SpamAssassin spam başlıklarının çözümü
  • Gmail ve Yahoo toplu gönderici kuralları, tek tıkla abonelikten çıkma dahil

E-posta başlığı nedir?

E-posta başlığı, ileti metninin üstündeki satırlar bloğudur: kimin kime, ne zaman gönderdiği ve iletiyi işleyen her sunucunun bir kaydı. Posta uygulamaları çoğunu gizler; “Orijinali göster” veya “Kaynağı görüntüle” hepsini gösterir.

Her satır bir ad, iki nokta ve bir değerden oluşur; uzun bir değer, boşlukla başlayan satırlarda devam eder (RFC 5322). Başlıklar ilk boş satırda biter. Ondan sonrası, bu aracın asla okumadığı gövdedir.

Başlıkları üç tür yazar yazar: göndericinin uygulaması (From, To, Subject, Date), yoldaki her sunucu (her biri bir Received satırı) ve sağlayıcınız (Authentication-Results, spam kararları). Yalnızca sonuncuları, güvendiğiniz biri kontrol eder.

Bülten örneği30 alan · 4,6 KB

Sağlayıcınız tarafından eklendi (Google)11 alan

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

Yoldaki sunucular tarafından eklendi (SendGrid example.org)5 alan

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

Göndericinin uygulaması tarafından yazıldı14 alan

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

boş satır: gövde burada başlar ve bu araç onu asla okumaz

Kısaltılmış: alan başına bir satır, başlıklardaki gibi numaralı. Renkler sonuçtaki gibi: sağlayıcınız, yoldaki sunucular, gönderen.
Taklit PayPal iletisi için e-posta başlık analizi sonucu: karar, bulgular ve 41 dakikalık boşluklu teslim yoluTaklit PayPal iletisi için e-posta başlık analizi sonucu: karar, bulgular ve 41 dakikalık boşluklu teslim yoluKararKimin gönderdiği, yalnızca sağlayıcınızın yazdığı Authentication-Results'a göre, kontrolü yapan sunucuyla birlikte.Dikkat çekenlerHer bulgu; önem derecesi, nedeni ve geldiği tam başlık satırıyla.Teslim yoluDate başlığından gelen kutusuna kadar her sunucu; boşluklar ölçekli, üzerinden geçen güven sınırı çizili.OlgularTeslimin ne kadar sürdüğü, kaç atlama olduğu, dış atlamaların tamamının TLS kullanıp kullanmadığı ve Microsoft'un hangi klasörü seçtiği.
Şüpheli örnek: Microsoft 365'in kendi kontrolleri göndereni doğrulamıyor, bulgular kanıtı gösteriyor ve yol, iletinin nerede beklediğini ortaya koyuyor. Her bölümün neyi gösterdiğini görmek için bir numara seçin.

E-posta başlık analizi: başlıklar alttan üste nasıl okunur

E-posta başlıklarını analiz etmek için Received satırlarını alttan üste doğru okuyun. Her sunucu satırını zaten orada olanların üstüne ekler; bu yüzden en alttaki ilk atlamadır, en üsttekisi ise sağlayıcınızın iletiyi posta kutusuna vermesidir (RFC 5321 §4.4).

Bir satır, kimin aldığını (by), hangi sunucudan ve adresten geldiğini (from, bağlantıda görülen adres), nasıl geldiğini (with: ESMTPS STARTTLS, ESMTPSA ise STARTTLS artı oturum açma anlamına gelir) ve ne zaman geldiğini söyler. Sunucular kendi yerel saatlerini damgalar, bu yüzden çıkarma yapmadan önce her birini UTC'ye çevirin: 07:02:47 -0700, 14:02:47 UTC'dir.

Yalnızca sağlayıcınızın yazdığı satırlar kesindir. Onun ilk satırının altındaki her şey kontrol edemediğiniz sunuculardan gelir ve bir gönderen kendi satırlarını ekleyebilir.

Başlıkta · en yenisi üstte

Yolculuk · önce atlama 1

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Google dahili14:02:48 UTC+1 sn
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33 sn

Güven sınırı

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3SendGrid filtresi14:02:13 UTC+0,6 sn
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2,9 sn
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTCilk

Yukarı doğru okuyun: her sunucu satırını en üste ekler

Bültenin beş Received satırı. Atlama 1 bülten uygulamasıdır; SendGrid ile Google arasındaki 33 sn en büyük boşluktur.

E-posta başlıklarında SPF, DKIM ve DMARC

SPF, gönderen sunucunun zarf alan adı (Return-Path) adına göndermesine izin olup olmadığını sorar. DKIM, bir alan adının iletiyi imzalayıp imzalamadığını ve imzanın hâlâ eşleşip eşleşmediğini sorar. DMARC ise geçen bir SPF veya DKIM alan adının gördüğünüz From adresiyle eşleşip eşleşmediğini sorar.

Sağlayıcınız yanıtları Authentication-Results'a yazar. Sağlayıcınızın kendi Received satırının yanına yazdığı bloğa güvenin. Diğer kopyaları, ARC kopyalarını ve göndericinin satırları arasında duranları herkes ekleyebilir (RFC 8601).

Geçti sonucu alan adını kanıtlar, niyetini değil: examp1e.com kendi adına üçünü de geçebilir.

Authentication-Results, parça parçabülten · ardından şüpheli örnek
Authentication-Results: mx.google.com;1

Kim kontrol ettiauthserv-id: sağlayıcınızın kendi sunucusu

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM: example.org imzaladıanahtarı s1._domainkey.example.org konumunda

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

İkinci bir imzagönderim hizmetinin kendi imzası; example.org ile hizalanamaz

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF: sendgrid.net adına göndermesine izin varzarf (Return-Path) alan adı, From değil

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC: From alan adı ② ile eşleşiyorp=quarantine, example.org alan adının alıcılardan başarısızlıklarda yapmasını istediği şeydir

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001SayıldıMicrosoft 365 yazdı, eklediği ilk Received satırının üstünde.

Güven sınırı

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100Yok sayıldıMicrosoft adını veriyor ancak her Received satırının altında duruyor: iletinin içinde geldi. Alıcı oraya asla yazmaz.
Çizginin altında: şüpheli örneğin iki Authentication-Results'ı. Hangisinin sayılacağını konum belirler.

Bu e-posta gerçek mi, sahte mi?

Başlıklar bir teklifin dürüst olup olmadığını söyleyemez, ancak From alan adının iletiyi gerçekten gönderip göndermediğini ve başkasını taklit edip etmediğini gösterir. Sağlayıcınızın yazdığı kararla başlayın, ardından şu işaretlere bakın.

Hiçbiri tek başına kimlik avını kanıtlamaz ve yaygın farkların birçoğu normaldir. Microsoft, benzer görünen bir alan adının sahibi ayarlamışsa SPF, DKIM ve DMARC'ı geçebileceğini belirtir (Microsoft).

  • Benzer görünen bir From alan adıYüksek

    paypa1-billing.examplekarşıpaypal.com

    Bir rakam ya da benzer bir harf değiştirilmiş. Kendi adına SPF, DKIM ve DMARC'ı geçebilir.

  • Başka bir alfabeden harflerYüksek

    xn--pypal-4ve.exampleşöyle görünürpаypal.example

    Buradaki а Kiril harfidir. Başlıklar xn-- biçimini (punycode) korur ve bu, durumu ele verir.

  • Sağlayıcınız başarısız diyorYüksek

    compauth=fail reason=001 · spf=softfail

    Alıcı, From alan adını iletiyi gönderen sunucuyla ilişkilendiremedi.

  • Başka bir adres taşıyan adOrta

    "accounts@example.com" <notice@mailer.example>

    Uygulamalar adresi değil, adı gösterir. Gerçek gönderen köşeli parantezlerin içindedir.

  • Filtrenin kendi kararıOrta

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft bunu kimlik avı olarak sınıflandırdı ve Gereksiz klasörüne koydu; 9.25 ilk temas ipucudur.

  • Çizginin altındaki geçti sonuçlarıOrta

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    Her Received satırının altına yazılmış, yani gönderen yazmış. Yalnızca sağlayıcınızınkiler sayılır.

Normal, tek başına tehlike işareti değil

  • Return-Path, From'dan farklı

    sendgrid.netkarşıexample.org

    E-posta hizmetleri sizin adınıza gönderir; eşleşmeyi DKIM sağlar.

  • Reply-To, From'dan farklı

    Reply-To: support@example.org

    Yanıtlar bir destek masasına gider. Yalnızca o alan adı başkasını taklit ediyorsa bakmaya değer.

  • Geriye giden bir zaman

    09:47:12 → 09:47:11 (−1 sn)

    Her sunucu kendi saatini damgalar ve saatler bir saniye veya daha fazla farklı olabilir.

  • Başka bir ülkedeki sunucu

    CTRY:US · 209.85.208.54

    Bu, sunucunun bulunduğu yerdir, kişinin değil. Büyük sağlayıcılar her yerden gönderir.

Şüpheli örnekten ve uydurma varyantlardan işaretler. Hiçbiri tek başına kimlik avını kanıtlamaz.

E-postam neden gecikti?

Her Received zamanını, UTC cinsinden, üstündekinden çıkarın. En büyük boşluk, iletinin nerede beklediğini gösterir. 30 dakika veya daha uzun bir boşluk, yeniden denemeyle tutarlıdır (RFC 5321 en az 30 dakika beklenmesini önerir).

Date başlığı göndericinin cihazından gelir; bu yüzden Date'ten ilk sunucuya kadar geçen süre, geri kalan bir saati veya gönderilmeden çok önce yazılmış bir taslağı da içerir. İki sunucunun saati farklı olduğunda zamanlar bir saniye geriye de gidebilir.

Hiçbir standart, ne kadarın çok uzun olduğunu söylemez.

Şüpheli örnekzamanlar UTC
Date başlığı09:05:44 UTC
+7 sn
mail.paypa1-billing.example09:05:51 · ilk sunucu
41 dk 21 sn≥ 30 dk: yeniden deneme

Microsoft 365

  • 09:47:12uç sunucu, ilk satır
  • 09:47:11dahili · −1 sn
  • 09:47:13posta kutusu sunucusu
  1. 09:05:44Date başlığıgöndericinin saati
  2. +7 sn
  3. 09:05:51mail.paypa1-billing.exampleilk sunucu
  4. 41 dk 21 sn≥ 30 dk: yeniden denemeyle tutarlı
  5. 09:47:12Microsoft 365 uç sunucusuMicrosoft sağlayıcısının yazdığı ilk satır
  6. −1 snsaatler farklı
  7. 09:47:11Microsoft dahili
  8. +2 sn
  9. 09:47:13Microsoft posta kutusu sunucusu
Date başlığından
41 dk 29 sn
ilk sunucudan
41 dk 22 sn
Bülten örneği · 44 snzamanın nereye gittiği
  • Date → ilk sunucu 6 sn
  • SendGrid'e giriş 2,9 sn
  • SendGrid filtresi 0,6 sn
  • SendGrid → Google, en büyük boşluk 33 sn
  • Google içinde 1 sn

Microsoft 365 ve Gmail spam başlıkları, çözümlenmiş

Microsoft 365, filtresinin kararını X-Forefront-Antispam-Report içine yazar: CAT karardır, SFV spam filtrelemenin nasıl karar verdiğidir ve X-Microsoft-Antispam-Mailbox-Delivery hangi klasöre gittiğini söyler.

SCL hâlâ yazılır, ancak Microsoft artık Microsoft 365'te hiçbir şeye karar vermediğini söyler: bunun yerine CAT'i okuyun (Microsoft). BCL, toplu e-postaları şikâyetlere göre 0 ile 9 arasında puanlar ve politikanızın eşiği (varsayılan 7) karar verir.

Gmail belgelenmiş bir spam kararı yazmaz. SpamAssassin çalıştıran sunucular, puanı, eşiği ve tetiklenen kuralları içeren X-Spam-Status ekler.

X-Forefront-Antispam-Reportşüpheli örnek
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH karar: kimlik avı (SPM spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM spam filtreleme bunu spam olarak işaretledi (NSPM: spam değil)
  3. 3SCL:5 filtrelemeye bir girdi, Microsoft 365'te karar değil
  4. 4SFTY:9.25 ilk temas güvenlik ipucu gösterildi
  5. 5IPV:NLI IP hiçbir itibar listesinde yok
  6. 6DIR:INB gelen; SFS ve ARA Microsoft'un dahili tanılamalarıdır

Toplu şikâyet düzeyiBCL:0

01–3 az4–7 karışık8–9 çok

Eşikler: 5 strict, 6 standard, 7 varsayılan; bu değerde veya üzerinde toplu sayılır.

Nereye gittidest:J

Gereksiz E-postaX-Microsoft-Antispam-Mailbox-Delivery

dest:I gelen kutusudur. ucf, jmr ve ENG dahilidir.

Gmail ve SpamAssassin

Gmail belgelenmiş bir spam kararı yazmaz: X-Received, X-Google-Smtp-Source ve X-Gm-* dahilidir.

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin: yalnızca gereken puanda veya üzerinde spam.

Şüpheli örnekteki her değer, Microsoft'un anti-spam başlık tablolarıyla okundu.

E-posta başlığı nasıl görülür: Gmail, Outlook, Apple Mail ve diğerleri

Tam başlıkları veya özgün iletinin tamamını bir bilgisayardan ya da web tarayıcısından kopyalayın. Ardından yukarıya yapıştırın veya iletiyi .eml dosyası olarak kaydedip yükleyin.

Her uygulama bunları farklı bir menüye gizler. Kendinizinkini seçin: adımlar her sağlayıcının kendi yardım sayfasını izler.

  1. 1E-postayı açın
  2. 2Diğer ⋮
  3. 3Orijinali göster
  4. 4Panoya kopyala

Kaynak: support.google.com/mail/answer/29436

Telefonda mısınız? Gmail, Outlook ve Apple Mail uygulamaları tam başlıkları göstermez. İletiyi bir tarayıcıda (Gmail, web üzerinde Outlook) veya masaüstü uygulamasında açın ya da ek olarak iletip .eml dosyasını buraya yükleyin.

E-posta nasıl izlenir ve bir IP size neyi söyler, neyi söylemez

Bir e-postayı izlemek için sağlayıcınızın yazdığı ilk Received satırındaki from adresini alın: iletiyi teslim eden sunucu. Kime ait olduğunu sorgularsanız, o sunucunun kime ait olduğunu öğrenirsiniz; bu, özgün gönderen yerine bir yönlendirici olabilir.

Başlıklar posta sunucularını gösterir ve göndericinin kendi ağını yalnızca bazen, X-Originating-IP içinde gösterir.

O adres bile bir ağı ve kabaca bir ülkeyi gösterir, asla bir kişiyi veya bir sokağı değil.

Gmail → Outlook örneğitarayıcınızdan sorgulandı
Ana'nın bilgisayarıbaşlıklarda yok
209.85.208.54mail-ed1-f54.google.com
Microsoft 365yazdığı ilk Received satırı

209.85.208.54 size ne söyler

Sahip
Google LLC · 209.85.128.0/17 (ARIN)
Ülke
Amerika Birleşik Devletleri, sunucunun bulunduğu yer
Rol
bir Gmail gönderen sunucusu, SPF'nin kontrol ettiği

Size neyi söylemez

Kim
Ana veya example.net'teki herhangi biri
Nerede
şehri veya sokağı
Cihaz
bilgisayarı veya telefonu
Analiz aracı yalnızca sunucuların herkese açık adreslerini, kendi kayıtlarında sorgular ve neyi sorduğunu tam olarak gösterir.

E-posta başlıkları: sorular ve yanıtlar

E-posta başlık analizi nasıl yapılır?

Tam başlıkları posta uygulamanızdan kopyalayın, yukarıya yapıştırın ve Başlıkları analiz et'i seçin. E-posta başlık analizi bunları alttan üste okur: sağlayıcınızın yazdığı karar, sunucu sunucu yol ve her birindeki gecikme, bir de kanıtlarıyla bulgular.

E-posta başlıklarını buraya yapıştırmak güvenli mi?

Başlıklar tarayıcınızda okunur ve bize hiçbir zaman gönderilmez. Yalnızca herkese açık sunucu IP'leri sorgulanır: sahipleri kayıtlarda (RDAP, tarayıcınız sorar) ve ülkeleri kendi sitemizden alınan DB-IP dosyalarında; yani sunucumuz hangi adres aralığının sorulduğunu görür. Gönderenin alan adı yalnızca siz isterseniz dns.google'da sorgulanır. Başlıklar adresler ve sunucu adları içerir, bu yüzden dikkatle paylaşın.

E-posta başlıkları sahte olabilir mi?

Evet: iletiyi sağlayıcınız almadan önce yazılan her şey. Her sunucu kendi satırını en üste ekler; bu yüzden gönderici altlara sahte Received satırları ve hatta pass diyen sahte bir Authentication-Results koyabilir. Güvenebileceğiniz kısım, sağlayıcınızın en üstteki kendi satırları ve yanlarına yazdığı sonuçlardır; analiz aracı geri kalanını iddia olarak gösterir.

Bir e-postanın sahte olup olmadığını nasıl anlarım?

Sağlayıcınızın Authentication-Results'ıyla başlayın: Microsoft 365'te bir DMARC fail ya da compauth fail, From alan adının doğrulanmadığı anlamına gelir. Ardından alan adının kendisini okuyun: paypa1-billing.example gibi benzer görünen bir alan adı kendi adına her kontrolü geçebilir. Son olarak yanıtların nereye gittiğine ve iletiyi hangi sunucunun teslim ettiğine bakın; analiz aracı her bulguyu kanıtıyla listeler.

Bir e-postadan göndericinin IP adresini bulabilir miyim?

İletiyi sağlayıcınıza teslim eden sunucuyu bulabilirsiniz: sağlayıcınızın ilk Received satırındaki from adresi, yani SPF'nin kontrol ettiği adres. Bu genellikle bir posta sunucusudur, kişinin bilgisayarı değil. Bazı sağlayıcılar ayrıca genellikle göndericinin cihazı ya da ağı olan X-Originating-IP ekler; o bile bir ağı ve kabaca bir ülkeyi gösterir, asla bir kişiyi değil.

Gmail neden göndericinin IP adresini göstermiyor?

Gmail'in web arayüzünden ve uygulamalarından gönderilen iletiler genellikle yalnızca Google'ın sunucularını taşır: ilk Received satırının from kısmı yoktur, bu yüzden göndericinin kendi adresi başlıklarda bulunmaz. Görebildiğiniz adres, iletiyi devreden Google sunucusuna, yani SPF'nin kontrol ettiğine aittir; bu yüzden sorgu, sahip olarak göndericinin ağını değil Google'ı gösterir.

SPF geçti, peki DMARC neden başarısız oldu?

SPF, gördüğünüz From'dan farklı olabilen zarf alan adını (Return-Path) kontrol eder. DMARC, SPF veya DKIM'in From ile eşleşen, tam olarak ya da aynı kuruluş içinde bir alan adı için geçmesini ister; geçen alan adı başkasınınsa, örneğin bir e-posta hizmetinin geri dönüş alan adıysa, DMARC başarısız olur. From alan adının DKIM imzası tek başına DMARC'ı geçirir.

Atlamalar arasındaki negatif gecikme ne anlama gelir?

Sonraki bir sunucu, öncekinden daha erken bir zaman damgaladı. Her sunucu zamanı kendi saatinden yazar ve bu saatler farklı olabilir; bu yüzden analiz aracı bir gecikme değil, saat farkı gösterir. Sağlayıcınızın yazdıklarının altındaki satırlardaki zamanlar da sahte olabilir, bu yüzden sıralarını ve aralarındaki süreleri iddia olarak değerlendirin.

SCL ve BCL ne anlama gelir?

İkisi de Microsoft 365'in spam karşıtı başlıklarındaki puanlardır. BCL, toplu e-postaları şikâyet düzeyine göre 0 (toplu gönderici değil) ile 9 arasında puanlar. SCL hâlâ yazılır, ancak Microsoft 365'te filtrelemeye bir girdidir, karar değildir: kararı CAT taşır, SFV ise istenmeyen posta filtrelemesinin iletiye nasıl davrandığını söyler.

E-posta başlıkları BCC alıcılarını gösterir mi?

Hayır. Gizli kopyalar başlıklara asla yazılmaz: gönderen sunucu bunları zarftan teslim eder, To ve Cc satırları ise yalnızca görünen alıcıları gösterir. Bir Received satırındaki for ifadesi tek bir alıcıyı adlandırabilir; bu yüzden sunuculardan onu dikkatle kullanmaları istenir. Delivered-To ayrıca iletinin ulaştığı posta kutusunu gösterebilir.

Bu, Microsoft'un Message Header Analyzer aracıyla aynı mı?

Hayır. Microsoft'un Message Header Analyzer aracı, bir iletinin başlıklarını çözen bir Outlook eklentisi ve web sayfasıdır. Bu araç aynı Microsoft başlıklarını ve ayrıca Gmail'inkileri, SpamAssassin'inkileri ve her atlamanın izini okur, hangi sonuçlara güvenileceğine bulundukları yere göre karar verir ve tamamen tarayıcınızda çalışır.

Neden birden fazla Authentication-Results başlığı var?

Bir iletiyi kontrol eden her sunucu bir tane ekleyebilir ve göndericiler sahtelerini ekleyebilir, bu yüzden bir iletide çoğu zaman birkaç tane bulunur. Yalnızca sağlayıcınızın yazdığı sayılır: en üstte, kendi Received satırının yanında, kendi sunucusunun adını taşıyan. ARC-Authentication-Results, bir yönlendiricinin mühürlediği sonuçlardır; böylece sonraki sunucu, yönlendirme iletiyi değiştirmeden önce neyin geçtiğini görebilir.

Diğer e-posta araçları