Mailler spama düşüyorsa, alıcı sunucu mailin gerçekten sizden geldiğine ya da alıcının onu istediğine güvenmiyor demektir. En sık üç neden vardır: eksik ya da görünen adresle uyumsuz SPF, DKIM ve DMARC kayıtları; itibarı düşmüş gönderen IP adresi veya alan adı; spam kalıplarına benzeyen içerik. Kalıcı çözüm, nedeni mail başlığından teşhis edip kaynağında düzeltmektir.
Kısaca
- Spama düşen mailin tam başlığındaki
Authentication-Resultssatırı SPF, DKIM ve DMARC sonucunu açıkça gösterir; teşhis buradan başlar. - KOBİ'lerde en sık neden, web formu, CRM ya da fatura yazılımının sizin adınıza kimlik doğrulamasız veya hizalanmamış mail göndermesidir.
- Google, Gmail'e mail gönderen herkesten SPF veya DKIM, geçerli PTR kaydı, TLS ve %0,3'ün altında spam oranı istiyor.
- Microsoft, 5 Mayıs 2025'ten beri günde 5.000'den fazla mail gönderen ve şartları karşılamayan alan adlarının maillerini reddediyor.
- Alıcıdan "güvenilir gönderenlere ekleyin" istemek sorunu gizler; kalıcı çözüm gönderen altyapısındaki sekiz adımlı düzeltmedir.
"Mailimiz müşterinin spamına düşmüş": sorun nasıl görünür?
Tipik tablo şöyledir: satış ekibi teklif gönderir, müşteri bir hafta sonra "mailiniz hiç gelmedi" der; aranınca mailin gereksiz klasöründe beklediği anlaşılır. Bazen yalnızca Gmail veya Outlook kullanan alıcılarda olur, bazen yalnızca web sitesindeki iletişim formundan çıkan bildirimlerde ya da fatura yazılımının gönderdiği maillerde. Hangi alıcıda ve hangi kaynakta görüldüğü, teşhisin ilk ipucudur.
Çoğu şirketin ilk tepkisi alıcıdan "bizi güvenilir gönderenlere ekleyin" diye rica etmektir. Bu rica tek bir müşteri için sorunu geçici olarak gizler; ama yeni müşterilere, ihale komisyonlarına ve tedarikçilere giden maillerde aynı sorun devam eder. Spam sorununun kalıcı çözümü alıcının ayarında değil, sizin gönderim altyapınızdadır.
Bu rehber teşhis ve düzeltme üzerinedir. Kayıtların kendisini SPF, DKIM ve DMARC nedir rehberinde, sıfırdan kurulumu ise alan adlı e-posta kurulumu yazısında adım adım anlattık.
Spama düşen mailin işletmeye maliyeti nedir?
Spam klasörüne düşen bir mail, reddedilen mailden daha sinsidir: gönderene hata dönmez, kimse fark etmez. Teklif süresi geçer, fatura hatırlatması okunmaz, ihale yazışması zamanında yanıtlanmaz. Kayıp çoğu zaman "müşteri ilgilenmedi" diye yanlış yorumlanır.
Büyük e-posta sağlayıcılarının kuralları da sıkılaştı. Google'ın Gmail gönderici yönergelerine göre Gmail'e mail gönderen herkes SPF veya DKIM kurmalı, gönderen alan adının ya da IP adresinin geçerli ileri ve ters DNS (PTR) kaydı olmalı, iletim TLS ile şifrelenmeli ve Postmaster Tools'ta raporlanan spam oranı %0,3'ün altında kalmalı.
Microsoft, 5 Mayıs 2025'ten itibaren Outlook.com, Hotmail ve Live adreslerine günde 5.000'den fazla e-posta gönderen alan adlarından SPF, DKIM ve en azp=nonepolitikalı DMARC şartı aramaya başladı. Duyurudaki güncellemeye göre şartı karşılamayan mailler Gereksiz klasörüne alınmak yerine550 5.7.515koduyla reddediliyor; yani sorun spam klasörünü de aşıp mailin hiç ulaşmamasına dönüşebiliyor. (Microsoft Defender for Office 365 Blog — Outlook's New Requirements for High-Volume Senders, 2025)
Kayıtları kurmuş olmak da yetmiyor. EasyDMARC'ın 1,8 milyon alan adını tarayan 2026 DMARC Adoption Report'una göre alan adlarının %52,1'inde DMARC kaydı var, ama yalnızca yaklaşık %9'u uygulama politikasını raporlamayla birlikte kullanıyor. DMARC raporu okunmayınca hangi servisin adınıza doğrulanmadan mail gönderdiği de görülmüyor.
Mailler neden spama düşüyor? Belirtiden nedene teşhis tablosu
Teşhise başlamadan önce spama düşen bir mailin tam başlığını (Gmail'de "Orijinali göster", Outlook'ta "İleti kaynağı") alın. Başlıktaki Authentication-Results satırı; SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) ve DMARC (Domain-based Message Authentication, Reporting and Conformance) sonucunu açıkça yazar. Tahmin yürütmek yerine teşhise bu satırdan başlayın.
| Belirti | Olası neden | Başlıkta / nerede bakılır | İlk düzeltme |
|---|---|---|---|
| Yalnızca web formu, CRM ya da fatura yazılımından çıkan mailler spama düşüyor | O servis SPF'te yok veya kendi alan adıyla DKIM imzalıyor; DMARC hizalaması bozuk | spf=fail ya da dmarc=fail, DKIM d= başka alan adı | Servisi SPF'e ekleyin, DKIM'i kendi alan adınızla imzalatın |
| Tüm mailler, tüm alıcılarda | SPF/DKIM hiç yok, ikinci SPF kaydı var ya da SPF 10 DNS sorgusunu aşıyor | spf=permerror, dkim=none | Tek ve sade bir SPF kaydı, DKIM imzalamayı açma |
| Sunucunuzdan çıkan mailler, özellikle bir sağlayıcıda | PTR kaydı yok, IP kara listede | Ters DNS sorgusu, kara liste kontrolü | PTR'yi alan adıyla eşleştirme, kara listeden çıkış başvurusu |
| Birden bire başladı, alıcılar şikâyet ediyor | Ele geçirilmiş bir hesaptan spam gönderilmiş, itibar düşmüş | Giden kuyrukta olağandışı hacim, oturum kayıtları | Parolaları sıfırlama, oturumları kapatma, MFA |
| Toplu duyurular spama düşüyor, birebir yazışma sorunsuz | Eski liste, geri dönen adresler, şikâyet oranı, abonelikten çıkma yok | Geri dönme raporları, Postmaster verisi | Liste temizliği, kolay abonelikten çıkma, ayrı gönderim alt alan adı |
| Belirli mail türü (ör. tek görsel + kısa bağlantı) | İçerik ve bağlantı sinyalleri | Mailin gövdesi | Metin ağırlıklı içerik, açık bağlantı, ek yerine paylaşım bağlantısı |
Tablonun ilk satırı KOBİ'lerde en sık görülen durumlardan biridir. Web sitesi iletişim formu, CRM, e-fatura portalı ve bülten aracı "Kimden" satırına sizin adresinizi yazar, ama maili başka bir sunucudan gönderir. DMARC yalnızca kimlik doğrulamanın geçmesine değil, görünen alan adıyla hizalanmasına bakar; bu yüzden SPF'e eklenmiş bir servis bile DMARC'tan kalabilir.
Mailler spama düşüyorsa ne yapılmalı? 8 adımda kalıcı çözüm
- Örnek topla. Farklı alıcılardan, farklı gönderim kaynaklarından spama düşen en az üç mailin tam başlığını alın; tek örnekle karar vermeyin.
- Gönderen envanteri çıkar. Alan adınız adına mail gönderen her şeyi listeleyin: posta sunucusu, web sitesi, CRM, muhasebe ve e-fatura yazılımı, bülten aracı, yazıcı-tarayıcılar, izleme sistemleri. DMARC raporlarını okumak bu listenin eksiklerini gösterir.
- SPF'i sadeleştir. Tek kayıt, gerçekten kullanılan servisler, en fazla on DNS sorgusu. Kullanılmayan eski
includeifadelerini temizleyin. - Her servisi DKIM ile kendi alan adınızla imzalat. Servisin "kendi alan adınla imzala" ayarını açıp verdiği anahtarı DNS'e ekleyin; hizalama böylece sağlanır.
- DMARC'ı izleme modunda başlatıp kademeli sıkılaştır.
p=noneile raporları toplayın, tüm meşru kaynaklar hizalanıncaquarantine, ardındanrejectseviyesine geçin. - Sunucu itibarını kontrol et. Kendi sunucunuzdan gönderiyorsanız PTR kaydını (ters DNS), TLS'i ve kara liste durumunu kontrol edin. Web sitesinin paylaşımlı barındırmadan doğrudan mail göndermesi yerine kimlik doğrulamalı SMTP üzerinden göndermesini sağlayın.
- Hesapları ve hacmi koru. Ele geçirilen tek bir kutu, tüm alan adının itibarını düşürür. Güçlü ve paylaşılmayan parolalar (kurumsal parola güvenliği) ile iki adımlı doğrulama bu yüzden bir teslim edilebilirlik önlemidir de.
- Toplu gönderimi ayır ve ölç. Duyuru ve kampanyaları ayrı bir alt alan adından, temiz listeyle ve kolay abonelikten çıkma seçeneğiyle gönderin; Google Postmaster Tools verisini aylık takip edin.
Düzeltmeden sonra ne kadar beklemeli?
DNS değişiklikleri kaydın TTL süresine göre yayılır; gönderen itibarı ise birikerek toparlanır. Bu nedenle düzeltmeden sonra aynı test alıcılarına birkaç gün boyunca örnek mail gönderip başlıkları yeniden kontrol edin. Aynı gün "çözüldü" veya "çözülmedi" sonucuna varmak yanıltıcı olur.
Hangi hatalar spam sorununu büyütür?
Bazı refleksler spam sorununu çözmek yerine derinleştirir. Kara listeye düşen IP adresinden gönderime inatla devam etmek, itibarı daha da düşürür. SPF'in sonuna +all yazmak "herkes adıma gönderebilir" demektir; spam sorununu çözmez, sahteciliğe kapı açar. İkinci bir SPF kaydı eklemek ise iki kaydı da geçersiz kılar.
Yalnızca görselden oluşan ya da dış sunucudan resim çeken e-posta imzaları da içerik sinyallerini bozar. İmzayı merkezden ve sade tutmak için kurumsal e-posta imzası yazımıza bakın.
Alan adını ya da sağlayıcıyı değiştirmek de tek başına çözüm değildir. E-posta taşıma sırasında DKIM anahtarı ve SPF güncellenmezse yeni sistemde aynı sorun ilk günden başlar. Yeni sağlayıcı seçiyorsanız alan adı ve DNS yönetiminin nasıl yapıldığını, kurumsal e-posta nasıl seçilir rehberindeki kriterlerle birlikte değerlendirin.
Son olarak, sizi taklit eden alan adları da itibarınızı etkiler. Harfi değiştirilmiş bir alan adından müşterilerinize sahte mail gidiyorsa alıcılar gerçek maillerinize de şüpheyle bakar; bu riski benzer alan adı saldırıları yazısında anlattık.
Digital Bridge mailleri spama düşen şirketlere nasıl yardımcı olur?
Digital Bridge, spam sorununu tek bir DNS kaydını düzelterek değil, alan adınız adına mail gönderen her sistemi birlikte ele alarak çözer:
- Keşif ve teşhis. Siber güvenlik danışmanlığı kapsamında spama düşen maillerin başlıklarını, SPF/DKIM/DMARC kayıtlarını, PTR ve kara liste durumunu inceliyor; gönderen envanterini sizinle birlikte çıkarıyoruz.
- Uygulamaların gönderim yolunu düzeltiyoruz. Web sitenizin formları kimlik doğrulamasız gönderim yapıyorsa firmaya özel web yazılımı tarafında doğrulamalı SMTP'ye taşıyoruz; CRM sisteminizin ve e-fatura yazılımınızın maillerini kendi alan adınızla imzalayacak şekilde yapılandırıyoruz.
- Entegrasyonları tek düzene bağlıyoruz. ERP, fatura ve bildirim servisleri gibi birden fazla sistem mail gönderiyorsa bunları sistem entegrasyonları kapsamında ortak ve denetlenebilir bir gönderim yapısına topluyoruz. Fatura bildirimlerinin akışını e-fatura entegrasyonu yazısında ayrıca ele aldık.
- Kademeli geçiş ve izleme. DMARC'ı izleme modundan reddetme seviyesine, meşru hiçbir kaynağı kesmeden, raporlara bakarak kademeli taşıyoruz.
Smart360 ve SmartMail teslim edilebilirliğe nasıl katkı sağlar?
Digital Bridge'in geliştirdiği Smart360 ailesinde alan adları ve DNS ayarları; kullanıcılar, departmanlar ve ürün erişimleriyle birlikte tek kurum panelinden yönetilir. Panelin sistem sağlığı bölümü, her ürünün alan adı ve DNS kayıtlarını, neyin neden eklenmesi gerektiğini ve kaydın şu anki durumunu gösterir. SmartMail için sunucu kurulmaz; ödeme onaylandığı anda ürün açılır.
SmartMail kurumsal e-postada MX, SPF, DKIM, DMARC, MTA-STS ve TLS-RPT kayıtlarını Smart360 ekibi hazırlar, doğrular ve alan adını etkinleştirir. Alan adınıza gelen DMARC raporları SmartMail'in toplayıcı adresine düşer, okunabilir biçime çevrilir ve ay ay arşivlenir; böylece gönderen envanterindeki eksikler görünür hale gelir.
Gönderen itibarını en hızlı düşüren olay, ele geçirilmiş bir hesaptan spam çıkmasıdır. Smart360 Security giriş ekranlarında insan doğrulaması kullanır ve doğrulama tamamlanmadan giriş isteği sunucuya ulaşmaz. Posta kutusu parolalarını sistem üretir ve AES-256-GCM ile şifreli saklar, çalışanlara dağıtılmaz. Açık oturumlar cihaz bilgisiyle listelenir ve uzaktan kapatılabilir; parola değişince tüm oturumlar kapanır.
Madalyonun öbür yüzü, müşterilerinizin size gönderdiği maillerdir. SmartMail kurumsal e-posta gelen her maili üç grup ölçümle değerlendirir: kimlik (SPF, DKIM, DMARC ve PTR'yi kendisi yeniden hesaplar), yapı (benzer alan adı, görünen ad taklidi, yanıt adresi ve bağlantı uyuşmazlığı) ve içerik. Sonuç, gerekçesi yazılı bir değerlendirmedir; bir müşterinizin maili karantinaya düştüyse "gönderenin DMARC doğrulaması başarısız" gibi nedeni görür ve ona somut bir düzeltme önerebilirsiniz.
Karantina eşiğini kurum yöneticisi belirler; eşiği değiştirmeden önce kaç mesajı etkileyeceği gösterilir. Karantinaya düşen meşru maillerin kim tarafından, ne sürede serbest bırakılacağını e-posta karantina politikası yazımızda anlattık. SmartMail'i satın almak için SmartMail.com.tr satın alma sayfasını kullanabilirsiniz.
Sonraki adım
Başlamak için spama düştüğünü bildiğiniz üç mailin tam başlığını ve alan adınız adına mail gönderen sistemlerin listesini hazırlayın. Ardından iletişim sayfamızdan bize ulaşın; başlıkları birlikte okuyalım, nedeni belirleyelim ve düzeltme sırasını yazılı olarak çıkaralım. E-posta altyapısıyla ilgili diğer rehberler için Kurumsal E-posta ve Belge sayfamıza göz atabilirsiniz.