You've seen the error message 550 5.7.1 Daily sending quota exceeded or 552 5.3.4 Message size exceeds fixed maximum message size and now you're looking for the exact number. The problem is that "email sending limit" isn't a single number; at least five independent limits sit along the path of a message, and each one is enforced in a different place. Until you figure out which layer rejected your message, any change to settings is just guesswork.
The five limits applied to a single email
A message's path from mail() in PHP or from Thunderbird to the recipient's inbox passes through these layers, and each layer has its own limit:
| Layer | What it limits | Typical value | Sample error |
|---|---|---|---|
| Local MTA (Exim/Postfix) | Number of recipients per message | 50 to 100 | 452 Too many recipients |
| Local MTA | Total message size after Base64 | 25 to 50 MB | 552 Message size exceeds |
| Account quota | Number of messages per hour/day | 200 to 500 per hour | 550 Daily sending quota exceeded |
| Destination service | Connection rate from a single IP | Variable, often unknown | 421 Too many connections |
| Final recipient | Message size after receipt | 10 to 25 MB | Silent rejection or bounce |
The layer that catches most people off guard is the last one. Suppose your host accepts a 30 MB message and it sends successfully. Gmail rejects that same message on its end, because its actual limit is lower. You only see 250 OK in the host log and think everything was fine. Until you open the bounce in the sender's inbox, you won't realize what happened.
Why attachment size isn't the same as file size
A 20 MB file on disk becomes about 27 MB in SMTP. The reason is that attachments are encoded with Base64, and this encoding adds roughly 33 percent to the size. Add to that MIME headers, multipart boundaries, and UTF-8 encoding of the text.
The approximate formula that works in practice: raw file size multiplied by 1.37, plus a few fixed kilobytes. So if the message limit is 25 MB, the largest file that actually goes through is about 18 MB, not 25.
Here's where people make a mistake: the user raises the message limit in the panel to 50 MB and thinks the problem is solved. Then messages silently get stuck in the MTA queue, the queue fills up, and sending for the entire domain stops. The sign is that even small emails stop going out. Only raise the limit as high as your actual recipients will accept; anything higher just holds the queue hostage.
Recipient count limit and the difference between To and BCC
The recipient limit per message is usually between 50 and 100, and it's counted on the total of To, Cc, and BCC, not just To. If you email 300 people via BCC, you'll get the same 452 Too many recipients error.
The right solution is to split into smaller batches, not to remove BCC. But simple splitting isn't enough either: if you send 10 messages back-to-back to the same domain, the destination server detects it as a bulk sending pattern and closes the connection with 421. Leave at least 30 to 60 seconds between batches.
For sending to a list larger than a few hundred people, the host's SMTP isn't the right place. This is where the discussion of transactional email and why not to send from the host becomes serious; dedicated bulk sending services handle queue management, warmed-up IPs, and bounce reporting themselves, and free you from wrestling with local limits.
Where hourly and daily sending quotas come from
This limit exists to prevent abuse, not to restrict you. If a user's account turns into a spam tool for any reason (vulnerable script, contact form without captcha, leaked password), the hourly limit prevents sending a hundred thousand messages in ten minutes and gives you a chance to notice before the domain's IP lands on a blacklist.
See the sign of hitting this limit in the Exim log with this command:
exim -bp | wc -l
grep "sending quota" /var/log/exim/mainlog | tail -20If the first command returns a large number and you see repeated lines in the second log, it means messages are stuck in the queue and the limit has kicked in. Clearing the queue without fixing the cause just brings back the same situation a few hours later.
How to raise the hourly limit
In most control panels this number is changeable, but any change should have a reason. If you genuinely have a newsletter with 800 subscribers that you send once a week, raising the limit makes sense. If you have a script that sends three emails per signup and you get 2,000 signups a day, your problem isn't the limit; it's the sending architecture.
Mailbox quota, the limit that gets forgotten
The sending limit is only one side of the story. When the recipient's mailbox fills up, the server rejects new messages with 552 Mailbox full and the sender thinks your domain is broken. If you've run into "mailbox full" messages or strange bounces, email quota management and solutions for a full mailbox opens up exactly this scenario.
One practical note: mailbox quota and sending limit are two separate settings, and raising one has no effect on the other. If you bring up both in a single ticket, you'll get to an answer faster.
How to figure out which limit rejected you
- Read the three-digit SMTP code.
5xxmeans permanent rejection,4xxmeans temporary and retryable. - Copy the full error text, not just the code. The word
quotapoints to the sending limit,sizeto size,recipientsto recipient count. - Match the MTA log to the same time window to figure out whether the error came from your side or the destination server.
- If the error is from the destination side, check the domain records. Missing or misconfigured SPF and DKIM cause messages to be rejected, even when no limit was hit. With the MX record and domain records lookup tool you can see the current status.
In my experience, more than half of the cases reported as "sending limit" are actually domain authentication problems. The message is sent, no limit is hit, but on the recipient's side it goes to spam or is rejected entirely. If messages are being sent but not arriving, a completely different troubleshooting path is needed, which is laid out step by step in the guide to fixing emails going to spam.
Choosing between raising the limit and changing the architecture
If your sending volume is under a few thousand messages a day and they all genuinely go to real recipients, raising the limit on the same host is enough. Simpler, cheaper, and without extra dependencies.
But if you've entered bulk sending territory, raising the limit is the wrong move. The cost is that you tie the host's shared IP to your own reputation; one bad campaign can lower the deliverability of every domain on that server. In that case, separating the bulk sending path from the business email path is the right decision, even if it takes more work.
For business domains that send a few hundred regular emails a day, a Linux host with a configured Exim and transparent limits is enough; just read the limit number from the panel before launching a campaign and set up recipient batching correctly from the start.
Before any other change, check three things: the full error code and text, the actual message size after Base64, and the recipient count per batch. In most cases, the answer is in these three numbers. If you're still stuck after that, the documentation and knowledge base and ultimately the ServerNet blog have covered similar cases with configuration details.
Frequently asked questions
What is the email sending limit on shared hosting?
There's no fixed number and it varies between providers; the common range is between 200 and 500 messages per hour and a few thousand messages per day. Get the exact number for your own service from the control panel or that provider's documentation, because guessing means you'll hit the limit at the worst possible time.
Why won't an email with a 20 MB attachment send?
Because Base64 encoding increases the attachment size by about 33 percent, and a 20 MB file becomes close to 27 MB in SMTP. If the message limit is 25 MB, this message gets rejected. For files larger than 10 MB, send a download link instead of an attachment.
What's the difference between a 550 and a 452 error in SMTP?
5xx codes are permanent errors and retrying is pointless; like 550 Daily sending quota exceeded, which means the daily limit is full. 4xx codes are temporary and the sender should retry later; like 452 Too many recipients, which is solved by splitting the message into smaller batches.
Does raising the sending limit fix the spam problem?
No. Sending limit and deliverability are two separate issues. If messages are being sent but going to spam, the problem is in SPF, DKIM, and DMARC records or domain reputation, not the limit. Start by checking domain records and then move on to limit settings.