Mail Sunucum Kara Listede: Sorgulama ve Listeden Çıkma

Sabah ilk iş olarak "mailler gitmiyor" mesajıyla uyanmak, mail sunucusu işleten herkesin er ya da geç yaşadığı bir şeydir. Gönderdiğiniz her mail birkaç saniye içinde geri döner, geri dönen mesajın içinde blocked using zen.spamhaus.org ya da Client host rejected gibi bir satır vardır ve o an anlarsınız: sunucunuzun IP'si kara listeye girmiş. Mail blacklist sorgulama işlemi bu noktada başlar, ama asıl mesele sorgulama değildir — asıl mesele hangi listeye, neden girdiğinizi bulup o sebebi ortadan kaldırmaktır. Sebep durduğu sürece kaç kez blacklistten çıkma başvurusu yaparsanız yapın, ya reddedilir ya da birkaç saat sonra yeniden listelenirsiniz.

Bu yazıda kara liste sorununu bir sistem yöneticisinin izlediği sırayla ele alıyoruz: önce geri dönen mesajı doğru okuyup hangi listenin engellediğini tespit etmek, sonra dig ile DNSBL sorgulaması yapıp tam olarak hangi kayda düştüğünüzü öğrenmek, ardından Spamhaus'un SBL / CSS / XBL / PBL kayıtları arasındaki farkı anlamak — çünkü bu dördü tamamen farklı sebeplerden konur ve tamamen farklı çözümler ister. Sonra sunucunun içinde sebebi arıyoruz: kuyrukta biriken mail, ele geçirilmiş bir PHP dosyası, şifresi çalınmış bir hesap. En sonunda delisting formunu doğru dolduruyor ve aynı şeyin bir daha yaşanmaması için kalıcı önlemleri kuruyoruz.

Kara Listeye Girdiğinizi Nasıl Anlarsınız#

Kara listeye girdiğinizin en net kanıtı, alıcı sunucunun geri döndürdüğü bounce mesajının içindeki reddetme satırıdır. "Mailler gitmiyor" belirsiz bir ifadedir; geri dönen mesajın ham hâlini açtığınızda karşı tarafın size neden hayır dediğini kelimesi kelimesine yazdığını görürsünüz.

Tipik bir kara liste reddi şuna benzer:

550 5.7.1 Service unavailable; Client host [185.xx.xx.xx] blocked
using zen.spamhaus.org; https://check.spamhaus.org/query/ip/185.xx.xx.xx

Bu satırda üç kritik bilgi var: reddeden liste (zen.spamhaus.org), listelenen IP (185.xx.xx.xx) ve genellikle sorgulama bağlantısı. Bazı sağlayıcılar liste adını vermez, kendi iç itibar sistemlerini kullanır:

550 5.7.1 [TSS04] Messages from 185.xx.xx.xx temporarily deferred
due to unexpected volume or user complaints

421 4.7.0 [TSS04] Our system has detected an unusual rate of unsolicited mail
originating from your IP address.

Bu ikinci tip, Google ve Microsoft gibi büyük sağlayıcıların kendi iç kara listeleridir ve hiçbir DNSBL sorgusunda görünmezler. Bu ayrım çok önemli: DNSBL sorgusu "temiz" dediği hâlde Gmail'e mail gitmiyorsa, sorununuz kamuya açık bir liste değil, Google'ın kendi itibar puanınızdır ve çözümü de farklıdır — gönderim hacmi, şikâyet oranı ve kimlik doğrulama kayıtları üzerinden ilerler.

Bounce mesajını nasıl okuyacağınızı ve 4xx ile 5xx kodları arasındaki farkı daha detaylı görmek isterseniz mail geri dönüyor: bounce mesajlarını çözme yazısı bu konuyu ayrıca ele alıyor.

Hangi Kara Listede Olduğunuzu Komutla Sorgulama#

DNSBL sorgulaması, IP adresinin oktetlerini ters çevirip liste alan adının önüne ekleyerek yapılan basit bir DNS A kaydı sorgusudur. Web tabanlı toplu sorgu araçları bu işi arkada zaten böyle yapar; komut satırından yaparsanız sonucu ham hâliyle ve gecikmesiz görürsünüz.

IP adresiniz 185.10.20.30 ise ters çevrilmiş hâli 30.20.10.185 olur. Spamhaus'un birleşik zone'unu sorgulamak için:

dig +short 30.20.10.185.zen.spamhaus.org A

Cevap boşsa listede değilsiniz. Bir IP dönüyorsa listedesiniz ve dönen IP'nin son okteti hangi alt listede olduğunuzu söyler. Sebebi metin olarak almak için TXT kaydını da sorgulayın:

dig +short 30.20.10.185.zen.spamhaus.org TXT

Birkaç listeyi tek seferde taramak için küçük bir döngü işinizi görür:

IP=185.10.20.30
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
for BL in zen.spamhaus.org b.barracudacentral.org bl.spamcop.net \
          dnsbl.sorbs.net dnsbl-1.uceprotect.net psbl.surriel.com; do
  RESULT=$(dig +short $REV.$BL A)
  if [ -n "$RESULT" ]; then
    echo "LISTELI  $BL -> $RESULT"
  else
    echo "temiz    $BL"
  fi
done

Alan adı bazlı listeler de vardır ve bunlar IP'nizden bağımsız çalışır. Alan adınız spam mailin gövdesinde geçtiği için listelenmiş olabilirsiniz — sunucunuz hiç mail göndermemiş olsa bile:

dig +short sirketiniz.com.dbl.spamhaus.org A

dig çıktısını okumakta zorlanıyorsanız dig ve nslookup ile DNS sorgulama yazısı komutun tüm parametrelerini açıklıyor.

Spamhaus Listeleri Arasındaki Fark: SBL, CSS, XBL, PBL#

Spamhaus tek bir liste değildir; zen.spamhaus.org altında birleştirilmiş birkaç ayrı listedir ve hangisine düştüğünüz çözümü tamamen değiştirir. Türkçe kaynakların neredeyse hiçbiri bu ayrımı yapmaz, oysa yanlış listeye yanlış başvuruyu yapmak en sık görülen zaman kaybıdır.

Dönen IP'nin son oktetine göre:

Bu tablonun pratik karşılığı şudur:

PBL bir ceza değildir. PBL, IP bloğunun sahibi olan sağlayıcının "bu aralık dinamik/son kullanıcı alanıdır, buradan doğrudan mail çıkmamalı" diye kaydettirdiği bir politika listesidir. Yeni kurduğunuz bir sunucuda hiç mail göndermeden PBL'de çıkabilirsiniz. Çözümü sunucuyu temizlemek değildir; IP'nin mail sunucusu olarak tahsis edildiğini kaydettirmektir. Genellikle sağlayıcınıza rDNS/PTR kaydı ve statik tahsis talebi açtığınızda hâlledilir. Kendi başınıza da PBL'den çıkarma isteği gönderebilirsiniz, ama sağlayıcının bloğu için koyduğu genel kayıt duruyorsa geri gelir.

XBL sunucunuzda kötü yazılım var demektir. Bu listede çıkmak, sunucunuzun açık relay olduğunu, bir web formunun kötüye kullanıldığını ya da bir hesabın şifresinin çalınıp SMTP üzerinden spam atıldığını gösterir. Temizlemeden başvurmanın hiçbir anlamı yoktur.

CSS otomatik tespittir ve genellikle yeni/az ısıtılmış IP'lerde görülür. Uzun süre sessiz kalmış bir IP'den aniden binlerce pazarlama maili çıkarsa CSS tetiklenir. Çözüm gönderim hacmini kademelendirmek ve liste hijyenini düzeltmektir.

SBL en ağırıdır ve elle konur. Genellikle spam tuzağı (spamtrap) adreslerine mail düştüğünde ya da tekrarlayan şikâyetlerde uygulanır. Delisting başvurusu insan tarafından okunur; "temizledim" demek yetmez, ne olduğunu ve ne yaptığınızı anlatmanız beklenir.

Diğer Önemli Listeler ve Gerçek Ağırlıkları#

Onlarca DNSBL vardır ama hepsi aynı ağırlıkta değildir. Bir toplu sorgu aracında 5 kırmızı görmek panik yaratır; oysa o beşin dördü hiçbir büyük sağlayıcının kullanmadığı listeler olabilir.

Buradaki en önemli pratik bilgi: UCEPROTECT Level 2 ve Level 3, sizin IP'nizi değil, IP'nizin bulunduğu tüm bloğu veya AS numarasını listeler. Yani hiçbir şey yapmamış olabilirsiniz; aynı veri merkezindeki başka bir müşteri yüzünden kırmızı görünürsünüz. Bu listeleri ciddiye alan sistem sayısı çok azdır, ve delisting'i genellikle ücretli sunarlar. Öncelik sıranızı Spamhaus, Barracuda ve büyük sağlayıcıların iç itibar sistemlerine ayırın.

Listelenme Sebebini Sunucuda Bulma#

Sebebi bulmadan yapılan hiçbir işlem kalıcı değildir. Sunucunuza SSH ile bağlanıp şu sırayla bakın.

1. Mail kuyruğuna bakın. Kuyrukta binlerce mesaj birikmişse kaynak sunucunun içindedir.

Postfix için:

mailq | tail -1
postqueue -p | grep -c '^[A-F0-9]'

Exim (cPanel) için:

exim -bpc
exim -bp | head -40

2. Kuyruktaki mesajların kimden çıktığını sayın. Exim'de gönderen bazlı özet:

exim -bp | awk '/^ *[0-9]+[mhd]/{print $4}' | sort | uniq -c | sort -rn | head

Postfix'te log üzerinden:

grep "from=<" /var/log/mail.log | awk -F'from=<' '{print $2}' \
  | cut -d'>' -f1 | sort | uniq -c | sort -rn | head -20

3. Mailin bir web scriptinden çıkıp çıkmadığına bakın. cPanel/WHM sunucularında PHP mail() çağrıları hangi dosyadan geldiğini kayda geçer:

grep "cwd=/home" /var/log/exim_mainlog | awk '{print $NF}' \
  | sort | uniq -c | sort -rn | head

Çıktıda cwd=/home/musteri/public_html/wp-content/uploads gibi bir yol görüyorsanız, uploads dizinine yerleştirilmiş bir mailer scripti var demektir. Bu klasörde PHP çalışmasını kapatmak ilk müdahaledir.

4. SMTP kimlik doğrulamasıyla giren hesapları kontrol edin. Şifresi ele geçmiş bir mail hesabı, kendi sunucunuzu meşru şekilde kullanarak spam atar:

grep "sasl_username" /var/log/mail.log | awk -F'sasl_username=' '{print $2}' \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head

Bir hesap normalde günde 20 mail atarken 4.000 satırla listenin başındaysa sebebi buldunuz. O hesabın şifresini derhâl değiştirin, oturumlarını kapatın ve varsa yönlendirme/filtre kurallarına bakın — saldırganlar genellikle kanıtı gizlemek için gelen bounce'ları çöpe yönlendiren bir filtre bırakır. Bu senaryonun tam müdahale adımlarını mail hesabım ele geçirildi yazısında bulabilirsiniz.

5. Sunucunun açık relay olup olmadığını doğrulayın. Doğru yapılandırılmış bir sunucu, kimlik doğrulaması olmadan dışarıya mail kabul etmez. Dışarıdan bağlanıp kimlik doğrulamadan bir MAIL FROM / RCPT TO çifti denediğinizde beklenen cevap 554 Relay access denied benzeri bir rettir; 250 OK dönüyorsa sunucunuz açık relaydir ve derhâl kapatılmalıdır.

Sebep Durduğu Sürece Delisting Başvurusu Neden Reddedilir#

Delisting başvurularının reddedilmesinin tek bir yaygın sebebi vardır: liste operatörü, başvuru anında IP'den hâlâ spam trafiği görmektedir. Bu mekanizmayı anlamak, tekrar tekrar başvurup neden hiçbir şeyin değişmediğini anlamamaktan kurtarır.

Büyük listeler, spam tuzağı adreslerine (spamtrap) gelen mailleri gerçek zamanlı izler. Sunucunuzda kuyrukta bekleyen 40.000 mesaj varsa ve siz delisting yaptırsanız bile, kuyruk boşalmaya devam ettiği sürece o tuzaklara yeniden mail düşer ve IP dakikalar içinde tekrar listelenir. Üstelik çoğu listede tekrarlayan listelemeler bekleme süresini uzatır; ilk seferde birkaç saatte çıkabileceğiniz bir kayıt, üçüncü tekrarda günlerce sürebilir hâle gelir.

Bu yüzden doğru sıra kesindir:

1. Kaynağı durdurun (hesabı kilitleyin, scripti silin, formu kapatın).
2. Kuyruğu boşaltın. Meşru mailleri korumak isteseniz bile, spam kuyruktan çıkmaya devam ederken başvuru yapmayın.
3. Sunucudan test maili gönderip gerçekten temiz aktığını doğrulayın.
4. Ondan sonra delisting başvurusu yapın.

Kuyruktaki spam mesajlarını gönderene göre temizlemek için (Exim):

exim -bp | awk '/<[email protected]>/{print $3}' | xargs exim -Mrm

Postfix'te belirli gönderene ait mesajları silmek:

postqueue -p | awk '$7 ~ /[email protected]/ {print $1}' \
  | tr -d '*!' | xargs -n1 postsuper -d

Kuyruğun tamamını silmek son çaredir; meşru mailleri de yok eder. Gerçekten gerekiyorsa postsuper -d ALL ya da exim -bp | awk '{print $3}' | xargs exim -Mrm kullanılır, ama öncesinde kuyruk dizininin bir kopyasını almanız yerinde olur.

Delisting Başvurusu Adım Adım#

Kaynağı temizlediyseniz başvuru genellikle hızlı sonuçlanır. Her listenin süreci farklıdır ama beklentileri ortaktır.

Hazırlığınız şu olmalı:

• Listelenen IP adresi ve rDNS/PTR kaydının doğru kurulmuş olması. dig -x 185.10.20.30 +short komutu sunucunuzun HELO adıyla eşleşen bir hostname döndürmeli. Eşleşmiyorsa önce bunu düzeltin — PTR kaydı ve reverse DNS yazısı bu ayarı anlatıyor.
• SPF, DKIM ve DMARC kayıtlarının yayında olması. Bunlar delisting formunun sorusu değildir ama operatör sizi değerlendirirken bakar. Kurulumları için SPF, DKIM ve DMARC rehberi yeterlidir.
• Ne olduğunu anlatan 3-4 cümlelik net bir metin.

Başvuru metnini şöyle yazın (İngilizce yazmanız gerekir, ama önemli olan içeriktir):

On 2026-08-09 an e-mail account on our server ([email protected]) was compromised through a weak password and used to send unsolicited mail via authenticated SMTP. We have disabled the account, forced a password reset on all mailboxes, purged 12.400 messages from the outbound queue, enabled per-account hourly sending limits, and disabled PHP execution in user upload directories. Outbound volume has been normal for the last 6 hours. Please review for delisting.

Bu metnin işe yaramasının sebebi somut olmasıdır: tarih, kök sebep, alınan aksiyonlar, ölçülebilir sonuç. "We fixed the issue, please remove" tarzı metinler elle incelenen listelerde çoğunlukla geri döner.

Süreç listeye göre:

1. Spamhaus — Sorgu sayfasında IP'nizi arattığınızda kaydın türüne göre bir "Removal" bağlantısı çıkar. XBL ve PBL kayıtlarında otomatik kaldırma mümkündür; SBL ve bazı CSS kayıtlarında form insan tarafından okunur. Aynı IP için kısa sürede tekrar tekrar başvurmayın, bu değerlendirmeyi olumsuz etkiler.
2. Barracuda — Form doldurulur, ardından formda verdiğiniz adrese doğrulama maili gelir. O adres listelenen sunucunuz üzerinden çalışıyorsa mail size ulaşmayabilir; bu yüzden başvuruda farklı bir sağlayıcıdaki adresi kullanın. En sık yapılan hata budur.
3. SpamCop — Sebep durduysa genellikle 24 saat içinde otomatik düşer. Elle çıkarma da mümkündür ama sebep sürüyorsa anlamsızdır.
4. SORBS — Alt listeye göre farklı formlar vardır. Özellikle "spam" alt listesinde süreç yavaş işleyebilir; sabır gerektirir.
5. Google / Microsoft — Bunlar DNSBL değildir, ayrı gönderici destek formları vardır. Başvuru öncesi SPF/DKIM/DMARC'ın kusursuz olması ve şikâyet oranının düşmesi beklenir.

Başvuru sonrası doğrulamayı yine komutla yapın; web araçları önbellek gösterebilir:

dig +short 30.20.10.185.zen.spamhaus.org A

Boş dönüyorsa kayıt kalkmıştır. Ancak alıcı sunucuların kendi DNS önbellekleri (TTL süresince) eski cevabı bir süre daha tutabilir, bu yüzden birkaç saat içinde toparlanma normaldir.

Tekrar Listelenmeyi Kalıcı Olarak Önleme#

Delisting bir onarımdır, çözüm değildir. Aynı IP ikinci kez listelenirse hem çıkması zorlaşır hem itibarınız kalıcı hasar görür. Şu yedi önlem, yıllardır gördüğüm tekrar listelenmelerin neredeyse tamamını önler.

1. Hesap başına gönderim limiti koyun. Ele geçirilmiş bir hesabın saatler içinde binlerce mail atmasını engelleyecek tek şey budur. cPanel/WHM'de "Max hourly emails per domain" ve "Max emails per hour per account" ayarları vardır; kendi Postfix sunucunuzda policyd veya postfwd aynı sınırı kurar.

2. Kimlik doğrulamalı gönderimi 587'ye taşıyın ve 25'i sadece gelen mail için bırakın. Kullanıcı istemcilerinin 25 üzerinden kimlik doğrulayarak mail atmasına izin veren yapılandırmalar, ele geçirilmiş bir hesabın en rahat kullandığı kapıdır.

3. Kullanıcı dizinlerinde PHP mail() kullanımını izleyin. cPanel sunucularında gönderen scriptin yolunu loga yazan ayar açık olmalı; olmayan sunucularda kaynağı bulmak neredeyse imkânsızdır.

4. SPF, DKIM ve DMARC'ı eksiksiz kurun ve DMARC raporlarını okuyun. DMARC rua raporları, adınıza kimin mail attığını gösteren tek kaynaktır ve alan adınızın taklit edildiğini fark etmenin başka bir yolu yoktur.

5. Geri bildirim döngülerine (FBL) kaydolun. Büyük sağlayıcılar, kullanıcı "spam" dediğinde size bildirim gönderir. Bu bildirimleri işleyip adresi listenizden çıkarmazsanız şikâyet oranı büyür ve şikâyet oranı, itibarın en ağır bileşenidir.

6. Toplu gönderimi ayrı bir IP'den yapın. İşlem mailleri (şifre sıfırlama, sipariş onayı) ile pazarlama mailleri aynı IP'den çıkarsa, pazarlama tarafındaki bir hata sipariş onaylarını da durdurur. İki trafiği ayırmak, en kötü senaryoda bile ticari akışın ayakta kalmasını sağlar.

7. Yeni IP'yi ısıtın. Sıfırdan bir SMTP sunucusu kurup ilk gün 50.000 mail atmak, CSS listesine düşmenin en garantili yoludur. Hacmi günler içinde kademeli artırın.

Bunların üstüne basit bir izleme alışkanlığı ekleyin: kuyruk uzunluğunu beş dakikada bir kontrol edip eşik aşıldığında uyaran bir cron, saldırıyı saatler değil dakikalar içinde fark etmenizi sağlar.

*/5 * * * * [ $(exim -bpc) -gt 500 ] && echo "Kuyruk: $(exim -bpc)" | \
  mail -s "UYARI: mail kuyrugu sisti" [email protected]

Uyarının başka bir sağlayıcıdaki adrese gitmesi bilinçli bir tercihtir: kendi sunucunuz tıkandığında uyarı maili de tıkanmış kuyrukta bekler.

Sıkça Sorulan Sorular#

Kara listeden çıkmak ne kadar sürer#

Sebep gerçekten ortadan kalktıysa çoğu listede birkaç saat ile 48 saat arasıdır. SpamCop ve PSBL gibi otomatik listeler, trafik temiz kaldığı sürece kendiliğinden düşer. Spamhaus'un XBL ve PBL kayıtları başvuruyla dakikalar içinde kalkabilir. SBL gibi elle konan kayıtlarda ise başvurunuz bir insan tarafından okunur ve bu birkaç iş günü sürebilir. Süreyi uzatan en büyük etken, sebep durmadan yapılan tekrarlı başvurulardır.

Toplu sorgu aracında kırmızı görünüyorum ama mailler gidiyor, sorun var mı#

Çoğu durumda ciddi bir sorun yoktur. Toplu sorgu araçları onlarca listeyi tarar ve bunların büyük kısmını hiçbir büyük sağlayıcı kullanmaz. Özellikle UCEPROTECT Level 2 ve Level 3, sizin IP'nizi değil komşu IP bloğunu veya AS numarasını işaretler; sizin yapabileceğiniz bir şey yoktur ve pratik etkisi neredeyse sıfırdır. Önceliğiniz Spamhaus, Barracuda ve alıcı sağlayıcıların kendi iç itibar sistemleri olmalıdır.

Alan adım listelendi ama IP'm temiz, bu nasıl olur#

Alan adı bazlı listeler (örneğin Spamhaus DBL) IP'den bağımsız çalışır ve alan adınız spam mesajın gövdesinde bağlantı olarak geçtiği için konabilir. Bu genellikle sitenizin ele geçirilip yönlendirme sayfası barındırdığı ya da alan adınızın başkalarının gönderdiği spamde referans olarak kullanıldığı anlamına gelir. Önce sitede zararlı içerik olup olmadığını denetleyin, temizledikten sonra alan adı için ayrı delisting başvurusu yapın.

Sunucumu tamamen temizledim ama tekrar listelendim#

Neredeyse her zaman kaynak tam olarak kapatılmamıştır. En sık atlanan üç yer şunlardır: kuyrukta hâlâ eski spam mesajları bekliyordur, ele geçirilen hesabın oturumları kapatılmadığı için saldırgan bağlı kalmıştır, ya da web dizinine bırakılan scriptin bir kopyası başka bir klasörde durmaktadır. Kuyruğu boşaltın, tüm mail şifrelerini zorunlu olarak değiştirin ve dosya sistemini son değiştirilme tarihine göre tarayarak yeni eklenen PHP dosyalarını kontrol edin.

IP değiştirmek kara liste sorununu çözer mi#

Geçici olarak çözer, kalıcı olarak çözmez. Sebep sunucunun içindeyse yeni IP de aynı hızla listelenir ve elinizde iki lekeli IP kalır. Ayrıca yeni IP'nin geçmişi yoktur, bu da ilk günlerde "ısıtılmamış gönderici" olarak daha sıkı filtrelenmesi anlamına gelir. IP değişimi ancak kök sebep tamamen giderildikten sonra ve eski IP'nin itibarı onarılamayacak durumdaysa mantıklıdır.

Paylaşımlı hostingteysem kara listeden ben mi çıkaracağım#

Hayır, paylaşımlı hostingte sunucunun IP'si sağlayıcıya aittir ve delisting başvurusunu sağlayıcı yapar. Sizin sorumluluğunuz, listelenmeye kendi hesabınız sebep olduysa onu düzeltmektir: ele geçirilmiş WordPress kurulumunu temizlemek, güvensiz iletişim formunu kapatmak, zayıf mail şifresini değiştirmek gibi. Sağlayıcıya destek kaydı açarken bulgularınızı da yazın; bu, hem çözümü hızlandırır hem hesabınızın askıya alınmasını önler.

Kendi sunucumda mı yoksa özel bir SMTP sunucusunda mı mail göndermeliyim#

Düzenli ve hacimli gönderim yapıyorsanız mail trafiğini web sitenizin çalıştığı sunucudan ayırmak en sağlıklısıdır. Aynı sunucuda hem site hem mail çalışırken, sitedeki bir güvenlik açığı mail itibarınızı da yakar; ayrı bir SMTP sunucusunda ise yalıtım vardır ve gönderim limitleri, rDNS, imza ayarları o iş için yapılandırılabilir. Az sayıda kurumsal mail için ise hosting üzerindeki mail hizmeti fazlasıyla yeterlidir.

Kapanış#

Kara liste sorunu, göründüğünden daha mekaniktir: bounce mesajını okuyun, dig ile hangi listede olduğunuzu kesinleştirin, dönen kaydın son oktetine bakıp SBL mi PBL mi olduğunu ayırt edin, sunucunun içinde kaynağı bulun, kuyruğu boşaltın ve ancak ondan sonra başvuru yapın. Bu sıradan sapan her deneme ya reddedilir ya da geçici olur. Uzun vadede sizi koruyacak olan ise delisting becerisi değil, gönderim limitleri, doğru kurulmuş SPF/DKIM/DMARC, çalışan bir PTR kaydı ve kuyruğu izleyen basit bir uyarıdır.

Bu işi kendi başınıza sürdürmek istemiyorsanız işi bölmek en mantıklısıdır. Düzenli ve hacimli gönderim yapıyorsanız mail trafiğini siteden ayıran bir SMTP sunucusu kurulu hâlde teslim edilir; birkaç kurumsal adrese ihtiyacınız varsa e-posta hizmeti sayfasındaki paketler bu işi zaten üstlenir. Sunucudaki kaynağı bulup temizlemek, gönderim limitlerini kurmak ve kuyruk izlemesini ayakta tutmak için teknik bir ele ihtiyacınız varsa sunucu yönetimi hizmeti tam olarak bu bakımı kapsar.