Cegah Subscription Bombing pada Formulir Pendaftaran

Apa itu subscription bombing?

Subscription bombing adalah serangan yang menggunakan formulir pendaftaran Anda untuk memenuhi inbox milik orang lain. Penyerang mengambil alamat email satu korban, lalu memasukkannya ke ratusan atau ribuan formulir yang tidak terlindungi dalam waktu singkat. Setiap situs tersebut mengirimkan pesan sambutan atau pesan konfirmasi ke alamat itu. Secara keseluruhan, pesan-pesan tersebut menyembunyikan email yang sebenarnya perlu dibaca oleh korban.

Sasaran serangan adalah pemilik inbox tersebut. Saat inbox dipenuhi konfirmasi subscription, penyerang membelanjakan uang menggunakan kartu milik orang itu atau mereset password salah satu akunnya. Peringatan fraud dari bank tetap masuk. Namun, peringatan itu berada di bawah dua ribu pesan lain yang masuk pada jam yang sama, sehingga tidak ada yang melihatnya tepat waktu.

Server Anda menjadi alat yang digunakan untuk menjalankan serangan tersebut. Tidak ada yang rusak pada sistem Anda. Tidak ada akun milik Anda yang disusupi. Seseorang memasukkan sebuah alamat ke formulir publik, dan software Anda menjalankan fungsinya: mengirim email ke alamat tersebut. Inilah yang membuat serangan ini sulit dideteksi. Tidak ada intrusion dalam log Anda karena memang tidak terjadi intrusion.

Seperti apa serangan tersebut dari sisi Anda

Serangan ini muncul dalam salah satu dari dua bentuk.

Bentuk yang mencolok adalah lonjakan singkat. Beberapa ratus permintaan POST masuk ke satu formulir dalam beberapa menit, dari banyak alamat IP sumber yang berbeda, dengan alamat email pada domain yang belum pernah Anda kirimi sebelumnya. Serangan ini mudah terlihat setelah Anda memeriksanya.

Bentuk yang tidak mencolok sering terlewatkan. Penyerang memiliki daftar berisi ribuan formulir yang rentan, sehingga formulir Anda hanya perlu menerima satu atau dua pengiriman per jam. Jye Cusch menggambarkan serangan dengan bentuk yang sama persis pada situs yang ia kelola: tidak ada lonjakan trafik, hanya pendaftaran yang terus masuk pada jam yang tidak sesuai dengan audiensnya. Satu formulir terlihat tidak mencurigakan karena hampir tidak melakukan apa-apa. Kerusakan tersebut merupakan akumulasi dari semua formulir dalam daftar penyerang.

Kedua bentuk tersebut memiliki ciri yang sama setelahnya: tidak ada tindakan lanjutan. Alamat-alamat tersebut tidak pernah dikonfirmasi. Tidak ada yang membuka pesan atau mengeklik tautan. Pada daftar confirmed opt-in, alamat-alamat tersebut akan tetap berstatus unconfirmed selamanya. Tumpukan inilah bukti paling jelas yang akan Anda dapatkan.

Mulailah dengan menghitung jumlah pengiriman per menit dalam access log Anda.

sudo awk '/POST \/subscription\/form/ {print substr($4, 2, 17)}' \
  /var/log/nginx/access.log | uniq -c | sort -rn | head

$4 dalam format default combined log adalah timestamp yang diapit tanda kurung siku. Perintah ini mencetak jumlah untuk setiap menit, dengan jumlah tertinggi di urutan pertama. Formulir yang biasanya menerima empat pendaftaran per hari tetapi tiba-tiba menerima enam puluh pendaftaran dalam satu menit tidak sedang mengalami kondisi normal.

Opt-in terkonfirmasi: pertahanan dengan dampak terbesar

Opt-in terkonfirmasi, yang biasanya disebut double opt-in, berarti sebuah alamat belum menjadi subscriber sampai seseorang mengklik tautan dalam pesan yang dikirim ke alamat tersebut. Aktifkan pengaturan ini, dan setiap alamat yang dikirimkan hanya menghasilkan tepat satu pesan. Alamat tersebut tidak pernah masuk ke dalam list, sehingga tidak pernah menerima campaign atau welcome sequence.

Di listmonk, server newsletter yang di-host sendiri, pengaturan ini berlaku per list: sebuah list menggunakan single opt-in atau double opt-in. Dokumentasinya menjelaskan perbedaannya secara tegas. Pada list double opt-in, subscriber "secara eksplisit menyetujui subscription dengan mengklik email konfirmasi yang diterimanya. Sebelum itu, subscriber tidak menerima pesan campaign." Subscriber berada pada status unconfirmed, berpindah ke confirmed setelah tautan diklik, dan hanya subscriber confirmed pada list opt-in yang menerima email campaign.

Jelaskan manfaatnya secara realistis. Opt-in terkonfirmasi tidak mengurangi kontribusi Anda menjadi nol. Pengaturan ini membatasinya hingga satu pesan per alamat. Korban tetap menerima pesan tersebut, dan satu pesan dari masing-masing seribu situs sudah cukup untuk menjalankan seluruh serangan. Yang dihilangkan oleh opt-in terkonfirmasi adalah semua pesan setelahnya: list Anda tetap bersih, dan Anda tidak pernah mengirim pesan kedua kepada orang yang tidak pernah meminta pesan pertama.

Ada dua pengaturan lain yang penting dan keduanya mudah terlupakan. Pertama, batasi pengiriman ulang email konfirmasi. Jika alamat yang sama dapat dikirimkan kembali dan menerima email konfirmasi baru setiap kali, penyerang tidak memerlukan seribu formulir, karena formulir Anda sendiri akan mengirim seribu pesan. Alamat yang sudah berada pada status unconfirmed di list tersebut seharusnya tidak menerima pesan tambahan apa pun setidaknya selama satu hari. Kedua, hapus baris yang belum dikonfirmasi secara terjadwal. Alamat yang belum dikonfirmasi selama tiga puluh hari bukan subscriber yang masih menunggu. Menyimpannya hanya menciptakan kemungkinan alamat tersebut tidak sengaja menerima email di kemudian hari.

Batasi laju formulir pendaftaran pada reverse proxy

Terapkan batas di depan aplikasi, bukan di dalamnya. Permintaan yang diblokir pada proxy tidak pernah membuka koneksi database dan tidak pernah memulai percakapan SMTP (simple mail transfer protocol). Batas di dalam aplikasi berjalan setelah permintaan tersebut menghabiskan proses worker dan satu kueri, dan pada banyak stack, pesan sudah masuk antrean sebelum pemeriksaan penyalahgunaan dijalankan. Batas pada proxy juga tetap berlaku setelah aplikasi diperbarui karena tidak berada dalam kode yang Anda ganti.

Contoh berikut menggunakan nginx. Gagasan ini dapat diterapkan pada reverse proxy yang Anda jalankan di depan aplikasi, meskipun nama directive-nya berbeda.

Tambahkan konfigurasi ini ke blok http, dalam file seperti /etc/nginx/conf.d/signup-limit.conf:

map $request_method $signup_key {
    POST    $binary_remote_addr;
    default "";
}

limit_req_zone $signup_key zone=signup:10m rate=2r/m;
limit_req_status 429;
limit_req_log_level warn;

map menjalankan fungsi penting. nginx tidak menghitung permintaan yang key-nya berupa string kosong, sehingga hanya permintaan POST yang masuk ke zone. Memuat halaman pendaftaran beberapa kali tidak menghabiskan anggaran. Tanpa map tersebut, seseorang yang memuat ulang halaman dua kali akan menghabiskan batasnya sendiri sebelum pernah mengirimkan apa pun.

$binary_remote_addr adalah alamat client dalam format packed. Karena itu, zone berukuran 10 megabyte dapat menampung sekitar 160,000 alamat. rate=2r/m mengizinkan satu pengiriman setiap tiga puluh detik. limit_req_status 429 mengembalikan HTTP 429 Too Many Requests, bukan 503 bawaan nginx. Kode 429 adalah kode yang tepat dan diharapkan oleh client library.

Kemudian, tambahkan konfigurasi berikut ke blok server untuk situs Anda:

location = /subscription/form {
    limit_req zone=signup burst=3 nodelay;
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

burst=3 nodelay mengizinkan pengguna yang mengeklik tombol dua kali untuk tetap lolos, dan langsung menolak permintaan keempat tanpa memasukkannya ke antrean.

sudo nginx -t && sudo systemctl reload nginx

nginx -t seharusnya menampilkan configuration file /etc/nginx/nginx.conf test is successful. Sekarang kirimkan formulir lima kali dengan cepat dan pantau error log:

sudo tail -f /var/log/nginx/error.log

Permintaan yang diblokir menulis satu baris. Inilah string yang perlu Anda cari:

2026/08/13 09:14:22 [warn] 812#812: *4412 limiting requests, excess: 3.400 by zone "signup", client: 203.0.113.10, server: news.example.com, request: "POST /subscription/form HTTP/1.1", host: "news.example.com"

Jika tidak ada baris sama sekali, berarti batas tersebut tidak diterapkan. Penyebab yang paling umum adalah limit_req berada dalam blok location yang tidak pernah dicapai oleh permintaan. Karena itu, jalankan curl -si -X POST https://news.example.com/subscription/form beberapa kali berturut-turut dan pastikan Anda mendapatkan 429.

Ada dua hal yang perlu diketahui sebelum Anda mengandalkan batas per-IP.

Di belakang CDN atau proxy lain, $binary_remote_addr adalah proxy tersebut. Semua pengunjung masuk ke satu bucket, sehingga beberapa pengiriman pertama setiap menit membuat semua pengunjung lain ditolak. Perbaiki ini dengan modul real IP: set_real_ip_from untuk setiap range yang dipublikasikan oleh CDN Anda (Cloudflare mencantumkan range mereka di cloudflare.com/ips) dan real_ip_header CF-Connecting-IP. Pastikan perbaikannya dengan membaca $remote_addr dalam access log dan memeriksa bahwa nilainya merupakan alamat pengunjung, bukan alamat CDN Anda.

IPv6 membuat batas per-alamat menjadi lemah. $binary_remote_addr menyimpan seluruh /128, sedangkan alokasi IPv6 untuk koneksi rumah biasanya berupa /64 atau lebih besar. Jumlah alamat tersebut jauh lebih banyak daripada yang dapat digunakan penyerang, dan masing-masing memiliki anggaran yang masih utuh. Tambahkan zone kedua sebagai batas atas untuk endpoint itu sendiri, dengan key berupa konstanta, sehingga formulir memiliki batas laju total terlepas dari jumlah alamat sumber yang digunakan:

map $request_method $signup_total_key {
    POST    "signup";
    default "";
}

limit_req_zone $signup_total_key zone=signup_total:1m rate=30r/m;

Tambahkan limit_req zone=signup_total burst=10 nodelay; ke location yang sama. Tetapkan laju di atas jumlah penggunaan tertinggi pada jam tersibuk, dengan cadangan yang cukup. Ini adalah kontrol yang kasar: selama serangan berlangsung, pendaftaran yang sah juga akan ditolak. Inilah kompromi yang tepat karena alternatifnya adalah server Anda yang mengirimkan email.

Batas per alamat tidak dapat diterapkan di proxy

Alamat email berada di dalam isi POST, sedangkan nginx tidak mengurai isi request. Setiap variabel yang dapat digunakan sebagai kunci oleh limit_req_zone berasal dari request line, header, atau koneksi. Jadi, aturan seperti “alamat ini boleh menerima paling banyak satu konfirmasi per hari” harus ditempatkan pada komponen pertama yang membaca isi request, yaitu aplikasi Anda.

Jangan mengatasi hal ini dengan memindahkan alamat tersebut ke query string agar $arg_email tersedia. Cara ini menulis alamat setiap pelanggan ke access log dalam bentuk teks biasa, serta ke setiap log shipper setelahnya. Anda hanya akan mengganti batas laju dengan masalah privasi.

Ada satu pengecualian yang nyata. Modul JavaScript nginx, njs, dapat membaca isi request dan menetapkan variabel berdasarkan isinya. Dengan demikian, Anda dapat membuat kunci per alamat di proxy. Ini merupakan opsi yang valid, tetapi juga menambahkan kode baru ke jalur request Anda. Untuk sebagian besar situs, batas per alamat sebaiknya ditempatkan di dekat database yang sudah mengetahui apakah alamat tersebut memiliki konfirmasi yang masih tertunda. Proxy menangani batas per-IP dan per-endpoint yang memang menjadi keunggulannya.

Jangan mengulangi teks yang dikirimkan dalam pesan

Jauhkan setiap string yang dikirimkan penyerang dari pesan yang Anda kirimkan. Ada dua alasan terpisah, dan keduanya pernah digunakan dalam serangan nyata.

Jika email konfirmasi menyapa pembaca dengan nama yang diambil dari formulir, penyerang dapat menulis pesannya ke dalam kolom nama. Server Anda kemudian mengirimkan teks tersebut kepada korban dari domain Anda, dengan tanda tangan kunci DKIM (DomainKeys Identified Mail) Anda. Situs Anda menjadi layanan pengiriman untuk penyalahgunaan oleh pihak lain, dan penyedia email penerima akan melihat domain Anda pada pesan tersebut.

Alasan kedua lebih serius. Jika suatu kolom yang dikirimkan digabungkan secara manual ke dalam header email, karakter baris baru pada kolom tersebut dapat menambahkan header pilihan penyerang, termasuk Bcc. Pustaka email modern menolak karakter baris baru dalam nilai header. Kode yang menyalurkan teks ke sendmail dari skrip shell sering kali tidak menolaknya.

Pesan konfirmasi yang aman berisi nama situs Anda dan satu tautan, disertai satu kalimat penjelasan. Alamat tersebut hanya muncul di tempat yang memerlukannya bagi mail transfer agent, yaitu pada header To. Uji hal ini: kirimkan formulir dengan kolom nama yang berisi baris baru dan tautan yang jelas, lalu baca pesan mentah yang Anda terima dengan less dan periksa bahwa keduanya tidak ikut terkirim.

Sekalian, buat halaman keberhasilan menampilkan pesan yang sama untuk setiap alamat. Halaman yang menampilkan "Anda sudah berlangganan" untuk satu alamat dan "periksa kotak masuk Anda" untuk alamat lain mengubah formulir Anda menjadi pemeriksa keanggotaan bagi siapa pun yang memiliki daftar alamat untuk diuji.

Pemeriksaan bot mana yang sebaiknya digunakan?

Pilih pemeriksaan berdasarkan aksesibilitas dengan pertimbangan yang sama kuatnya seperti efektivitas. CAPTCHA pemilihan gambar tidak dapat diselesaikan oleh pembaca tunanetra, sedangkan opsi audio sulit digunakan oleh orang dengan pendengaran biasa. Pemeriksaan yang membuat orang sah gagal mendaftar juga menjadi beban. Berikut empat opsi, sesuai urutan yang sebaiknya dicoba.

Proof of work di browser. Browser menghitung hash yang dapat diverifikasi server dengan biaya rendah, dan pengguna tidak perlu menyelesaikan apa pun. listmonk menyediakan opsi ini melalui Settings, lalu Security, dengan menggunakan ALTCHA yang tidak memerlukan layanan pihak ketiga. Per Agustus 2026, ini merupakan rekomendasi listmonk sendiri sebagai pengganti opsi hCaptcha yang sudah tidak digunakan lagi. Beban komputasi ditanggung oleh pihak yang paling banyak mengirimkan permintaan, yaitu penyerang.

Pemeriksaan noninteraktif terkelola. Cloudflare Turnstile biasanya tidak menampilkan apa pun kepada sebagian besar pengunjung dan hanya memberikan tantangan ketika sinyalnya terlihat mencurigakan. Opsi ini efektif, tetapi menempatkan pihak ketiga dalam alur pendaftaran Anda.

Field honeypot. Ini adalah input teks yang tidak pernah dilihat pengguna, tetapi diisi oleh bot sederhana. Gunakan nama yang tidak dipakai oleh form Anda untuk keperluan lain, lalu tetapkan autocomplete="off", tabindex="-1", dan aria-hidden="true" agar password manager tidak mengisinya dan screen reader tidak membacakannya. Field bernama email2 atau address akan diisi otomatis oleh browser, sehingga Anda justru menolak pengguna yang sah.

<div style="position:absolute; left:-9999px;" aria-hidden="true">
  <label for="hp_ref">Leave this field empty</label>
  <input type="text" id="hp_ref" name="hp_ref" autocomplete="off" tabindex="-1">
</div>

Pemeriksaan waktu pengiriman. Masukkan timestamp bertanda tangan ke dalam hidden field saat halaman ditampilkan, lalu tolak pengiriman yang tiba kurang dari dua detik kemudian. Pengguna tidak mungkin membaca form dan mengetik alamat secepat itu. Tanda tangani timestamp tersebut; jika tidak, bot cukup mengirimkan timestamp lama.

Apa pun pilihan Anda, verifikasi satu hal berikut: token harus digunakan satu kali. Jika sebuah script dapat menyelesaikan pemeriksaan sekali lalu menggunakan kembali token tersebut untuk seribu alamat, pemeriksaan itu hanya membuktikan bahwa browser pernah menjalankannya sekali dan tidak lebih.

Bagaimana cara mengetahuinya sebelum laporan penyalahgunaan masuk?

Anda memerlukan grafik dari sistem sendiri, bukan dari tim penanganan penyalahgunaan penyedia hosting. Pantau dua hal.

Hitung jumlah pengiriman berdasarkan alamat sumber di seluruh log:

sudo awk '/POST \/subscription\/form/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Kemudian biarkan fail2ban membaca baris limiting requests yang juga ditulis oleh nginx, lalu memblokir pelaku yang berulang kali melakukan pelanggaran. fail2ban menyediakan filter khusus untuk kebutuhan ini. Buat /etc/fail2ban/jail.d/nginx-limit-req.local:

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 3600

sudo systemctl reload fail2ban
sudo fail2ban-client status nginx-limit-req

Output status mencantumkan filter jail serta jumlah kegagalan dan pemblokiran saat ini. Nilai Currently banned: 0 pada hari yang sepi adalah kondisi yang benar. Jika jail sama sekali tidak muncul, fail2ban tidak pernah memuat file tersebut, dan sudo fail2ban-client -d | grep nginx-limit-req menampilkan konfigurasi yang benar-benar diprosesnya. Filter bawaan mencocokkan setiap zona limit_req. Persempit cakupannya ke zona pendaftaran Anda dengan menetapkan ngx_limit_req_zones = signup dalam bagian [Definition] pada /etc/fail2ban/filter.d/nginx-limit-req.local. Tata letak file jail dan perintah pemblokiran dibahas lebih mendalam dalam panduan fail2ban untuk Ubuntu 24.04.

Sinyal kedua adalah rasio dan tidak memerlukan perangkat lunak baru: jumlah pengiriman dibagi jumlah konfirmasi. Pada mailing list yang sehat, sebagian besar orang yang mengirimkan alamat akan mengeklik tautan, biasanya jauh lebih dari setengahnya. Jika rasio tersebut turun tajam sementara jumlah pengiriman meningkat, sistem Anda sedang disalahgunakan. Bandingkan jumlah pelanggan unconfirmed yang dibuat dalam satu jam terakhir dengan jumlah pelanggan confirmed, sesuai jadwal yang sudah Anda gunakan untuk menjalankan laporan.

Biayanya: reputasi pengirim dan blocklist

Inilah bagian yang mengubah gangguan menjadi tagihan.

Daftar alamat yang digunakan untuk bombing dikumpulkan dari berbagai sumber, dan daftar hasil pengumpulan itu berisi spamtrap: alamat yang tidak pernah mendaftar ke layanan apa pun dan hanya dipublikasikan untuk menangkap pengirim yang mengirim email tanpa izin. Pesan konfirmasi Anda akan menjangkau salah satu alamat tersebut. Beberapa operator blocklist tidak memerlukan bukti lain.

Penerima yang tidak pernah meminta pesan Anda tidak akan mengeklik unsubscribe. Mereka akan mengeklik "report spam". Aturan bulk sender Google yang berlaku sejak February 2024 mengharuskan pengirim yang mengirim 5,000 pesan atau lebih per hari ke Gmail untuk menjaga tingkat spam yang dilaporkan di Postmaster Tools tetap di bawah 0.3%. Pengirim dengan volume lebih kecil tidak diukur berdasarkan angka tersebut, tetapi sinyal keluhan yang sama tetap digunakan dalam keputusan penyaringan yang memasukkan email Anda ke folder spam. Alamat palsu dalam pengiriman tersebut juga menghasilkan hard bounce, dan kenaikan tingkat hard bounce menjadi sinyal reputasi tersendiri di setiap provider besar.

Jika Anda menjalankan server email sendiri pada VPS dengan mailcow, pencatatan tersebut akan berlaku pada alamat IP dan domain Anda. Penghapusan dari blocklist oleh operator seperti Spamhaus memerlukan pengisian formulir dan waktu tunggu. Selama menunggu, invoice dan email reset password Anda juga tidak akan terkirim. Jika Anda mengirim email melalui provider bersama, perkirakan mereka akan menangguhkan akun Anda terlebih dahulu dan baru membaca penjelasan Anda setelahnya, karena trafik Anda menjadi risiko bagi semua pengirim lain pada alamat IP tersebut.

Dibandingkan dengan dampaknya, pekerjaan ini sederhana. Aktifkan confirmed opt-in hari ini karena pengaturannya hanya perlu dilakukan sekali untuk setiap list. Selanjutnya, tambahkan rate limit pada proxy karena hanya memerlukan satu file dan reload. Pemeriksaan bot dan alerting dapat menyusul minggu ini.

FAQ

Apakah double opt-in menghentikan subscription bombing?

Hal ini mencegah daftar Anda tercemar dan membatasi kontribusi Anda hingga satu pesan untuk setiap alamat yang dikirimkan. Ini merupakan perbaikan tunggal terbesar yang dapat Anda lakukan. Namun, cara ini tidak mencegah inbox korban penuh, karena serangan tersebut merupakan akumulasi satu pesan dari setiap seribu situs. Terapkan juga rate limit per-IP pada proxy Anda dan batasi pengiriman ulang konfirmasi. Dengan demikian, pengiriman alamat yang sama dua kali tidak menghasilkan pesan kedua.

Bagaimana cara membedakan serangan bombing dari hari dengan banyak pendaftaran nyata?

Perhatikan apa yang terjadi setelah pengiriman formulir. Pendaftaran nyata akan dikonfirmasi, biasanya dalam beberapa jam. Serangan bombing meninggalkan banyak alamat yang tidak pernah dikonfirmasi, dibuka, atau diklik. Pola pengirimannya juga tidak wajar: banyak alamat sumber yang belum pernah Anda lihat, domain penerima yang biasanya tidak Anda kirimi pesan, serta waktu kedatangan yang tersebar merata sepanjang hari, bukan mengikuti jam aktif audiens Anda.

Apakah alamat yang dikirimkan sebaiknya saya hapus?

Ya. Hapus catatan yang belum dikonfirmasi dan berusia lebih dari sekitar tiga puluh hari. Lakukan secara terjadwal, bukan manual. Jangan pernah mengirimkan apa pun lagi ke alamat tersebut, termasuk permintaan maaf atau pesan "apakah ini Anda?", karena itu merupakan pesan kedua yang tidak diminta kepada seseorang yang sudah menerima banyak pesan semacam itu. Jika sebagian alamat tersebut merupakan spamtrap, pesan lanjutan akan menjadi konfirmasi yang ditunggu oleh operator blocklist.

Apakah rate limiting akan menolak pelanggan nyata?

Batas per-IP satu pengiriman setiap tiga puluh detik dengan burst tiga kali tidak akan terasa bagi seseorang yang mengisi formulir satu kali. Batas ini akan terasa jika banyak orang nyata menggunakan satu alamat, misalnya kantor di balik satu gateway NAT (network address translation), atau jika proxy Anda melihat alamat CDN, bukan alamat pengunjung. Baca $remote_addr dalam access log sebelum memperketat aturan apa pun, dan pertahankan batas endpoint di atas jumlah pengiriman nyata tertinggi dalam satu jam tersibuk.

IP pengiriman saya masuk blocklist setelah serangan. Apa yang harus saya lakukan terlebih dahulu?

Hentikan pengiriman dari IP tersebut sebelum mengajukan permintaan apa pun. Hentikan sementara antrean campaign, perbaiki formulir, dan hapus alamat yang belum dikonfirmasi. Delisting yang kemudian diikuti oleh traffic yang sama akan membuat IP Anda masuk kembali ke blocklist lebih cepat daripada sebelumnya. Selanjutnya, cari tahu daftar yang memuat IP Anda, karena sebagian besar operator menyediakan halaman pencarian berdasarkan alamat IP. Ikuti proses penghapusan yang mereka tetapkan. Proses ini biasanya memerlukan waktu beberapa hari. Gunakan waktu tersebut untuk memastikan record SPF (sender policy framework) dan penandatanganan DKIM Anda masih berhasil diverifikasi.