So, you’ve sent a campaign and expect to get some bounces back because you intentionally put invalid emails there but nothing shows in the bounces area of the campaign and you are stumped because of that (that makes two of us) and of course you need to know why.
When a bounce server is being used to process bounces, its status changes from active to “cron-running” in your AppMail web interface.

AppMail relies on pcntl extension to make sure if the process doesn’t exit nicely (because of some error or timeout) to restore the initial status of the server, that is, the active status so that the server can be selected next time when the cron job will run.
The thing is, the pcntl extension is something that doesn’t come with php and has to be installed separately so most of the time is likely that your php install doesn’t contain the extension. And because the extension is missing, AppMail might not be able to restore a proper state of the bounce server (AppMail has fallbacks mechanisms to cope with missing pcntl extension) and your bounce server will remain stuck in cron-processing mode and will not be picked for processing next time when the cron runs, remember, only bounce server having the status active are picked up for processing.
Bottom line, if you see your bounce server has the status “cron-running” for more than 30 minutes, then you can go to your application.

Backend -> Miscellaneous -> Emergency Actions and reset your bounce servers status so that they become active again.
Another thing is that, when processing bounces, AppMail uses php’s imap extension and even if your web instance of php contains the imap extension that doesn’t mean your command line (CLI) contains it too, matter a fact, I saw multiple servers that use php 5.3 as the web module(well, yeah php-fpm too, but you get the point), and php 5.2 as the CLI module.
You can verify this from command line, by running the command

php -v

which will tell you the version you are using in command line and if that is indeed using the CLI module and not the web module, because, I also saw the command line calling the web module, which is wrong since the web module is subject to timeouts and the such while the command line module isn’t (well, it shouldn’t anyway) thus is perfect for long running scripts.
To make sure your command line php contains the imap extension and the functions, the best way would be to create a php file on your server, say imap.php with the following contents:

var_dump(function_exists('imap_open'));

then run in from command line with: php imap.php

If the output contains the false word, then you don’t have imap installed and you have too.
If all the above look fine on your server, then make sure you don’t use services like gmail / yahoo / aol / etc as bounce servers. These services will limit the number of connections and might as well deny access to read the bounce boxes thus AppMail won’t be able to connect and read the emails.

Other things you can do, since the cron job for processing bounces is a simple command line script, you can actually call it from the command line as:
php {FULL_PATH_TO_APPS_FOLDER}/apps/console/console.php bounce-handler
and see how that goes, if it processes any bounce from your bounce box.

IMPORTANT NOTES:

1) Because of the nature of processing bounces, because each email has to go through thousand of bounce rules and because connecting to imap/pop3 server is usually a slow action (like any other network action) you should make sure your command line php has enough memory to process your bounces. This, in tandem with the settings for bounces from Backend -> Settings -> Cron should be tweaked to match your server.

2) While processing bounces, AppMail has to scan the email box over and over again and has to go through all the emails in that box to make sure those are bounces caused by sending a campaign with AppMail.
This is why it is very important to use the bounce email box only for processing bounces from AppMail and not for any other sort of communication.
This way AppMail doesn’t have to go through thousand emails that have nothing to do with the campaigns AppMail has sent, which in turn makes bounce processing very efficient.
Additionally, when adding a bounce server in AppMail, you have an option to “Delete all messages”. We recommend you turn it on, which means that even if by accident that bounce email box will get emails not related to AppMail, when AppMail will process those emails and will see they don’t belong in that email box, it will simply delete them, resulting in more efficient bounce processing next time when the bounce handler runs.

3) In AppMail, services like Amazon SES, Mandrill, Mailgun, Leadersend, ElasticEmail, Sendgrid not only work by using their smtp interface, but they do have custom API implementation in AppMail and when you create a delivery server, you can use the API implementation instead of the smtp implementation:

The reason why you should use these instead of the SMTP alternative is because they are slightly faster when sending and because you don’t need bounce servers at all because AppMail will subscribe to certain webhooks and will receive notifications when an email bounces, marks you as spam, etc so you don’t need the memory intensive cron job to process bounces.

Please note that AppMail will connect to the given email provider and will create a webhook where the email provider will send data. The webhook is a URL back to your AppMail application.
where X is the ID of your delivery server. This means that you don’t have to block incoming requests to these URLs.

Each of these providers have their own area where they show you which webhooks have been created and what events they will receive. Always make sure you check these areas to be sure the webhooks are created and the right events will be sent and of course see the history of the events they have sent in order to see if they actually have sent any info to your webhook url or not.