PlusNet rejecting some email

[#1]

Whilst removing the spam filtering may get around the SPF issue, as I've had my PN e-mail address for around 25 years I get about 1 spam e-mail every 5 minutes. It's so damn annoying that I've had to resort to this, but I've had confirmation from a couple of sources that e-mails have been rejected.

Please Bob, try and put pressure on whoever made this change for a hard reject, to revert it.

[#2]

Zen adding a TXT record to your domain is not going to change this behaviour at all. To pass the checks, the people sending you email would need to add Zen's TXT record to their domain names, which they're obviously not going to do.

[#3]

I'm in the process of testing the water with Zoho mail. They will host mail for a single domain for free ( https://www.zoho.com/mail/zohomail-pricing.html ) with up to 25 mailboxes. Singing up was pretty painless, no need to move the domain registration, you just need to verify ownership and then change the MX records. It's a proper mail service ( i.e mailboxes ) so you can collect mail with POP or IMAP but also has forwarding facilities. An initial test of forwarding worked , and looking at the message source it indicated that they do rewrite the return-path.

edit 12/09 : having turned spam detection back on ( and confirmed it's active by checking the mx record ) I can report that forwarding via zoho still works, as I would have expected.

[#4]

It would be nice if PN offered a setting in the Spam Filtering settings that allowed us to use the old setting or the new one and give us a choice if they are not going to back this change out. I was pretty happy with how things worked before. I got a small mount of spam but nothing too serious.

Can I assume if I add domains to my spam whitelist this new filtering will be ignored for these domains?

[#5]

For some months we've been having a few lost emails but last week it got considerably worse with nearly everything being rejected with SPF Validation messages. We use a forwarding service from tsohost.com which has worked fine for years and years until recent months. This is administered through a package called CPanel which people may be familiar with if they have hosting accounts.

I contacted them last week and they added SPF records for our domains - no help at all. Fortunately, reading this post here prompted me to research switching on SRS inside CPanel - https://documentation.cpanel.net/dosearchsite.action?queryString=srs

This returned the following in the CPanel release notes:

54 Release Notes ...........SRS (Sender Rewriting Scheme) support In cPanel & WHM version 54, we added Sender Rewriting Scheme (SRS) functionality to Exim. This fixes issues with email forwarding Documentation • Jun 29, 2016

I couldn't find the Exim option in my CPanel because Tsohost tells me I'm on a shared server. But bringing it to their attention I got them to switch SRS on - absolute miracle! Within a few minutes emails starting coming in. Now 4 days on there have been no SPF Validation errors at all. (CPanel has a "Track Delivery" option so you can see the SPF errors).

Just to add, we have not changed our Plusnet Spam settings at all during this fiasco.

Hope this helps someone with their forwarding issues.

[#6]

We were the same.

Happily had a domain name hosted by 123-Reg which had worked fine for over 10 years. About a fortnight ago we started getting lots of people sayinying our emails were bouncing back.

Plusnet were not exactly helpful.

"Thanks for getting back to us.

We have recently integrated SPF validation checks on our inbound mail servers therefore any domain publishing these records will be observed.
It's possible that gmx aren't observing SPF and thus the reason why mail works when you forward it to them.


In the examples you have provided the SPF record has the following entry :-

"v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:74.208.122.0/26 ip4:212.227.126.128/25 ip4:212.227.15.0/24 ip4:212.227.17.0/2 7 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

So if a mail is not sent from any of the IP's / subnets then SPF will fail as it has the -all flag set

The error here seems that it's failing as the IP passing off the domain is not part of the SPF record.
SMTP error from remote server for RCPT TO command, host: mx0.123-reg.co.uk (94.136.40.154) reason: 550-Callout verification failed:

It's quite common for mail forwarding to break SPF which it looks to be doing here."

In desperation I moved our domain from 123-Reg to Plusnet (paying £30!)

This has if anything made matter worse as since moving the domain to Plusnet hardly any emails are getting through

Very disappointed!

[#7]

All now hopefully resolved.

I hope others don't have the same issues

[#8]

Recently, my wife noticed some important email not getting through to our plusnet email. When an email she sent from her work address to her plusnet account bounced, at least we had something to go on - a 550 SPF rejection message. After a chat with support I was directed here and I now realise that this was due to the new SPF email settings and her work SPF records not being correct. I have told her what to say to her email admin team, but who knows if they'll be able to fix it, or want to.

I have added her work email to our whitelist, but after 1 hour (>30 mins the webpage said is needed), that didn't work and it still got bounced (maybe that setting needs 48 hours as well?). So I have had to resort to turning off ALL my spam settings just so that we can receive her work email. I think it would be MUCH better if such non-validated SPF email just got put in the JUNK/Spam email folder. Then we can view it with suspicion, but at least we will know it has arrived.

What about all the other lost email we have missed? We only know about the email we were expecting that didn't arrive. There must be others that we weren't expecting but didn't arrive - they can be important too. And I don't even know what they are to be able to whitelist them!

[#9]

I think it would be MUCH better if such non-validated SPF email just got put in the JUNK/Spam email folder.

In fact the originator of the email can specify (in their SPF record) what to do with email that fails SPF validation. They can specify 'hard fail' i.e reject or 'soft fail' i.e mark as suspect. In practice though, most SPF records probably say 'hard fail' and so PN are just doing what they are being asked to do by the SPF record.

@procount. as you've discovered, whitelisting has no effect, the SPF check is done long before any whitelisting is looked at. The only way at the moment is to disable SPAM checking completely.

I have told her what to say to her email admin team, but who knows if they'll be able to fix it, or want to.

They need to fix it, PN aren't the only email supplier who check SPF and only more and more are going to be doing it.

I believe PN ARE reviewing the recent change though...

[#10]

I'm well out of my comfort zone here and don't really follow who has to fix this 

So Amazon send me an email to bert@abc.def and that domain is registered with 123-reg. I've configure 123-reg to forward all mail for abc.def to my Plusnet email.

Who's SPF record is being checked? I assume Amazon as they originated the email.

Should 123-reg be actively doing something in the email to say it's ok this is a forwarded message? Thus PN accept it? However what's to stop a spammer writing the same headers?

I guess what PN have done is only something all ISPs will implement to reduce Spam so it really needs fixing upstream but I've no idea where or how. Can someone in simple layman's terms explain the process?

[#11]

Thanks for confirming this, @MisterW.

It is now logged with their helpdesk and fortunately, they say it should be resolved shortly. This PN upgrade also coincided with an update to their email host which resulted in their SPF records getting out of date. An oversight I think.

Glad to hear PN are reviewing their action. I'm generally in favour of SPF, but upfront communication about the change and being able to choose what to do with such email (tag, filter, reject etc) are key considerations.

[#12]

@Picnic

Who's SPF record is being checked? I assume Amazon as they originated the email.

Yes. The amazon SPF says which servers should be sending mail from amazon email adresses.

Should 123-reg be actively doing something in the email to say it's ok this is a forwarded message? Thus PN accept it? However what's to stop a spammer writing the same headers?

I guess what PN have done is only something all ISPs will implement to reduce Spam so it really needs fixing upstream but I've no idea where or how. Can someone in simple layman's terms explain the process?

You're absolutely correct, 123-reg SHOULD be rewriting the emails headers to show that it has been forwarded by them, from YOUR abc.def address. That way PN ( and anyone else ) checking SPF records will now check the SPF for the .def domain, rather than amazon, which will say emails from that domain are ok when sent from the 123-reg server.

Does that help explain...

[#13]

Should 123-reg be actively doing something in the email to say it's ok this is a forwarded message? Thus PN accept it? However what's to stop a spammer writing the same headers?

I guess what PN have done is only something all ISPs will implement to reduce Spam so it really needs fixing upstream but I've no idea where or how. Can someone in simple layman's terms explain the process?

[#14]

You're absolutely correct, 123-reg SHOULD be rewriting the emails headers to show that it has been forwarded by them, from YOUR abc.def address. That way PN ( and anyone else ) checking SPF records will now check the SPF for the .def domain, rather than amazon, which will say emails from that domain are ok when sent from the 123-reg server.

Does that help explain...

[#15]

Does that help explain?

Well, sort of. What we want is some definitive statement from PN as to the progress being made and timetable for sorting it. Email is universal and I cannot believe that the industry is not working to a common standard for email headers and for checking them.

[#16]

There is a standard. SPF & SRS!

[#17]

---

@MisterW wrote:

Does that help explain...

---

Thanks it does somewhat. Next then is I need to know the list of IPs for 123-reg mail servers and add a suitable TXT/SPF record to my domain's DNS and I'll be sorted. Is that correct?