Email on suspended cPanel accounts
When a cPanel account is suspended, its email stops working in two separate ways at the same time. If you suspend accounts for overdue invoices, this is worth understanding before it happens, because the usual behaviour permanently rejects incoming mail rather than holding it.
What a suspension does to email
A suspension is not just a "website off" switch. It has two independent effects on mail:
| Effect | What the user sees |
|---|---|
| Incoming mail is rejected | Senders get an immediate bounce: 525 5.7.13 Disabled recipient address |
| Mailbox logins are blocked | POP3, IMAP, and webmail all fail to authenticate, for every mailbox on the account |
Together these look exactly like "the mail server is down" from the customer's side, which is why a suspension is often mistaken for an outage.
Only the suspended account is affected
This trips people up when one company owns several domains. Each cPanel account is independent, so suspending one leaves the others untouched.
If example.org lives on a suspended account while example.com and example.net are separate accounts, then:
- Mail to
@example.orgis rejected. - Mail from
@example.comstill sends normally, including to people at@example.org. The message is accepted from the sender and then refused by the recipient side.
So a user can watch their own outgoing mail fail to a colleague's address while everything else works. That is the expected pattern, not a partial server failure.
Choosing what happens to incoming mail
You can change how the server treats mail addressed to suspended accounts. In WHM:
- Go to Home » Service Configuration » Exim Configuration Manager.
- Open the Mail tab.
- Find Delivery behavior for suspended cPanel accounts.
- Select the behaviour you want (see the table below), then click Save.
WHM offers four choices:
| Option in WHM | Behaviour | Does the mail survive the suspension? |
|---|---|---|
| Deliver messages normally | Delivered to the mailbox as if nothing were wrong | Yes, but the user still cannot log in to read it. See the warning below |
| Accept and discard messages | Accepted, then silently deleted | No, and the sender is never told |
| Reject messages at SMTP time | Refused at once with a permanent error | No, the sender gets a bounce |
| Accept and queue messages | Accepted and held on the server, delivered once the account is reactivated | Yes, within the retention window below |
"Reject messages at SMTP time" is the setting that produces the 525 bounce described at the top of this guide. If you have never changed this option, that is most likely what your server is doing now.
Recommended: Accept and queue messages
For suspensions you expect to reverse, such as an overdue invoice or a temporary hold, Accept and queue messages is the option cPanel itself recommends, and the one that best matches what most hosts actually want:
- The sender gets a normal delivery confirmation, and sees no error and no delay warning.
- The message waits on the server.
- Once the account is reactivated, the queue delivers everything automatically. Nothing needs to be re-sent. Recently queued mail typically arrives within minutes; a message that has been waiting for days has backed off to a longer retry interval and can take several hours longer.
No mail service restart is required. The change takes effect immediately and is fully reversible.
Two limits to know before choosing Queue
1. Queued mail is not held forever. The server retries for about four days and gives up at five, then bounces the message back to the sender. A suspension resolved in hours or a couple of days loses nothing. An account left suspended for a week still bounces its mail.
2. Accepted mail can still be lost if the account is deleted. Because queueing accepts the message, the sender has already been told it was delivered. If that account is ultimately terminated rather than reactivated, the queued mail is discarded and the sender never learns it did not arrive.
The practical rule: with queueing enabled, resolve suspensions one way or the other, reactivate or terminate, inside that four-to-five day window rather than leaving accounts suspended indefinitely.
Verifying the change
If you have root access, you can confirm the new behaviour without sending a real message. exim -bh runs a simulated SMTP session that goes through all the normal checks but delivers nothing:
exim -bh 127.0.0.1Then type the following, one line at a time, replacing user@example.com with a real address on a suspended account:
EHLO mail.example.net
MAIL FROM:<test@example.net>
RCPT TO:<user@example.com>
QUITThe EHLO line is not optional. Most servers require a HELO or EHLO before accepting a sender, and it must look like a real hostname, so going straight to MAIL FROM returns 503 HELO or EHLO required.
With queueing active, the RCPT TO line answers 250 Accepted, where it previously answered 525 5.7.13 Disabled recipient address.
Two more checks are worth running as controls:
- An address on an active account should still return
250, confirming nothing else changed. - A nonexistent address should still return
550 No Such User Here, confirming the server did not turn into a catch-all that accepts anything.
exim -bt address test reports queued recipients as discarded, which looks alarming and wrong. It is an artifact of how the queue behaviour is evaluated in address-verification mode, not what actually happens to real mail. Always confirm with exim -bh. Recovering mail rejected during a suspension
Once the account is active again, delivery resumes on its own and mailbox logins start working immediately. Mail that was already rejected, however, cannot be replayed from the server: the rejection was permanent and nothing was stored.
- Senders on your own server usually still have the message sitting in their mail program's outbox, because the client never completed the send. They only need to send it again.
- External senders received a bounce notification and have to re-send.
If you suspend from your own billing system
When suspensions are triggered by billing automation such as WHMCS, the account can be suspended again automatically on the next run if the underlying invoice is still open. After reactivating an account by hand, confirm the invoice is settled in your billing system, or the suspension simply repeats.