Emails accepted but vanished when using relay.plus.net

[#1]

Hey team

I've been relying mails from my on prem mail server (Sophos XG) which sends mails fine and has done for many years. Recently I've noticed that some mails do not arrive to my personal mail account on Gmail.

It seems related to mails that contain attachments and possibly some are filtered as SPAM mails but I dont seem to have any control or visibiltiy to the logs your side of my plugnet account.

I'm not using excesive amounts of mail. Its a handful of mails per day with one mail containing a 1Mb backup file each day.

As you can see, the mail logs are send and accepted for delivery but they never arrive at my gmail account (I've checked the SPAM folder of course)

I was hoping someone in the plusnet team could look at the smtp logs on their side and see if they can work out why they are failing?

From my logs I can see that the mail was sent "250 neK6ogZFNzcNzneK7o7t3r mail accepted for delivery"

Attachents added which have been heavily filtered. Happy to share unfiltered if needed.

Thanks

[#2 · Accepted solution]

MSG   Oct 26 11:11:35Z [1oneJq-0000ui-Dv]: [0xa0bc0600
FROM: MYEMAILADDRESS@gmail.com , 
TO: MYEMAILADDRESS@gmail.com

A quick skim of that log - are you sending from your mail system via Plusnet's relay using your @gmail.com email address as the SENDER's email address?

If yes, then I would suspect that you are falling foul of Gmail's overly aggressive SPF checking.

The SPF constraint for gmail.com does not include relay.plus.net as a permitted message submission MX.

"v=spf1 redirect=_spf.google.com"
>>>
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
>>>>
"v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
"v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

~all dictates a SOFTfail which is not the same as FAIL meaning "NOT passed and discard".

For a SOFTfail, receivers should ACCEPT the email but mark it as being of concern.  Ironically that is EXACTLY what GoogleMail's support pages state here - Define your SPF record—Advanced setup - Google Workspace Admin Help

When an SPF record includes ~all (softfail qualifier), receiving servers typically accept messages from senders that aren't in your SPF record, but mark them as suspicious.

So, in your situation, if sending the email as if from your @gmail.com address via relay.plus.net then the sending MX is not in gmail.com's SPF set, so it should SOFTfail and still be accepted.  Clearly (yet again) Gmail is not playing by their own rules.  If they wish to restrict sending mail for @gmail.com to just their own SMTP servers, they should change the SPF records to -all

You should be able to get around this issue by sending the email from yourmailbox@youraccount.plus.com

[#3]

Hey  Townman

Thanks for youre advise. Ill give this a go and see how get on.  Really appericate you taking the time to reply!

Paul

[#4]

Hey again Townman

Just an email to say thank you - That actually fixed the issue. I'm now sending mails *from* my user@account.plus.com mail address to my gmail account and all the mail is arriving normally.

Something fishy is going on with Google, but I'm just pleased it's sending mails as expected.

Top man, thanks!

Paul

[#5]

Great news!!

It’s not particularly fishy, but it is not kosher!

They have set SPF rules to identify legitimate MX relays for @gmail.com sending addresses, with the instruction to soft fail non-matches. That is not fishy!

What is not kosher is to drop emails on a soft fail. In that space - yet again - Gmail is not compliant with international technical standards.