How to configure any website or form for successful email delivery

Although you’d think websites or forms that send notification emails would come pre-configured to work successfully in all cases, you’d be surprised how often they’re poorly configured by default. There’s a number of very particular aspects to the configuration of forms that need to be set precisely in order to work successfully both with our hosting and more generally in the modern world of email.

The first two we’re going to discuss will help you with general email deliverability as well as your forms, while the last two apply specifically to form configurations. Here’s an overview:

• Use SMTP? If you’re using external mail services, be sure to use SMTP to send your emails.
• DNS Records: ensure you have an SPF and DMARC DNS record. If you’re using SMTP to deliver mail, also obtain your DKIM record from your SMTP provider.
• Email Headers: From, To, and Reply-To headers must be set correctly
• HTML Messages: Disabling HTML formatting can improve deliverability

In the settings and examples below we’re going to be using the name Random Visitor and email address randomvisitor@gmail.com as our sample data to represent the visitor to your website that is submitting the form. We’ll also be using the to address of info@mywebsite.com, which is where contact form submissions will be sent.

Non-Local Email: Use SMTP

If your email is not hosted on the same server as your website (E.g.: Gmail, Hotmail, BellAliant, Eastlink, or even our Exchange offering), for best delivery we recommend configuring your website to use SMTP and directly route mail through your external mail provider’s servers, rather than having our server send it directly. This ensures that all headers for optimal deliverability are applied to the message because it flows through the domain’s approved mail service.

TIP for those with their own virtual server running Plesk that will not be hosting any mail services on the server: you should replace the Postfix mail server with MSMTP and then configure MSMTP to relay messages through your external mail service. You must not plan to use the local mail service for any domain hosted on the server. Doing this means you do not need to configure your website to send messages with SMTP as the MSMTP service will take care of this for you.

If you haven’t already done this, when using external mail, you must disable the local mail service and DKIM in Plesk.

You’ll need to check with your 3rd party mail service provider for the correct settings to use for SMTP. This will consist of a server hostname, port, username, and password. Once you have these settings, you then need to enter them into your web application’s configuration.

Here’s how to configure some common web apps to use SMTP:

• WordPress: See our guide on how to use SMTP with WordPress.
• MODx: Their documentation describes how to configure MODx to use SMTP services
• Magento: The SMTP Pro Email plugin has worked very well for us. Install the plugin using their guide, then configure it to use common email providers like Gmail or custom SMTP credentials for all emails leaving Magento.

If you’re using another application and have found a solution for using 3rd party SMTP providers, please let us know in the comments below!

SMTP Port Tips: If you’re hosted on your own VPS hosted in Canada with Websavers, you can configure SMTP using any of the standard SMTP ports. If you’re on shared hosting, our firewalls will only allow SMTP over port 587, so your mail provider must support port 587 (most do).

Mail Deliverability DNS Records: SPF, DKIM, DMARC

Read our article on managing your mail validation records to learn how to configure SPF, DKIM, and DMARC DNS records. You’ll find a record generator on that page to help you select the best options for SPF. DKIM records require your mail provider to generate the record and provide it to you. The guide will also show you optimal configurations for DMARC.

This is absolutely essential to keep your messages out of spam / junk folders of the big providers.

From, To, and Reply-To Headers

The first setting that is often misconfigured is the “From” header.  Most will configure a contact form to have the messages coming from the email address that the submitter entered in the form, such as randomvisitor@gmail.com. Or you might have notification emails set to come from your own Gmail (or other externally operated email) address. However this is bad practice, and will usually cause messages to not be delivered!

When the receiving email server receives the message sent from the contact form, it will check gmail.com for its SPF record, which specifies servers that are allowed to send emails on behalf of @gmail.com email addresses. Since the server your website is hosted on is not an approved sender for @gmail.com addresses, it will fail the test and so the message is either dropped or filtered to spam.

The solution is actually quite simple! Set the “From” address to an email address that is hosted on your server. For example we often use no-reply@mywebsite.com. (Be sure to replace mywebsite.com with your actual website’s domain, no www).

To ensure that when the recipient replies to these emails the replies actually go to the person who submit the form, you need to set the Reply-To header to the submitter’s email address. With some contact form plugins, you can simply enter this in a Reply-To field, but with others you need to add it to an “Additional headers” field. Here’s a couple examples:

• Contact Form 7 has an ‘Additional Headers’ field. Enter: Reply-To: [your-name] <[your-email]>
• Gravity Forms has a Reply-To Field. Enter: {Name (First):1.3}{Name (Last):1.6} <{Email:2}>

Note that [your-name] and [your-email] are default tags that Contact Form 7 uses as a placeholder; if you’ve changed the name of the tag, be sure to put in the correct placeholder there. The same is true for {Name (First):1.3} and {Email:2} when using Gravity Forms — be sure to use the correct placeholder values for your particular form.

Address Formatting (From/To)

Make sure that your form is configured so that all email addresses are formatted correctly, including the from address, to address, and the reply-to field. If your form system has a field for name and email, then it *should* be formatting this correctly for you. If it only provides an email field, you may need to format this yourself, like Name <email_address>

e.g.: John Smith <johnsmith@fakedomain.com>

Disable HTML Messages

Most form plugins (like Gravity Forms) sadly do not support the multi-part standards required for normal email communications with an HTML message body. Spam filters will detect that the message format being used does not match the standard because it only uses HTML with no plaintext version, making it ‘malformed’. Malformed messages are most commonly attributed to poorly coded spamming software and therefore the messages end up getting spam points against them.

If you must use Gravity Forms, or any other form plugin that also does not support multi-part standards and you wish to be sure messages sent via the form make it to the destination, your best bet is to disable HTML messages such that it only sends plain text. Here’s how to do that with different form plugins for WordPress:

• Gravity Forms (sadly requires some coding knowledge)
• WP Forms (See the “Switch to Plain Text Emails” section near the bottom of the page)
• Formidable Forms

Using the correct configuration for your forms, as described above, will ensure accurate and successful sending of all messages through the forms on your website.