Email on suspended cPanel accounts

Why a suspended cPanel account stops receiving mail and blocks mailbox logins, and how to choose in WHM what happens to incoming messages so nothing is lost while an account is suspended.

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.

The rejection is a **permanent** error. The sending server does not retry, it gives up immediately and returns a bounce to the sender. Messages sent during the suspension are gone, even after you reactivate the account.

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.org is rejected.
Mail from @example.com still 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.

This is cPanel's own caution: delivering to a suspended account requires the server to evaluate that account's mail filters and forwarding rules. Those rules can be abused to retain access to a server after an account has been suspended, which is often exactly why the account was suspended in the first place. Avoid this option for suspensions that are security-related.

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.

Older guides mention a "defer" behaviour, which returns a *temporary* error so the sending server keeps retrying for several days. cPanel no longer exposes it in WHM, so you will not find it in the list. It is also worse for the sender: their mail server starts issuing "delivery delayed" notices after roughly a day, so your customer's contacts see warnings. Queueing avoids that entirely.

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.1

Then 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>
QUIT

The 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.

The 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.

Suspending an account also blocks mail sent to it, including from your own billing system. If the suspension notice goes to an address hosted on the account you just suspended, the customer never receives it. Keep billing contact addresses on a domain you are not going to suspend.

Still stuck? Ask a human, we answer in minutes.