Managing your own web server not only means ensuring that your client's websites are being displayed. It also means that you need to make sure that your client's email is uninterrupted. While recommending clients use GSuite for their email (which is about a million times easier than managing the email on the server for them and is therefore highly recommended) is the best and easiest way of avoiding email headaches, not everyone is a non-profit organization or they frankly willing to pay the $5.00/user/month cost just for email.
Luckily, EXIM has some safeguards built in. For any messages it can't safely relay, it saves in a buffer until the message can be sent again or allowed to expire and be deleted. EXIM also comes with some command line tools so that you can easily analyse the sender and receiver of these frozen messages and ultimately identify patterns in problems.
mailq is the command that does just that. It shows how old the message is, the size of the message, a unique serial number identifying the message and finally the sender and receiver information.
This information can be included in a bigger multi part Linux command to attempt to unfreeze all messages in the queue.
mailq | grep frozen | awk '{print $3}' | xargs exim -v -M
SOURCE: https://blog.x-way.org/Linux/2009/07/28/Unfreeze-messages-in-Exim-queue.html
You likely will find that for some reason, random messages end up inside of your server for domain names that your DNS server is not even serving. You can safely ignore these messages unless they are part of a plague of similar messages as this has the potential to overload your server. For troubleshooting messages that involve real email accounts on your server, carefully analyse the to and from data and even consult the EXIM4 mainlog file found at /var/log/exim4 (Debian 8).