Domain Has Exceeded the Max Defers and Failures per Hour

What does "Domain has exceeded the max defers and failures per hour" mean?

The error means cPanel has temporarily stopped a domain from sending outgoing mail because both the number and percentage of failed or deferred deliveries reached the configured protection thresholds.

A user may notice the problem while sending a completely normal message from Roundcube, Outlook, Thunderbird, a phone, or another mail client. The mailbox still exists, the password may be correct, IMAP may work, and incoming mail may continue to arrive. That makes the error easy to misread as an SMTP login problem even though authentication may have nothing to do with it.

The restriction is evaluated for the domain, not simply for the one person who happens to see the error. A single noisy source can therefore affect otherwise healthy mailboxes. A compromised account may send to hundreds of invalid recipients. A WordPress contact form may repeatedly try to deliver notifications to an address that no longer exists. A cron-driven application may keep processing a stale mailing list. Exim sees the failures even if the owner who reports the problem personally sent only one or two messages.

The same domain-level reasoning matters on temporary setups too. If you are diagnosing mail on a test account that uses a subdomain rather than a separately registered domain, the hosting model described in test hosting with a third-level domain can help clarify which domain cPanel is actually evaluating.

With cPanel access, start with Email > Track Delivery. With root access, check /var/log/exim_mainlog. The goal is to find several messages that contributed to the failed/deferred count instead of diagnosing the domain from the final block message alone.

grep 'example\.com' /var/log/exim_mainlog

A domain search is only the first pass. On a busy mail account it can mix legitimate mail, bounces, local deliveries, remote deliveries, and unrelated recipients into one long output. Once a suspicious transaction appears, stop searching broadly and follow that specific Exim message through the log.

exigrep '1rAbCd-000XYZ-1A' /var/log/exim_mainlog*

That changes the diagnosis. You are no longer asking why example.com is blocked in general; you are asking how one particular message entered Exim, where Exim tried to deliver it, and what happened next.

After this first section you should be able to separate the defer/failure protection from an unrelated SMTP authentication error, connection failure, or normal hourly-volume limit.

Why does cPanel block the domain after failed or deferred email?

cPanel triggers this protection only when two conditions are reached together: the domain has accumulated at least the configured minimum number of failed/deferred messages, and those messages represent at least the configured percentage of its outgoing and local mail over the previous hour.

The two relevant server-side controls are:

• Number of failed or deferred messages a domain may send before protections can be triggered
• Maximum percentage of failed or deferred messages a domain may send per hour

At the configuration level, these correspond to email_send_limits_min_defer_fail_to_trigger_protection and email_send_limits_max_defer_fail_percentage. The minimum count exists so that a tiny sample does not trigger protection only because its percentage looks dramatic.

Suppose the minimum count is 5. Four messages are sent, all four fail, and the failure rate is therefore 100%. The percentage condition may be satisfied, but the count condition is not. Once five failed/deferred messages have accumulated, cPanel can apply the percentage condition as well.

Why does 5/5 (100%) not mean a five-email hourly limit?

The second 5 is the defer/failure count threshold, not the normal hourly sending quota. A domain can have an hourly quota of hundreds of messages and still encounter an error such as 5/5 (100%) if its recent delivery attempts have failed badly enough.

For example, an Exim entry can contain:

Domain example.com has exceeded the max defers and failures per hour (7/5 (20%)) allowed. Message discarded.

Read that as seven failed/deferred messages, a minimum protection threshold of five, and a current failed/deferred percentage of 20%.

Why must both the count and percentage thresholds be reached?

The count threshold prevents very small mail volumes from producing misleading blocks. If a newly created domain sends one message to a misspelled address, its failure percentage is 100%, but that single failure alone does not satisfy a minimum threshold of five.

The percentage threshold serves a different purpose. A busy domain might produce five failed messages while successfully delivering hundreds more. Five failures in that traffic pattern do not describe the same situation as five failures out of five attempts.

Do not chase the wrong counter. Before changing anything in WHM, check the defer/failure settings separately from Maximum Hourly Email by Domain Relayed.

Which defer/failure limit is actually applied to the domain?

If the value shown in one WHM screen does not seem to match the error, check the configuration from the most specific level back toward the server defaults. cPanel can have an individual domain percentage override, an account-level value, and a server-wide default. Looking only at Tweak Settings can therefore send an administrator down the wrong path.

For a cPanel account, the percentage may be visible under:

WHM > Account Functions > Modify an Account > Maximum percentage of failed or deferred messages a domain may send per hour

A root administrator should also check the owning account file if an individual domain override may exist:

grep 'MAX_DEFER_FAIL_PERCENTAGE' /var/cpanel/users/username

A result such as:

MAX_DEFER_FAIL_PERCENTAGE-example.com=25

means that example.com has a domain-specific percentage configuration. That is more useful evidence than assuming that every domain under the account follows the same global number.

Which emails are generating the failed and deferred count?

The messages contributing to the counter may have been generated by a completely different source from the mailbox whose owner reports the problem. Find several recent failed or deferred deliveries and compare their sender, recipient, result, authentication method, and source.

A typical support conversation starts with: "I sent only two messages today." That can be true. The same domain may also have a WordPress form, a second mailbox, a scheduled billing application, an autoresponder, a CRM, or a compromised SMTP password generating mail in the background.

If the five latest failures all belong to another sender and point to dozens of unrelated recipients, the mailbox that reported the error stops being the main suspect.

How to check failed mail in cPanel Track Delivery

If you do not have root access, cPanel Track Delivery is the fastest starting point when the hosting provider exposes the feature and the required mail statistics are available. Open cPanel > Email > Track Delivery and filter for deferred and failed messages.

Do not stop at the red or deferred status indicator. Inspect the fields that explain the transaction:

• From Address
• Sender
• Sender Host or Sender IP Address when available
• Authentication
• Recipient
• Result
• Message ID

The Result field often gives more useful information than the visible From address. Five messages with five unrelated failures suggest a different investigation from fifty messages returning the same 550 user unknown response.

How to inspect /var/log/exim_mainlog with root access

On a cPanel server, /var/log/exim_mainlog contains Exim receipt and delivery activity. Start broadly enough to find the affected domain, then narrow the investigation around one or more Exim queue IDs.

grep 'example\.com' /var/log/exim_mainlog

exigrep 'example.com' /var/log/exim_mainlog*

Exim log markers help while reading a transaction. Depending on the entry, you will commonly see <= when Exim receives a message, => for a successful delivery route, ** for a failed delivery, and == when a delivery is deferred.

The interesting line is often the submission line, not the final bounce. First establish how Exim received the message. Then follow the same Exim queue ID to the delivery result.

Which Message ID should you use with exigrep?

Do not confuse the Exim queue ID with the RFC Message-ID header inside the email. Both identifiers can appear during troubleshooting, but commands such as exigrep are especially convenient when you copy the Exim queue ID from the main log.

An Exim queue ID typically appears near the beginning of a log entry and looks similar to:

1rAbCd-000XYZ-1A

The RFC header may look like:

Message-ID: <20260910153000.12345@example.com>

If you have the Exim queue ID, use it consistently when tracing receipt, routing, defer, failure, and completion lines:

exigrep '1rAbCd-000XYZ-1A' /var/log/exim_mainlog*

That keeps one transaction together. A domain-wide grep is good for discovery; the queue ID is better for proving what happened to a specific message.

What if Track Delivery shows nothing useful?

Track Delivery is not guaranteed to be available or equally useful on every hosting account. A provider can restrict the feature, and the interface depends on Exim statistics. If the UI lacks the necessary history and you have root access, switch to /var/log/exim_mainlog rather than guessing from the user's bounce message.

If you do not have root access either, save the exact error text, sender, recipient, approximate sending time, and any visible delivery record before contacting the provider. Those details give support enough anchors to find the transaction server-side.

Are bad recipient addresses or remote mail servers causing the failures?

If the sender is legitimate, classify the remote delivery errors before changing server settings. Permanent SMTP failures, temporary deferrals, DNS errors, and remote throttling require different fixes even though all of them can contribute to the cPanel protection.

How do permanent failures differ from temporary deferrals?

A permanent SMTP failure normally means Exim has received a response indicating that the message cannot be delivered as addressed. A temporary defer means delivery may succeed later, so Exim normally keeps the message for another delivery attempt.

A simplified distinction looks like this:

550 5.1.1 User unknown
Permanent failure: verify or remove the recipient.

451 4.x.x Temporary server problem
Temporary defer: inspect the exact remote response and retry behavior.

Connection timed out
Temporary defer: check whether the destination host is reachable and whether the issue repeats.

Do not translate every 4xx response into "our IP is blacklisted." A remote provider may temporarily throttle traffic, use greylisting, experience a service problem, or reject a particular policy condition. Likewise, a 5xx response is not automatically evidence of a blacklist. Read the text returned by the remote server.

What does a permanent Exim failure look like?

A permanent recipient failure may appear in exim_mainlog in a form similar to this simplified example:

2026-09-10 15:21:44 1rAbCd-000XYZ-1A ** baduser@example.net
R=dnslookup T=remote_smtp H=mx.example.net [192.0.2.25]:
SMTP error from remote mail server after RCPT TO:<baduser@example.net>:
550 5.1.1 User unknown

Four parts matter immediately:

• ** tells you that the delivery failed;
• baduser@example.net tells you which recipient failed;
• H=mx.example.net identifies the remote host involved;
• 550 5.1.1 User unknown gives the remote server's reason.

If five different messages fail with the same User unknown result against addresses imported from one mailing list, the next useful action is not an Exim restart. Clean the list.

What does an Exim defer look like?

A temporary connection problem can look different:

2026-09-10 15:24:18 1rEfGh-000ABC-2B == user@example.net
R=dnslookup T=remote_smtp defer (110):
Connection timed out H=mx.example.net [192.0.2.25]

Here the == marker matters. The message was deferred rather than permanently failed, and the reason is a connection timeout. That does not prove whether the problem is the remote server, a network path, firewall policy, or another transient condition. It tells you which branch to investigate.

One timeout is weak evidence. Twenty consecutive timeouts to the same MX while other destinations deliver normally are much more useful. Group the failures before changing anything.

When the log points to a recipient-domain DNS problem, verify that domain instead of changing the sending server's DNS at random:

dig MX recipient-domain.tld
dig A mail.recipient-domain.tld

MX and CNAME records solve different DNS tasks. If the destination setup uses aliases as well as mail records, review the separate CNAME-to-another-domain case instead of treating a CNAME result as proof that mail routing is correct.

An MX record that resolves correctly proves only that the DNS lookup works; it does not prove that the destination SMTP service accepts connections. A DNS failure affecting one recipient domain also does not explain failures to twenty unrelated domains.

If almost every defer targets one provider and other external mail delivers normally, inspect that provider's repeated SMTP response. If failures are spread across many unrelated destinations and contain invalid-user responses, turn your attention back to the sender or recipient database.

Is a compromised email account sending through SMTP authentication?

If the domain owner does not recognize the outgoing messages, check whether Exim accepted them through authenticated SMTP. Authentication markers can point directly to the mailbox whose credentials were used.

Trace a suspicious Exim queue ID:

exigrep '1rAbCd-000XYZ-1A' /var/log/exim_mainlog*

Then inspect the submission line. An authenticated SMTP transaction may contain data similar to:

<= sender@example.com H=client.example.net [203.0.113.25]
P=esmtpa A=dovecot_login:sender@example.com S=1842
id=example-message-id@example.com
T="Invoice"
for recipient@example.net

How do you identify an authenticated SMTP sender in Exim logs?

If the submission contains A=dovecot_login: or A=dovecot_plain:, begin with the authenticated mailbox rather than assuming that a PHP script sent the message.

Now you have something concrete: Exim accepted the message using that mailbox's credentials. The visible From header is no longer your primary evidence.

Authentication by itself does not prove compromise. A CRM, monitoring service, website plugin, desktop mail client, phone, or helpdesk can legitimately use the same account. Compare four pieces of evidence:

• the authenticated email address;
• the source IP or host;
• the recipients;
• the sending time and volume.

If the account owner does not recognize the activity, change that mailbox password promptly. Then update the new password only on known devices and applications. If a forgotten integration still contains the old credential, its future authentication attempts should fail, which can help expose the forgotten sender.

You can search recent activity for the mailbox:

grep 'sender@example\.com' /var/log/exim_mainlog

What does the sender IP tell you?

An unfamiliar IP is a clue, not proof that the password was stolen. If the mailbox owner says, "That is not my IP," check whether the address belongs to a CRM, monitoring platform, office gateway, VPN, mobile carrier, or other known service before calling the event a compromise.

Three patterns deserve different reactions:

• Known user IP: verify whether the user's mail client or device generated the messages.
• Known external application IP: check the CRM, website, ticket system, scanner, monitoring service, or other application configured with the mailbox credentials.
• Unknown IP plus unexplained recipients: treat the credential as potentially compromised and reset it while investigating the affected devices and integrations.

The recipients matter as much as the IP. A known CRM connecting from a familiar network but suddenly sending to thousands of unrelated addresses can still be malfunctioning or abused. A mobile IP that changes every day may be perfectly normal for a user.

Is WordPress, PHP, or another website script generating the failed mail?

If suspicious messages do not show SMTP authentication, investigate locally generated mail. WordPress, WooCommerce, custom PHP code, cron jobs, CMS plugins, and malicious scripts can hand messages to the local mail system without logging in through a mailbox.

This does not make every PHP-generated message suspicious. A legitimate WooCommerce store may send order notifications, a WordPress contact form may notify an administrator, and a billing application may send scheduled reminders.

The From address is not enough. Trace one failed message back to its submission and check how Exim received it.

How does the Exim cwd entry help locate a sending script?

Exim's cwd entry records the current working directory associated with a local submission. It can narrow the source to a cPanel account or application directory, although it does not necessarily identify the exact PHP file responsible.

For one known Exim queue ID, look around its submission:

grep -B1 '1rAbCd-000XYZ-1A' /var/log/exim_mainlog | head -1

You may find an entry containing a directory such as:

cwd=/home/username/public_html

Or a more specific path may point deeper into a site:

cwd=/home/username/public_html/wp-content/plugins/example-plugin

The directory narrows the search. It does not prove that every PHP file inside that directory is malicious.

For a wider server-level check, an administrator can count directories appearing as Exim working directories:

awk '$3 ~ /^cwd/{print $3}' /var/log/exim_mainlog \
| sort \
| uniq -c \
| sed "s|^ *||g" \
| sort -nr

A directory with unusually heavy activity deserves investigation, but do not delete files merely because the directory appears often. A busy application can generate legitimate mail. Correlate the message timestamps with web access logs, application logs, cron schedules, WordPress scheduled tasks, and actual recipients.

How can you separate an SMTP mailbox from a local website source?

Use authentication and working-directory evidence together rather than guessing from the visible From address.

No SMTP auth? Check the local submission. If the same cwd appears every five minutes, compare those timestamps with cron and application schedules. A repeating interval is often more useful than the From address.

If WordPress is the source, disable only the feature or plugin that is generating the suspect mail when possible. Turning off the entire website may be unnecessary. If the source looks malicious, the investigation must expand into file integrity, administrator accounts, plugins, themes, scheduled tasks, and the wider hosting account.

What should you stop first when the domain is already blocked?

Stop the process that is creating new failures before trying to remove the block. If a cron job submits another bad message every few minutes, waiting an hour solves nothing useful: the previous-hour statistics keep receiving fresh failures.

Then watch the log. At this stage you are not trying to prove that every message delivers; you are checking whether the offending source has stopped submitting new mail.

tail -f /var/log/exim_mainlog | grep 'example\.com'

Fresh submissions are still appearing? The source is not contained.

How do you confirm that the mail source has actually stopped?

The verification should match the source you identified. A generic "nothing looks wrong now" check is weaker than testing the exact signal that led you to the source.

Suppose a suspicious mailbox previously produced an authenticated submission every minute. After changing the password, monitor the same account:

tail -f /var/log/exim_mainlog | grep 'A=dovecot_login:sender@example.com'

If the suspicious submissions stop but a legitimate Outlook client now reports authentication errors, that is expected until the new password is entered there. The important distinction is that unauthorized or unexplained mail is no longer entering Exim.

For a local PHP source, use the path you already found rather than grepping only for the domain:

grep 'cwd=/home/username/public_html' /var/log/exim_mainlog | tail -50

If the messages followed a fixed cron schedule, note the last submission time and wait through the next expected execution. No new submission at that point is stronger evidence than simply seeing a quiet log for thirty seconds.

Should you delete the Exim mail queue?

Do not purge the entire Exim queue because one domain reached the defer/failure limit. A shared server may have legitimate deferred mail for many unrelated accounts and destinations.

First inspect the queue:

exim -bpc
exim -bp

WHM administrators can also use Email > Mail Queue Manager to inspect queued messages. Filter and verify the sender, domain, recipient, and Exim queue IDs before removing anything.

If a compromised application has placed hundreds of clearly unwanted messages into the queue, removing those identified messages can be appropriate after the source has been stopped. The queue is not the source. Deleting it first while the same script continues feeding Exim only gives the queue time to fill again.

Should you increase or disable the cPanel defer and failure limit?

Changing the cPanel defer/failure percentage can restore mail flow, but it should come after the failed-mail source has been identified. The normal hourly sending quota, the failed/deferred percentage, and the minimum defer/failure trigger are different controls.

Increasing Maximum Hourly Email by Domain Relayed does not solve a max defers and failures per hour incident when the defer/failure thresholds are the controls being hit. A domain may be far below its normal hourly volume limit and still be blocked because too many recent attempts failed.

Which value wins: server, account, or domain?

Check the most specific configuration first. An individual domain can have a percentage override, an account can have its own setting, and otherwise the server-wide configuration provides the inherited behavior. This matters when the number displayed in one WHM screen does not match what you expected from the global policy.

A practical root-level check starts with the cPanel user file:

grep -E 'MAX_DEFER_FAIL_PERCENTAGE|MAX_EMAIL_PER_HOUR' /var/cpanel/users/username

A domain-specific percentage override can look like:

MAX_DEFER_FAIL_PERCENTAGE-example.com=25

An administrator who sees a value there should not assume that changing only the global percentage will immediately change the effective behavior for that domain.

Then check the account-level configuration in:

WHM > Account Functions > Modify an Account

Finally compare it with the server-wide mail settings under:

WHM > Server Configuration > Tweak Settings > Mail

This order prevents a common support dead end: an administrator changes the server default, tests again, sees the same result, and concludes that Exim ignored the setting. The more specific configuration may simply still be in place.

What if WHM shows Unlimited but the domain is still blocked?

If one WHM view says Unlimited but the domain still produces a max-defers error, do not immediately assume that cPanel is malfunctioning. First confirm which setting says Unlimited and whether it is the setting involved in this protection.

Check these possibilities:

• the screen shows the normal hourly sending limit rather than the failed/deferred percentage;
• the account has a different percentage value from the server default;
• the individual domain has a MAX_DEFER_FAIL_PERCENTAGE-domain.tld override;
• you are looking at a different cPanel account from the one that owns the domain;
• the visible error was generated before the configuration change;
• mail statistics or Eximstats need to be checked before trusting an incomplete UI view.

Use the exact error, account owner, domain configuration, and fresh Exim entries from after the change. Otherwise you can spend a long time comparing settings that were never involved in the rejected transaction.

When is a temporary Unlimited value reasonable?

A temporary Unlimited value for the failed/deferred percentage can be reasonable after the cause has been fixed and an administrator needs to restore mail without waiting for the previous-hour statistics to fall below the configured threshold.

With WHM root access, the account-level control can be reviewed under:

WHM > Account Functions > Modify an Account > Maximum percentage of failed or deferred messages a domain may send per hour

Before changing it, record the existing policy and verify that the bad source has stopped. If the setting is relaxed temporarily, return the account to its intended configuration after mail flow has been checked.

How can an individual domain have a different percentage limit?

For a root-level per-domain override, cPanel supports a MAX_DEFER_FAIL_PERCENTAGE-domain.tld entry in the owning account's user configuration.

MAX_DEFER_FAIL_PERCENTAGE-example.com=25

The entry belongs in:

/var/cpanel/users/username

After editing the account file, apply the domain data with:

/usr/local/cpanel/scripts/updateuserdomains

This is an administrative configuration method, not the first troubleshooting action. Before creating or changing an override, establish what value is already effective and why the current protection triggered.

How do you know when the domain can send email again?

The domain can send normally again once the failed/deferred statistics no longer satisfy both protection conditions, or after an administrator deliberately changes the applicable percentage configuration. Do not assume that the block simply expires at the top of the next clock hour.

cPanel evaluates outgoing and local mail over the previous hour. As those statistics change, the domain can fall below the conditions that triggered protection. Waiting helps only if the source of new failures has stopped.

If a script keeps submitting another bad message every few minutes, fresh failures continue to enter the calculation. Waiting while the sender is still active is not a fix.

Do you need to restart Exim?

Restarting Exim is not the normal fix for a domain that crossed the cPanel defer/failure thresholds. A restart does not correct invalid recipients and does not revoke a compromised SMTP password.

An Exim restart belongs to a different troubleshooting branch: service failure, a configuration change that requires a reload, or another MTA-level problem. If the log explicitly shows R=enforce_mail_permissions with the max-defers message, investigate the mail statistics and source before touching the service.

Why should the first test go to a known-good recipient?

A known-good recipient removes one variable from the recovery test. Resending to the same misspelled or disabled mailbox that caused earlier failures can immediately produce another bounce and make a successful repair look unsuccessful.

Trace the test message using its Exim queue ID:

exigrep '1rTest-000XYZ-3C' /var/log/exim_mainlog*

You want to see that the message did more than enter Exim locally. A receipt line such as this:

2026-09-10 16:02:11 1rTest-000XYZ-3C <= sender@example.com
H=mailclient.example.net [203.0.113.44]
P=esmtpsa A=dovecot_login:sender@example.com S=2015

only proves that Exim accepted the message from the authenticated client. That is not remote delivery.

What does successful remote delivery look like in Exim?

A successful remote delivery normally produces a => entry for the recipient, followed by completion of the message transaction. A simplified example looks like this:

2026-09-10 16:02:12 1rTest-000XYZ-3C => recipient@example.net
R=dnslookup T=remote_smtp H=mx.example.net [192.0.2.25]
C="250 2.0.0 OK"

2026-09-10 16:02:12 1rTest-000XYZ-3C Completed

The useful evidence is the sequence:

• Exim accepted the message;
• Exim routed it to the remote SMTP transport;
• the remote host returned a success response;
• the Exim transaction completed.

Now you have proof. The mail client merely stopping its error popup is weaker evidence because a message can be accepted locally and still fail later during remote delivery.

One successful message does not prove that a mailing list is clean. After a clean single-message test, try several ordinary destinations if that matches the user's normal mail pattern. Only then resume newsletters, notification batches, or application queues.

How can you prevent max defers and failures from returning?

If the same domain hits the protection again after the first incident, the earlier problem was probably cleared rather than fully explained. After recovery, you should be able to name the source, the failure pattern, and the change that stopped it.

For ordinary mailboxes, use unique passwords and investigate unexplained SMTP clients or source IPs. If an old CRM or phone no longer needs a mailbox credential, remove it. A password stored in several forgotten applications is much harder to control than one used only by known clients.

For WordPress and other CMS installations, watch individual mail-producing components rather than treating "the website" as one sender. Contact forms, WooCommerce notifications, membership plugins, scheduled actions, cron jobs, and custom code can generate completely different mail streams. When the domain begins failing again, correlate the timestamp with those tasks.

For mailing systems, remove hard-bouncing recipients instead of repeatedly retrying them in future campaigns. A list that keeps known invalid addresses can turn a simple data-quality problem into a domain-wide mail restriction.

For server administration, keep meaningful defer/failure protection in place. A more generous threshold may be appropriate for a particular workload, but excessive limits should not hide a compromised account. The useful baseline is the normal sender, volume, recipient pattern, and failure behavior for that domain.

What should you monitor after the incident?

Monitor three things after mail flow returns: who is sending, which destinations are failing, and how the messages enter Exim. Those three signals usually expose a recurrence earlier than the final cPanel block.

There is no single healthy failure percentage for every workload. A transactional application sending to verified customers has a different normal pattern from a large mailing list. Use the domain's own legitimate traffic as the baseline and investigate changes that cannot be explained by its applications or users.

A useful final test is not simply "Does email work now?" Ask a stricter question: "What generated the failures that caused the block?" If you can identify the source, explain the remote errors, show why the protection triggered, and prove that new bad submissions have stopped, the incident is actually closed. If you cannot name the source, keep investigating.