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 (email@example.com) 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:220.127.116.11/32 ip4:18.104.22.168/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: firstname.lastname@example.org X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning email@example.com does not designate 22.214.171.124 as permitted sender) firstname.lastname@example.org
If you refer back to the SPF record, you see that the IP address, 126.96.36.199 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:
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 — 188.8.131.52 — 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):
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: email@example.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 184.108.40.206 as permitted sender) email@example.com