Final-recipient: rfc822; *E-Mail placeholder* Diagnostic-Code: smtp; 550 5.7.1 Message rejected due to SPF policy
Last-attempt-Date: Sat, 21 Nov 2020 11:46:12 +0100
Other recipients on the CC list receive the email without problem and when I send an email from my GMail account to the xtra.co.nz domain, it also arrives without problem so this looks like a Bluewin->Xtra issue only.
Issues with sending and receiving e-mails can be a major headache. Common stumbling stones include incorrect passwords, POP3 instead of IMAP and spam or phishing e-mails. The following 5 tips will help you avoid problems with your Bluewin e-mail account
Thanks for the reply Black Mamba ... I had found most of these suggestions in my investigations and had tried them all, but it never hurts to double check.
So far, I have found only one domain that is causing me an issue and that is xtra.co.nz (and this only started in the last week or so) ... I used to be able to send to this domain and I can still send emails to any other address without problems. I know there is no problem with the target email account as if I send an email from my googlemail or hotmail account to an this address, then the email arrives successfully.
I believe that Bluewin uses Cleanmail to filter email and apply rules and I wondered if something had changed there that inhibited sending emails to this domain?
Well, SPF (Sender Policy Framework) is a technology to allow a mail recipient (or receiving mail server) to validate if the mail is legit or might have been forged.
How it works:
Mail server for xtra.co.nz (which is mx.xtra.co.nz/18.104.22.168) receives a mail from a Swisscom mailserver (22.214.171.124) in this case
The mail server checks in DNS if 126.96.36.199 is legitimate to send e-mails for @Bluewin.ch by checking the SPF record
In case of Bluewin the SPF record says: "v=spf1 redirect=_spf.bluewin.ch" Well this just means we need to check _spf.bluewin.ch too
_spf.bluewin.ch SPF record says: "v=spf1 include:_netblocks.bluewin.ch include:_netblocks2.bluewin.ch include:_netblocks3.bluewin.ch ~all" Damn, still not the end of the road, we need to check _netblocks*.bluewin.ch then
Checking _netblocks.bluewin.ch SPF record says: "v=spf1 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ~all"
And there you have it, Swisscom _netblocks.bluewin.ch will allow 220.127.116.11/24 to send mails for @Bluewin.ch from IP 18.104.22.168. So this sounds legit actually.
So why is your mail still failing?
To be honest I am not fully sure. The Bluewin SPF entry seems to look alright. Although multiple includes make it hard to read and follow. One possibility is that the target mailserver at mx.xtra.co.nz is broken and failed to resolve the SPF entry or it does not support includes and therefore cannot validate the entry.
There isn't much Bluewin could do about this if this is the case. Except perhaps changing the SPF record not to use includes, but this is perfectly according to standards and should be supported.
So I think we might look at a broken mailserver implementation or misconfiguration. Perhaps there is a support department at xtra.co.nz which could provide more information about why their mailserver is refusing a perfectly valid mail delivery attempt.
In general Mail is broken by design. Initially mail was designed for an internet where security does not matter. Everyone could simply chose the from and to fields in an e-mail to their liking. Unfortunately the internet is not the friendly playground as it used to be. Spam and abuse has forced mail providers to introduce filters, authentication, probability checks, spam analyzers etc. Nowadays it's more likely for a mail NOT to arrive than actually being delivered. Mail is broken by design and all the insane amount of energy put into keeping it alive is just wasted effort. Unfortunately it's simple and still widely used - despite the fact messengers taking a lot of load from mails towards instant messaging.