Mail Server SPAM Listelerinden Çıkma Rehberi (Net Adımlar)

E-posta gönderimi kesintiye uğradığında kullanıcıların yaşadığı problem genellikle aynı noktaya dayanır: IP adresi (veya alan adı) bazı SPAM listelerine (blacklist) düşmüştür. Bu durum, gelen kutularına ulaşmayı doğrudan etkiler ve “mail gönderiyorum ama düşmüyor” şikâyetini tetikler. Bu rehberde; spam listesine neden düştüğünüzü hızlıca teşhis edeceksiniz, gerekli teknik düzeltmeleri yapacak ve en sonunda doğru şekilde “listeden çıkma” (delisting) talebi göndereceksiniz.

1) Önce net teşhis: Hangi liste, hangi IP ve hangi etkilenme?

SPAM listesi kontrolü yapmadan “düzeltme” denemek zaman kaybettirir. NetKıyas mantığıyla önce teşhis, sonra aksiyon:

Etkilenen öğeleri belirleyin

Aşağıdaki üçlü doğru tanımlanırsa sorun hızla daralır: - Gönderim IP’si: Mail’i hangi sunucudan gönderiyorsunuz? (VDS/VPS’de outbound IP) - Hangi alan adı (domain): SPF/DKIM/DMARC kayıtları hangi domain’de tanımlı? - Hangi senaryo: Sadece belirli alıcılara mı gitmiyor, yoksa tüm alıcı gruplarında mı düşüyor?

Hızlı kontrol listesi

• Mail başlıklarını (headers) inceleyin: “SPF fail”, “DKIM fail”, “DMARC policy”, “blacklisted” gibi ifadeler görülür.
• Şu kontrolü yapın: Aynı IP’den hem web formundan hem de SMTP’den gönderim test edin. Sorun tek kaynaktaysa MTA (Mail Transfer Agent) tarafı daha güçlü ihtimaldir.
• Hedef listeyi netleştirin: Bazı sağlayıcılar IP yerine “domain” bazlı listeleme yapar, bazısı da ikisini birlikte raporlar.

Aşağıdaki tablo pratik bir çerçeve sunar:

2) En yaygın 6 teknik neden ve net düzeltme

Spam listeye düşmenin kök nedeni çoğu zaman aynı kategorilere toplanır: Kimlik doğrulama eksik/yanlış, ters DNS uyumsuzluğu, yanlış rota, zayıf güvenlik, anormal gönderim davranışı ve ham içerik.

2.1 SPF kaydı yanlış veya yetersiz

SPF (Sender Policy Framework) alıcının “bu IP bu domain adına gönderme yetkisine sahip mi?” sorusuna cevap verir. - SPF hiç yoksa: doğrudan fail riski yükselir. - SPF var ama gönderen IP kapsam dışındaysa: fail oluşur.

Net düzeltme: - Gönderim yaptığınız tüm outbound IP’leri SPF içine ekleyin. - “all” mekanizmasını gerçek politikaya göre netleştirin.

Örnek SPF formatı (alanınıza göre düzenleyin): v=spf1 ip4:203.0.113.10 include:_spf sağlayıcı.com -all

2.2 DKIM imzası gönderilmeden/yanlış imzayla gidiyor

DKIM (DomainKeys Identified Mail) mail içeriğine imza atar. DKIM doğrulaması başarısız olursa teslimat kalitesi düşer.

Net düzeltme: - DKIM anahtarını doğru selector ile yayınlayın. - “imza var mı, domain hizalanıyor mu” test edin.

2.3 DMARC uyumu yok (veya yanlış policy)

DMARC; SPF/DKIM sonuçlarını “domain hizalaması” ile birleştirir ve politikanızı belirler.

Net düzeltme: - p= politikanızı önce izleme moduna alın: p=none ile rapor toplayın. - rua/ruf ile rapor akışını doğrulayın.

2.4 Reverse DNS (rDNS) yok veya uyumsuz

Birçok RBL/RDNS tabanlı filtre ters DNS uyumuna bakar. Uyum bozuksa, aynı IP “zaten spam göndermiş gibi” algılanabilir.

Net düzeltme: - IP’nin PTR kaydını (reverse) kontrol edin. - rDNS adının A kaydı ile IP eşleşmesini sağlayın.

2.5 Sunucu ele geçirildiyse gönderim kitlenir

Spam listelerinin en sert gerekçesi “kompromize olmuş sunucu”dur. Eğer hesabınız/şifreniz ele geçirildiyse, düzelttiğinizi sanıp yeniden listeleneceksiniz.

Net düzeltme: - Postfix/Exim kullanıcılarını ve servis loglarını inceleyin. - SSH erişimleri, panel şifreleri, API anahtarlarını tarayın. - Zafiyetli modülleri kapatın.

2.6 Gönderim davranışı anormal

Aniden binlerce mail, çok kısa aralıklar, tek kullanıcılı tekrarlar veya sahte geri dönüş adresleri itibar skorunu düşürür.

Net düzeltme: - Gönderim hızını (rate) kontrollü artırın. - Bounce (geri dönüş) oranını takip edin. - Listeden çıkan/engelleyen kullanıcıları otomatik dışlayın.

3) Delisting için hazırlık: Kanıt dosyası gibi düşünün

SPAM listelerinden çıkış (delisting) “bekleye geçer” değildir. Çoğu liste, talep gönderildiğinde belirli şartların sağlandığını görür.

3.1 Mail loglarından “temizleme” kanıtı üretin

Aşağıdaki mantıkla log toplayın: - Şikâyet var mı? (zararlı pattern) - Son değişikliklerden sonra hata/ban oranı azalıyor mu? - SPF/DKIM/DMARC doğrulaması artıyor mu?

3.2 Gönderim testleri yapın

SPF/DKIM/DMARC testleri tek başına delisting garantisi vermez; ama düzgün olduğunuzun sinyalini verir.

Net test senaryoları: - Gmail/Outlook dahil birden fazla alıcı grubuna 5-10 mail gönderin. - Sonuçları: “spam klasörü”, “reject”, “quarantine” ayrımlarını not edin. - Aynı içerikle değil, önce temel bir test mailiyle başlayın.

3.3 Gerekli kayıtları “doğru domain”e yerleştirin

Burada en sık yapılan hata şudur: DKIM/SPF kayıtlarını yanlış domain’e eklemek. Örneğin example.com gönderiyor ama SPF/DKIM mail.example.com üzerinde karıştırılıyor.

Net kontrol: - Envelope from (MAIL FROM) ve header from (From:) alanı hangi domain’de? - DKIM’de “d=” alan adı (imza domain’i) ile “From” hizası uyumlu mu?

4) SPAM listelerinden çıkış (delisting) nasıl yapılır?

Her listeleme servisi farklı arayüz ve şablon ister. Ancak süreç aynı iskeleti izler: teşhis → düzeltme → bekleme/yeniden test → talep.

4.1 Liste servisini tespit edin ve talep prosedürünü izleyin

Delisting adımları tipik olarak şunları içerir: - Liste web sitesinden “lookup” ile IP/domain durumunu görmek - Talep formuna “neden düzelttim” şeklinde kısa, teknik açıklama yapmak - Doğrulama beklemek (bazıları saat, bazısı gün ister)

4.2 Talepte hangi bilgileri vermeniz gerekir?

Net ve tekrar eden başlıklar şunlar olmalı: - Etkilenen IP (veya etkilenen domain) - SPF/DKIM/DMARC kayıtlarının güncellendiğini kanıtlayan doğrulama çıktıları - rDNS düzeltildiyse sağlayıcıdan gelen doğrulama - Sunucuda güvenlik aksiyonları (kompromize şüphesi varsa)

4.3 Bekleme süresini bilin: “Düzeltme yaptım, hemen gitsin” yoktur

Delisting sürecinde iki zaman vardır: 1. Yapılandırma yayılımı (DNS TTL, MTA önbelleği) 2. Liste servisinin yeniden kontrol periyodu

Net yaklaşım: - SPF/DKIM/DMARC düzeltmesinden sonra DNS TTL’yi düşük tutabiliyorsanız birkaç saat/1 gün daha hızlı izlenir. - Ama rDNS değişimleri bazen daha uzun sürer; sağlayıcı ile bu süreyi netleştirin.

5) Gelecekte tekrar düşmemek için 30 gün kontrol planı

Delisting sonrası en kritik nokta “aynı hatayı tekrar etmemek”tir. Aşağıdaki plan doğrudan uygulanabilir.

5.1 İlk 7 gün: izleme ve doğrulama

• SPF/DKIM/DMARC doğrulamasını günlük kontrol edin.
• Mail loglarında “reject”, “bounced”, “spf fail” gibi anahtarları izleyin.
• Dışarıdan gelen raporlara göre (DMARC aggregate/forensic) domain hizasını düzeltin.

5.2 8-20 gün: gönderim kalitesini kalibre edin

• Gönderim hacmini kademeli artırın.
• Yanlış hedeflere göndermeyi önlemek için abonelik doğrulaması yapın.
• Panik butonu: Aniden bounce artarsa hız düşürün.

5.3 21-30 gün: güvenlik ve altyapı sağlamlaştırma

• SSH erişimlerini kısıtlayın, mümkünse anahtar tabanlı doğrulamaya geçin.
• Panel ve mail servis loglarını düzenli raporlayın.
• Aylık yedek (backup) ve geri dönüş testi yapın.

6) NetKıyas tarzı seçim: Doğru hosting/servis sağlayıcı nasıl etkiler?

SPAM problemi sadece mail ayarı değildir; çoğu zaman kullanılan altyapının IP itibarı da etkilidir. Yeni bir VDS/VPS aldığınızda IP daha “temiz” olabilir; fakat sıfır risk yoktur.

Sağlayıcıyı değerlendirirken kontrol listesi

• IP için rDNS yönetimi mümkün mü (PTR desteği)?
• SPF/DKIM/DMARC testlerinde çıkabilecek tipik bloklar var mı?
• Firewall veya upstream “outbound 25/587” kısıtı var mı?
• Mail trafiği için rate limit veya “abuse” mekanizması net mi?

Bu kontrol maddelerini, satın alımdan önce kısa testlerle doğrulamak gerekir. Eğer sağlayıcı tarafında rDNS açılamıyorsa, delisting için zaman kaybı yaşanır.

Sonuç: Listeden çıkmak için sırayı bozmadan ilerleyin

Spam listelerinden çıkışın anahtarı, “düzeltme yaptım” iddiasından önce teşhisi netleştirmek, sonra SPF/DKIM/DMARC ve rDNS uyumunu tamamlamak ve en sonunda delisting talebini doğrulanabilir kanıtlarla göndermektir. Aksiyon önerisi: İlk olarak etkilenen IP/domaini ve liste servisini tespit edin; ardından kimlik doğrulama kayıtlarını düzeltip 5-10 mail test edin; son adımda delisting formunu kullanın. İyileşme yoksa, sunucunun ele geçirilip geçirilmediğini loglarla kesinleştirin ve aynı gün güvenlik aksiyonuna geçin.