Google (Gmail) is now newly blocking billing emails from Plusnet

[#1]

This is about Plusnet billing emails for Broadband - rather than broadband itself.

I am hoping that it will be forwarded on to your Devops by one of the Mods or Superusers - thanks!

So Google has just got very aggressive about what email it now accepts - to try and further limit Spam (see:  https://www.forbes.com/sites/daveywinder/2024/03/20/new-mass-gmail-rejections-will-start-in-14-days-...) which I can see has already started.

A lot of folk (me included) have our own hosted domains, and email sent to that domain, is simply forwarded on to our Gmail accounts.

For example:

Let's say I own bob.co.uk and use the email address big@bob.co.uk. I would simply get my domain host (in my case, Cloudflare) to forward any email to big@bob.co.uk to bigbob@gmail.com.

Now this all worked until last Tuesday, when Gmail turned on it's more aggressive approach to spam email rejection. Since then, I haven't received any email re managing my Plusnet account (like bills and CPI billing increase etc), because Google is rejecting these emails on the grounds that the domain of the sender address - donotreply@plus.net has a "very low reputation".

How do I know if I am getting Plusnet emails rejected - if I am not actually receiving them? 

Well, it just so happens, that I use Cloudflare, and they surface very good logs of all the emails being forwarded and the status of each forward. Here's an example:

What I have discovered, from monitoring other emails sent to Google via my domain, is that they have to have valid SPF AND DKIM signatures in the email header (i.e. a "pass"). DMARC is not mandatory - i.e. can be "none", but it can't be a "fail".

Interestingly, I had forgotten my password for this forum, so had to request a password reset. That reset email came from noreply@community-mailer.plus.net - and I did receive it, as it had a valid SPF AND DKIM (but no DMARC).

I understand, that Yahoo and other large email providers are now following Google's lead, so Plusnet, if you want folk to receive your corporate emails, you really need to fix DKIM (and ideally, add DMARC) pretty damn quick.

Thanks!

[#2]

Moderator's note:
Post released from the automatic Spam Filter and moved to Email

[#3]

I haven't received any email re managing my Plusnet account (like bills and CPI billing increase etc), because Google is rejecting these emails on the grounds that the domain of the sender address - donotreply@plus.net has a "very low reputation".

Strange, I've just checked my PN billing emails (going directly to my domain) and they all come from support@plus.net. Even more strange is that they all have valid DKIM signatures and pass SPF.

The domain plus.net also has a valid DMARC record ( according to mxtoolbox ).

Do Cloudmark implement ARC https://proton.me/blog/what-is-authenticated-received-chain-arc#:~:text=Authenticated%20Received%20C.... for their forwarded email ?

[#4]

@Daisybank  Why are you using Google, a free, questionable Email service, when you’re probably paying for a far better and far more secure service hosting ‘bob.co.uk’ ?

[#5]

Do Cloudmark implement ARC

Mistype, I meant Cloudfare.

@Daisybank the email in question couldnt be a scam email could it ? Hence not actually from PN. SPF may pass due to Cloudfare forwarding implementing SRS but DKIM obviously wont...

[#6]

Good question.

I am NOT an ARC expert, but I don't think it is appropriate in this specific use case.

As I understand it, ARC signatures are mainly added by mail servers (mainly bulk email servers used for mailing lists and the like) so when an email flows through them, they add an ARC seal and then Cloudflare (which is only forwarding remember) then adds an ARC seal. If no ARC signature in the first place, then a Cloudflare forward wouldn't add a seal.

I got alerted to your message in this forum, by an email, because this forum generates alert emails, which it then sends OUT through outbound.eu.khoros-mail.com. It is khoros-mail.com which (as a list server) which is adding the ARC signature, for which Cloudflare then adds the seal.

As far as I can tell, if there is no ARC signature in the first place - which there isn't on account specific emails from Plusnet - then I can see that Gmail invariably rejects email (from anyone) if SPF and DKIM isn't properly configured and ideally, DMARC as well.

Now, this is not me having an argument with Plusnet or anybody else. I am simply saying two things:

1. This is new - in that I haven't mentioned it before - for about 4-5 months now, email sent to me by Plusnet (both for broadband and mobile phone account management) has ended up in my Gmail Spam. I always (from the web interface) click "Report not Spam" in order to try and train Google generically, that emails from Plusnet (and they are genuine Plusnet emails) are not Spam.

2. This issue got worse approx 2 weeks ago - matching Googles public statement about them ramping up Spam protection - so that's why I started analysing headers to try and see if there was a pattern in what gets rejected by Google and what gets accepted (from any sender - not just Plusnet).

I'll repeat. I don't have any beef with Plusnet or Plusnet IT/email management team, just trying to helpfully point out (not start a war) that in my testing, email forwarded by Cloudflare (which doesn't have an ARC sig) always seems to be accepted by Gmail if SPF and DKIM is properly configured and that email with correct SPF, DKIM AND DMARC ALWAYS gets delivered to my Gmail account.

[#7]

Ah, so this is really interesting - and good analysis input - thanks!

The distinction here, is that you were picking up emails from your domain, whereas mine were being forwarded via my domain. 

So I checked, and I did receive a "Your Plusnet bill is ready to view" (forwarded) email on 18th March and the header contains this (so it DOES) have an ARC sig - but note the bit I put in bold. Is this a clue?

ARC-Authentication-Results: i=1; mx.cloudflare.net;
dkim=neutral (body hash did not verify) header.d=plus.net header.s=052019 header.b=UaUzrw/K;
dmarc=pass header.from=plus.net policy.dmarc=reject;
spf=pass (mx.cloudflare.net: domain of postmaster@hubrelay-rd.bt.com designates 217.32.182.70 as permitted sender) smtp.helo=hubrelay-rd.bt.com;
spf=pass (mx.cloudflare.net: domain of support@plus.net designates 217.32.182.70 as permitted sender) smtp.mailfrom=support@plus.net;
arc=none smtp.remote-ip=217.32.182.70

[#8]

As I understand it, ARC signatures are mainly added by mail servers (mainly bulk email servers used for mailing lists and the like) so when an email flows through them, they add an ARC seal and then Cloudflare (which is only forwarding remember) then adds an ARC seal. If no ARC signature in the first place, then a Cloudflare forward wouldn't add a seal.

My understanding is that the ARC signature only applies to forwarded email and is applied by the forwarding servers. The problem with forwarded email is that it can break DMARC. In an attempt to alleviate this, the forwarding mail server performs DKIM & SPF checks on the originating email and then adds an ARC header giving the results of this. When the forwarded email gets to the final destination and DMARC fails, the presence of the ARC header can verify that the original mail was ok and so the mail can be accepted. I believe the requirement for ARC is part of the recent changes by google https://powerdmarc.com/google-arc-sender-guidelines/

[#9]

dkim=neutral (body hash did not verify)

Seems our posts crossed. That may well be significant , I'll have a look later (just been descended on by both grandkids so its a bit hectic at the moment)

[#10]

@Daisybank ok, so it would appear that Cloudfare don't like the DKIM signature on the original email from Plusnet and so have reported that in the ARC header.  Sounds like its similar to this https://community.cloudflare.com/t/email-routing-where-sender-has-strict-dmarc-lands-in-spam/348211

If you can possibly get Cloudfare to look at the original email headers and advise why they think the DKIM signature is not correct then I can feed that information back to the right people at PN and get them to look at it.

TBH routing email through a forwarding system is becoming a nightmare these days. If you have (and use) your own domain, I'd suggest getting the email hosted directly and dispense with forwarding. It needn't cost the earth, my email hosting costs £20/yr for unlimited mailboxes but subject to a 2Gb total storage limit.

[#11]

Thank you so much for your investigation - really appreciated!

For my other businesses, I actually use MXroute - so yes, proper SMTP with POP or IMAP to and from the client.

In this particular case (for my personal email address @a_domain_that_I_own) I catch-all forward to a personal Gmail account. 

Now, I have been hosting the domain with Cloudflare for about 8 months now - after moving from Gandi (when they got greedy) and everything was fine (back at Gandi) and using Cloudflare forwarding, until two weeks ago when Google announced that they were getting aggressive. I could then see, that the only emails failing were those with SPF/DKIM failures - as we have already discussed. A few friends emailing had similar failures, I got them to correct SPF/DKIM and all worked, so, it was a cause and effect thing - or so I thought, until you provided the link to that forum on Cloudflare - thanks!

This in turn has lead me down a rabbit hole to: https://community.cloudflare.com/t/transient-error-421-4-7-0-when-forwarding-emails-to-gmail/629941/... - which matches the issue, but seems to indicate that it may be because Google are blocking a very specific Cloudflare IP range.

Anyhow, I have taken the advice there, and have just now, started to experiment with improvmx.com. This means that the email flow is not to Cloudflare, for now my Cloudflare MX records point to improvmx.com - who in turn, forward to my personal Gmail account - so let's see how that goes!

Now, to answer some of the questions other folk asked - which boils down to "what the hell are you up to?" let me explain - because if you ever hit this professionally, it's what loads of other folk do:

It is NOT a good idea to forward mail like this - as it is likely to end in tears (it already has) - so why do it?

Well, as long as you configure your personal Gmail (IMAP or POP) to NOT delete any emails, it means that you can read and send email from multiple devices concurrently (PC - or Phone etc when not at base) AND you have a kind of central repository of all emails ever (useful for subsequent discovery). 

Of course, users could save everything in a local PST (mine is in Onedrive - and yes, it does work..) but lose the PST and you are toast.. so a full backup in Gmail.com can be a lifesaver. 

Now, you might be thinking that multiple devices accessing the same personal Gmail account concurrently, will never work - but here's my present to you al;: from your POP/IMAP client, APPEND “recent:” to the front of your googlemail account name – i.e. in our example previously "recent:bob@gmail.com" 

[#12]

As @MisterW has noted forwarding brings a host of unwelcome issues, especially if SRS has not been implemented, a failing of many forwarding services.

There has been a number of issues with Plesk platforms used for forwarding - where an email had attachments, the headers were being corrupted (line feed inserted) on forwarding, resulting in checksum failures at the recipient.  A fix for this was released around 6th March.

Gmail is becoming an utter pain - probably best to avoid using them if you can and use a professional organisation instead.

As for Plusnet email correspondence delivery failing, I did not receive my price increase email and was notified through the post, an issue which has been raised with the business in the SU space.  I considered adding this to that discussion, however given that there is a third party involved here and the middle man accepted delivery, I do not think that there is anything material for Plusnet to look at here.  If that perception changes, either @MisterW or I will pick it up.

[#13]

Thank you so much for this - and it now turns out, I have a bit of egg on my face - sorry!

In all my testing, correctly configured DKIM, DMAC, SPF messages were delivered, and incorrect emails were not - 100%. BUT after 2 weeks, Cloudflare finally admitted a problem (which is disappointing in itself - because ordinarily, they are the gold standard) and published this: https://www.cloudflarestatus.com/incidents/0jx8x02cv5l6

In the meantime, I got a tip off to use https://improvmx.com/ (one domain is a completely free tier subscription) - and it all works a treat. Additionally, they have very good logging, so I can more clearly see individual failures and delays etc.

You are absolutely right about SRS though. Completely separately, Jarland Donnell, who runs MXroute, has written various blogs about Google's incomplete use of SRS and separately, that the MXroute service is impacted so much by Spam, they are no longer accepting any email from the monster TLD (as they say it looks like the TLD has been created only for the purpose of short-lived .monster domains, created (and deleted within hours) for the apparent sole purpose of sending industrial quantities of Spam. So it appears that this is only going to continue to get worse before it gets better..

[#14]

Thank you so much for this - and it now turns out, I have a bit of egg on my face - sorry!

@Daisybank don't worry you're not alone😀

Having said this at the beginning...

Strange, I've just checked my PN billing emails (going directly to my domain) and they all come from support@plus.net. Even more strange is that they all have valid DKIM signatures and pass SPF.

We've just been advised ( belatedly! ) via the superusers forum that Plusnet HAVE recently changed the source for service messages to donotreply@plus.net. Apparently despite all the emails stating that the support@plus.net address was not monitored, people were still replying to it!. Changing to the 'donotreply' address makes it more obvious that it will not accept replies.

[#15]

Good to know that I am not going completely nuts - LOL!

All good now though - as my latest billing emails (from donotreply@plus.net) now come through OK - whereas they didn't used to - even though noreply@community-mailer.plus.net have always sailed through fine.