Domain has exceeded the maximum allowed defers and failures per hour (5/5 (100%))
Answered
### Explanation:
Within the last hour:
- All outgoing emails (5 out of 5) from the domain were either deferred (not delivered immediately) or failed (bounced or rejected).
- To prevent abuse or spam-like behavior, the server temporarily stopped accepting new outgoing emails from the domain.
### Common Causes:
- Incorrect recipient email addresses
- Remote mail server issues preventing delivery
- Sending emails to full or non-existent inboxes
- Compromised email accounts or forms sending messages to invalid recipients
Recommendation For cPanel Improvement
Subject: Review of Domain-Level Email Blocking Policy
Dear Community Members & cPanel Support Team,
We’ve encountered this issue multiple times where our domains were temporarily blocked from sending emails due to repeated failures or deferrals from a single email account. While we understand the importance of preventing spam and abuse, blocking an entire domain for issues related to one email ID can disrupt legitimate business operations.
Concerns:
- The restriction affects all users within the domain, even if only one account is experiencing delivery issues.
- This approach might unintentionally disrupt critical communications, causing delays and unnecessary troubleshooting.
- A more granular restriction, limiting the affected email address rather than the entire domain, would be more practical.
Request:
We kindly request cPanel to:
- Review the current domain-wide blocking mechanism and consider a more targeted approach for email failures.
- Allow exceptions or gradual restrictions, where only problematic email accounts are temporarily blocked instead of the whole domain.
- Provide administrative control for domain owners to monitor, override, or whitelist safe addresses from within the cPanel, but within the hosting provider's sending limits.
This adjustment would provide a better balance between spam control and uninterrupted business communication.
Thanks
-
Hey there! Thanks for sharing this - I've submitted this as a feature request over at features.cpanel.net and I'll bring it up with the team during our next meeting this coming Friday. I'll be sure to post once I have more details and let you know what we've decided!
0 -
Hey! Much appreciated. Looking forward to the post. Thanks.
0 -
Update - I spoke with the teams about this and this is not a behavior we want to change at this time. From a security standpoint we are concerned that if one account is compromised it is highly possible that another account on the same domain is compromised as well, so allowing other messages to continue to send could lead to further restrictions on the domain's email reputation.
0 -
Hello,
From a security standpoint, this can be controlled at the account level.
If one account is compromised, block it. If another account is also compromised, block it as well. If all accounts are compromised, block them all; however, this should be done at the account level, not the domain level.
Please see the screenshot of an example from another hosting panel that lets us control these settings at the account level. Even in cases of blocking, the system accurately identifies the problem account and blocks it while also sending an alert to admins to update the password.Thanks
0 -
eBD Hosting - you are 100% correct that it *can* be controlled, this isn't something we've had any other requests for on our side so it's not going to be something we will implement.
0 -
"...this isn't something we've had any other requests for..."
Well you have now!
I am 100% with eBD Hosting on this - including their suggested remedy.
And whilst you are at it perhaps you could reverse the breaking change that stopped perfectly valid email addresses containing the '#' character that had been used entirely satisfactorily for years from working as well please.
0 -
I'll bring this up with the team during our features meeting next week!
EalingBadger - can you get me more details about the # character issues you're having?
0 -
The explanation of the problem is here:
It is difficult to overstate the pain that this unnecessary breaking change (introduced in a recent cpanel update) has and continues to cause us.
0 -
I've added your feedback to the case! Our weekly features meeting is tomorrow, so I should have some data to share with you early next week.
0 -
I spoke with the team about this again just now and they confirmed this still isn't something we want to change as we want to block the entire domain when these are triggered.
0 -
With respect cPRex, this is ridiculous.
Taking out a whole domain in this context is far too broad-brush of an approach.
It is a sledgehammer to crack a nut.
0 -
You could also disable the feature completely if you don't want to risk an account getting blocked, although that opens up a different set of issues.
0 -
Thanks, but that's not really a solution.
0 -
I don't disagree, but at this point it's all I've got to offer.
0
Please sign in to leave a comment.
Comments
14 comments