Domain ... exceeded the max emails per hour

So I attempted my first campaign of 2,000 emails to users of my product. I was surprised to see phplist just splated them out over a few minutes

Next day I get thousands of bounce messages like the above.

Now I have a mess. I do not know which messages succeeded, which failed, and it looks like I need to go through them one by one!

The emails appear to be sent in a random order, not by email address nor user id etc.? If I knew which ones were sent first I could mark those addresses as done and then resent to the others. Does it keep track of the time each email actually sent somewhere, so that I can sort on it? The following does not work

SELECT email, M.entered FROM plxk_usermessage M, plxk_user_user U where userid = order by M.entered

Phplist has statistics etc. for bounced emails. But it would seem to me that this could never work. There is no way that it can know what happens to emails because it can never see the bounce messages.

These are exactly the sorts of problems that I was hoping phplist would avoid. Otherwise it is pretty easy to write a .php program that runs through a table and just sends emails. Slowly.

So, what do I do now? Is there some utility that can read the bounce messages, or do I need to write that myself?

Thanks for providing phplist for free. But if it is not useful to the 90% of users that use a hosted service then you should say so clearly. It takes a lot of effort to work out how to use it effectively, and now to fix up the mess it creates. Useful functionality is far more important that pretty UIs.

Sounds like it didn’t work the way you were expecting, and that can be frustrating.

You should have some summary stats on the “sent” tab, views, clicks, etc.
The ones that were not viewed either didn’t get there, or were sent to a folder, unviewed.
For more detailed delivery stats, you should install two plugins: @duncanc “Common” plugin, and his “advanced statistics”

By default, phpList stores all of the bounces, if you search for a user, under ‘history’, you’ll see the bounce.

I’d probably start with the UI, figure out exactly what you are looking for, and then go into the SQL queries, it might be easier.


Just a thought, have you set the number of messages sent out in the config file that match your hosts email limits?

By default, phplist does nothing.

All it knows is that it sent something to the SMTP server. It has no way of knowing whether they were actually sent. Nor whether they bounced.

To do more would require lots of undocumented configuration, if it is really possible at all.

So I am left writing scripts to go through the bounce messages. Then I will manually update lists. I may or may not use phplist to actually send the emails, the value add is tiny.

There is no way a non-programmer could use phplist.

The problem, as always, is the lack of any real documentation.

There are many throttling options in the config file, and it is not clear what they all do.

define(‘MAX_PROCESS_MESSAGE’, 999);

What does that do once 999 have been sent? Just stop? How do I even know what the tool has actually sent?

There is also


Which seems to do the same thing


looks more promising. Make it large, say 30 seconds.

@aberas - I’ve been using phplist for several years and it has worked great for me. You may have already figured this out or even given up, but in case you haven’t, I’ll attempt to answer a couple of questions.

Let’s say you want to send a maximum of 400 emails per hour and you want a one second delay between sending each email.

First define the period of time you want to monitor. In the config.php file use the following:


3600 seconds is one hour.

Then define the maximum number of emails you want to send in the time period defined above. In the config.php file set use the following:

define('MAILQUEUE_BATCH_SIZE', 400);

Now set the delay between each email being sent. In the config.php file set use the following:

define('MAILQUEUE_THROTTLE', 1.00);

If you want a 1.5 second delay between emails, then you may use 1.50 instead of 1.00.

Leave the following at their default states.

define('MAX_PROCESS_MESSAGE', 999);

With this configuration, if you were sending 1,000 emails, the process will send 400 emails, with a one second delay between each email. Since you are permitting only 400 emails per hour, it will wait until the next hour and then send 400 more. It will then wait until the next hour and then send the remaining 200 emails. If there is another campaign waiting to be sent, then 200 emails would be sent from that other campaign during that hour time period.

Here is a typical message you should receive when send limits are enabled.

[Thu 6 Jul 2017 19:15] [CL] Started
[Thu 6 Jul 2017 19:15] [CL] Sending in batches of 400 messages
[Thu 6 Jul 2017 19:15] [CL] This batch will be 174 emails, because in the last 3600 seconds 226 emails were sent
[Thu 6 Jul 2017 19:15] [CL] Processing has started,
[Thu 6 Jul 2017 19:15] [CL] One campaign to process.
[Thu 6 Jul 2017 19:15] [CL] Processing message 227
[Thu 6 Jul 2017 19:15] [CL] Looking for subscribers
[Thu 6 Jul 2017 19:15] [CL] Found them: 7 to process
[Thu 6 Jul 2017 19:15] [CL] Processed 7 out of 7 subscribers
[Thu 6 Jul 2017 19:15] [CL] It took 15 minutes 01 seconds to send this message
[Thu 6 Jul 2017 19:15] [CL] Script stage: 5
[Thu 6 Jul 2017 19:15] [CL] 7 messages sent in 3.18 seconds (7925 msgs/hr)

1 Like

Thank you very much for that detailed reply. I will do this next time.

As it is, I just manually broke it up into small batches.

But your values should probably be the default. Then people would not have to find out by accident. If people really need higher speeds, then they could carefully tune these figures. The default should be conservative.

Or at the very least, warnings need to be put prominently in the documentation.

If you are in a position to effect either of those changes that would make the tool much better. Default configuration and documentation is important. Most people will not post to the forum, they will just fail and say that phplist does not work.