Keep in mind FTP sends your password in CLEAR TEXT. So the potential for compromise is definitely there.
Another thing to consider, is your FTP password UNIQUE to your hosting? Are you sure you're not using it ANYWHERE else? No other accounts, websites, etc?
How secure is your EMAIL password? I've been involved in cases where the "weak link" was actually the EMAIL password and the culprit was just sending "forgot passwords" to the email and deleting the evidence from the email box while everyone was too busy focusing on the compromised server to notice.
Just a few things that came to mind... some other things of course would be a social engineering approach with your ISP or some software vulnerability on your server or one of the packages your hosting.
There's more (obviously) but those are typically the "usual suspects".
UPDATE:
Based on this new information (that the hacker is not using FTP to change your files) I can only assume that the most likely cause is probably an unsecured web app.
That's not the ONLY thing it can be but in cases like this is the most likely.
Another thing to consider (and check for) is if he left himself some sort of "back door" to your app. I seem to recall you mentioning before that your ISP said he came in via FTP. Is it possible he came in via FTP the first time and left himself a back door?
Also, its a shot in the dark, but I have personally witnessed compromised boxes where a hacker only came in ONE time but left a cron job that kept changing files and other various evil. Is it possible that the hacker DIDN'T come back and you're dealing with an automated script? Just something to check if you feel you've exhausted all other possibilities.
Finally, do you have access to your web logs, system logs, etc? If so, what do they say? Do they reveal any clues?
It isn't uncommon for applications to only support a server name and nothing else. These apps just don't support authenticating before they send. Nothing about that requires you to run your own mail server locally - it just means you need to list a mail server that will accept the mail without first authenticating. There are 2 ways to achieve that:
If the name of the mail server you give it is the mail server that hosts your mailboxes (Verizon, in your case) and the UPS alerts are only going to your mailboxes, you can list that server without even asking Verizon first. Their system will always receive mail for your email addresses so that will work.
If you supply a different mail server that isn't configured to host mail for your email addresses, that server will usually reject the mail unless you authenticate first. BUT, you can often convince the company to allow a specific IP address to relay through them. It sounds like this would be the likely option for the local company you use. They may or may not offer that service. Note that you would be able to give them a specific external IP address that all of the mail would be coming from which could get tricky if that box the UPS software runs on isn't already connected to the internet.
Really, #1 is by far the easiest solution. Good luck!
Best Answer
Are you using nginx? I had the same issue. Following the tip of @PetrChloupek, I analysed the access logs (/var/log/nginx/access.log) and found out that sometimes an agent could get a 200 out of "/.env". It turned out that the configuration of the nginx was so that when using just the ip (v.g. 12.244.21.21 instead of "mywebsite.com") the malicious agent hitted the /var/www/html and not the public folder, as specified in the nginx conf file, since this dealt only with the specified host (v.g."mywebsite.com").