It's not clear, for me anyway, that we're looking at a blocked or blacklisted scenario currently. Since success or failure seems to depend upon the content of the message being sent. ("Forgot password" fails, others do not fail.) If the reputation of the originating mail server was the issue, I would be expecting all messages to fail.
One thing I'm also presuming that the response from your ISP means that their own Barracuda appliance
is choosing to drop those emails, as opposed to "a Barracuda appliance outside of our control at the recipient's end is rejecting this." If you've tested with recipients who are on entirely separate email address domains and still get the same "Forgot Password"-specific failure, this would support that the email is being dropped within your own hosting service's network.
If that's true, and the mail is being dropped by your own hosting service, then it will be difficult to get mail-tester.com's or any other recipient's scoring of the failing mail. Since the failing mail never actually leaves the hosting service's network, same as is happening to all of the normal recipients.
A service like SMTP2GO sounds like a great option. It also brings to mind Amazon's mail service
that was mentioned here not too long ago.
For what its worth, in our case, all we needed to do was not attempt to use the email services provided by my hosting account. Simply purchasing a dedicated mailbox -- as you would for any other non-phpBB and non-server hosting-related purpose -- and having phpBB authenticate and send through the SMTP server using those credentials was enough. The bottom line was "if we can send the same email content successfully using Outlook or any other SMTP client, our phpBB server will be able to send it too." Since from the SMTP server's perspective, phpBB is just another client authenticating with the correct credentials. We no longer bother modifying the email templates, and just send the email as phpBB intended.
Regardless of which way you go, one other thing which turned out to be important was that our hosting service also
actively blocked outbound port 25 or 465 connections. What you're looking for are services which provide alternative non-standard ports which are less likely to have been blocked; such as in SMTP2GO's case where they provide "SMTP port: 2525 (or 80, 25, 8025 or 587 if that doesn’t work)
." Port 80 out of that list is the most "evasive" one, and the least likely that your hosting service would have been able to block for outbound traffic since it's needed for outbound HTTP, too.
To me the biggest "crime" in all of this is that you weren't immediately receiving back a rejection notice, by email, confirming that the send attempt was being dropped. It took a conversation with your hosting provider to learn this, same as it did with us. Until that point, emails were being " randomly lost" and we had no idea when or how often. But I suppose that's part of the anti-spam intention too; they don't necessarily want to reveal and confirm exactly when the spammer is running afoul of their detection, just to keep the spammers guessing whether they've been thwarted or not.