Practical guide to unblocking emails in DirectAdmin: usage counters and Exim queues

I recently handled an outbound email block incident in DirectAdmin that could not be resolved simply by clicking "Unblock" or "Reactivate" in the control panel.

Restoring mail flow required jumping into the SSH terminal to validate real-time usage counters, perform a surgical cleanup of the mail queue to remove spam artifacts, and force a credential renewal for the affected account. This is the operational workflow that reduces hours of trial and error into a few minutes of predictable system maintenance.

1) Diagnosis: where DirectAdmin tracks outbound limits#

When a sending limit is hit in DirectAdmin, the system references a specific tracking file located at:

/etc/virtual/usage/domain.com.br

If you inspect the file contents:

cat /etc/virtual/usage/domain.com.br

You will typically see a long sequence of the character 1 (e.g., 1111111111).

Operational interpretation#

• Each 1 represents a single counted message sent during the current period.
• When the length of this string reaches the configured limit, the system automatically blocks further attempts.
• Important note: Reactivating the account via the GUI without resetting the counter and purging the queue often leads to an immediate re-block as the system re-evaluates the existing data.

2) The critical step often overlooked by documentation#

Even after zeroing the counter or increasing the limit, a block may persist if the system flags the account for ongoing spam-like behavior.

In technical operations, changing the mailbox password is frequently the "missing piece" that restores the account:

• It invalidates all current authentication tokens / active sessions.
• It abruptly ends any ongoing abuse from leaked or weak credentials.
• It forces a new "trust cycle" for that specific sender.

Without rotating the password, you are merely treating the symptom while the root cause (unauthorized access) remains active and ready to restart the abuse cycle.

3) Runbook via SSH (when the GUI fails)#

3.1 resetting the domain counter#

> /etc/virtual/usage/domain.com.br
chown mail:mail /etc/virtual/usage/domain.com.br

Ownership is critical here. If the file is not owned by the mail user, the system may fail to write new counts correctly, leading to erratic blocking behavior.

3.2 removing account-specific override locks#

Sometimes a lock is placed at the user level, which overrides global domain rules:

rm -f /etc/virtual/domain.com.br/limit/email-username

If this file exists, it will maintain the block even if the panel shows the account as active.

3.3 surgical Exim queue purge#

If the block was caused by a script or compromise, the queue will be full of "junk" messages. Purging the queue for that specific sender is mandatory:

exiqgrep -i -f [email protected] | xargs -r exim -Mrm

Failure to remove this backlog means that as soon as you unblock the account, Exim will attempt to re-process these messages, triggering a new block instantly.

4) Production service sequence#

My standard operating procedure for these incidents:

1. Zero the counter: Clear /etc/virtual/usage/domain.com.
2. Clear overrides: Remove /limit/user files if they exist.
3. Purge the queue: Use exiqgrep to remove all messages from the compromised sender.
4. Rotate credentials: Change the email account password.
5. Monitor logs: Watch for new activity to ensure the fix is stable.

Monitoring commands:

tail -f /var/log/exim/mainlog
grep '[email protected]' /var/log/exim/mainlog | tail -n 30
exim -bpc # Check total queue count

5) Common errors increasing MTTR#

5.1 blanket queue purging#

Deleting the entire mail queue to fix a localized incident destroys forensic evidence and negatively impacts legitimate traffic. Always use targeted filters with exiqgrep.

5.2 neglecting password rotation#

Without a credential change, the attacker or script will simply re-authenticate and re-initiate the abuse cycle as soon as mail flow is restored.

5.3 ignoring file ownership#

A usage file with incorrect ownership leads to intermittent counting errors, making the support issue recurring and difficult to track.

6) Post-correction checklist#

• [ ] Outbound mail flow restored without defer/bounce anomalies.
• [ ] Mail queue stabilized (exim -bpc trending downwards).
• [ ] Account credentials have been rotated.
• [ ] Logs show no new patterns of abuse.
• [ ] Client advised on password hygiene and potential compromised endpoints.

Operational conclusion#

In DirectAdmin, safely unblocking an email account is not a single-click operation. It is a multi-layered procedure involving the usage counter, the mail queue, and the authentication credentials. When you address all three layers simultaneously, the fix is no longer a temporary patch but a definitive resolution. Understanding these internal system paths is what separates a generic support interaction from professional infrastructure management.

See also

Infrastructure Gmail rejecting DirectAdmin system emails: authenticating server hostnames with SPF and DKIM

Infrastructure Anatomy of a phantom email: filesystem and Dovecot IMAP desynchronization

Infrastructure The Forwarding Trap and Backscatter Loops in Exim: Avoiding SPFBL and UCEPROTECT-L3 Blocks

This post is licensed under CC BY-NC.