Contact Form 7 and Validation Errors

The WordPress plugin Contact Form 7 version 4.4 introduced a new Configuration Validator. This feature checks contact form configurations to find errors that might result in mail delivery failures or other problems. When you first update your Contact Form 7 plugin to version 4.4 or later, you are invited to validate your forms. When the validator reports that there are errors, it’s not always obvious what the problem is.

First, note that the validator checks for configuration settings that can cause problems in some hosting and mail environments, usually as a result of anti-spam/anti-scam email settings. Just because an error is reported, it doesn’t mean that your form won’t work. The validator does nothing to your form. If it worked before, the likelihood is that it still works. But be aware that if the mail server that handles your Contact Form 7 emails is changed to use stricter mail policies, your form could stop working. So it’s a good idea to pay attention to any reported errors and fix them.

This email address does not belong to the same domain as the site

The most common error I’ve encountered so far is “This email address does not belong to the same domain as the site.” See the image below:

This means that the email address used for the From: field is set to a different domain than the website on which the form is used. When creating a new contact form, it’s common to put a tag for the user’s email (as they entered it in the form itself) as the From address. But many email providers and email programs flag as spam any email that’s coming from a different domain than the domain in the From field.

For example:

A person named Jane Doe, in filling out my contact form, enters janedoe@example.com as her email, which has the input name “your-email.” The Contact Form 7 “Mail” settings use [your-email] as the From address. Contact Form 7 would use that to plug in janedoe@example.com as the From email address. But the email is actually being sent to me from the mailserver for tropicalwebworks.com. This could result in a delivery failure if the mail server and/or email program settings consider that only email from tropicalwebworks.com should be sent out from tropicalwebworks.com. So I should put something like noreply@tropicalwebworks.com as the From address.

But but but……. if I use that as the From address, then when I receive Jane’s email, I can’t just hit “Reply” to get back to Jane, because the reply would go to noreply@tropicalwebworks.com.

The fix for this is easy. You simply add Reply-To: [your-email] or Reply-To: [your-name] <[your-email]> in the Additional Headers field in your mail settings.

When you set up your Contact Form 7 form like this, then when you hit “Reply” in your email program, the reply will go to the user’s email address, not to yourself, AND you avoid tripping anti-spam triggers.

This field can be empty depending on user input

Another common error is “This field can be empty depending on user input.” See the screenshot:

This error often appears for the Subject: field, and it happens when the form contains a field for the user to fill in a subject but doesn’t make that field required. The fields To:, From:, and Subject: must contain something. Additionally, the “Message Body” should generally not be left blank either, but it’s not as critical as the other fields. This particular error is easily fixed by adding an asterisk in affected form field to make the field required, like so:

This field has syntax errors

The most head-scratching error that I’ve encountered so far is “This field has syntax errors.” See the screenshot:

This one almost made me crazy. It said the Additional Headers field had syntax errors regardless of whether I put Reply-To: [your-email] or Reply-To: [your-name] <[your-email]> or Reply-To: <[your-email]>. I know that all 3 of those variations work just fine, because I use them elsewhere without getting validation errors. I tried deleting everything from the Additional Headers field, saving the form, and re-adding it. I tried every variation I could think of. I tried renaming the email field — I tried youremail, myemail, testemail. I tried putting a return character at the end, and two return characters. Nope. No matter what I tried, I still got this maddening validation error. I examined and re-examined the mail settings in other forms where I use this exact same setting, and I couldn’t find a single difference.

Finally, I noticed something. In the form itself, the email field in the offending form was [text* your-email]. In the forms without configuration errors, the email field was [email* your-email].

So, it turns out, the solution to the mysterious syntax error message is to make sure that the email field is designated as an email field, not as a text field.

At last, victory is mine! No configuration errors. Test to make sure the dang form actually works, and I’m good to go.