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:

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:

The headers when the email SOFTFAILs is as follows:

Delivered-To: [email protected]
ARC-Authentication-Results: i=1; mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 2001:4b98:dc4:8::230 as permitted sender) [email protected]
Return-Path: <[email protected]>
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 <[email protected]>
        (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 [email protected] 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 [email protected] does not designate 2001:4b98:dc4:8::230 as permitted sender) [email protected]
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 <[email protected]>; Sun,
  1 May 2022 09:22:05 +0000 (UTC)
X-Envelope-To: [email protected]
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 <[email protected]>; Sun,
  1 May 2022 09:22:04 +0000 (UTC)
Received: by mail-lf1-f48.google.com with SMTP id w19so20836346lfu.11
        for <[email protected]>; 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 <[email protected]>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 01 May 2022 02:22:02 -0700 (PDT)
From: Me <[email protected]>
To: My Brother <[email protected]>
Received-SPF: pass (spool3: domain of gmail.com designates 209.85.167.48 as permitted sender) client-ip=209.85.167.48; [email protected]; helo=mail-lf1-f48.google.com;
Authentication-Results: spool.mail.gandi.net; dkim=none; dmarc=none; spf=pass (spool.mail.gandi.net: domain of [email protected] designates 209.85.167.48 as permitted sender) [email protected]

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 [email protected] 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 [email protected]. 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 [email protected]. I cannot change the `return-path` as Gmail forces this to be [email protected] - 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 [email protected] 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.