2014-02-20 17:09:51 1WGboV-0004DR-Ql <= firstname.lastname@example.org H=localhost (18.104.22.168) [127.0.0.1]:34436 P=esmtpa A=dovecot_login:email@example.com S=614 firstname.lastname@example.org T="test" for email@example.com
Based on the above line we can see mail is attempting to be sent from firstname.lastname@example.org
. Without have a few more logs my below thoughts are theoretical as I don't have the logs to back them up, but some basic DNS checks almost confirm this is the case.
I can see that your domain "blacktower.com" is using Google Apps for email hosting.
dig mx blacktower.com +short
Based on this, it means your server should be contact Google servers to attempt to deliver the mail.
My theory here is that the domain "blacktower.com" is setup on your server in /etc/remotedomains as it should be, so when attempting delivery to it your server is going to check the MX records for the domain - here's where our problem starts.
Since blacktower.com is also hosted on your server, it's going to check the DNS record that exists for it on your server. Hopefully you still follow me here.
dig ns blacktower.com +short
dig a +short dns3.name-services.com
These two DNS lookups tell us that DNS for the domain is NOT managed by your server, thus it's very likely the the local DNS zone on your server for "blacktower.com" is out of date.
My guess is it's still got the cPanel defaults to direct MX back to the local server, at which point Exim is confused because you've already told it that mail should go outbound, but it's getting the mail coming back inbound thus it can't route it.
If you can run the following command I can confirm this is the case:
grep 1WGboV-0004DR-Ql /var/log/exim_mainlog
I'm assuming it's going to return something about a loop in MX records or something.