Use authorized server administration access and handle message headers as private information. Record queue size and growth rate, available disk space and the incident time. Avoid opening message bodies unless necessary and permitted for the investigation.

1. Open Admin-level Mail Queue Administration, or run exim -bpc to count queued messages and exim -bp for a listing. On a large queue start with counts and a limited representative sample.
2. Choose one queued message ID and inspect its log with exim -Mvl MESSAGE_ID. Record the destination response and last retry reason.
3. Compare several messages for a common sender, recipient domain or error. Correlate the queue IDs with /var/log/exim/mainlog and check paniclog for local service failures.
4. For suspected abuse, contain the affected credential or application and preserve evidence before resuming delivery. For legitimate mail, repair the actual DNS, routing, quota or remote connectivity issue.
5. Retry one confirmed legitimate message using the panel or exim -M MESSAGE_ID. Observe the result before scheduling broader queue processing.

Run these only as an authorised administrator on the DirectAdmin server that uses Exim. Start with the queue count and select an actual queue ID from Mail Queue Administration. Replace QUEUE_ID in the second command with that single message identifier.

sudo exim -bpc
sudo exim -Mvl QUEUE_ID

Read the result: The count gives the number of queued messages at that instant. The selected message log explains its recent delivery attempts, such as a remote deferral, routing failure or mailbox issue. A large count alone cannot distinguish spam from legitimate mail waiting during a destination outage.

Correlate the message with its sender, destination and incident time using only the authorised information needed. Do not paste message bodies or recipient lists into public diagnostics. Resolve the actual cause before requesting a narrow retry; this example neither retries nor deletes queue entries.

No. Frozen state means automated delivery handling has stopped for that message. Its log explains whether the cause is an undeliverable bounce, addressing problem or another condition.

Confirm the sample is delivered and the queue stops growing abnormally. Track new arrivals as well as old messages, because an apparently shrinking queue can hide a continuing compromised sender. Test both local and external delivery when those paths were affected.

Do not force all frozen messages repeatedly or clear the whole queue as a first response. Deletion permanently discards undelivered mail, while bouncing abusive mail can generate unwanted backscatter. Review each intended bulk action against a confirmed scope and retain a record of the decision.

• Diagnosing Dovecot login errors on DirectAdmin
• Reviewing Rspamd filtering on a DirectAdmin server
• Investigating DirectAdmin disk-usage differences
• Investigating a DirectAdmin brute-force block

• DirectAdmin: Maintaining Email Queue
• DirectAdmin: Outgoing Spam