On a recent site build, we ran into a fascinating issue. Form submission notification emails absolutely refused to send.
It wasn’t a particularly complicated form setup, either. We used Gravity Forms, our usual reliable forms tool, and neither of the two forms we built for the website were even a bit out of the ordinary: no conditional logic, no email routing, no legacy code, no add-ons. The emails weren’t ending up in the spam or trash folders either (for the client, or for us when we tested the setup with our own inbox in place).
Stumping multiple support teams
We checked everything we could think of, from the DNS records to the SMTP setup to the reCAPTCHA. The client’s hosting was on Bluehost, so we asked their support to check it out too, and they confirmed:
- The SPF, DMARC, DKIM, and MX records were all exactly how they were supposed to be.
- SMTP was properly set up.
- The inbox was actually sending and receiving emails — as long as they weren’t form notifications.
Since the inbox itself was working, Bluehost told us it really seemed like an issue with Gravity Forms, so we emailed Gravity Forms support.
Gravity Forms looked through our logs and was also puzzled — the email notifications were making it through the plugin and off the server, just like they were supposed to, and once a notification was off the server it was out of reach of the Gravity Form logs. Whatever was happening, it happened somewhere between the email being sent to the inbox and the inbox receiving the email, where Gravity Forms couldn’t see it any longer.
Finding the issue
Guess who had the answer?
Another Bluehost user had run into almost exactly the same issue a few months ago, and after going in circles with their support, a Bluehost tech finally confirmed to them that Bluehost implemented an outbound email filter in October 2025 that blocks almost every kind of contact form subject line. Apparently there’s no published or internal allowlist (and it could change at any time), but blocked terms include “Forms”, “Contact”, “New Message”, and “Submission”.
As a test, we changed the form notification subject to “Let’s see if this works”, and the next notification email hit our inbox with zero issues. (And then we tested different subject lines until we found a working version that would still make sense when it turned up in the client’s inbox, of course.)
Fixing the problem
Bluehost’s official guidance is to use “a mix of bot protection on the form, authenticated SMTP, and a dedicated transactional mail service for the actual delivery.” But if your project calls for working with Bluehost’s out-of-the-box email service, and everything seems to be working except your form notifications… you may want to try a different subject line.
