SPF check based on client IP instead of MTA IP?

Question

Setup

On a client computer with IP address a.a.a.a, there is a mail client that uses SMTP to send emails via company email server example.com with IP address b.b.b.b.

The company email server example.com has a SPF record that includes IP address b.b.b.b.

Issue

Using the above setup, an Email is sent both a regular gmail address address@gmail.com and a Google apps address address@another_example.com, with the from address of author@example.com.

The two receiving account gives different SPF results.

In Gmail:

Received-SPF: pass (google.com: domain of author@example.com designates b.b.b.b as permitted sender) client-ip=b.b.b.b;

However, in Google Apps:

Received-SPF: softfail (google.com: domain of transitioning author@example.com does not designate a.a.a.a as permitted sender) client-ip=a.a.a.a;

Please note, in the failed SPF checks, Google Apps is checking SPF record against my client IP address a.a.a.a, which isn't and shouldn't be added to the SPF record.

As stated above, this is just one single email message that is sent to two different addresses.

Question

There should be no question whether or not the SPF record is setup correctly for example.com, and regular gmail confirms it. The question is why would Google Apps checks against client IP a.a.a.a?

Extra

Complete header as shown in Gmail and Google Apps:

Gmail

Delivered-To: address@gmail.com
Received: by 10.50.155.1 with SMTP id vs1csp2310853igb;
    Tue, 14 Apr 2015 13:24:07 -0700 (PDT)
X-Received: by 10.202.184.3 with SMTP id i3mr12882037oif.61.1429043047220;
    Tue, 14 Apr 2015 13:24:07 -0700 (PDT)
Return-Path: <author@example.com>
Received: from mail.example.com (mail.example.com. [b.b.b.b])
    by mx.google.com with ESMTP id u128si1421479oig.11.2015.04.14.13.24.07
    for <address@gmail.com>;
    Tue, 14 Apr 2015 13:24:07 -0700 (PDT)
Received-SPF: pass (google.com: domain of author@example.com designates b.b.b.b as permitted sender) client-ip=b.b.b.b;
Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of author@example.com designates b.b.b.b as permitted sender) smtp.mail=author@example.com
Received: from x.x.tld ([a.a.a.a])
      by mail.example.com (IBM Domino Release 9.0.1FP2 HF590)
      with ESMTP id 2015041415240678-1040231 ;
      Tue, 14 Apr 2015 15:24:06 -0500 
From: author@example.com <author@example.com>
Subject: test spf
Message-Id: <B39FB647-AD58-41C1-9C9E-F61355F3C1DF@example.com>
Date: Tue, 14 Apr 2015 15:24:06 -0500
To: address@gmail.com, address@another_example.com
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
X-MIMETrack: Itemize by SMTP Server on XXX(Release 9.0.1FP2 HF590|December 11, 2014) at
     04/14/2015 03:24:06 PM,
Serialize by Router on XXXX (Release 9.0.1FP2 HF590|December 11, 2014) at
     04/14/2015 03:24:07 PM,
Serialize complete at 04/14/2015 03:24:07 PM
X-TNEFEvaluated: 1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Google Apps:

Delivered-To: address@another_example.com
Received: by 10.112.136.137 with SMTP id qa9csp2056333lbb;
    Tue, 14 Apr 2015 13:24:08 -0700 (PDT)
X-Received: by 10.60.52.237 with SMTP id w13mr17898646oeo.58.1429043047841;
    Tue, 14 Apr 2015 13:24:07 -0700 (PDT)
Return-Path: author@example.com
Received: from mail.example.com (mail.example.com. [b.b.b.b])
    by mx.google.com with ESMTP id uv7si1397910obc.93.2015.04.14.13.24.07
    for <address@another_example.com>;
    Tue, 14 Apr 2015 13:24:07 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning author@example.com does not designate a.a.a.a as permitted sender) client-ip=a.a.a.a;
Authentication-Results: mx.google.com;
   spf=softfail (google.com: domain of transitioning author@example.com does not designate a.a.a.a as permitted sender) smtp.mail=author@example.com
Received: from x.x.tld ([a.a.a.a])
      by mail.example.com (IBM Domino Release 9.0.1FP2 HF590)
      with ESMTP id 2015041415240678-1040231 ;
      Tue, 14 Apr 2015 15:24:06 -0500 
From: <author@example.com>
Subject: test spf
Message-Id: <B39FB647-AD58-41C1-9C9E-F61355F3C1DF@example.com>
Date: Tue, 14 Apr 2015 15:24:06 -0500
To: address@another_example.com, address@gmail.com
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
X-MIMETrack: Itemize by SMTP Server on XXX (Release 9.0.1FP2 HF590|December 11, 2014) at
     04/14/2015 03:24:06 PM,
Serialize by Router on XXX(Release 9.0.1FP2 HF590|December 11, 2014) at
     04/14/2015 03:24:07 PM,
Serialize complete at 04/14/2015 03:24:07 PM
X-TNEFEvaluated: 1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Why does it say `Delivered-To: address@gmail.com` in the mail supposedly delivered to GApps? Makes me wonder what mail those headers actually come from. — Håkan Lindqvist, Apr 14 '15 at 21:52
sorry, my bad. It's really should be `Delivered-To: address@another_example.com`. I have it corrected. — Livy Li, Apr 14 '15 at 21:59
If these are correct, then this is Google's fault, and you'll have to address the issue with them. — Michael Hampton, Apr 14 '15 at 22:01

score 2 · Accepted Answer · answered Sep 01 '16 at 23:52

From what I can see I believe the problem is the clients email configuration. It looks like it is using a local email server or that person's ISP mail servers rather than talking directly with google's SMTP servers. Based on the lines

Received: from x.x.tld ([a.a.a.a]) by mail.example.com (IBM Domino Release 9.0.1FP2 HF590)

Which look like the client is sending email via some other email server. Google Apps logs are correct. The email should not pass SPF checking. However, because the email is allowed into the email system for your company, it progresses through anyway.

The reason why the two checks are different is likely due to the company Google Apps account has a setting located in the Admin console "Apps -> Google Apps -> Settings for Gmail --> Advanced settings" then under the spam heading the setting named "Inbound Gateway" it will have the address b.b.b.b listed. However if the address b.b.b.b is one of the IPs in the MX record for the domain it SHOULD be listed there, otherwise it likely needs to be removed from there and put in the SPF record if it is not already. What this setting does with the SPF checking is that it lets Google know that the IP address it should be looking at could come on the previous public IP MTA hop before that b.b.b.b address.

This is useful for companies like ours, who use our own servers as in our MX record, and then for the staff using Google Apps email, our servers direct the email out to Google's servers. If Google did regular SPF checking in this case, it would think that all email was arriving from the IP address like b.b.b.b and the SPF check would be useless.

The reason the gmail recipient shows it differently is that different Google servers process that email that know nothing of the "Inbound Mail Gateway" setting and only see that the email's last public IP MTA hop before Google's servers was b.b.b.b.

See Google's help page on the "Inbound Mail Gateway" here https://support.google.com/a/answer/60730?hl=en

In Summary

Fix the client email settings to use Google's SMTP servers. If the user complains they don't have time to fix it, then break their email by blocking them from sending by changing the softfail to an outright fail.

SPF check based on client IP instead of MTA IP?

Setup

Issue

Question

Extra

1 Answers1