A lot of businesses have one or more contact forms on their public website that are used by customers to get in touch with the company for sales, customer service, and other enquiries.
What I frequently encounter with customers is the case where all other emails are being received by the company just fine, but they are not receiving any of the contact form submissions from their website. If the company is busy enough with enquiries coming in via phone or direct email, they might not notice this for quite a while, and it can be quite alarming to suddenly discover that opportunities have been missed simply because an email was never received.
There are three common causes of this problem:
- Web hosting problems
- Spam filters
- SPF records
Web Hosting Problems
It’s very common for businesses to register a domain name and host their public website with the same web hosting provider. DNS hosting is usually included for free with such a package, and the web host helpfully adds a bunch of DNS records to the zone that they host to point things at their servers. This is fine, it’s helpful for their customers and reduces the friction with establishing a web presence for businesses that can’t afford specialist assistance.
Email hosting is often also included in those web hosting deals. The problems begin when the customer decides to host their email elsewhere, such as in Office 365 or an on-premises Exchange server. Things start to go wrong when:
- The MX record is changed to point somewhere other than the web hosting company servers
- The DNS zone has been delegated to other name servers (not always, but tends to be a factor in most of the cases I deal with)
What tends to happen is the web host is configured to always deliver email locally, while the rest of the world uses the MX record to determine where email should be delivered. In effect, the web hosting server ignores what is in DNS in favour of its own local configuration. The customer either ends up with a bunch of emails sitting in a “catch all” mailbox on the web hosting server, or the emails just error and get dropped by the server completely (but nobody ever finds out until someone notices a lack of website enquiries).
Fortunately, the solution is often as simple as making a configuration change in your web hosting control panel. The exact steps will be different, depending on the control panel that your provider is using. If you can’t find the correct options, or some guidance in their help documentation, then you should contact your web hosting customer support for more assistance.
Spam Filters
Another common cause of emails from website contact forms not delivering is spam filters. Most web sites will simply make use of an SMTP instance on the local server to send emails. Others will use various SMTP functions built in to the language or platform that the website runs on.
Either way the result is the same – the emails are coming *from* the web server’s IP address. The IP space for a lot of web hosts, particularly low cost shared web hosting providers, tends to have a pretty bad reputation in the eyes of spam filters around the world. This tends to result in either:
- SMTP connection attempts being outright rejected by connection filtering
- Emails submitted from those IP addresses receiving a high spam score
The outcome is that the emails do not arrive in the recipient’s inbox, and either get rejected entirely, filtered into a quarantine, or delivered to a junk email folder.
In Exchange on-premises and Exchange Online we can add a rule to bypass spam filtering for emails arriving from specific IP addresses.
If you’re running a third party email security appliance or service, look in the configuration of that product for an equivalent bypass rule.
Another option, which removes the dependency on the web server IP address remaining the same, is to route emails from the website through an SMTP service such as Amazon Web Services SES.
SPF Records
The last root cause I want to mention here is SPF records. This ties in to the topic of DNS above, but deserves a specific mention. Organizations that have implemented SPF (which you should), and who are filtering inbound email based on SPF results, will often discover that emails originating from an IP address that is not included in the SPF record are not being received.
If the web form needs to use your domain as a “From” address, then the solution is to add the web server IP address to the SPF record for your domain. You can learn more about SPF in my SPF primer for Exchange admins.
Alternatively, as with the problem of web server IP addresses looking spammy, you can use third party SMTP services such as AWS SES to send your web form emails, which often simplifies compliance with SPF and other frameworks like DKIM.
Summary
In this article I’ve covered three common causes of emails sent from websites not being delivered to recipients. Web forms are widely used and are usually critical to a business, so Exchange admins need to make sure that emails are being successfully delivered. Aside from the technical solutions mentioned in this article, it’s also a good idea to periodically test your website contact forms to catch any other issues that might come up from time to time.
Hi Paul from a website owner point of view, is there a way to retrieve the webform submissions when the emails weren’t sent?
please give more details on below point, I think you point to Cpanel remote mailbox and local mailbox config :
Fortunately, the solution is often as simple as making a configuration change in your web hosting control panel. The exact steps will be different, depending on the control panel that your provider is using. If you can’t find the correct options, or some guidance in their help documentation, then you should contact your web hosting customer support for more assistance.
Thanks for a very brief but complete description of this common problem.
Thanks, this is a helpful write up that’s gets to the most likely culprits. Just helped me in troubleshooting this issue!
Another reason is the website code which generates the email “helpfully” uses the person who completed the webform’s address as the From address of the email generated. This is to allow the recipient to just reply to the webform email to reach person who filled it in. What it actually does is create a spoofed email that spam filters are designed to pick up. If, for example, the person who filled in the webform has a Gmail address then the email generated will not match Gmail’s SPF record and all the other systems designed to determine an email’s authenticity.
Please, website coders, stop doing this!
Another issue is when the application is set to use and internal address as the from address. The spam filters catch it as a spoofed address.