Not receiving (or intermittently receiving) notifications via GravityForms

Scenario:

You have a website hosted on Rackspace (for our example; this applies equally to most other hosting providers) and your e-mail is hosted by Google Apps (again, this could apply to any other mail host.)

You’ve configured GravityForms to send you (admin@example.tld) a notification whenever a visitor submits a form. Sometimes you receive the notification; sometimes you don’t.

Your website has a proper SPF record:

example.tld descriptive text "v=spf1 mx a ip4:50.57.219.119/32 ip4:50.57.219.120/30 include:_spf.google.com ~all"

You can see that we’ve authorized our MX, A, and our web hosting provider’s (the IP addresses specified by the “ip4” directive) servers to send mail on behalf of our domain (example.tld), in addition to configuring the recommended SPF setting for Google Apps.

So naturally you look at the mail headers of one of the notifications that you did receive (… assuming you got one; all of this may still apply if you aren’t receiving any notifications at all) and you notice the following message, regarding SPF:

X-Original-Sender: website_visitor@somemailhost.tld
X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning website_visitor@somemailhost.tld does not designate 50.57.219.123 as permitted sender) smtp.mail=website_visitor@somemailhost.tld

If you refer back to the SPF record, you see that the IP address, 50.57.219.123 is authorized to send mail for our domain (example.tld) but obviously we can’t set an SPF record for a domain we don’t own — somemailhost.tld, in this example, so somewhere in our form submission process, we must be attempting to send mail on behalf of somemailhost.tld (a fact made clear by the X-Original-Sender header), otherwise we wouldn’t be seeing this message. Time to take a look at how our GravityForms notifications are configured:

Incorrectly configured notification attempts to send e-mail on behalf of (i.e., spoof/impersonate) the visitor who submitted the form. Address spoofing is exactly the thing that SPF is designed to combat.

Incorrectly configured notification attempts to send e-mail on behalf of (i.e., spoof/impersonate) the visitor who submitted the form. Address spoofing is exactly the thing that SPF is designed to combat.

In the picture above, you can see that the “From” address is configured to be whatever the visitor submits. This means that your webserver will spoof that user’s address whenever sending the notification. Once the notification is relayed to your mail server (provided any intermediate relays don’t stop it first), it is likely being tagged as spam or discarded altogether because the origin of the message — 50.57.219.123 — is not permitted, according to the SPF record for your visitor’s e-mail domain (somemailhost.tld), to send e-mail on behalf of said domain.

Fixing this is quite simple; all you need to do is set the “From” address to an e-mail address within your domain (i.e., one that is validated by your SPF record):

Set the "from" field to an e-mail address within your domain, and set the "reply-to" address to the user-submitted value.

Set the “from” field to an e-mail address within your domain, and set the “reply-to” address to the user-submitted value.

Test your changes and verify that your form isn’t trying to spoof mail anymore by taking a look at the headers of one of the notifications that you receive:

X-Original-Sender: admin@example.tld
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of admin@example.tld designates 50.57.219.120 as permitted sender) smtp.mail=admin@example.tld