Ana sayfa › Rehberler

Kara Liste İzleme: Betikler, API ve Webhook Uyarıları

Yayın tarihi 2026-11-03 ／ Güncelleme 2026-11-03 ／ Yayımlayan Yuki Nakazawa

Kara liste izleme, gönderen IP'lerinizi ve alan adlarınızı belirli aralıklarla birkaç DNS engelleme listesinde (DNSBL) sorgulamak ve yalnızca bir sonuç değiştiğinde uyarı vermek demektir. Bir kaydı müşteriler geri dönen e-postaları bildirdiğinde değil, gerçekleştiği anda yakalamak, zarar yayılmadan önce nedeni bulmanız ve kaldırma talebinde bulunmanız için size zaman kazandırır.

Bunu yapmanın iki pratik yolu vardır: küçük bir dig ve cron betiğini kendiniz çalıştırmak ya da kontrolleri bir API ve webhook'lar aracılığıyla bir hizmete devretmek. Her iki durumda da izleyicinin doğruyu söyleyip söylemediğini iki ayrıntı belirler: genel çözümleyiciler üzerinden gönderilen sorgular Spamhaus gibi listeler tarafından reddedilir ve yanıltıcı yanıtlar üretir; hata kodları da asla kayıt olarak sayılmamalıdır.

Burada aktarılan liste işletmecisi kuralları, Kasım 2026 itibarıyla resmî sayfalarına dayanır. Politikalar değişir; bir kuruluma güvenmeden önce bunları doğrulayın. DNSBL'lerin nasıl çalıştığına dair arka plan için DNSBL (RBL) nedir yazısına bakın.

Neyi izleyeceğinize ve hangi listeleri sorgulayacağınıza karar verin

İşe gerçekten izlemeniz gereken nesneleri yazarak başlayın.

• Gönderen IP adresleri. E-posta sunucunuzun veya e-posta sağlayıcınızın gerçekte gönderim yaptığı adreslerdir. Web siteniz ve e-postalarınız çoğu zaman farklı makinelerden çıkar; bu yüzden adresi gönderdiğiniz bir iletinin Received başlıklarından doğrulayın. IPv6 üzerinden gönderim yapıyorsanız bu adresleri de izleyin.
• Alan adları. From adresinizdeki alan adı ve iletilerinizdeki bağlantılarda geçen tüm alan adları. Alan adları, IP listelerinden ayrı olan alan adı engelleme listelerinde kontrol edilir.

Sorgu biçimi RFC 5782'de tanımlanmıştır. IPv4'te sekizlileri ters çevirip listenin bölgesini eklersiniz; böylece bir listede 192.0.2.99, ardından bölge adı gelen 99.2.0.192 olur. IPv6'da adres ters sırada 32 onaltılık nibble olarak yazılır. Alan adı ise doğrudan bölgenin önüne eklenir. Listelenmiş bir giriş, geleneksel olarak 127.0.0.0/8 aralığında bir A kaydı döndürür; listelenmemiş bir giriş NXDOMAIN döndürür. RFC ayrıca listelerin, listelenme nedenini açıklayan bir TXT kaydı yayımlaması gerektiğini belirtir.

Alıcıların hepsi aynı listeleri kullanmadığından tek bir liste yerine birkaç listeyi izleyin. Her dönüş kodunun anlamı işletmeciye göre değişir; DNSBL dönüş kodları rehberimiz yaygın olanları ele alır.

Genel çözümleyiciler neden yanlış yanıt verir

Kendi yazdığınız izleme sistemlerinde sık yapılan bir hata, sorguları Google Public DNS (8.8.8.8) veya Cloudflare (1.1.1.1) gibi bir genel çözümleyici üzerinden göndermektir. Spamhaus'un resmî DNSBL kullanım SSS'si ne olduğunu açıklar:

• Spamhaus DNSBL'lerinin ücretsiz kullanımı, kullanımın ticari olmamasını ve sorguların genel veya açık bir çözümleyiciden ya da jenerik ters DNS'e sahip bir IP'den gelmemesini gerektirir.
• Google Public DNS gibi ücretsiz açık çözümleyiciler üzerinden yapılan sorgular çoğu durumda listelenmemiş (NXDOMAIN) yanıtı alır. Başka bir deyişle listelenmiş bir IP temiz görünebilir.
• Genel bir çözümleyici üzerinden yapılan sorgular 127.255.255.254 yanıtı da alabilir. Bu bir kayıt değil, hata kodudur. Benzer şekilde 127.255.255.252 DNSBL adında bir yazım hatası, 127.255.255.255 ise aşırı sayıda sorgu anlamına gelir. Spamhaus, bu kodların sorgulanan nesnenin listelendiği şeklinde yorumlanmaması gerektiğini belirtir.
• NXDOMAIN yanıtlarını yeniden yazan çözümleyiciler bunun yerine bir IP adresi döndürür; böylece doğru NXDOMAIN yanıtını hiç görmezsiniz.

SSS'nin en önemli önerisi kendi DNS çözümleyicinizi çalıştırmanızdır. Genel bir çözümleyicide kalmak zorunda olan kullanıcılar için Spamhaus, Data Query Service'i (DQS) önerir; neyin ücretsiz olduğunu koşullarından kontrol edin. SSS, gerçekte hangi çözümleyiciyi kullandığınızı görmek için dig txt whoami.fastly.net komutunu önerir.

RFC 5782 yerleşik bir sağlamlık kontrolü de ekler: bir IPv4 listesi 127.0.0.2 için bir giriş içermeli ve 127.0.0.1'i içermemelidir; istemciler de listenin çalıştığını doğrulamak için bu test girişlerini düzenli olarak kontrol etmelidir. Spamhaus'un örneğinde 2.0.0.127.zen.spamhaus.org 127.0.0.10, 127.0.0.4 ve 127.0.0.2 döndürürken 1.0.0.127.zen.spamhaus.org NXDOMAIN döndürür. Bir izleyici önce bunu test etmeli ve başarısız olursa o çalıştırmanın sonuçlarını atmalıdır.

Seçenek 1: dig ve cron betiği

Aşağıda, bir IPv4 adresini Spamhaus ZEN ve SpamCop'ta (SpamCop'un belgelerine göre bl.spamcop.net listelenmiş bir IP için 127.0.0.2 yanıtı verir) kontrol eden minimal bir betik yer alıyor. Adresi ve bölgeleri kendinizinkilerle değiştirin.

#!/bin/sh
# Kendi özyinelemeli çözümleyicinizi sorgulayın (ör. aynı makinedeki unbound), asla genel bir çözümleyiciyi değil
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # 127.0.0.2 test girişi bir kayıt koduna çözümlenmiyorsa bu çalıştırmaya güvenmeyin
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

Betiğin yaptıkları:

• Yalnızca NXDOMAIN durumu temiz sayılır, 127.255.255.x bir hatadır ve diğer tüm 127.x yanıtları kayıttır. 127.0.0.0/8 dışındaki her şey, yeniden yazan bir çözümleyici gibi bir anormallik olarak değerlendirilir.
• Zaman aşımı dig'in sıfırdan farklı bir kodla çıkmasına yol açarken SERVFAIL ve REFUSED 0 ile çıkar. Bunların hiçbiri temiz sayılmaz; betik bir hata kaydeder.
• Dönüş kodları listeye özgüdür. Örneğin bazı listeler sorgunun reddedildiğini belirtmek için 127.0.0.1 kullanır; bu nedenle eklediğiniz her listenin belgelerini okuyun ve gerektiğinde case ifadesini genişletin.

Ardından cron'un her çalıştırmayı bir öncekiyle karşılaştırmasını ve yalnızca bir şey değiştiğinde e-posta göndermesini sağlayın:

# Örnek: saatte bir çalıştır, yalnızca çıktı bir önceki çalıştırmadan farklıysa e-posta gönder
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

Saatlik aralık yalnızca bir örnektir. Spamhaus düşük hacimli, ticari olmayan kullanım için ücretsiz erişim sunar; sorgu hacmi eşiğini aşan istemcilerin ücretli bir seçeneğe ihtiyacı vardır. İzlediğiniz IP sayısı arttıkça her listenin koşullarını kontrol edin. SSS ayrıca sonuçların aynı kaldığını doğrulamak için komutları birkaç kez denemenizi önerir.

Seçenek 2: DNSBL Checker toplu API'si ve webhook'lar

Bir çözümleyici ve liste bazında ayrıştırma kuralları bakımıyla uğraşmak istemiyorsanız kontrolleri bir hizmete bırakabilirsiniz. Aşağıda bu sitenin v1 API'si, sunucu uygulamasının gerçekte yaptıklarıyla sınırlı olarak açıklanmaktadır. Başvuru belgeleri /en/api-docs adresindedir ve anahtarlar /account adresindeki üye sayfasında verilir. Kayıt için yalnızca bir e-posta adresi gerekir ve e-postayla gönderilen bir bağlantıyla oturum açarsınız.

Kimlik doğrulama ve sınırlar

• Anahtarlar dnsbl_ ile başlar ve oluşturulduktan hemen sonra yalnızca bir kez gösterilir; yalnızca bir hash saklanır. Anahtarı yeniden oluşturmak öncekini geçersiz kılar.
• Anahtarı her istekte X-API-Key başlığında gönderin. Yalnızca HTTPS kullanılır; düz http:// adresi https:// adresine yönlendirilir, bu yüzden en baştan https:// çağırın.
• Sınırlar günde 1.000 kontrol (bir hedef bir kontrol sayılır), toplu istek başına 100 hedef ve 50 izleme kaydıdır. Günlük sınır aşıldığında daily_limit_exceeded ve bir resets_at zaman damgasıyla birlikte 429 alırsınız.

Toplu kontroller

Alan adlarından veya IP adreslerinden oluşan bir targets dizisini POST /api/v1/batch adresine gönderin:

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

Herhangi bir hedefin hâlâ kontrol edilmesi gerekiyorsa yanıt, bir batch_id ile birlikte 202 olur. status değeri done olana kadar birkaç saniyede bir GET /api/v1/batch/{batch_id} adresini sorgulayın (kısaltılmış örnek; sayılar ve liste adı gerçek bir sonuç değil, temsilîdir):

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• En az bir liste kayıt bildirirse verdict değeri listed, aksi takdirde clean olur. Zaman aşımına uğrayan veya 127.255.255.x gibi bir hata koduyla yanıt veren listeler error_count içinde sayılır ve asla kayıt olarak sayılmaz.
• Son 30 güne ait saklanmış bir sonuç varsa toplu istek onu döndürür. Zamanlanmış izlemede her zaman checked_at değerine bakın.
• Hatalı biçimlendirilmiş hedefler bir nedenle birlikte rejected içinde döner ve sayılmaz. Bir URL verirseniz yalnızca ana bilgisayar adı kullanılır. 192.0.2.0/24 gibi yalnızca belgelerde kullanılan aralıklar reddedilir; bu yüzden gerçek bir gönderen IP ile test edin.

Webhook ile izleme

POST /api/v1/monitors ile bir target ve bir callback_url kaydedin. Kaydedilen her hedef bundan sonra önbellek kullanılmadan günde bir kez kontrol edilir (ilk kontrol kayıttan sonra yaklaşık bir gün içinde yapılır) ve URL'nize yalnızca ilk kontrolde (monitor.initial) ve sonuç listed ile clean arasında değiştiğinde (monitor.status_changed) bir JSON POST gönderilir.

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• Yanıttaki signing_secret yalnızca bir kez gösterilir. Her gönderim, ham gövdenin bu gizli anahtarla hesaplanan HMAC-SHA256 değeri olan bir X-DNSBL-Signature: sha256=... başlığı taşır. Bunu kendi tarafınızda doğrulayın.
• callback_url, 443 numaralı portta https olmalı ve genel bir IP'ye çözümlenmelidir; yönlendirmeler izlenmez ve zaman aşımı 10 saniyedir. Bu nedenle ağır işleri kuyruğa alın ve hızlı yanıt verin.
• Uç noktanız 2xx dışında bir yanıt döndürürse veya bağlantı başarısız olursa gönderim bir sonraki günlük kontrolde yeniden denenir. Neden, GET /api/v1/monitors içinde last_delivery_error olarak görünür; DELETE /api/v1/monitors/{monitor_id} ise bir izleyiciyi kaldırır.

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

Uyarı tasarımı: sıklık, birden fazla liste ve yanlış alarmlar

Bir izleyici, ancak insanlar birkaç ay sonra da uyarılarını okumaya devam ediyorsa işe yarar. Sürekli uyarı veren bir izleyici kısa sürede görmezden gelinir.

Sıklık

• Ne sıklıkla sorguladığınızı ne sıklıkla bildirim gönderdiğinizden ayırın. Belirli aralıklarla sorgulayın, ancak yalnızca durum değiştiğinde bildirim gönderin. Her gün gelen bir "her şey yolunda" mesajı, önemli olan tek uyarıyı gömer.
• RFC 5782, liste TTL'lerinin listenin ne kadar hızlı değiştiğini yansıtması gerektiğini ve spam kaynağı listelerinin dakikalar düzeyinde TTL'ler kullanabileceğini söyler. Aralığınızı, bazı kayıtların hızla ortaya çıkıp düştüğünü bilerek seçin.
• Yoğun sorgulama, bir listenin kullanım koşullarını ihlal edebilir veya gerçek yanıtlar yerine 127.255.255.255 (aşırı sorgu) almanıza yol açabilir.

Birden fazla liste

• Her uyarıya listenin adını ekleyin. Listeler, kaç alıcının onları kullandığı açısından farklılık gösterir; alıcılarınız için en önemli listelerde hemen uyarı verip geri kalanını bir özette toplayabilirsiniz.
• Yukarıdaki webhook yalnızca sonuç listed ile clean arasında değiştiğinde tetiklenir. Bir hedef zaten listelenmişken ikinci bir listede de görünürse olay gönderilmez. Bu durumu yakalamak için GET /api/v1/monitors içindeki last_listed_count değerini izleyin ya da bir toplu istek çalıştırıp listed_on değerini okuyun.

Yanlış pozitifler ve geçici yanıtlar

• Hataları kayıtlardan ayrı kaydedin. Spamhaus, işletmecileri hata kodlarına dayanarak e-postaları reddetmemeleri veya filtrelememeleri konusunda uyarır; aynı mantık izleme için de geçerlidir. Bir zaman aşımı veya 127.255.255.x yanıtı asla kayıt uyarısı tetiklememelidir.
• Tek bir tuhaf sonuca tepki vermemek için yalnızca art arda iki aynı sonuçtan sonra uyarı verin ya da bir şey göndermeden önce birkaç dakika sonra yeniden sorgulayın.
• Hatalar sürerse bir çözümleyici değişikliğinden veya liste tarafındaki bir değişiklikten şüphelenin ve önce test girişi sonucuna bakın.
• Spamhaus PBL'deki ev tipi bir IP bir suçlama değil, bir politika kaydıdır: adresin doğrudan e-posta göndermemesi gerektiği anlamına gelir. Neyin uyarı sayılacağına liste bazında karar verin (bkz. Spamhaus'tan çıkma).

Bir kayıt tespit edildiğinde ne yapmalı

1. Doğrulayın. İşletmecinin kendi sorgulama sayfasını kontrol edin ve liste adını, zamanı ve gösterilen nedeni not edin.
2. Önce nedeni giderin. Ele geçirilmiş hesapları, kötüye kullanılan web formlarını, virüslü makineleri, kötü liste hijyenini ve eşleşmeyen ters DNS (PTR) veya HELO adlarını araştırın. Neden devam ederken kaldırma talep etmek genellikle yeni bir kayda yol açar.
3. O listenin kaldırma sürecini izleyin. Listeden çıkarma kararı her liste işletmecisine aittir ve talep göndermek kaydın kaldırılacağı anlamına gelmez. Paylaşımlı hostingde olduğu gibi IP'yi siz kontrol etmiyorsanız hosting sağlayıcınızla veya İSS'nizle iletişime geçin.
4. Sonucu izleyicinin doğrulamasına izin verin. Alıcılar kendi filtrelerini de çalıştırır; bu nedenle sonuç clean'e döndükten sonra da teslimatı gözlemlemeye devam edin.

Bir IP'ye veya alan adına tek seferlik bakmak için kara liste kontrol aracını kullanın. Nedenin izini sürmek veya talepleri yürütmek üstlenebileceğinizden fazlaysa bizden yardım isteyebilirsiniz. E-postalar geri dönüyorsa sorun gidermenin tam yolu için kara listeler yüzünden engellenen e-postalar yazısına bakın.

Sık sorulan sorular

Kullanılan resmî sayfalar

Bu makaledeki bilgiler, yayın tarihinde aşağıdaki resmî sayfalarla karşılaştırılarak doğrulanmıştır. Politikalar ve işleyiş haber verilmeden değişebilir; önemli bir konuda karar vermeden önce resmî sayfaları kontrol edin.

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

İlgili rehberler

Tüm rehberler →