Beranda › Panduan

Pemantauan Blacklist: Skrip, API, dan Notifikasi Webhook

Diterbitkan 2026-11-03 ／ Diperbarui 2026-11-03 ／ Oleh Yuki Nakazawa

Pemantauan blacklist berarti melakukan kueri ke beberapa daftar blokir DNS (DNSBL) untuk IP dan domain pengirim Anda secara terjadwal, dan baru memunculkan peringatan ketika ada hasil yang berubah. Mengetahui pencantuman saat itu juga, bukan ketika pelanggan melaporkan email yang terpental, memberi Anda waktu untuk menemukan penyebabnya dan meminta penghapusan sebelum dampaknya meluas.

Ada dua cara praktis untuk melakukannya: menjalankan sendiri skrip kecil berbasis dig dan cron, atau menyerahkan pengecekan kepada sebuah layanan melalui API dan webhook. Apa pun caranya, ada dua detail yang menentukan apakah pemantauan memberikan hasil yang benar: kueri yang dikirim melalui resolver publik ditolak oleh daftar seperti Spamhaus dan menghasilkan jawaban yang menyesatkan, dan kode galat sama sekali tidak boleh dihitung sebagai pencantuman.

Aturan operator daftar yang dikutip di sini didasarkan pada halaman resmi mereka per November 2026. Kebijakan dapat berubah, jadi pastikan kembali sebelum Anda mengandalkan sebuah konfigurasi. Untuk latar belakang cara kerja DNSBL, lihat apa itu DNSBL (RBL).

Tentukan apa yang dipantau dan daftar mana yang dikueri

Mulailah dengan mencatat objek yang benar-benar perlu Anda pantau.

• Alamat IP pengirim. Ini adalah alamat yang benar-benar dipakai server email atau penyedia email Anda untuk mengirim. Situs web dan email Anda sering keluar dari mesin yang berbeda, jadi pastikan alamatnya melalui header Received pada pesan yang Anda kirim. Jika Anda mengirim melalui IPv6, pantau juga alamat-alamat tersebut.
• Domain. Domain pada alamat From Anda dan domain apa pun yang muncul di tautan dalam pesan Anda. Domain diperiksa terhadap daftar blokir domain, yang terpisah dari daftar IP.

Format kueri didefinisikan dalam RFC 5782. Untuk IPv4, Anda membalik urutan oktet lalu menambahkan zona daftar, sehingga 192.0.2.99 pada sebuah daftar menjadi 99.2.0.192 diikuti nama zona. Untuk IPv6, alamat ditulis sebagai 32 nibble heksadesimal dalam urutan terbalik. Domain cukup ditempatkan di depan zona. Entri yang tercantum mengembalikan record A, menurut konvensi dalam rentang 127.0.0.0/8; entri yang tidak tercantum mengembalikan NXDOMAIN. RFC juga mencatat bahwa daftar sebaiknya memublikasikan record TXT yang menjelaskan alasan pencantuman.

Pantau beberapa daftar, bukan hanya satu, karena tidak semua penerima memakai daftar yang sama. Arti setiap kode balasan berbeda-beda menurut operatornya; panduan kami tentang kode balasan DNSBL membahas kode-kode yang umum.

Mengapa resolver publik memberikan jawaban yang salah

Kesalahan umum pada pemantauan buatan sendiri adalah mengirim kueri melalui resolver publik seperti Google Public DNS (8.8.8.8) atau Cloudflare (1.1.1.1). FAQ resmi penggunaan DNSBL dari Spamhaus menjelaskan apa yang terjadi:

• Penggunaan gratis DNSBL Spamhaus mensyaratkan bahwa penggunaannya nonkomersial dan bahwa kueri tidak berasal dari resolver publik atau terbuka, maupun dari IP dengan reverse DNS generik.
• Melalui resolver terbuka gratis seperti Google Public DNS, kueri dalam sebagian besar kasus akan mendapat balasan tidak tercantum (NXDOMAIN). Dengan kata lain, IP yang tercantum bisa tampak bersih.
• Kueri melalui resolver publik juga dapat menerima 127.255.255.254. Itu adalah kode galat, bukan pencantuman. Demikian pula, 127.255.255.252 berarti ada salah ketik pada nama DNSBL, dan 127.255.255.255 berarti jumlah kueri berlebihan. Spamhaus menyatakan bahwa kode-kode ini tidak boleh diartikan bahwa objek yang dikueri tercantum.
• Resolver yang menulis ulang jawaban NXDOMAIN mengembalikan alamat IP sebagai gantinya, sehingga Anda tidak pernah melihat NXDOMAIN yang benar.

Rekomendasi utama FAQ tersebut adalah menjalankan resolver DNS sendiri. Bagi pengguna yang harus tetap memakai resolver publik, Spamhaus mengarahkan ke Data Query Service (DQS) miliknya; periksa ketentuannya untuk mengetahui apa yang gratis. FAQ tersebut menyarankan dig txt whoami.fastly.net untuk melihat resolver mana yang sebenarnya Anda pakai.

RFC 5782 menambahkan pemeriksaan kewajaran bawaan: daftar IPv4 harus memuat entri untuk 127.0.0.2 dan tidak boleh memuat 127.0.0.1, dan klien sebaiknya memeriksa entri uji ini secara berkala untuk memastikan daftar berfungsi. Dalam contoh Spamhaus, 2.0.0.127.zen.spamhaus.org mengembalikan 127.0.0.10, 127.0.0.4, dan 127.0.0.2, sedangkan 1.0.0.127.zen.spamhaus.org mengembalikan NXDOMAIN. Pemantauan sebaiknya menguji hal ini terlebih dahulu dan membuang hasil putaran tersebut jika gagal.

Opsi 1: skrip dig dan cron

Berikut skrip minimal yang memeriksa satu alamat IPv4 terhadap Spamhaus ZEN dan SpamCop (bl.spamcop.net, yang menurut dokumentasi SpamCop menjawab 127.0.0.2 untuk IP yang tercantum). Ganti alamat dan zonanya dengan milik Anda.

#!/bin/sh
# Kueri ke resolver rekursif milik sendiri (misalnya unbound di host yang sama), jangan ke resolver publik
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
  # Jika entri uji 127.0.0.2 tidak menghasilkan kode pencantuman, jangan percayai putaran ini
  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

Yang dilakukan skrip ini:

• Hanya status NXDOMAIN yang dihitung bersih, 127.255.255.x adalah galat, dan 127.x lainnya adalah pencantuman. Apa pun di luar 127.0.0.0/8 diperlakukan sebagai anomali, misalnya resolver yang menulis ulang jawaban.
• Timeout membuat dig keluar dengan kode bukan nol, sedangkan SERVFAIL dan REFUSED keluar dengan 0. Tidak satu pun dari ketiganya diperlakukan sebagai bersih; skrip mencatatnya sebagai galat.
• Kode balasan bersifat khusus untuk tiap daftar. Misalnya, sebagian daftar memakai 127.0.0.1 untuk menyatakan bahwa kueri ditolak, jadi baca dokumentasi setiap daftar yang Anda tambahkan dan perluas pernyataan case bila perlu.

Kemudian biarkan cron membandingkan setiap putaran dengan putaran sebelumnya dan hanya mengirim email ketika ada perubahan:

# Contoh: jalankan tiap jam, kirim email hanya jika output berbeda dari putaran sebelumnya
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

Interval per jam ini hanya contoh. Spamhaus menyediakan akses gratis untuk penggunaan bervolume rendah dan nonkomersial, dan klien yang melampaui ambang volume kuerinya memerlukan opsi berbayar; periksa ketentuan setiap daftar seiring bertambahnya jumlah IP yang Anda pantau. FAQ tersebut juga menyarankan untuk mencoba perintah beberapa kali guna memastikan hasilnya tetap sama.

Opsi 2: API batch dan webhook DNSBL Checker

Jika Anda tidak ingin mengelola resolver dan aturan parsing per daftar, Anda dapat menyerahkan pengecekan kepada sebuah layanan. Berikut adalah API v1 situs ini, sebatas apa yang benar-benar dilakukan oleh implementasi servernya. Referensinya ada di /en/api-docs dan kunci diterbitkan di halaman anggota di /account. Pendaftaran hanya memerlukan alamat email, dan Anda masuk dengan tautan yang dikirim melalui email.

Autentikasi dan batasan

• Kunci diawali dengan dnsbl_ dan hanya ditampilkan sekali, tepat setelah diterbitkan; yang disimpan hanya hash-nya. Menerbitkan ulang kunci akan membatalkan kunci sebelumnya.
• Kirim kunci di header X-API-Key pada setiap permintaan. Hanya HTTPS; http:// biasa dialihkan ke https://, jadi panggil https:// sejak awal.
• Batasannya adalah 1.000 pengecekan per hari (satu target dihitung satu), 100 target per batch, dan 50 pendaftaran monitor. Jika melampaui batas harian, Anda akan menerima 429 dengan daily_limit_exceeded dan stempel waktu resets_at.

Pengecekan batch

Kirim array targets berisi nama domain atau alamat IP ke POST /api/v1/batch:

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"]}'

Jika masih ada target yang perlu diperiksa, responsnya adalah 202 dengan batch_id. Lakukan polling ke GET /api/v1/batch/{batch_id} setiap beberapa detik hingga status bernilai done (contoh ringkas; angka dan nama daftar hanya ilustrasi, bukan hasil sebenarnya):

{
  "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" }
      ]
    }
  ]
}

• verdict bernilai listed jika setidaknya satu daftar melaporkan pencantuman, dan clean jika tidak. Daftar yang mengalami timeout, atau menjawab dengan kode galat seperti 127.255.255.x, dihitung dalam error_count dan tidak pernah dihitung sebagai pencantuman.
• Batch mengembalikan hasil tersimpan jika ada hasil dari 30 hari terakhir. Untuk pemantauan terjadwal, selalu perhatikan checked_at.
• Target dengan format yang salah dikembalikan di rejected beserta alasannya dan tidak dihitung. Jika Anda mengirim URL, hanya nama host yang dipakai. Rentang khusus dokumentasi seperti 192.0.2.0/24 ditolak, jadi lakukan pengujian dengan IP pengirim yang sebenarnya.

Pemantauan dengan webhook

Daftarkan target dan callback_url dengan POST /api/v1/monitors. Setiap target yang terdaftar kemudian diperiksa sekali sehari tanpa memakai cache (pengecekan pertama berjalan dalam waktu sekitar satu hari setelah pendaftaran), dan POST berformat JSON dikirim ke URL Anda hanya pada pengecekan pertama (monitor.initial) dan ketika verdict berubah antara listed dan clean (monitor.status_changed).

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"}'

• signing_secret dalam respons hanya ditampilkan sekali. Setiap pengiriman membawa header X-DNSBL-Signature: sha256=..., yaitu HMAC-SHA256 dari body mentah dengan secret tersebut sebagai kunci. Verifikasilah di sisi Anda.
• callback_url harus berupa https di port 443 dan me-resolve ke IP publik; pengalihan (redirect) tidak diikuti, dan batas waktunya 10 detik, jadi masukkan pekerjaan berat ke antrean dan jawab dengan cepat.
• Jika endpoint Anda mengembalikan apa pun selain 2xx, atau koneksi gagal, pengiriman dicoba ulang pada pengecekan harian berikutnya. Alasannya muncul sebagai last_delivery_error di GET /api/v1/monitors, dan DELETE /api/v1/monitors/{monitor_id} menghapus sebuah monitor.

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", ""))

Merancang notifikasi: frekuensi, banyak daftar, dan alarm palsu

Pemantauan hanya berguna jika orang masih membaca peringatannya setelah beberapa bulan. Pemantauan yang terus-menerus berbunyi akan segera diabaikan.

Frekuensi

• Pisahkan seberapa sering Anda melakukan kueri dari seberapa sering Anda mengirim notifikasi. Lakukan kueri secara terjadwal, tetapi kirim notifikasi hanya ketika status berubah. Pesan harian "semua aman" akan menenggelamkan satu peringatan yang benar-benar penting.
• RFC 5782 menyebutkan bahwa TTL daftar sebaiknya mencerminkan seberapa cepat daftar berubah, dan daftar sumber spam dapat memakai TTL dalam hitungan menit. Pilih interval Anda dengan menyadari bahwa sebagian pencantuman muncul dan kedaluwarsa dengan cepat.
• Kueri yang berlebihan dapat melanggar ketentuan penggunaan daftar atau membuat Anda menerima 127.255.255.255 (kueri berlebihan) alih-alih jawaban yang sebenarnya.

Beberapa daftar

• Sertakan nama daftar di setiap peringatan. Daftar berbeda-beda dalam hal seberapa banyak penerima yang memakainya, jadi Anda dapat langsung mengirim peringatan untuk daftar yang paling penting bagi penerima Anda dan menggabungkan sisanya ke dalam ringkasan.
• Webhook di atas hanya terpicu ketika verdict berubah antara listed dan clean. Jika sebuah target sudah tercantum lalu muncul di daftar kedua, tidak ada event yang dikirim. Perhatikan last_listed_count di GET /api/v1/monitors, atau jalankan batch dan baca listed_on, untuk menangkap kasus tersebut.

False positive dan jawaban sesaat

• Catat galat secara terpisah dari pencantuman. Spamhaus memperingatkan operator agar tidak menolak atau menyaring email berdasarkan kode galatnya; logika yang sama berlaku untuk pemantauan. Timeout atau jawaban 127.255.255.x tidak boleh memicu peringatan pencantuman.
• Agar tidak bereaksi terhadap satu hasil yang janggal, kirim peringatan hanya setelah dua hasil identik berturut-turut, atau lakukan kueri ulang beberapa menit kemudian sebelum mengirim apa pun.
• Jika galat terus berlanjut, curigai adanya perubahan resolver atau perubahan di sisi daftar, dan periksa hasil entri uji terlebih dahulu.
• IP rumahan di Spamhaus PBL adalah pencantuman berdasarkan kebijakan, bukan tuduhan: artinya alamat tersebut tidak semestinya mengirim email secara langsung. Tentukan per daftar apa yang dianggap sebagai peringatan (lihat penghapusan dari Spamhaus).

Yang perlu dilakukan saat pencantuman terdeteksi

1. Konfirmasikan. Periksa halaman pengecekan milik operator dan catat nama daftar, waktunya, serta alasan apa pun yang ditampilkan.
2. Atasi penyebabnya terlebih dahulu. Cari akun yang disusupi, formulir web yang disalahgunakan, mesin yang terinfeksi, pengelolaan daftar penerima yang buruk, serta reverse DNS (PTR) atau nama HELO yang tidak cocok. Meminta penghapusan selagi penyebabnya masih ada biasanya berujung pada pencantuman baru.
3. Ikuti proses penghapusan daftar tersebut. Keputusan penghapusan berada di tangan masing-masing operator daftar, dan mengajukan permintaan tidak menjamin pencantuman akan dicabut. Jika Anda tidak mengendalikan IP tersebut, seperti pada shared hosting, hubungi penyedia hosting atau ISP Anda.
4. Biarkan pemantauan mengonfirmasi hasilnya. Penerima juga menjalankan filter sendiri, jadi tetap pantau pengiriman setelah verdict kembali menjadi clean.

Untuk pengecekan sekali waktu terhadap IP atau domain, gunakan pemeriksa blacklist. Jika menelusuri penyebab atau menangani permintaan terlalu berat bagi Anda, Anda dapat meminta bantuan kami. Untuk jalur pemecahan masalah selengkapnya ketika email terpental, lihat email yang diblokir karena blacklist.

Tanya jawab

Halaman resmi yang digunakan

Fakta dalam artikel ini telah diperiksa berdasarkan halaman resmi di bawah ini pada saat diterbitkan. Kebijakan dan perilaku layanan dapat berubah tanpa pemberitahuan, jadi periksa halaman resmi sebelum mengandalkan informasi yang penting.

• 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?

Panduan terkait

Semua panduan →