Bir e-posta sunucusu kara listeye girdiyse önce listeleme nedeni doğrulanır. Kötüye kullanım varsa kaldırma başvurusundan önce bu gönderim durdurulmalıdır; sorun devam ederse başvuru reddedilebilir veya IP adresi kısa süre sonra yeniden listelenebilir.

Önce hangi IP adresinin ya da alan adının listelendiğini kesinleştirin, ardından SMTP günlüklerinden listeleme nedenini araştırın ve varsa kötüye kullanımı durdurun. Yalnız bundan sonra ilgili DNSBL (DNS-based Blocklist) sağlayıcısının resmi kaldırma sürecini uygulayın. DNS tabanlı listeler benzer bir sorgu yapısı kullansa da listeleme kuralları ve başvuru şartları her DNSBL sağlayıcısında farklıdır.

Kara Listeden Çıkma Sürecine Nasıl Başlanır?

  • Reddedilen iletinin SMTP yanıtından liste adını ve listelenen IP adresini veya alan adını belirleyin.
  • Yetkisiz gönderimi durdurun; şüpheli hesapları, uygulamaları ve posta kuyruğunu kontrol altına alın.
  • Yetkisiz istemcilerin başka alan adlarına ileti göndermek için kullanabildiği open relay, ele geçirilmiş hesaplar, bakımsız alıcı listeleri ve sunucu yapılandırma hataları gibi kök nedenleri giderin.
  • PTR kaydını, SMTP selamlama komutları HELO/EHLO adını, SPF (Sender Policy Framework) kaydını, DKIM (DomainKeys Identified Mail) doğrulamasını ve DMARC (Domain-Based Message Authentication, Reporting, and Conformance) yapılandırmasını gönderim altyapısıyla uyumlu hale getirin.
  • Sorun çözüldükten sonra yalnız ilgili DNSBL sağlayıcısının resmi kaldırma yöntemini kullanın ve yeniden listelemeyi izleyin.

Listelenen IP Adresi veya Alan Adı Nasıl Belirlenir?

Gönderen alan adı ile e-postayı gerçekten dışarı çıkaran sunucunun IP adresi aynı şey değildir. Bir kuruluş kendi alan adını kullansa bile iletiler bir barındırma şirketi, güvenlik geçidi, bulut hizmeti veya başka bir SMTP aktarım sunucusu üzerinden çıkabilir. İncelemeye alıcı sunucunun gördüğü gerçek çıkış IP adresinden başlayın.

Reddedilen iletinin teslim edilememe bildiriminde genellikle SMTP durum kodu, alıcı sunucunun açıklaması, listelenen adres ve bazen DNSBL sağlayıcısının adı bulunur. Bu kaydı silmeden saklayın; zaman damgası, kuyruk kimliği, alıcı alan adı ve gönderim IP adresi olayın hangi sistemden çıktığını belirlemeye yardım eder.

  1. İletinin hangi sunucu veya hizmet üzerinden gönderildiğini doğrulayın.
  2. IPv4 ve IPv6 çıkışlarını ayrı ayrı kontrol edin; iki protokol farklı adreslerden çıkabilir.
  3. NAT, yük dengeleme veya SMTP geçidi varsa alıcının gördüğü genel IP adresini belirleyin.
  4. Listelemenin IP tabanlı mı, alan adı tabanlı mı olduğunu ayırın.
  5. Aynı adresin başka kara listelerde görünmesi durumunda her listeyi ayrı olay olarak kaydedin.

Birden fazla çıkış sunucusu kullanılıyorsa yalnız ilk görülen adresi kontrol etmek yeterli değildir. Kampanya sistemi, işlem bildirimleri, destek uygulaması ve kullanıcı posta kutuları farklı IP adresi havuzlarından çıkabilir. Doğru adresi bulmak için reddedilen iletinin kuyruk kimliğini SMTP bağlantı günlüğüyle eşleştirin.

Tarayıcıda görünen genel IP adresi ile SMTP gönderiminde kullanılan çıkış adresi farklı olabilir. İncelemede SMTP ret yanıtını, liste işletmecisinin güncel sorgu sonucunu ve sunucu günlüklerini birlikte kullanın.

Kara Liste Kaydına Yol Açan Nedenler

Kara liste kaydı çoğu zaman sorunun kendisi değil, başka bir olayın belirtisidir. İnceleme sırasında normal gönderim hacmiyle olay anındaki hacmi karşılaştırın. Kimlik doğrulaması yapan hesap ve uygulamaları, alıcı sayısını, hata oranını ve posta kuyruğunu da inceleyin.

Her kara liste kaydı kötüye kullanım kanıtı değildir. Bazı listeler, doğrudan alıcı sunuculara posta göndermemesi gereken son kullanıcı IP adreslerini politika gereği sınıflandırır. Örneğin Spamhaus PBL (Policy Blocklist), bu amaçla kullanılır. Böyle bir durumda e-posta hizmeti sağlayıcısının SMTP gönderim sunucusuna kimlik doğrulamasıyla bağlanmak gerekebilir; doğrudan gönderim için kaldırma başvurusu ancak listenin koşulları karşılanıyorsa yapılır.

Ele Geçirilmiş E-posta Hesapları

Zayıf veya tekrar kullanılan parolalar, saldırganın geçerli bir kullanıcı hesabıyla çok sayıda ileti göndermesine yol açabilir. Kısa sürede farklı ülke ve ağlardan oturum açılması, olağan dışı alıcı sayısı, gece saatlerinde başlayan gönderimler ve normalden hızlı kuyruk büyümesi bu durumu gösterebilir.

Açık Röle Riski

SMTP sunucusu, yetkisiz istemcilerin başka alan adlarına ileti aktarmasına izin veriyorsa açık röle olarak kullanılabilir. Yetkili yerel ağdan gelen bir istemciye parola doğrulaması olmadan aktarım izni verilmesi tek başına açık röle anlamına gelmez; önemli olan aktarım yetkisinin doğru tanımlanmasıdır. Kurallar yalnız yetkili ağları, doğrulanmış hesapları ve açıkça tanımlanmış uygulamaları kapsamalıdır.

Web Uygulamaları ve Zararlı Süreçler

Ele geçirilmiş bir web sitesi, iletişim formu, eklenti veya sunucudaki zararlı süreç posta kuyruğuna istenmeyen iletiler ekleyebilir. Günlüklerde aynı betik yolundan, kullanıcı hesabından, işlem sahibinden veya yerel teslim mekanizmasından gelen yoğun gönderimleri arayın.

Yalnız posta hesabı parolalarını değiştirmek bu senaryoda yetersiz kalır. Uygulama açığını kapatın, ilgili yazılımı güncelleyin, zararlı dosyaları temizleyin ve uygulamaların gönderebileceği ileti hızını sınırlandırın.

Alıcı Listesinin Kalitesi ve Gönderim Davranışı

İzin kaydı belirsiz, uzun süredir kullanılmayan veya satın alınmış alıcı listeleri yüksek teslim hatası ve şikayet üretebilir. Geçersiz adreslere tekrar tekrar gönderim yapmak, abonelikten çıkan kişileri listede tutmak ve ani hacim artışları IP adresinin itibarını olumsuz etkileyebilir.

Geçersiz veya bulunamayan alıcı adresi nedeniyle hard bounce (kalıcı teslim hatası) veren adresleri yeniden gönderime kapatın ve gönderim engelleme listesinde tutun. Kara liste veya başka bir gönderici politikası nedeniyle alınan kalıcı ret, alıcı adresinin geçersiz olduğunu tek başına göstermez. Abonelikten çıkma isteklerini gecikmeden uygulayın ve yalnız doğrulanabilir izin kaydı bulunan alıcılara gönderim yapın. Bir kampanyayı küçük parçalara bölmek, kötü bir listenin temel sorununu ortadan kaldırmaz.

Gönderen Sunucu Yapılandırmasındaki Hatalar

Eksik ters DNS kaydı, tutarsız HELO/EHLO adı, yanlış SPF kapsamı veya DKIM ile imzalanmayan iletiler tek başına her kara listede kayıt nedeni değildir. Buna rağmen bu hatalar alıcıların göndericiyi doğrulamasını zorlaştırır ve mevcut itibar sorununu ağırlaştırabilir.

Paylaşımlı IP Adresindeki Diğer Göndericilerin Etkisi

Gönderim paylaşımlı bir IP adresinden yapılıyorsa kötü trafik başka bir müşteri veya aynı altyapıdaki farklı bir hesap tarafından üretilmiş olabilir. Bu durumda adresin sahibi olan e-posta hizmeti sağlayıcısı günlükleri incelemeli, kötüye kullanımı durdurmalı ve gerekli kaldırma başvurusunu kendisi yürütmelidir.

Kötüye Kullanımı Durdurma ve Altyapıyı Temizleme

Müdahale sırasında olay kayıtlarını korurken zararlı gönderimi de durdurun. Günlükleri, reddedilen ileti örneklerini ve kuyruk bilgilerini saklayın; ancak olay sürerken dışarı giden trafiğin devam etmesine izin vermeyin.

  1. Şüpheli gönderimi duraklatın: Şüpheli gönderimin kaynağı olan hesabı, uygulamayı veya gönderim bağlayıcısını geçici olarak devre dışı bırakın. Tüm kurumsal postayı kapatmak yerine kaynağı ayırmaya çalışın.
  2. Hesapları güvenceye alın: Ele geçirilmiş hesapların parolalarını değiştirin, etkin oturumları sonlandırın ve destekleniyorsa çok faktörlü kimlik doğrulamayı etkinleştirin.
  3. Sunucuyu ve uygulamaları inceleyin: Güncel olmayan bileşenleri güncelleyin, zararlı süreçleri temizleyin ve yetkisiz posta üreten betikleri kapatın.
  4. Aktarım kurallarını daraltın: Yetkisiz istemcilerin başka alan adlarına ileti aktarmasını engelleyin; uygulama ve kullanıcılar için gönderim hızına, alıcı sayısına ve eşzamanlı bağlantıya uygun sınırlar koyun.
  5. Posta kuyruğunu ayıklayın: Yetkisiz veya istenmeyen e-posta olduğu doğrulanan iletileri kaldırın. Meşru iletileri topluca silmeden önce olay kaynağına göre ayırın.
  6. Alıcı listesini temizleyin: Geçersiz, şikayetçi veya izni bulunmayan alıcıları çıkarın; geçersiz adres nedeniyle alınan teslim hatalarını ve abonelikten çıkma kayıtlarını bütün gönderim sistemlerine merkezi olarak yansıtın.

Temizlikten sonra kontrollü bir deneme gönderimi yapın ve kuyruk büyümesi, kimlik doğrulama hataları, alıcı reddi ile gönderim hacmini izleyin. Trafik yeniden olağan dışı biçimde yükseliyorsa kaldırma başvurusunu erteleyin ve olay kaynağını tekrar araştırın.

Sunucu Kimliği, SPF, DKIM, DMARC ve TLS Ayarları

Listeleme nedeni giderildikten sonra gönderim altyapısının kendisini tutarlı biçimde tanıtması gerekir. Bu kontroller listeden çıkarılmayı garanti etmez; ancak alıcı sunucuların iletiyi hangi sistemin gönderdiğini değerlendirebilmesi için temel oluşturur.

  • Çıkış IP adresinin PTR kaydı, gönderim sunucusunu tanıtan geçerli bir sunucu adına işaret etmelidir.
  • Bu sunucu adının IPv4 adresini gösteren A veya IPv6 adresini gösteren AAAA kaydı, kullanılan IP adresiyle tutarlı olmalıdır.
  • SMTP sunucusunun HELO/EHLO adı, geçerli ve çözümlenebilir bir tam alan adı olmalıdır.
  • SPF kaydı yalnız yetkili gönderim kaynaklarını kapsamalı; eski ve kullanılmayan servisler kayıttan çıkarılmalıdır.
  • DKIM imzası doğru alan adı ve seçiciyle doğrulanmalı, anahtarın DNS kaydı erişilebilir olmalıdır.
  • DMARC yapılandırılırken bütün gerçek gönderim kaynakları kontrol edilir. İletide görünen From (Gönderen) alan adıyla hizalı, yani DMARC'ın alan adı eşleştirme koşulunu karşılayan en az bir başarılı SPF veya DKIM sonucu gerekir.
  • TLS sertifikası ve protokol ayarları güncel olmalıdır. TLS 1.2 desteklenmeli, TLS 1.3 desteklenip kullanılabilir olduğunda tercih edilmelidir; eski SSL 2.0 ve 3.0 ile TLS 1.0 ve TLS 1.1 kullanılmamalıdır. TLS tek başına gönderici itibarını düzeltmez.

Listeden Çıkma Başvurusu Nasıl Yapılır?

Her kara liste kendi kayıt nedenini, bekleme süresini ve kaldırma yöntemini belirler. Bazı kayıtlar kötü trafik kesildikten sonra otomatik olarak sona erebilir; bazıları IP adresi sahibinin, barındırma şirketinin veya yetkili yöneticinin başvurusunu gerektirir.

  1. DNSBL sağlayıcısının sorgu sonucunda verdiği kayıt nedenini ve politika metnini okuyun.
  2. Kaydın otomatik olarak sona ermesi, hesap doğrulaması veya barındırma ya da e-posta hizmeti sağlayıcısı üzerinden başvuru gibi koşulları belirleyin.
  3. Başvuruyu, liste işletmecisinin kaldırma koşullarını karşıladıktan ve varsa kötüye kullanımı durdurduktan sonra gönderin.
  4. Listelenen IP adresini veya alan adını, olay zamanını, bulunan nedeni ve uygulanan düzeltmeleri açıkça yazın.
  5. İstenirse IP adresi üzerindeki yetkinizi, e-posta hizmeti sağlayıcısındaki hesabı veya yetkili yönetici iletişim adresini doğrulayın.
  6. Başvuru kimliğini ve yanıtları saklayın; aynı sorun için kısa aralıklarla tekrarlanan başvurular göndermeyin.

DNSBL işletmecileri için hazırlanan RFC 6471, kaldırma taleplerinin iki gün içinde yanıtlanmasını önerir ve belirli bir istisna dışında yanıtın en geç yedi günde verilmesini ister. İstisna, işletmecinin ek görüşmeyle kaldırma koşullarının karşılanamayacağına karar verip bunu başvuru sahibine bildirmesidir. Bunlar yanıt süreleridir; kaydın bu süre içinde mutlaka kaldırılacağı anlamına gelmez.

Yeni bir IP adresine geçiş, yalnız mevcut adresin geçmişinden kaçmak için yapılmamalıdır. Daha önce düzenli gönderimde kullanılmamış yeni bir IP adresinden aniden yüksek hacimde ileti göndermek de alıcı sistemlerde olumsuz sinyal oluşturabilir. Geçiş zorunluysa hacim, kimlik doğrulama ve ters DNS ayarları önceden planlanmalı; eski ve yeni IP adreslerinden yapılan gönderimler günlüklerde ayrı izlenmelidir.

Üçüncü tarafların otomatik veya garantili kaldırma vaadi, DNSBL sağlayıcısının kararını bağlamaz. Olumsuz itibar bildiren bir DNSBL, iyi uygulama kurallarına göre kaldırma veya daha hızlı işlem için ücret ya da bağış istememelidir; DNSBL sorgu hizmetine erişim için alınan ticari ücret ise ayrı bir konudur. Yalnız ilgili listenin resmi sürecini esas alın.

Kaldırma Sonrasında E-posta Gönderimini İzleme

Kayıt kaldırıldıktan sonra DNS önbellekleri ve alıcı sistemlerin yerel verileri nedeniyle sonuç her yerde aynı anda değişmeyebilir. Ayrıca bir listeden çıkmak, başka listelerdeki kayıtların da kaldırıldığı veya tüm alıcıların iletiyi kabul edeceği anlamına gelmez; bazı alıcı e-posta hizmetleri kendi itibar ve içerik politikalarını uygular.

Gönderime yeniden başlarken hacmi normal kullanımınıza uygun biçimde kademeli olarak artırın. SMTP ret oranı, kalıcı teslim hataları, şikayetler, kimlik doğrulama başarısızlıkları, yeni hesap oturumları ve kuyruk büyümesi için uyarılar oluşturun.

  • Hesap başına olağan dışı gönderim ve alıcı sayısını izleyin.
  • Web uygulamalarının posta gönderimini ayrı hesaplarla yönetin ve uygulama günlükleriyle izleyin.
  • Geçersiz alıcı adreslerini ve abonelikten çıkan adresleri bütün gönderim sistemlerinde gönderime kapalı tutun.
  • Paylaşımlı IP adresi kullanılıyorsa e-posta hizmeti sağlayıcısının itibar ve kötüye kullanım politikasını takip edin.
  • IPv4 ve IPv6 çıkışlarını, ters DNS kayıtlarını ve kimlik doğrulama sonuçlarını düzenli olarak yeniden denetleyin.