Email via form fails unexpectedly, citing an SPF policy failure

[GoWilkes]

I have a hosting client that has a form submitted from another website (not on my server). That form comes from a totally unrelated email address, and is sent to [email protected].

Then [email protected] is forwarded via cPanel to their Gmail address.

Recently they had a customer using a CenturyLink email address to submit the form, and that customer received an error that the email had bounced! I looked in my Mail Queue and found it with the following error:

ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after end of data:
550-5.7.26 The MAIL FROM domain [[URL='http://centurylink.net/']centurylink.net[/URL]] has an SPF record with a hard
550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the ip:
550-5.7.26 [123.45.67.89]. To best protect our users from spam and phishing,
550-5.7.26 the message has been blocked. Please visit
550-5.7.26 [URL]https://support.google.com/mail/answer/81126#authentication[/URL] for more
550 5.7.26 information. c10-20020aa7c74a000000b005067d449614si4560247eds.218 - gsmtp

(Where [123.45.67.89] is the IP to my server)

The client's SPF is:

v=spf1 +a +mx +ip4:123.45.67.89 +include:_spf.google.com ~all

(Note that there's a soft fail on my end)

I don't have access to the code of the form, but when I look at previous submissions I don't see the customer's email in the headers at all! So I'm lost on this one.

Any thoughts on why the customer got an email that the form email had bounced?

 

[quietFinn]

I have a hosting client that has a form submitted from another website (not on my server). That form comes from a totally unrelated email address, and is sent to [email protected].

As far as I understand, the domain of that "totally unrelated email address" is where Google is checking the SPF record.

 

[mtindor]

I have a hosting client that has a form submitted from another website (not on my server). That form comes from a totally unrelated email address, and is sent to [email protected].

Then [email protected] is forwarded via cPanel to their Gmail address.

Recently they had a customer using a CenturyLink email address to submit the form, and that customer received an error that the email had bounced! I looked in my Mail Queue and found it with the following error:

ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after end of data:
550-5.7.26 The MAIL FROM domain [[URL='http://centurylink.net/']centurylink.net[/URL]] has an SPF record with a hard
550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the ip:
550-5.7.26 [123.45.67.89]. To best protect our users from spam and phishing,
550-5.7.26 the message has been blocked. Please visit
550-5.7.26 [URL]https://support.google.com/mail/answer/81126#authentication[/URL] for more
550 5.7.26 information. c10-20020aa7c74a000000b005067d449614si4560247eds.218 - gsmtp

(Where [123.45.67.89] is the IP to my server)

The client's SPF is:

v=spf1 +a +mx +ip4:123.45.67.89 +include:_spf.google.com ~all

(Note that there's a soft fail on my end)

I don't have access to the code of the form, but when I look at previous submissions I don't see the customer's email in the headers at all! So I'm lost on this one.

Any thoughts on why the customer got an email that the form email had bounced?

Centurylink publishes SPF information that basically says "if email from @centurylink.net is not sent from one of the IP addresses in this SPF record, it's no good"

It sounds like the form on the website (not on your server) is accepting the email address entered on the form and entering it into the FROM and/or Envelope Sender (MAIL FROM) address in the created form email. Never a good idea. That website should have a hardcoded FROM address from a domain that has proper SPF records in place that allow that form to pass SPF authentication when it is sent from that website's server to any other server.

I do wonder though if you have SRS enabled on your server? Assuming your server accepted the incoming mail (and it did), it sounds like maybe you don't have SRS enabled on your server. SRS should have re-written that message when it was being forwarded it so that Gmail would have seen it (for authentication purposes) as an email coming from @theirdomain.com.

Even if you do have SRS enabled and it's working properly, it is not surprise that this is happening. So many companies now (years late if you ask me) are starting to enforce their SPF / DKIM / DMARC policies, which makes it harder in general to forward emails without them looking spammy to the forwarder email domain's mailsystem.

Look in your exim_mainlog for that particular email transaction (the transaction when it was forwarded to the Gmail account, not the transaction where it was delivered to your server by the server hosting the website). Depending upon your exim logging, you should see something like:

2023-06-08 02:59:08 1q79bv-009gMR-14 => [email protected] ([email protected] <[email protected]> P=<SRS0=acc9=b4=groups.io=[email protected]> R=dkim_lookuphost T=dkim_remote_forwarded_smtp H=gmail-smtp-in.l.google.com [172.253.122.26] TFO X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes C="250 2.0.0 OK 1686207548 t13-20020a0562140c6d00b005e9e789f094si329961qvj.437 - gsmtp"

The above example is an email that was sent by groups.io to my [email protected] address and then got forwarded to my Gmail account. SRS rewrote that so that it appears to come from mydomain.org for authentication purposes so that it passes the published SPF information published by mydomain.org. If SRS was not enabled / working, then the outgoing forward email would instead appear to come from @groups.io instead of @mydomain.org and would fail SPF when it hit Google's servers.

Mike

 

[sparek-3]

The simple answer here is to understand that any time you forward mail off of the server, then you're opening yourself up for SPF failures.

You can argue that forwarding mail has always been around and it must remain. But you can also argue that SPF is a really good anti-spam/anti-spoofing measure, if you avoid off-server email forwarders. In my opinion the landscape of email has changed, everybody has an email client that is capable of checking multiple email addresses, smart phone email clients can check multiple email accounts - the need to forward mail off-server and funnel mail into a single off-server email account, is much less than it was in the 90's and 00's. And the potential gains from a properly formatted SPF record outweighs the need to keep off-server forwarders working. But that's my opinion and it's not necessarily shared by everyone else. But if you really want to stop or make an impactful dent in the amount of spam and email address spoofing that goes on... there's going to have to be a give and take some where. There's not going to be a magic mushroom that solves everything and keeps everything the same.

I'm not sold on SRS as being a solution to this. To me it's just another band-aid solution that further complicates the whole mail process.

Additionally, as @mtindor alludes to - I would look at the form itself and see who specifically it is sending the message from. Keep in mind there are two different from addresses. The FROM header and the ENVELOPE-SENDER address. I would encourage you to consider using the form visitor's email address in the REPLY-TO header and using a valid FROM and ENVELOPE-SENDER address that you control. But again, if there is no off-server forwarding and the server that the form is on and the server that handles the email for the address that form is sent to are the same, then the impacts of all of this are minimal.

In my opinion, the main impact of this is the off-server forwarding.

 

[GoWilkes]

Interesting dilemma there, @sparek-3! When I use my server for emails, a lot of them are filtered as spam by Gmail and Yahoo for no apparent reason. I fought that for YEARS, but eventually gave up and started running my emails through Gmail and forwarding everything from the server. Now, I have far fewer emails being filtered.

But now it appears that I'm being punished for that, too :'-(

Based on this and several other variables, it really looks like Google is making a concentrated effort to destroy the free internet. I could go on a rant about this one, but I'm going to force myself to chill out and stay on topic.

Back to the topic at hand, unfortunately for me the form isn't on my server, and I don't have access to it. I'm just getting the fallout from the client about the failed email; since emails go through me, she sees it as my fault!

So with that in mind, @mtindor, I did NOT have SRS turned on so I just now activated it. For future readers, just go to WHM > Exim Configuration Manager and search for "SRS", then turn it on.

Hopefully that band-aid helps! Until Google comes up with some other arbitrary rule change and doesn't tell anyone, I mean.

 

[sparek-3]

I would encourage you to tell the user to remove the forwarder and set up the email address as a real email account on your account and check that email account and see if the issue resolves itself. But I also understand the plight of "well it used to work this way" is real and no matter how much you explain why it's a better solution, if the person is not willing to listen and keep an open mind, then it won't do any good.

Even with SRS you will need to have the applicable anti-spoofing authentication measures in place for the domain. Meaning a valid and proper SPF, DKIM signing, and probably a DMARC record - even if it is the dumb one that I posted earlier. Kind of goes to show you how stupid DMARC is, Google doesn't actually care if the DMARC record does anything, it just has to be there.