CloudSpex

Domain sağlığı rehberi

E-postalarınız neden spam'e düşüyor

Meşru bir e-posta spam'e düştüğünde neden genellikle birkaç şeyden biridir ve bunlar sırayla kontrol edilebilir. İletinin kendisinde ölçülebilen şeylerle başlayın, ardından itibara bakın ve e-postanın metnini en sona bırakın.

E-posta Güvenlik Kontrolü aracını kullanın

English

Filtreleme kararları nasıl verilir

Bir e-posta sağlayıcısı, iletinin nereye gideceğine üç tür sinyale bakarak karar verir. Birincisi kimliktir: ileti, geldiğini öne sürdüğü domaine bağlanabiliyor mu. İkincisi itibardır: alıcılar bu domainden ve bu gönderen adresten daha önce gelen e-postalara nasıl tepki verdi. Üçüncüsü iletinin kendisidir: içeriği, bağlantıları ve yapısı.

Bunlar kabaca bu sırayla tartılır. Kimlik doğrulamadan geçemeyen bir ileti, ne söylerse söylesin filtrelenebilir. İtibarı kötü bir domainden gelen ileti, kimliği kusursuz biçimde doğrulanmış olsa bile filtrelenir. İçerik en çok sınırdaki durumlarda, sağlayıcının hakkında pek geçmiş bilgisi olmayan gönderenler için önem taşır. Konu satırını yeniden yazmanın bir spam klasörü sorununu nadiren çözmesinin nedeni budur.

Gerçek bir iletiyle başlayın

En hızlı tanı, gerçekten spam'e düşmüş bir iletiden gelir. İletiyi alıcı posta kutusunda açın, özgün hâlini ya da tam başlıkları görüntüleyin ve alıcı sunucunun eklediği Authentication-Results başlığını bulun. Bu başlık, tam o ileti için SPF, DKIM ve DMARC sonuçlarını kaydeder.

Her birinin yanında kendi domaininizin göründüğü üç pass sonucu, sorunun kimlik olmadığı anlamına gelir. Bunun dışındaki her şey, ilk nereye bakmanız gerektiğini söyler.

Sağlıklı bir sonuç ve iki ayrı sorunu olan bir sonuç
Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Authentication-Results: mx.example.net;
  spf=softfail smtp.mailfrom=example.com;
  dkim=pass header.d=mailer-service.example;
  dmarc=fail header.from=example.com

Kimlik doğrulama sorunları ve çözümleri

Bu başlıktaki her sonuç belirli bir nedene karşılık gelir.

  1. spf=fail ya da softfail: gönderen sunucu SPF kaydınızda yok. Servisi ekleyin ya da dönüş yolu (return path) olarak hangi domaini kullandığını kontrol edin.
  2. spf=permerror: kayıt geçersiz. Olağan nedenler, iki SPF kaydı bulunması ya da ondan fazla DNS sorgusudur.
  3. spf=none: dönüş yolu domaini için SPF kaydı yok.
  4. dkim=none: ileti imzalanmamış. İmzalama, gönderen serviste açılmamış.
  5. dkim=fail: imza doğrulanmadı. DNS'teki anahtar yanlış ya da kesilmiş, ya da ileti iletim sırasında değiştirilmiş.
  6. Başka bir şirketin domainiyle dkim=pass: ileti imzalanmış ama sizin tarafınızdan değil. Servisin özel domain imzalama özelliğini etkinleştirin.
  7. dmarc=fail: ne SPF ne de DKIM, From domainiyle hizalı biçimde geçti.

Olağan suçlu hizalamadır

Yukarıdaki ikinci örnek, üçüncü taraf bir platform üzerinden gönderilen e-postalarda en sık görülen durumdur. DKIM geçer, ama imza platforma aittir. SPF, ya platforma ait olan ya da yetkilendirilmemiş bir dönüş yoluna göre değerlendirilir. İletideki hiçbir şey görünen From domainine bağlı değildir, bu yüzden DMARC başarısız olur.

Çözüm platformdadır, genellikle domain kimlik doğrulaması ya da gönderen kimlik doğrulaması adı verilen bir bölümde. Platform, sizin domaininizle imzalayabilmesi için birkaç DNS kaydı yayınlamanızı ister. Bundan sonra başlıkta dkim=pass ifadesinin yanında sizin domaininiz görünmelidir.

Arkasındaki DNS kayıtlarını kontrol edin

Hangi denetimin başarısız olduğunu öğrendikten sonra genel kayıtları okuyun. Her biri tam olarak tek bir yanıt döndürmelidir.

Alıcı sunucunun sorguladığı kayıtlar
dig example.com TXT +short | grep spf1
dig _dmarc.example.com TXT +short
dig s1._domainkey.example.com TXT +short
dig example.com MX +short

İtibar

Kimlik doğrulama temizse ve e-posta yine de spam'e düşüyorsa, neden neredeyse her zaman itibardır. E-posta sağlayıcıları, her gönderen domain ve her gönderen IP adresi için sürekli güncellenen bir değerlendirme tutar. Bu değerlendirme, alıcıların e-postaya nasıl davrandığından oluşur: açıyorlar mı, okumadan siliyorlar mı, spam'e mi taşıyorlar, spam'den mi çıkarıyorlar.

İtibar aynı anda birkaç şeye bağlanır. Yeni bir domainin itibarı yoktur ve sağlayıcılar ona temkinli yaklaşır. Bir e-posta servisindeki paylaşımlı IP adresi, onu kullanan her müşterinin itibarını taşır. Geçmişte özensiz kullanılmış bir domain, bu geçmişi uzun süre üzerinde taşır. İtibar her sağlayıcıya özgüdür. Bu yüzden e-posta bir sağlayıcıda gelen kutusuna ulaşırken diğerinde spam'e düşebilir.

Büyük sağlayıcılar, doğrulanmış bir domain sahibinin itibar ve şikâyet verilerini görebildiği ücretsiz paneller sunar. Bu rakamların tek kaynağı onlardır. Hiçbir dış araç bunları ölçemez.

Şikâyetler ve liste kalitesi

En güçlü olumsuz sinyal, bir alıcının spam düğmesine basmasıdır. Sağlayıcılar toplu gönderenlerden şikâyet oranını yüzde 0,1'in altında tutmalarını ister ve yüzde 0,3 dolayında süregelen oranlar filtrelemeye ve reddetmeye yol açar. Çok küçük görünen bir oran çoktan sorun olmuştur.

Şikâyetler, listede kimin olduğuna ve oraya nasıl girdiğine bağlıdır.

  1. Yalnızca e-postayı isteyen kişilere gönderin. Satın alınmış, kazınmış ve ödünç alınmış listeler spam klasörüne giden en hızlı yoldur.
  2. Yeni adresleri bir onay iletisiyle doğrulayın. Böylece yazım hataları ve başkasının girdiği adresler listeye hiç katılmaz.
  3. Kalıcı olarak geri dönen (hard bounce) adresleri hemen çıkarın.
  4. Aylardır açmamış ya da tıklamamış adreslere göndermeyi bırakın.
  5. Abonelikten çıkmayı tek tıkla yapılır hâle getirin ve isteği hemen uygulayın. Abonelikten çıkma bağlantısını bulamayanlar onun yerine spam düğmesini kullanır.
  6. Çok eski listelere dikkat edin. Terk edilmiş adresler bazen sağlayıcılar tarafından spam tuzağına dönüştürülür.

Hacim ve tutarlılık

Gönderim davranışındaki ani değişiklikler, ele geçirilmiş bir hesap ya da bir spam dalgası gibi görünür. Normalde günde iki yüz ileti gönderen ve birdenbire elli bin gönderen bir domain, içerik ne kadar iyi olursa olsun yavaşlatılır ya da filtrelenir.

Yeni bir domain ya da yeni bir özel IP adresi ısıtılmalıdır: en ilgili alıcılara küçük hacimlerle başlayın ve birkaç hafta içinde artırın. Sonrasında gönderim düzenini sabit tutun. Tek seferlik büyük bir kampanya göndermeniz gerekiyorsa birkaç güne bölün.

İçerik ve yapı

İçerik incelenecek son şeydir, ama birkaç nokta gerçekten önemlidir. Bunlar belirli kelimelerden çok, iletinin olduğunu söylediği şeye benzeyip benzemediğiyle ilgilidir.

  1. Görünen metnin söylediğinden başka bir yere giden bağlantılar ve yoğun biçimde kötüye kullanılan genel bağlantı kısaltıcılar.
  2. Kendi itibarı kötü olan bağlantı ve görsel domainleri. Platform izin veriyorsa izleme bağlantıları için kendi domaininizi kullanın.
  3. Çok az metin içeren ya da hiç metin içermeyen, tek bir büyük görselden oluşan ileti.
  4. HTML'in yanında düz metin sürümünün olmaması.
  5. Bir kelime işlemciden yapıştırılmış, bozuk ya da şişkin HTML.
  6. Kötü amaçlı yazılım için sıkça kullanılan türlerde ekler.
  7. Bir gönderimden diğerine değişen From adı ya da adresi.
  8. Pazarlama e-postasında fiziksel adresin ya da abonelikten çıkma bağlantısının eksik olması. Bu, birçok ülkede yasal bir zorunluluktur da.

Kendi posta sunucunuz için altyapı kontrolleri

Bir e-posta sağlayıcısı ya da bir e-posta servisi üzerinden gönderiyorsanız sunucu tarafını onlar halleder. Kendi posta sunucunuzu çalıştırıyorsanız, itibar devreye girmeden önce birkaç temel şey gerekir: gönderen adres için, bir ileri kayıtla eşleşen bir ters DNS kaydı, gerçek bir ana makine adı olan bir HELO adı, giden bağlantılarda TLS ve başlıca engelleme listelerinde yer almayan bir adres. Konut ve dinamik aralıklardaki adresleri çoğu alıcı sunucu doğrudan engeller.

Gönderen bir adres için ileri doğrulamalı ters DNS
dig -x 203.0.113.10 +short      ; mail.example.com.
dig mail.example.com A +short    ; 203.0.113.10

İzlenecek sıra

Bu sırayla çalışmak, yanlış katmanda zaman harcamayı önler.

  1. Spam'e düşmüş bir iletinin Authentication-Results başlığını okuyun.
  2. Her şeyden önce, varsa SPF, DKIM ya da DMARC hatasını ve hizalama hatasını giderin.
  3. Genel DNS kayıtlarını yinelenen kayıtlar ve hatalar açısından kontrol edin.
  4. İtibar ve şikâyet oranı için sağlayıcıların kendi panellerine bakın.
  5. Adreslerin listeye nasıl girdiğini ve ne zaman çıkarıldığını gözden geçirin.
  6. Hacimde, gönderen sistemde ya da From adresinde yakın zamanda yapılan değişikliklere bakın.
  7. İletideki bağlantıları, görselleri ve yapıyı ancak bundan sonra gözden geçirin.
  8. Küçük, ilgili bir gruba yeniden gönderin ve tam hacme dönmeden önce sonucu izleyin.

Toparlanma nasıl görünür

Kimlik doğrulama düzeltmeleri, DNS güncellenir güncellenmez etkisini gösterir. İtibar öyle değildir. Bir sağlayıcı bir gönderene güvenmemeyi öğrendikten sonra bunu değiştirmek haftalarca tutarlı ve istenen e-posta göndermeyi gerektirir. Toparlanma sırasında daha az gönderin, e-postayı açma olasılığı en yüksek kişilere gönderin ve olumlu sinyallerin birikmesine izin verin. Birkaç alıcıdan iletiyi spam'den çıkarmalarını ve yanıtlamalarını istemek sınırlı ölçüde yardımcı olur. Nedeni gidermenin yerini tutmaz.

Gelen kutusuna ulaşmayı garanti eden bir ayar, kayıt ya da ifade yoktur. Sağlayıcılar her alıcı için ayrı karar verir ve bir kişinin istediği ileti, bir başkasının şikâyet ettiği iletidir.

Bir DNS kontrolü size neyi söyler, neyi söyleyemez

Genel kayıtların kontrolü bu listedeki ilk soruyu yanıtlar, yalnızca onu. SPF, DKIM ve DMARC kayıtlarının var olup olmadığını, geçerli olup olmadıklarını ve bir kaydın değişip değişmediğini gösterir. İtibarı, şikâyet oranlarını, etkileşimi ya da e-postanızın içeriğini göremez ve bir iletinin nereye düşeceğini öngöremez. CloudSpex E-posta Güvenlik Kontrolü, bir alıcı sunucunun sorgulayacağı kayıtları okur ve ölçtüğünü bildirir. Bu kayıtları izlemek önemlidir, çünkü geçen ay çalışan kimlik doğrulama, o günden beri sessizce bozulmuş olma olasılığı en yüksek şeydir.

Sık sorulan sorular

E-postalarım neden bir sağlayıcıda spam'e düşüyor da diğerinde düşmüyor?

Her sağlayıcı kendi itibar verisini tutar ve kendi filtrelerini uygular. Bir domainin bir sağlayıcıda iyi bir geçmişi olabilir, diğerinde ise çok az geçmişi olabilir ya da hiç olmayabilir.

SPF, DKIM ve DMARC kurmak e-postalarımı spam'den çıkarır mı?

Yaygın bir nedeni ortadan kaldırır ve büyük sağlayıcılar bunu zorunlu tutar. Sorun itibar ya da şikâyetlerse, kimlik doğrulama tek başına çözmez.

Spam tetikleyici kelimeler hâlâ önemli mi?

Eskisine göre çok daha az. Modern filtreler gönderen itibarına ve alıcı davranışına, tek tek kelimelerden çok daha fazla ağırlık verir.

Gönderen itibarını onarmak ne kadar sürer?

Genellikle ilgili alıcılara birkaç hafta boyunca istikrarlı gönderim gerekir. İtibarı istek üzerine sıfırlamanın bir yolu yoktur.

Herkese açık kontrolleri başlangıç noktası olarak kullanın

CloudSpex yalnızca dışarıdan görülebilen sınırlı sinyalleri okur. DNS, web sitesi, sertifika ya da e-posta ayarlarınızı değiştirmez. Bir düzeltmeyi uygulamadan önce sorumlu sağlayıcıyı doğrulayın ve değişikliği test edin.

Yayın bilgisi

Yazan ve gözden geçiren: CloudSpex. Kaynaklar: konuyla ilgili herkese açık teknik standartlar ve sağlayıcı belgeleri. Son gözden geçirme: 10 Kasım 2026. Ürünün davranışı ya da dayanılan kurallar değiştiğinde rehberleri güncelliyoruz.