Email delivery failure - message rejected due to SPF policy

RDBA

Hi,

Currently, I cannot send emails to the domain xtra.co.nz. This behaviour started a couple of days ago and prior to that, it has been working happily for years.

When sending an email, I get the response:

Reporting-MTA: dns; smtpauths.lb.bluewin.ch [195.186.227.133]
Received-From-MTA: dns; xxxxxxxx [y.y.y.y]
Arrival-Date: Sat, 21 Nov 2020 11:45:06 +0100

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.

Any ideas as to how I can resolve this?

Thanks and regards,

Robert.

Black Mamba

Setting up & repairing e-mail

On this page: Set up your Bluewin e-mail account on a PC or mobile phone. Problems sending or receiving e-mails? Repair the settings manually or automatically

Email Settings Update

On this page:Adjust the settings of your e-mail program if they do not yet comply with the current security standard

5 tips on resolving Bluewin e-mail issues

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

RDBA

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?

SkyBeam

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/210.55.143.33) receives a mail from a Swisscom mailserver (195.186.227.133) in this case
The mail server checks in DNS if 195.186.227.133 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:195.186.227.0/24 ip4:195.186.120.0/24 _all"

And there you have it, Swisscom _netblocks.bluewin.ch will allow 195.186.227.0/24 to send mails for @Bluewin.ch from IP 195.186.227.133. 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.

RDBA

Thanks for the detailed and clear analysis of this issue SkyBeam.

I will take this information to Xtra and see what they can offer as to an explanation/solution to the problem of getting emails accepted originating from Bluewin. I am hoping that someone there will be able to identify a change made in the last couple of weeks as this issue has only surfaced since then.

I will report back when I have an answer from them. Thanks again.

Black Mamba

@RDBA

in order to close a topic by the initiator, if the problem is resolved or requires outside research

please accept message @SkyBeam as approved solution

to do this, use the option Solution? at the bottom left of the post

Is the answer a solution to your contribution?

So mark it as a solution or use the equivalent option with the toothed wheel at the top right of the post

RDBA

The response from Spark (xtra.co.nz mail provider) identified that they were expecting any emails from my email address ( *E-Mail placeholder* ) to be sent from the mail provider deemed to be serving that domain:

"The domain simmey.com has the following SPF record [v=spf1 a mx a:newsletter-relay-01.sitesuite.net a:newsletter-relay-02.sitesuite.net a:newsletter-relay-03.sitesuite.net include:spf.sitesuite.com.au -all]

This means that all emails sent from the domain simmey.com are sent from the locations specified above and no where else.

The email that has been rejected has been sent from the following location

[195.186.120.131, vimdzmsp-sfwd01.bluewin.ch]

This location is not specified in the SPF record for simmey.com and so the email has been rejected for failing to meet SPF."

Once I changed my outgoing email server to the Sitesuite smtp server, the emails started to be routed correctly again. What I couldn't establish is what had changed to trigger this new behaviour.

Incidentally, this issue also affected emails sent using the address *E-Mail placeholder* to a recipient *E-Mail placeholder* where the outgoing email server was smtpauths.bluewin.ch.

Anyway thanks for your help in getting this resolved.

SkyBeam

@RDBA wrote:

This means that all emails sent from the domain simmey.com are sent from the locations specified above and no where else.

The email that has been rejected has been sent from the following location

[195.186.120.131, vimdzmsp-sfwd01.bluewin.ch]

This location is not specified in the SPF record for simmey.com and so the email has been rejected for failing to meet SPF."

Wait a moment, in the initial post you did not mention that you are using another mailserver (simmey.com).

Once I changed my outgoing email server to the Sitesuite smtp server, the emails started to be routed correctly again. What I couldn't establish is what had changed to trigger this new behaviour.

Incidentally, this issue also affected emails sent using the address *E-Mail placeholder* to a recipient *E-Mail placeholder* where the outgoing email server was smtpauths.bluewin.ch.

Anyway thanks for your help in getting this resolved.

As explained in my previous answer. Essentially when sending an e-mail through any mailserver you are prompted by the mailserver about your "from" address. Typically mailservers nowadays only accept the mail then if it corresponds to your account.

However there are mailservers which allow anything to be specified.

So for example you can use the simmey.com/sitesuite.net Mailserver and send an e-mail which claims to be sent from an @bluewin.ch mailbox. Usually the mailserver would reject this.

I think also Bluewin mailservers reject sending mails with foreign domains.

So what I think happened is:

You are trying to send an e-mail via with @simmey.com address (FROM Address)
You are delivering this e-mail by using the Bluewin mailserver
The Bluewin mailserver will deliver the e-mail to the target mailserver (TO Address, @xtra.co.nz)
The target mailserver of course verifies it: "Is the Bluewin mailsever allowed to deliver mails which claim to be from @simmey.com?)
The SPF record will tell the target mailserver "no, all @simmey.com mails are supposed to be delivered only from sitesuite.net mailservers
The mailserver rejects the mail and tells the Bluewin mailserver it will not accept this mail - so you get the message above

So the issue is coming from the fact that you are using the wrong mailserver. You are asking this mailserver to fake the FROM address and deliver mail claiming its sender address is a foreign address which is not owned by Bluewin in this case.

This is typically how spam is delivered. Imagine any non-legit mailserver somewhere in China or Russia (or any other country) is delivering a mail to xtra.co.nz claiming it got a mail from you. In the 90ies it worked fine, but nowadays target mailservers will check if the mail is coming from a legit mailserver.

Bottom line is: Assure you are sending Mail via a Mailserver which is allowed to deliver mails for the address you are using. Do not try to use Bluewin Mailservers to deliver simmey.com/sitesuite.net e-mail addresses and vice versa.

Unfortunately your initial request did not include the information which "FROM" Address you are troing to use via Bluewin mailservers. Please only use Bluewin/Bluemail "FROM" addresses when using the Bluewin mailserver or your mail might be rejected by the recipient.