Sık sorulan sorular

echo.email her adres için tek bir e-postayı analiz eder ve sonucu açıklar. Aşağıdaki yanıtlar, hizmetin nasıl çalıştığını ve rapordaki her kontrolün ne anlama geldiğini açıklar.

echo.email nasıl çalışır?

Ana sayfa, power.file.tube@echo.email gibi üç kelimeden oluşan yeni bir adres oluşturur. Bu adrese gönderilen bir ileti, echo.email e-posta sunucusuna ulaşır. Sunucu SMTP görüşmesini kaydeder ve iletiyi analize aktarır. Birkaç saniye sonra sayfa, kimlik doğrulama, içerik, kurallara uyum ve teslimat hakkında bir rapor gösterir. Hiçbir şey yüklemeniz gerekmez ve hesap sistemi yoktur.

Adres ne kadar süre geçerli kalır?

Adres, sayfa açık kaldığı sürece etkin kalır. Sayfa iki saniyede bir sunucuyla iletişim kurar. Sayfayı 10 dakika içinde yenilerseniz aynı sekmede aynı adresi korursunuz. Sayfa 10 dakikadan uzun süre kapalı kalırsa e-posta sunucusu bu adrese gelen yeni iletileri kalıcı bir hatayla reddeder.

Yalnızca ilk gelen ileti dikkate alınır. Aynı adrese gelen sonraki iletiler reddedilir, böylece her rapor tam olarak bir e-postaya karşılık gelir. 10 MB’tan büyük iletiler SMTP görüşmesi sırasında reddedilir.

Raporlar ne kadar süre saklanır?

Her rapor, saklanan ileti ve indirilen görsellere ait veriler, ileti geldikten 24 saat sonra otomatik olarak silinir. Bu 24 saat boyunca rapor bağlantısı, bağlantıya sahip olan herkes için çalışır. Bu süreden sonra bağlantı çalışmaz. Tek istisna örnek rapordur, çünkü bu rapor özel olarak gönderilmiş bir test iletisinden gelir.

İleti içeriğine ne olur?

echo.email iletinin tamamını, yani başlıkları, gövdeyi ve ekleri, SMTP oturumu verileriyle birlikte saklar. Bu veriler arasında gönderen IP adresi, HELO adı ve TLS sürümü bulunur. Veriler AB içinde kalır ve e-posta sunucusu Almanya’nın Falkenstein şehrinde çalışır. Rapor bağlantısına sahip olan herkes iletinin tamamını görür, bu yüzden paylaşabileceğiniz içerikle test etmeniz en iyisidir. Bültenlerde çoğu zaman izleme bağlantıları ve tek bir alıcıya bağlı bir abonelik iptal bağlantısı bulunur. Bir test listesine kopya gönderirseniz bu bağlantılar gizli kalır.

İki adres doğrudan hizmet işletmecisine ulaşır: sorular ve kötüye kullanım bildirimleri için contact@echo.email, veri talepleri için privacy@echo.email. Tüm ayrıntılar gizlilik politikasında yer alır.

SPF kontrolü neyi test eder?

SPF, return path içindeki bir alan adıyla e-posta göndermesine izin verilen sunucuları listeler. echo.email zarf göndericisinin (MAIL FROM adresi, return path olarak da bilinir) alan adını alır ve bu alan adının SPF kaydını, iletiyi teslim eden sunucunun IP adresi için değerlendirir. Yalnızca pass sonucu iyi kabul edilir. Softfail, neutral veya none durumunda alıcının elinde gönderen için SPF kanıtı olmaz.

HELO adı kontrol edilmez. Büyük e-posta sağlayıcıları da toplu e-postada SPF’yi değerlendirirken aynı şekilde davranır. Rapor, yol boyunca her kaydı ve her mekanizmayı gösterir. Böylece nihai sonuca nasıl ulaşıldığı görülebilir.

DNS sorgularının sayısı neden önemlidir?

Bir SPF değerlendirmesi en fazla 10 DNS sorgusu yapabilir. include, a, mx, ptr, exists ve redirect mekanizmaları bu sınıra dahildir. İç içe include’lardakiler de sayılır. Sınırın aşılması sonucu kalıcı bir hataya dönüştürür ve alıcılar iletiyi hiç geçerli SPF’si yokmuş gibi değerlendirir. Boş sorguların, yani kayıt döndürmeyen sorguların, ayrıca iki sorguluk bir sınırı vardır. Bunun olağan nedeni üçüncü taraf include’larından oluşan uzun zincirlerdir. Hizmet listesini kısaltmak sorunu çözer.

DKIM neyi kanıtlar?

DKIM, ileti başlıklarına kriptografik bir imza ekler. İmzalayan alan adı, ortak anahtarı DNS’te bir seçicinin altında yayımlar. echo.email anahtarı alır ve imzayı başlıklar ve gövde geldiği haliyle doğrular. Pass sonucu, imzalı bölümlerin değişmeden geldiği ve imzalayan alan adının bu bölümlerin sorumluluğunu üstlendiği anlamına gelir.

Rapor, imzalayan alan adını (d=), seçiciyi (s=), imzalı başlıkları (h=) ve anahtarın türünü ve boyutunu gösterir. Gövde uzunluğu sınırı (l=) işaretlenir, çünkü bu sınır imzadan sonra içerik eklenmesine izin verir.

DMARC nedir?

DMARC, SPF ve DKIM’i görünen From adresinin alan adına bağlar. From alan adı _dmarc.<domain> adresinde bir politika yayımlar. Bu politika alıcılara kimlik doğrulamadan geçemeyen e-postayı nasıl işleyeceklerini söyler: none, quarantine veya reject. SPF veya DKIM, From alan adıyla hizalı bir alan adı için başarılı olduğunda ileti DMARC’tan geçer.

DMARC kendi başına kimlik doğrulama eklemez. Değeri, hizalama gereksiniminde ve alıcıların alan adı sahibine gönderdiği toplu raporlarda (rua=) yatar.

Hizalı ne demektir?

Hizalama, kimliği doğrulanmış bir alan adını From alan adıyla karşılaştırır. Esnek hizalama aynı kurumsal alan adını gerektirir, bu yüzden mail.example.com, example.com ile hizalanır. Katı hizalama tam olarak aynı sunucu adını gerektirir. Kurumsal alan adı Public Suffix List’ten gelir. Bu liste, example.co.uk gibi adların tek bir kaydedilebilir alan adı sayıldığını bilir. Rapor başka bir açıklama olmadan hizalı dediğinde karşılaştırma From alan adıyla yapılmıştır.

BIMI nedir?

BIMI, e-posta sağlayıcılarının kimliği doğrulanmış iletilerin yanında göstermesi için bir marka logosu yayımlar. Kayıt default._bimi.<domain> adresinde bulunur ve bir SVG logoya (l=), sağlayıcıların çoğu için de bir Verified Mark Certificate’e (a=) işaret eder. BIMI yalnızca DMARC politikası uygulanan alan adları için geçerlidir. Bu politika yüzde 100 oranında quarantine veya reject olmalıdır. echo.email kaydı ve DMARC politikasının bu gereksinimi karşılayıp karşılamadığını gösterir.

Ters DNS neden önemlidir?

E-posta gönderen her IP adresinin bir sunucu adına işaret eden bir PTR kaydına ihtiyacı vardır. Bu adın da aynı IP adresine geri işaret eden bir A veya AAAA kaydına ihtiyacı vardır. Bu gidiş dönüş kontrolüne forward-confirmed reverse DNS veya kısaca FCrDNS denir. Büyük e-posta sağlayıcıları FCrDNS’i bir gönderen sunucu için asgari koşul olarak görür ve PTR kaydı olmayan bir IP adresinden gelen e-posta çoğu zaman hemen reddedilir.

Genel ters DNS nedir?

Bazı PTR kayıtları, internet sağlayıcısının bir adlandırma düzenini izler. Örneğin 192-0-2-10.dynamic.example.net. Bu tür adlar ev bağlantısını veya kimsenin e-posta için yapılandırmadığı bir sunucuyu akla getirir ve filtreler bu adlara şüpheyle bakar. mail.example.com gibi gönderenin alan adındaki özel bir ad, bilerek yapılandırılmış bir e-posta sunucusunu gösterir.

Hangi HELO adı en iyi sonucu verir?

Gönderen sunucu, SMTP görüşmesinin başında kendini bir HELO veya EHLO adıyla tanıtır. İyi bir ad gönderen sunucuya aittir, DNS’te çözümlenir ve gönderen IP adresinin PTR kaydıyla eşleşir. Adı olmayan IP adresleri, localhost gibi adlar ve rastgele karakter dizileri kötü amaçlı yazılımlarda ve snowshoe spam’de sık görülür. Filtreler bunu hesaba katar.

TLS neden kontrol edilir?

Fırsatçı TLS, alıcı sunucu STARTTLS sunduğunda SMTP görüşmesini şifreler. echo.email her bağlantıda STARTTLS sunar ve gönderenin seçtiği TLS sürümünü ve şifreleme paketini kaydeder. TLS olmadan gönderilen e-posta iki sunucu arasında düz metin olarak iletilir. Google ve Yahoo toplu gönderenlerden TLS ister. Rapor, düz http üzerinden yüklenen bağlantıları ve görselleri de sayar, çünkü bu istekler de şifresiz iletilir.

IPv6 neden kontrol edilir?

Bir iletinin IPv6’ya hazır olup olmadığını iki soru belirler. Birinci soru, gönderenin yalnızca IPv6 kullanan e-posta sunucularına ulaşıp ulaşamadığıdır. IPv6 üzerinden gelen bir ileti bu soruya doğrudan evet yanıtı verir. IPv4 üzerinden gelen bir ileti de şu koşullarda IPv6 uyumlu sayılır: gönderen sunucunun bir AAAA kaydı vardır, bu IPv6 adresinin ters DNS kaydı aynı sunucuya işaret eder ve SPF bu adres için başarılıdır. E-posta sunucularının çoğu her bağlantıda IPv4 veya IPv6 seçer, bu yüzden aynı sunucudan gelen bir sonraki ileti çoğu zaman IPv6 üzerinden gelir. İkinci soru, iletideki görselleri ve bağlantıları sunan her sunucunun bir AAAA kaydı olup olmadığıdır. Böylece yalnızca IPv6 kullanan bir ağdaki veya operatör NAT’ı (CGNAT) arkasındaki bir okuyucu da içeriği yükleyebilir. İki yanıt da evet olduğunda rapor iletiyi IPv6’ya hazır olarak işaretler.

E-posta boyutu nasıl ölçülür?

E-posta boyutu, iletildiği haliyle bayt sayısıdır: tüm başlıklar, her MIME bölümü, ekler ve base64 veya quoted-printable kodlamasının getirdiği ek yük. Gmail, yaklaşık 102 KB’tan fazla HTML içeren iletileri keser ve geri kalanını bir bağlantının arkasına gizler. Kesilen bölümde çoğu zaman abonelik iptal bağlantısı ve izleme pikseli bulunur.

Görsel boyutu nedir?

Görsel boyutu, <img> etiketlerinde başvurulan uzak görsellerin toplam boyutudur ve her görsel bir kez indirilerek ölçülür. Bu sayı bir alt sınırdır, çünkü srcset özniteliklerindeki görseller ve CSS arka planları sayılmaz. Büyük bir ileti mobil bağlantılarda yavaş yüklenir ve okuyucunun veri kotasını harcar.

Görsellerdeki fazlalık nedir?

Görsellerdeki fazlalık, gönderenin her görseli iletide gösterildiği boyuta daha yakın sunarak tasarruf edeceği bayt miktarının tahminidir. Görüntülenen boyutun en fazla iki katı olan bir görsel sıfır fazlalık sayılır, çünkü yüksek yoğunluklu ekranlar ek pikselleri kullanır. Görüntülenen boyutun iki katının üzerinde ek pikseller ayrıntı eklemeden bayt ekler. Ara boşluk görselleri gibi 1 KB’tan küçük görseller hesaba katılmaz.

echo.email görselleri nasıl işler?

Analiz her uzak görseli bir kez indirir ve HTTP durumunu, yönlendirmeleri, boyutu, içerik türünü ve piksel cinsinden ölçüleri kaydeder. Ardından bu ölçüleri HTML’de belirtilen boyutla karşılaştırır. Bir görseli indirmek, okuyucu iletiyi açtığında e-posta programının yaptığı işin aynısıdır. Bu yüzden açılma takibi bir açılma kaydeder. İndirmeler Cloudflare ağından yapılır ve özel veya dahili adreslere yönelik istekler reddedilir.

Bağlantılar HTML’den çıkarılır ve sunucuya göre gruplanır. Sorgu parametreleri kolay okunsun diye çözülür. echo.email sıradan bağlantıları asla açmaz, çünkü bir bağlantıyı açmak bir aboneliği onaylayabilir, bir işlemi başlatabilir veya bir tıklama kaydedebilir. Tek istisna, aşağıda açıklanan tek tıkla abonelik iptal URL’sidir.

List-Unsubscribe nedir?

List-Unsubscribe, RFC 2369’da tanımlanan bir başlıktır. Başlık, listeden ayrılmak için bir veya daha fazla yol içerir. Örneğin bir mailto: adresi, bir https: URL’si veya ikisi birden. E-posta sağlayıcıları bu başlığı kullanarak gönderen adının yanında kendi abonelik iptal düğmelerini gösterir. Düz http URL’leri eskimiştir ve beklenen https’tir.

Tek tıkla abonelik iptali nedir?

RFC 8058, sabit değeri List-Unsubscribe=One-Click olan ikinci bir başlık ekler: List-Unsubscribe-Post. İki başlık da olduğunda e-posta sağlayıcısı https URL’sine bir POST isteği gönderir ve alıcı hiçbir sayfayı ziyaret etmeden listeden çıkar. Google ve Yahoo toplu gönderenlerden tek tıkla abonelik iptali ister.

echo.email aynı POST isteğini gönderir ve yanıtı gösterir. Her 2xx durumu başarılı sayılır. Bu istek yalnızca geçici echo.email adresinin aboneliğini sonlandırır.

Etkileşimsiz abonelik iptali ne demektir?

Etkileşimsiz abonelik iptali, alıcı bir tarayıcı açmadan veya bir şey onaylamadan tamamlanır. Tercih edilen yöntem RFC 8058’deki one-click yöntemidir. List-Unsubscribe içindeki bir mailto: adresi de sayılır, ancak e-postayla abonelik iptali daha yavaştır ve alıcıya onay vermez. Bu yüzden sağlayıcılar mailto’yu yedek yöntem olarak görür.

İleti içinde neden yine de bir abonelik iptal bağlantısı gerekir?

Çoğu ülkedeki pazarlama yasaları, iletinin kendisinde listeden ayrılmanın görünür bir yolunu ister. Bu genellikle alt bilgideki bir bağlantıdır. Başlıklar e-posta sağlayıcısına, alt bilgideki bağlantı ise okuyucuya hizmet eder. echo.email, abonelik iptal metni içeren bir bağlantı veya abonelik iptal bağlantısına benzeyen bir URL arar. Bu tespit sezgiseldir ve bazen yanlış bağlantıyı seçer. Alt bilgideki bağlantıya özel bir izleme parametresi eklemek, gönderenin istatistiklerinde alt bilgiden ve başlıktan yapılan abonelik iptallerini ayırt etmeyi sağlar.

List-Id nedir?

List-Id (RFC 2919), bir iletinin ait olduğu e-posta listesine bir ad verir. Örneğin News <news.example.com>. Google ve Yahoo bu başlığı zorunlu tutmaz. Alıcı sunucular ve alıcılar bu başlığı e-postayı gönderim akışına göre sıralamak ve filtrelemek için kullanır. Bu yüzden bu başlığı eklemek iyi bir uygulamadır.

İyi uygulamalar listesi nedir?

Liste, Google ve Yahoo’nun 2024’te toplu gönderenler için yayımladığı gereksinimleri izler: hizalı SPF, hizalı DKIM, forward-confirmed reverse DNS (FCrDNS), TLS, ücretsiz e-posta hizmetine ait olmayan ve DMARC’tan geçen bir From alan adı, yayımlanmış bir DMARC politikası, en az bir hizalı kimlik doğrulama yöntemi, tek tıkla abonelik iptali ve görünür bir abonelik iptal bağlantısı. Her satır evet veya hayır der. Kırmızı bir satır, büyük sağlayıcılarda gelen kutusuna ulaşmanın zorlaşmasının olası bir nedenidir. Tam puan, toplu e-posta için temel düzeydir.

Bazı satırlar yalnızca geçerli olduklarında sayılır. Abonelik iptaliyle ilgili iki satır, iletide bir toplu gönderim başlığı olduğunda sayılır: List-Unsubscribe, List-Unsubscribe-Post, List-Id veya değeri bulk, list ya da junk olan Precedence. Bu başlıkların hiçbiri olmayan kişisel bir iletide bu satırlar sayılmaz. Zarf göndericisi SRS ile yeniden yazıldığında ve DMARC hizalı DKIM ile başarılı olduğunda SPF hizalaması puana dahil edilmez. SRS ile yeniden yazımdan sonra SPF, From alan adı yerine adresi yeniden yazan sunucunun alan adını kontrol eder. Yönlendirme hizmetleri varsayılan olarak SRS kullanır ve bazı gönderen sunucular tüm giden e-postalara SRS uygular. Bu da SPF hizalamasını ortadan kaldırır. Puan, sayılan satırlardan kaçının karşılandığını gösterir.

İleti nasıl gösterilir?

İşlenmiş görünüm, HTML bölümünü yalıtılmış bir çerçevede (sandbox) gösterir. İşlemeyi tarayıcı yapar, bu yüzden sonuç belirli bir e-posta programına veya cihaza değil, bir masaüstü tarayıcısına karşılık gelir. Önizlemede betikler, formlar ve bağlantılar devre dışıdır. Diğer görünümler iletiyi görseller engellenmiş halde ve her görselin yerinde alternatif metinle gösterir. Pek çok okuyucu bir iletiyi ilk kez bu şekilde görür.

MIME bölümü neyi gösterir?

MIME, bir iletinin iç yapısıdır: bölümler, içerik türleri, karakter kümeleri, aktarım kodlamaları ve bölümleri ayıran sınırlar. Tipik bir bülten, bir text/plain bölümü ve bir text/html bölümü içeren bir multipart/alternative kapsayıcısına sahiptir. Eksik bir metin bölümü, eksik bir kapanış sınırı veya alışılmadık bir iç içe yapı ağaçta hemen göze çarpar.

Ham ileti bölümü neyi gösterir?

Ham ileti bölümü, iletiyi alındığı haliyle istatistiklerle birlikte gösterir: toplam boyut, satır sayısı, en uzun satır, ASCII dışı karakterler ve CR içermeyen satır sonları. RFC 5322 bir satırı 998 karakterle sınırlar ve bazı sunucular daha uzun satırları böler veya reddeder. Satır başı karakteri (CR) içermeyen satır sonları, yol üzerindeki sunucular bunları yeniden yazdığı için DKIM hatalarının yaygın bir nedenidir.

Ham ileti görünümü, mx.echo.email’in teslimatta kaydettiği izleme başlıklarıyla başlar: Return-Path, Authentication-Results, Received-SPF ve Received. Bunların altında ileti tam olarak alındığı haliyle yer alır ve indirme bağlantısı değiştirilmemiş .eml dosyasını verir.

Rapor hangi engelleme listelerini kontrol eder?

Alıcılar gönderen IP adresini ve gönderen alan adlarını DNS engelleme listelerinde arar. Yaygın kullanılan bir listede yer almak, e-postanın reddedilmesine veya filtrelenmesine yol açar. Rapor, scan.mx ile aynı listeleri kontrol eder: IP adresi için Spamhaus ZEN ve AuthBL, From alan adı ve zarf alan adı için Spamhaus DBL ve ZRD, ayrıca IPv4 adresleri için SpamCop, GBUdb Truncate ve PSBL. Her satır listede veya listede değil der ve liste işletmecisinin listeden çıkarma sayfasına bir bağlantı içerir.

Spamhaus PBL’deki politika gereği bir kayıt, ev bağlantısı gibi doğrudan e-posta göndermemesi gereken bir adres aralığını işaretler. Böyle bir adresten gelen e-posta, sağlayıcının e-posta sunucusu üzerinden çıkmalıdır. Sonuçlar iki saat önbellekte tutulur, bu yüzden bir düzeltme en geç iki saat sonra yeni bir testte görünür.

SpamAssassin puanı ne anlama gelir?

SpamAssassin, birçok alıcı sunucunun kullandığı açık kaynaklı bir spam filtresidir. E-posta sunucusu her test iletisini SpamAssassin ve her gün güncellenen standart kurallarla puanlar. Rapor toplamı, 5 olan spam eşiğini ve eşleşen her kuralı, en çok puan verenlerden başlayarak gösterir. Eksi puanlar iletinin lehine sayılır. Geçerli bir DKIM imzası buna bir örnektir.

Ağ testleri, gönderen IP adresini ve bağlantılardaki alan adlarını Spamhaus’ta (DQS aracılığıyla), URIBL’de, SURBL’de ve standart kurallardaki diğer listelerde arar. Bayes öğrenmesi ve paylaşılan özet ağları Razor, Pyzor ve DCC kapalıdır. Bu yüzden puan yalnızca iletiye bağlıdır ve iletiyle ilgili hiçbir bilgi öğrenme amacıyla sunucudan dışarı çıkmaz.

Puan yalnızca bilgi amaçlıdır ve iyi uygulamalar puanına dahil edilmez. Her alıcı kendi kuralları ve eşikleri olan kendi filtresini kullanır. Gmail ve Outlook SpamAssassin kullanmaz. Sıfırın üzerinde bir puan normaldir. En çok puan veren kurallar, bir değişikliğin en çok nerede işe yarayacağını gösterir. 500 KB’tan büyük iletiler puanlanmaz.

Gönderen alan adlarının neden e-posta sunucularına ihtiyacı vardır?

Yanıtlar From alan adına, geri dönen iletiler ise zarf göndericisinin alan adına gider. İkisinin de bir MX kaydına veya en azından e-posta sunucularının yedek olarak kullandığı bir adres kaydına ihtiyacı vardır. Null MX, yani bir noktaya işaret eden tek bir MX (RFC 7505), bir alan adının hiç e-posta kabul etmediğini bildirir. Bazı alıcılar böyle bir alan adından gelen iletileri reddeder.

Hangi HTML öğeleri riskli sayılır?

Betikler, formlar, iframe, object ve embed öğeleri bir e-postada nadiren gerekir. E-posta programlarının çoğu bunları kaldırır ve spam filtreleri bunları kimlik avı işareti olarak puanlar. Basit bağlantılar ve görseller bu ceza olmadan aynı işi görür. İçerik bölümü HTML boyutunu ve HTML’nin ne kadar görünür metin içerdiğini de gösterir, çünkü neredeyse yalnızca biçimlendirmeden veya görsellerden oluşan bir ileti filtrelere şüpheli görünür.

Bağlantı kısaltıcılar neden işaretlenir?

bit.ly gibi herkese açık kısaltıcılar gerçek hedefi gizler. Kimlik avı kampanyaları bunları çok kullanır, bu yüzden filtreler bu hizmetlerden geçen bağlantılara şüpheyle bakar. Doğrudan gönderenin alan adına giden bağlantılar itibar oluşturur.

DNS bölümü neyi gösterir?

Rapor için yapılan her DNS sorgusu, amaca göre gruplanmış olarak DNS bölümünde yer alır: ters DNS, SPF, DKIM, DMARC, BIMI, e-posta sunucuları ve IPv6 kontrolü. Engelleme listesi sorguları bu bölümde yer almaz, çünkü bu sorguların adları bir erişim anahtarı içerir. Her kayıt adı, kayıt türünü, yanıt kodunu, TTL değeriyle birlikte yanıtları ve varsa yetkili kayıtları gösterir. Liste, her sonucun hangi kayıtlardan geldiğini gösterir. Bu, yakın zamanda yapılan bir DNS değişikliği henüz tüm çözümleyicilere ulaşmadığında işe yarar.

Diğer ücretsiz araçlar

scan.mx
Bir alan adının e-posta ayarlarını kontrol eder: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Bir IP adresinde hangi TCP bağlantı noktalarının açık olduğunu kontrol eder. Bağlantı noktası 25 de buna dahildir.