Troubleshooting Web Form Issues

Normally, when a web form has been submitted, it takes the data that was entered into the form and then e-mails it to someone at that company. Sometimes, that person doesn’t receive the e-mail from the web form. Why not? What happened to it?

According to FTC regulations, it is illegal to use “false or misleading header information.” The e-mail header includes “From,” “To,” and “Reply-To” information (among other things). E-mails sent from a web server need to follow these rules just like everyone else. If any of the header information appears to be incorrect, the receiving e-mail server may mark the e-mail as spam or block it entirely. This is to prevent spam and malicious e-mails. Sometimes, the server also blocks e-mail you want to receive. There are three e-mail statuses: (this becomes useful when creating an SPF record.)

Normal – E-mail that you will receive normally

Soft Fail – E-mail that you receive but is marked as spam

Hard fail – E-mail that is blocked entirely

Within your website’s code, the developer programs how to build the e-mail that is sent with the form data. For this topic, the developer needs to know what should be used for “From,” “To,” and “Reply-To.”

Problem 1:

From: useremail@example.com

To:  hello@gravitatedesign.com

It may seem logical to set a web form’s “From” to match what the users entered as their e-mail addresses in the form. Constructing it this way would make it easy to reply to the e-mail and to have it go to the user. However, there are a few problems with this. The e-mail didn’t actually come from the user’s e-mail server, and the receiving e-mail server knows this. It sees an e-mail coming from somewhere other than where it should be and, as such, it might be flagged or blocked. We do not recommend making the “From” match the user’s e-mail address. Instead, use one of your own e-mail addresses.

Problem 2:

From:  hello@gravitatedesign.com

To:  hello@gravitatedesign.com

Let’s instead make the “From” field something like hello@gravitatedesign.com. This would solve our first problem but now introduces a few more problems. The receiving e-mail server would still see the e-mail address coming from a web server, not the appropriate e-mail server. To correct this, create an SPF record. The SPF record is stored in your DNS Zone File, and it is used to tell the internet where to accept e-mails from and what to do with e-mails that do not match the places you specified.

SPF record example:  v=spf1 include:_spf.google.com include:amazonses.com ~all

v=spf1 is needed to begin all SPF records

include:_spf.google.com is used to state that e-mails can be sent from Google

include:amazonses.com is used to state that e-mails can be sent from Amazon SES

~all is used to state that all other e-mails will receive a soft fail (marked as spam but not blocked)

Now the receiving e-mail server knows that it is OK to receive e-mail from two different places (your e-mail server and your web server).

Problem 3:

From:  no-reply@gravitatedesign.com

To:  hello@gravitatedesign.com

If an e-mail is sent “From” hello@gravitatedesign.com and sent “To” hello@gravitatedesign.com, the e-mail server will most likely block this entirely. Imagine that you are standing next to your coworker, Bob Barker, and a masked person walks up to you and says, “My name is Bob Barker, and I want you to give this package to Bob Barker” and then walks away. Would you trust that the package is safe and give it to Bob Barker? Or would you question the fact that there is no way that Bob Barker actually gave you the package? E-mail servers are smart enough to know not to trust this type of e-mail and will therefore block them entirely. You will not see them in your spam folder. What if we change the “From” to something like no-reply@gravitatedesign.com?

Solution: SMTP

Similar to problem 3, some e-mail servers are strict enough to block all e-mails that are “From” and “To” the same domain that it receives from an external source. If this is the case, you will need to create an SMTP account. You use an SMTP account every time you send e-mail. It is a way to authenticate that you should be allowed to send e-mails from your e-mail account.

What you need to do: create an e-mail account just for your web server. Give all of this information (SMTP host address, port, authentication method, username, and password) to your web developer so that he or she can set up the form notifications to use this SMTP server. Now the receiving e-mail server will receive the e-mail directly from the correct place!

If using SMTP is so great, do I still need an SPF, and what drawbacks does it have?

Having an accurate SPF record is always a good idea, as it will help prevent spam. Drawbacks? Well, you may need to pay for the extra e-mail account. Also, you must remember never to delete this account or change the username or password without letting your web developer know. If the username or password is changed, the website needs the new credentials to continue using the SMTP server.

Everything works now, but can we do something to make it easier to write back to the person who submitted the form? Yes! Let’s make the “Reply-To” match the user’s e-mail address that he or she entered into the form.

Leave a comment below if you have questions or any suggestions.

If you need help with your web form contact our website maintenance team, here at Gravitate.