It seems that, under certain conditions, GMail reports failed SPF checks for messages fetched via POP3 from other mail servers.
I noticed this behaviour on messages received, for example, by mail servers where an internal relay is used, like the following message sent from PayPal (which uses an hard-fail policy):
Delivered-To: MYSELF@gmail.com ... Received-SPF: fail (google.com: domain of firstname.lastname@example.org does not designate A.B.C.D as permitted sender) client-ip=A.B.C.D; Received: by 10.64.225.172 with POP3 ... X-Gmail-Fetch-Info: MYSELF@MYDOMAIN.TLD 3 pop3.MYDOMAIN.TLD 995 MYSELF@MYDOMAIN.TLD Return-Path: <email@example.com> Delivered-To: MYSELF@MYDOMAIN.TLD Received: from server1.MYPROVIDER.TLD (A.B.C.D) by server2.MYPROVIDER.TLD with SMTP; ... Received: from outbound.emea.e.paypal.com (184.108.40.206) by mx1.MYPROVIDER.TLD with SMTP; ... Return-Path: <firstname.lastname@example.org> ... From: "PayPal" <email@example.com> To: MYSELF@MYDOMAIN.TLD
This is the SPF record for emea.e.paypal.com:
;; QUESTION SECTION: ;emea.e.paypal.com. IN TXT ;; ANSWER SECTION: emea.e.paypal.com. 3600 IN TXT "v=spf1 a:outbound.emea.e.paypal.com -all"
It authorizes every IP address resolved by the outbound.emea.e.paypal.com A record.
In the example, MyProvider receives the message from 220.127.116.11, which is one of the many IP addresses resolved by and authorized by outbound.emea.e.paypal.com:
;; QUESTION SECTION: ;outbound.emea.e.paypal.com. IN A ;; ANSWER SECTION: outbound.emea.e.paypal.com. 300 IN A 18.104.22.168 ... outbound.emea.e.paypal.com. 300 IN A 22.214.171.124
After receiving the message, MyProvider uses an internal relay and adds a new header:
Received: from server1.MYPROVIDER.TLD (A.B.C.D) by server2.MYPROVIDER.TLD with SMTP; ...
Unfortunately, when GMail fetches the message from MyProvider, it runs the SPF check against the IP address of the last Received header (A.B.C.D), that is the IP address of MyProvider internal relay, and not the one authorized by PayPal for outbound email, resulting in a SPF fail.
Also when messages are not internally relayed by the receiving provider, so when they present only one Received header, GMail fails the SPF check with the error “best guess record for domain of transitioning postmaster@MYOTHERDOMAIN.TLD does not designate
From the Common receiver mistakes FAQ of OpenSPF.org…
SPF is designed to work at the border of your network…
… to accept or reject messages as soon as they try to enter, and not after processing, relaying or forwarding have been performed. Moreover it’s intended to be use for SMTP sessions, and not on POP3/fetch.
Email good reputation is hard to achieve; lots of efforts are spent on methods like SPF, DKIM, DMARC to help senders to reach users’ InBox folders and to increase users’ confidence about their content. Surely GMail folks had more than good intentions when they decided to use this policy but, IMHO, a wrong use of these techniques may lead to the opposite results of those intended.
Latest posts by Pier Carlo Chiodi (see all)
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
- RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes - 9 March 2016