cPanel Email Sending Limit Exceeded: How to Fix It Fast

You send a newsletter, a batch of invoices, or a WooCommerce order confirmation blast, and suddenly mail just stops going out. No bounce, no error in your inbox client — just silence. Nine times out of ten, you've hit cPanel's hourly email sending limit, and the account is holding every message after that until the hour resets.

This is one of those limits nobody notices until they need to send more than a handful of emails at once. Here's what's actually happening, how to confirm it, and how to fix it without turning your server into a spam cannon by accident.

Symptom: Mail Just Stops, No Error

The usual pattern:

• The first 30-50 emails in a batch go out fine, then everything after that vanishes.
• WordPress or your app reports success (no PHP error), but recipients never get the message.
• Webmail (Roundcube/Horde) shows the email as "sent" in Sent Mail, but it's actually queued or deferred server-side.
• WHM shows a notice like Exim on your.server has exceeded the maximum number of emails to be sent per hour.

If you're the site owner on shared hosting, you won't see WHM directly — but your host's support ticket will usually mention "max hourly email limit" or "send limit exceeded" when you report the issue.

Cause: cPanel/WHM's Max Hourly Email Limit

WHM has a setting under Server Configuration → Tweak Settings → Mail (or the older Max Emails Per Hour option) that caps how many messages a single cPanel account can send per rolling hour. It exists for a good reason: it's the single biggest brake against a compromised WordPress install or leaked SMTP password turning your server into a spam relay that gets the whole box blacklisted.

The default on most shared/reseller setups is somewhere between 100 and 500 emails/hour per account, but hosts often set it lower — sometimes as low as 50 — for cheaper shared plans specifically to control abuse. Once an account crosses that count, Exim just defers the rest until the hour rolls over. It doesn't reject them outright (usually), it holds them, which is why you don't get an obvious bounce.

Common triggers:

• A marketing/newsletter send from Mailchimp-style plugins (Mail Poet, WP Mail SMTP local relay) that don't use an external SMTP relay.
• WooCommerce sending order + admin notification emails during a sale spike.
• A compromised plugin or theme quietly sending spam through wp_mail() or PHP's mail().
• A cron job or import script that emails a notification per row processed.

Fix: Confirm It, Then Choose the Right Solution

Step 1 — Confirm It's Actually the Limit

In cPanel, go to Email → Track Delivery (or ask your host to check WHM → Mail Queue Manager / Track Delivery for your account). Look for a delivery status like:

Reason: "Message rejected due to local rule set. Account has exceeded the max defer fail
count for the domain. Message discarded."

or, in the Exim main log, something like:

grep "exceeded" /var/log/exim_mainlog | tail -50
grep "max_emails_per_hour" /var/log/exim_mainlog | tail -50

If you have SSH access, that log confirms it in seconds. If you're on shared hosting without shell access, this is exactly what to paste into your support ticket — it saves a back-and-forth.

Step 2 — Figure Out What's Actually Sending So Much Mail

Before asking for a higher limit, find out whether the volume is legitimate or a symptom of something broken:

• Check Track Delivery's sender breakdown — it shows which script/account triggered each send.
• Check wp-content for unfamiliar files if this is a WordPress site — mailer scripts dropped by malware often live in uploads or a random plugin folder.
• Review recent plugin/theme installs — a plugin update or a poorly coded contact form plugin is a common accidental cause.
• Check cron with crontab -l for jobs that might be emailing on every run.

If nothing looks abusive and the volume is just your own legitimate traffic (a real newsletter, real order confirmations), move to Step 3.

Step 3 — Raise the Limit the Right Way

If you manage your own WHM/VPS:

1. Go to WHM → Server Configuration → Tweak Settings, search for "email", and adjust Max hourly emails per domain.
2. Alternatively, set a per-account override in WHM → Manage Email Suspensions or via the account's Max Emails Per Hour field in Edit Account — this is safer than raising the global limit for every customer on the box.
3. Restart Exim to be safe: systemctl restart exim.

If you're on shared/managed hosting (most Getwebup shared and reseller plans), you won't have this WHM screen — ask support to raise the per-account limit and mention the log line from Step 1. A reasonable, justified request (e.g. "I send about 800 WooCommerce order emails during a sale") gets approved a lot faster than "emails aren't working."

Step 4 — The Better Long-Term Fix: Route Bulk Mail Through an SMTP Relay

Raising the limit helps once, but if you regularly send more than a couple hundred emails an hour, you're better off not routing that volume through the shared mail server at all. Use a transactional/bulk email service and connect it via SMTP:

This keeps your hosting account's reputation clean, avoids the hourly cap entirely (the relay has its own, much higher limits), and generally improves deliverability since services like SES and SendGrid have dedicated IP reputation management.

Prevention

• Move bulk/marketing sends off your hosting account permanently — use an SMTP relay for anything beyond transactional volume.
• Set a realistic per-account limit if you manage WHM, rather than leaving it at a low shared default that legitimate customers keep tripping.
• Monitor Track Delivery weekly if you send a lot of automated mail, so you catch a compromised script before it maxes out the limit and gets your IP blacklisted.
• Keep plugins and forms updated — most surprise email floods trace back to an outdated contact form or import plugin with an open mail-relay bug.

The limit itself isn't the enemy — it's what stopped one bad plugin from getting your entire server's IP blacklisted last time. Work with it (route bulk mail elsewhere, ask for a sane per-account bump) rather than fighting to disable it.