Contact Form Not Sending Email

Posted by Paul on May 18, 2017

Most websites will have a contact form of some sort designed to take sales enquiries in a simple way and send them on to the business by email. If the form is well designed, it'll autocomplete the user's name and email address and then they'll usually need to type a little message about what help they need. The problem is that these sorts of forms are notoriously flaky and can often break of their own accord with potentially disastrous consequences for the business.

Technical Reasons Why a Form to Email Might Fail

There are quite a few reasons why a form to email might fail, below are some of the most common but there are plenty more:

Form Submission Blocked by Webhost

Usually a website that sends form data to an email address will use an HTML form to submit the data to a page which then uses PHP or some other server-side programming landuage to email that data. It is not uncommon for a webhost to carefully monitor data that is submitted by a webform and in certain cases block this submission. If this happens, your form will fail right here at the first hurdle. Reasons for this might include over-zealous firewall rules that block certain keywords. In Antropy's case for example, if a user was contacting us about a bug and was trying to send us an error message, it might contain code that looks like a hacking attempt and be blocked. To resolve this, you will need to talk to your webhost.

Email Not Sent by the Webserver

Assuming the webserver hasn't blocked the form submission, the server-side script will need to process the input. Assuming there are no errors in the code, if the site is built with PHP (which most are these days) then it's likely to be using the built-in mail() function. It's possible that this function will fail if it's misconfigured on the server. The way to trouble-shoot this one is to create a very simple test page that sends an email and see if it works. That will be something for a developer to do, and if it fails then they may be able to get help from the webhost.

Email Filtered by the Webserver

It's possible that even if the mail() function has done its job, the outgoing filters on the webserver have halted your email in its tracks. It's a good thing that they exist because otherwise any script might be hijacked and used to deliver millions of spam emails, but in our case here they will probably not be our friend. Again this is one for the webhost to identify and fix.

Email Filtered by your Spam Filter

If everything has been sent correctly from the webserver, you may still find that the email goes to either the junk in your email, or even worse that it's blocked at ESP (Email Service Provider) level and you'll never see any trace of it. In this case, the sender will usually receive a bounce-back, but it might be that the form is configured not to send from an email address you have access to. It's usually a good idea to add the email address that your form sends from to your safe sender list, but that's not always enough. Your domain name itself has things called DKIM and SPF records. When these are configured correctly, it's less likely that your email will be marked as spam. Generally though, it's quite rare your ESP will block email from a contact form, so the key is to make sure your junk filter isn't catching the email and costing you a lost lead in the process.

Email Delivered to the Wrong Inbox

This is a difficult one to find but if your email is not hosted on your webserver, but an email account exists on your webserver that is the same as the email address, the webserver can decide to deliver the email to the inbox on the webserver itself, which may not be the one you currently use. This is likely to be the case if you used to host your email on the webserver but moved it away to another service like Outlook or Google Apps. To fix this one (on a cPanel server at least) you need to go to "Edit DNS Zone" for your domain and then select "Remote Mail Exchanger":

Email SMTP Settings Incorrect

It's fairly unlikely that your form will use SMTP rather than mail() but this is an option in OpenCart and some other CMSs. When using this method, rather than the webserver sending the email, the code will connect to your email service (Outlook, Google Apps) in the same way your email client (Outlook, Thunderbird) would and send the email from there. This can increase deliverability but if these connection details are wrong, or the email service isn't allowing remote SMTP (Google Apps blocks this by default these days) then the email won't get delivered.

Early Detection is the Key

After spending a lot of time, errort and money on a website that generates sales leads, the worst thing in the world is losing those leads due to a broken contact form. So the best thing you can do to prevent this is to regularly test your form, perhaps as often as once a week, perhaps even make it a routine before you go home on a Friday so that enquiries over the weekend aren't lost.

Avoiding Loss of Sales

If your website doesn't run on a Content Management System (CMS) then it might be possible to get your web developers to save form enquiries to a spreadsheet, so at least if you do find from your regular tests of the form that emails aren't getting through, those enquiries won't be lost and if you're testing regularly enough the leads may still indeed be hot.

By default, WordPress doesn't save this data, which is pretty poor design, but at least there is a plugin called "Save Contact Form 7" that will save it. If you use Concrete5, then all form submissions are already saved to the database and are accessible in the backend.

Conclusion

1. Test your contact forms weekly.
2. Make sure submitted data is also saved somewhere e.g. the CMS database.

What did you think of this article? Please comment below and we'll try to get back to you as soon as possible!