Email Tertahan di Queue Exim dengan Pesan retry time not reached, Apa Artinya?

Pelanggan bilang email ke satu domain belum sampai sejak tadi pagi. Kamu buka queue Exim, pesannya memang masih di sana, dan di log tertulis retry time not reached. Banyak yang langsung menganggap kalimat itu sebagai penyebab masalah, lalu bingung harus memperbaiki apa. Padahal itu bukan error. Itu cuma Exim yang bilang belum waktunya mencoba lagi. Artikel ini menelusuri dari pesan itu sampai ke error yang sebenarnya, lalu membahas kapan pesan cukup ditunggu, kapan dipaksa kirim ulang, dan kapan lebih baik dihapus.

Apa yang sebenarnya dikatakan Exim

Exim menyimpan catatan kegagalan pengiriman di hints database, yaitu database kecil di direktori spool yang dipakai untuk mengingat host atau domain mana yang sedang bermasalah. Saat percobaan kirim gagal dengan error sementara (kode SMTP 4xx, connection timeout, DNS lookup yang belum selesai), Exim tidak langsung bounce. Ia mencatat kegagalan itu dan menghitung kapan boleh mencoba lagi berdasarkan retry rule di konfigurasi. Retry rule ada di bagian begin retry pada konfigurasi Exim. Konfigurasi default bawaan Exim biasanya memakai pola kira-kira begini: coba tiap 15 menit selama 2 jam pertama, lalu jeda makin panjang sampai 16 jam, lalu tiap 6 jam sampai total 4 hari. Kalau sampai batas akhir masih gagal, pesan di-bounce ke pengirim. Control panel atau admin sering mengubah aturan ini, jadi jangan berasumsi, cek konfigurasi di server kamu. Nah, queue runner Exim berjalan berkala dan menyisir semua pesan di queue. Kalau ia menemukan pesan untuk host yang jadwal retry-nya belum tiba, ia melewati pesan itu dan menulis retry time not reached. Jadi pesan ini muncul berulang kali di log justru karena Exim sedang patuh pada jadwal. Informasi yang kamu butuhkan ada di percobaan sebelumnya, yang gagal.

Menemukan pesan dan membaca header serta log-nya

Langkah pertama selalu sama: pastikan pesan mana yang tertahan, ke mana tujuannya, dan sudah berapa lama. Semua perintah di bawah ini read-only, aman dijalankan di server produksi.

BASH

# jumlah pesan di queue
exim -bpc

# daftar queue: umur, ukuran, message ID, pengirim, penerima
exim -bp | less

# hanya ID pesan untuk domain penerima tertentu
exiqgrep -i -r 'domaintujuan.example'

# header pesan (ganti MESSAGE_ID dengan ID dari exim -bp)
exim -Mvh MESSAGE_ID

# message log: riwayat percobaan kirim pesan ini
exim -Mvl MESSAGE_ID

# info retry yang tersimpan untuk sebuah domain
exinext domaintujuan.example

Dari header, cek tiga hal: alamat From dan Return-Path (apakah pengirimnya memang akun yang dimaksud pelanggan), penerima, dan baris Received paling bawah untuk tahu pesan masuk dari mana. Ini juga cara cepat mengecek apakah queue penuh karena satu akun yang dibobol dan mengirim spam, bukan karena satu email penting yang macet. Message log dari -Mvl adalah bagian terpenting. Isinya kronologis per pesan, termasuk respons server tujuan di setiap percobaan.

Mencari error asli dari server tujuan

Buka message log dan abaikan dulu baris retry time not reached. Cari baris yang mengandung defer atau kode respons SMTP. Bentuknya kira-kira seperti ini:

TEXT

# contoh format output, bukan dari kejadian nyata
2026-01-01 10:00:00 [email protected] R=dkim_lookuphost T=remote_smtp defer (110): Connection timed out
2026-01-01 10:15:00 [email protected] R=dkim_lookuphost T=remote_smtp defer (-44) H=mx.domaintujuan.example [192.0.2.10]: SMTP error from remote mail server after RCPT TO:<[email protected]>: 451 4.7.1 Please try again later
2026-01-01 10:30:00 [email protected]: retry time not reached

Nama router dan transport (R= dan T=) di server kamu bisa berbeda tergantung konfigurasi. Yang penting adalah teks setelah defer. Kalau message log sudah dirotasi atau kosong, cari message ID yang sama di main log Exim. Lokasinya tergantung setup: di server cPanel biasanya /var/log/exim_mainlog, di Debian atau Ubuntu biasanya /var/log/exim4/mainlog. Perintah seperti grep MESSAGE_ID /var/log/exim_mainlog cukup untuk ini. Beberapa pola yang sering muncul, dan artinya: Connection timed out atau Connection refused ke port 25 berarti server kamu tidak bisa membuka koneksi SMTP ke MX tujuan. Bisa karena server tujuan sedang down, firewall di sisi mereka, atau port 25 keluar dari server kamu diblokir di jaringan upstream. Yang terakhir ini sering terjadi di VPS baru. Respons 421 atau 451 dengan teks seperti try again later, rate limited, atau greylisted berarti server tujuan sengaja menunda. Greylisting memang menolak percobaan pertama dari pengirim yang belum dikenal dan menerima percobaan berikutnya, jadi biasanya beres sendiri setelah satu dua retry. Rate limit biasanya muncul kalau server kamu mengirim banyak email ke provider yang sama dalam waktu singkat. Respons 452 atau teks semacam mailbox full atau over quota berarti kotak surat penerima penuh. Itu masalah di sisi penerima, tidak ada yang bisa diperbaiki dari server kamu. host lookup did not complete atau error DNS sejenis berarti Exim gagal me-resolve MX tujuan saat itu. Cek resolver server dulu sebelum menyalahkan domain tujuan. Kalau error yang muncul justru kode 5xx, itu kegagalan permanen. Pesan seperti itu biasanya sudah langsung di-bounce, bukan tertahan dengan retry.

Menyingkirkan tersangka yang salah

Bagian ini yang sering memakan waktu kalau dilewati. Ada beberapa hal yang kelihatan relevan tapi biasanya bukan penyebabnya. Pertama, apakah Exim-nya mati? Kalau email ke domain lain masih terkirim normal di main log, layanan Exim sehat. Masalahnya spesifik ke satu tujuan. Restart Exim tidak akan membantu dan tidak mengubah jadwal retry yang tersimpan di hints database. Kedua, SPF, DKIM, dan DMARC. Ini memengaruhi apakah email diterima atau masuk spam, dan penolakannya biasanya berupa 5xx yang jelas menyebut policy. Untuk kasus tertahan dengan defer timeout, autentikasi domain jarang terlibat. Jangan mengutak-atik record DNS sebelum melihat error aslinya. Ketiga, cek apakah masalahnya satu domain atau semua tujuan eksternal. Jalankan exiqgrep -i -r untuk beberapa domain berbeda, atau lihat sebaran penerima di exim -bp. Kalau semua domain eksternal tertahan dengan timeout, curigai jaringan keluar atau port 25 yang diblokir. Kalau cuma satu provider, curigai rate limit, blocklist IP, atau gangguan di sisi mereka. Keempat, routing. Perintah exim -bt [email protected] menunjukkan bagaimana Exim akan me-route alamat itu, termasuk MX host yang dipilih. Ini berguna untuk menangkap kasus domain yang MX-nya salah arah atau masih menunjuk ke server lama setelah migrasi. Dari sisi support, ini juga yang perlu dijelaskan ke pelanggan dengan bahasa sederhana: email belum hilang, server sedang mencoba lagi sesuai jadwal karena server penerima belum mau menerima. Kalimat seperti itu jauh lebih menenangkan daripada menempelkan potongan log.

Kapan memaksa kirim ulang dan kapan menghapus

Setelah error asli ketemu, keputusannya biasanya jelas. Kalau penyebabnya sudah diperbaiki (port 25 dibuka, DNS resolver dibetulkan, server tujuan sudah normal lagi), tidak perlu menunggu jadwal retry berikutnya. Kamu bisa memaksa percobaan kirim untuk pesan tertentu. Kalau penyebabnya ada di sisi penerima (mailbox penuh, greylisting, rate limit), memaksa kirim ulang terus-menerus jarang membantu. Untuk rate limit malah bisa memperpanjang penundaan. Biarkan retry rule bekerja. Kalau pesannya spam dari akun yang dibobol, atau bounce yang tidak bisa dikirim balik ke siapa pun, hapus saja setelah akunnya diamankan. Penting: menghapus pesan dari queue tidak bisa dibatalkan. Pesan hilang dari server dan pengirim tidak mendapat notifikasi apa pun. Pastikan message ID yang kamu hapus memang yang dimaksud, cek dulu headernya dengan exim -Mvh. Hindari menghapus massal dengan pipe dari exiqgrep sebelum kamu yakin filternya hanya menangkap pesan yang benar.

BASH

# paksa percobaan kirim untuk satu pesan, output verbose
exim -v -M MESSAGE_ID

# paksa queue run untuk semua pesan (abaikan retry time)
exim -qf

# HAPUS satu pesan dari queue (tidak bisa dibatalkan)
exim -Mrm MESSAGE_ID

Opsi -v -M paling berguna untuk verifikasi, karena kamu melihat percakapan SMTP secara langsung. Kalau server tujuan masih menjawab 4xx, kamu tahu masalahnya belum selesai. Kalau muncul Completed di main log untuk message ID itu, pesannya sudah terkirim. Hati-hati dengan -qf di queue yang besar, karena ia mencoba semua pesan sekaligus dan bisa memicu rate limit di provider tujuan. Aturan praktisnya: perlakukan retry time not reached sebagai petunjuk arah, bukan diagnosis. Selalu buka message log atau main log untuk message ID yang sama, cari baris defer terakhir sebelum pesan itu, dan baru putuskan langkahnya dari situ. Paksa kirim hanya setelah penyebabnya beres, tunggu kalau masalahnya ada di penerima, dan hapus hanya setelah kamu yakin pesannya memang tidak perlu dikirim.