Score:0

Can I stop a SPF SOFTFAIL in Gmail when sending to and from addresses that have a mail alias?

in flag

I have a vanity domain (mydomain.com) hosted by Gandi and configured with mail aliases for my family that point to our respective Gmail addresses:

Alias Real address
me@mydomain.com me5678@gmail.com
mybrother@mydomain.com brother1234@gmail.com

and so on.

Gmail is configured to send email as the vanity address and I also have a SPF record set up:

v=spf1 include:_spf.google.com include:_spf.gpaas.net include:_mailcust.gandi.net ?all

Although mail-tester.com reports that the SPF is set up correctly, it's possible to get a SOFTFAIL when sending an email from [anyone]@mydomain.com to [anyone else]@mydomain.com:

Sent from Sent to SPF result of email
me5678@gmail.com brother1234@gmail.com PASS
me5678@gmail.com mybrother@mydomain.com PASS
me@mydomain.com brother1234@gmail.com PASS
me@mydomain.com mybrother@mydomain.com SOFTFAIL

The headers when the email SOFTFAILs is as follows:

Delivered-To: brother1234@gmail.com
ARC-Authentication-Results: i=1; mx.google.com;
       spf=softfail (google.com: domain of transitioning me5678@gmail.com does not designate 2001:4b98:dc4:8::230 as permitted sender) smtp.mailfrom=me5678@gmail.com
Return-Path: <me5678@gmail.com>
Received: from relay10.mail.gandi.net (relay10.mail.gandi.net. [2001:4b98:dc4:8::230])
        by mx.google.com with ESMTPS id w4-20020a05600018c400b0020ac7a84cb7si9021160wrq.441.2022.05.01.02.22.05
        for <brother1234@gmail.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Sun, 01 May 2022 02:22:06 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning me5678@gmail.com does not designate 2001:4b98:dc4:8::230 as permitted sender) client-ip=2001:4b98:dc4:8::230;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning me5678@gmail.com does not designate 2001:4b98:dc4:8::230 as permitted sender) smtp.mailfrom=me5678@gmail.com
Received: from spool.mail.gandi.net (spool3.mail.gandi.net [217.70.178.212]) by relay.mail.gandi.net (Postfix) with ESMTPS id 51151240003 for <brother1234@gmail.com>; Sun,
  1 May 2022 09:22:05 +0000 (UTC)
X-Envelope-To: mybrother@mydomain.com
Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by spool.mail.gandi.net (Postfix) with ESMTPS id 49A2CAC0C45 for <mybrother@mydomain.com>; Sun,
  1 May 2022 09:22:04 +0000 (UTC)
Received: by mail-lf1-f48.google.com with SMTP id w19so20836346lfu.11
        for <mybrother@mydomain.com>; Sun, 01 May 2022 02:22:04 -0700 (PDT)
Received: from smtpclient.apple (cpc1-sotn14-2-0-cust79.15-1.cable.virginm.net. [81.96.148.80])
        by smtp.gmail.com with ESMTPSA id r7-20020a2e8e27000000b0024f3d1dae9asm761964ljk.34.2022.05.01.02.22.02
        for <mybrother@mydomain.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 01 May 2022 02:22:02 -0700 (PDT)
From: Me <me@mydomain.com>
To: My Brother <mybrother@mydomain.com>
Received-SPF: pass (spool3: domain of gmail.com designates 209.85.167.48 as permitted sender) client-ip=209.85.167.48; envelope-from=me5678@gmail.com; helo=mail-lf1-f48.google.com;
Authentication-Results: spool.mail.gandi.net; dkim=none; dmarc=none; spf=pass (spool.mail.gandi.net: domain of me5678@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=me5678@gmail.com

Is there any way I can stop emails sent from mydomain.com to another address at mydomain.com failing SPF?

Richard avatar
in flag
An update: Due to other issues, I recently moved my mail forwarding away from Gandi to forwardemail.net. The emails that were previously getting a SPF SOFTFAIL now all get PASS, suggesting that Gandi wasn't doing something right
Score:1
ng flag

You can see that the mail was received from a Gandi server:

Received: from relay10.mail.gandi.net (relay10.mail.gandi.net. [2001:4b98:dc4:8::230])

You can see that the Gandi servers are not authorized in the SPF record:

Received-SPF: softfail (google.com: domain of transitioning me5678@gmail.com does not designate 2001:4b98:dc4:8::230 as permitted sender)

SPF checks against the return-path header. Not the mailfrom header. The return-path is me5678@gmail.com. Therefore, gmail.com SPF records do not permit Gandi servers to send email using a return-path with gmail.com email addresses.

SPF is functioning normally. What you are seeing is an inherent weakness in the SPF protocol regarding mail forwarding. When mail is forwarded at the MTA (mail server) level, the mailfrom and return-path headers are not rewritten (nor should they be), but when the forwarded mail reaches the recipient's email server it is coming from the forwarding server, and not from the sender's original e-mail server. Therefore, the recipient's email server checks SPF and sees that the return-path domain does not authorize the forwarding email server to send mail.

Forwarding breaks SPF. Because you do not control the SPF records for the gmail.com domain, you can not authorize Gandi servers to forward mail on gmail's behalf. This is why SPF cannot be used, alone, to determine if mail is authorized or not.

You have four solutions (Options 1 and 2 require a paid Google workspace account I believe):

  1. Make sure that when you send email from gmail using an alias email address, that it also uses the email alias in the return-path header. Also add the gmail servers to the SPF record for mydomain.com. For more information about sending email as an alias with gmail see here: https://support.google.com/mail/answer/22370?hl=en
  2. Configure your MX records and gmail so that email destined to your alias is sent directly to gmail's servers and in to your inbox, rather than forwarding them through a third party.
  3. Receive email destined to your alias email address at the third party, instead of forwarding the message. Then configure Gmail to collect that email from the third party using the Import emails from my other account (POP3) option in gmail.
  4. If you have control over the behavior of the forwarding email server, you could create a rule that re-writes the return-path header to match the mailfrom header when it forwards email that is received from and destined to one of your email aliases.
Richard avatar
in flag
Thanks for this. I realised that the header I included was actually when my brother emailed me, hopefully that hasn’t caused any confusion. Regarding email configuration, emails are sent using Gmail’s “send as another address” feature but for the smtp server I provide gmail’s own smtp server details with my gmail username and password. This removes the “on behalf of” on all emails, leaving just my vanity address.
Appleoddity avatar
ng flag
@Richard of course it has caused confusion. Please update your post with accurate information.
Richard avatar
in flag
I've updated the headers although I'm not sure if it's any additional help as the problem is the same irrespective of whether I send the email to my brother or vice versa. I have noticed that the SPF for `mydomain.com` doesn't appear to be checked at all - making me wonder if my SPF record is actually doing anything.
Appleoddity avatar
ng flag
@Richard ok. I’ve updated my answer.
Richard avatar
in flag
Thanks for this. I'm sending emails through Gmail and the Gmail SMTP server (using the method in the link you provided) and emails are arriving with the `from` as me@mydomain.com. I cannot change the `return-path` as Gmail forces this to be me5678@gmail.com - a limitation of not paying for GSuite.
Appleoddity avatar
ng flag
I see that. @Richard I have updated my post again to clarify the problem and provide solutions.
Richard avatar
in flag
Thanks, makes sense. I think there might be a 5th option which would be to use an alternative SMTP server to Gmail (eg. Mailgun, SendGrid or Mailjet) to send the emails. This would then set my `return-path` as me@mydomain.com and the SPF checks would pass.
Appleoddity avatar
ng flag
@Richard good question. I think gmail can still dictate the return-path header even if using a third party smtp. It’s worth a shot though.
Score:0
cn flag

The problem is that SPF alone has not been deemed to be sufficient to stop emails that fail authentication. Even hard fail would not do that.

That motivated the development of DMARC. With that you can instruct receiving servers (including sent from internal to internal) to reject email that does not pass authentication.

You can read more about hardfail vs softfail and why DMARC is the answer here: https://knowledge.ondmarc.redsift.com/en/articles/1148885-spf-hard-fail-vs-spf-soft-fail

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.