Emails rejected by gmail.com ...

[#1]

I am having emails rejected by gmail.com with the following message:

      This is an automatically generated Delivery Status Notification.    
Delivery to the following recipients failed permanently:
   *<redacted>@gmail.com

Reason: A message that you sent to the following recipient could not be
delivered due to a permanent error. ** The remote server ?? responded
with: ** <redacted>@gmail.com ??:?? This message was created
automatically by mail delivery software on the server .

I would have preferred to have been able to send this message in a "ticket", as it inevitably contains a personal email address.. It was stupid of Plusnet to hide behind the telephone and remove your ticketing system as a very useful means of contact - especially as I have to cause PlusNet to break GDPR rules in seeking help. Your records will show that the reponse to my telephone call on this matter was absolutely useless.

Kenneth Spencer

Moderators Note: Personal information removed but still visible to Plusnet staff

[#2]

I have asked for the post to be amended to remedy this.

[#3]

@kaspencer 

If you anonymise personal information when posting on this forum and a Plusnet agent can’t identify your account from the details that you supplied when you signed up to this forum, they will contact you by Private Message.

[#4]

Without knowledge of the reported reason for rejection and details of how the email is being sent, it is difficult to offer relevant help.  Gmail is making a real hash of receiving emails for many people by mandating non-mandatory email RFCs.

• What is the error reason / code sent by Gmail?
• What domain is the email being sent from @account.plus.com or @yourdomain.co.uk hosted by Plusnet **?
• Is the addressee actually @gmail.com or is it somewhere else and they are forwarding the email to @gmail.com?
• Are you still a Plusnet customer or is this a legacy email only account?
• If you send a blank email to the @gmail.com addressee is that also rejected?

** If you are using a personal hosted domain, there is something which can be done to improve interworking with Gmail's unilateral imposition of non-mandatory RFCs.  Will advise on that if it appears to be relevant, after you have answered the above questions.

[#5]

@Townman @Baldrick1 @jab1 

Answers to Townman's questions are:

What is the error reason / code sent by Gmail?
   The error message was given as received: i.e. no error code, just the reason as per the given text.

From which domain is the email being sent: @account.plus.com or @yourdomain.co.uk hosted by Plusnet **?
    I am sending the email from one of my domains: kaspencer.com.

Is the addressee actually @gmail.com or is it somewhere else and they are forwarding the email to @gmail.com?
   The addressee is in the gmail.com domain.

Are you still a Plusnet customer or is this a legacy email only account?
   I have been a Plusnet customer since September 2003, and still am! (Bet you a pint that beats you!)

If you send a blank email to the @gmail.com addressee is that also rejected?
  I don't know but I will try. AND incidentally, I have other corrspondents who use GMail and I communicate with them
  successfuily.

The history shows that there have been many communication issues between PlusNet and GMail.com. Are these problems generally or mainly of Plusnet's making or the fault of GMail.com? If gmail.com are intentionally blocking emails from my domain I'd like to know why! If they are not intentionally blocking them, there is a fault or malconfiguration somewhere, and I'd like that resolved. And, to finish, why os *that* gmail account rejecting my emails, and others not!

Thanks all,

Kenneth Spencer

[#6]

Hi Kenneth,

2003 - that is a close call - think I joined around that time too - my oldest still active referral is Jan 2004 and I had at least one prior to that.

That error message says nothing useful!!  I confess to having taken the line that this is a nefarious "it might be SPAM" rejection from Gmail, but that is not clearly the case, but it is worth exploring.

As I hinted at before, Gmail are mandating RFCs and they can bite Plusnet users in a variety of ways as false SPAM errors.  In your case I thought that you might be sending from your own domain hosted on Plusnet, which will leave you with neither SPF nor DKIM configured.  NEITHER ARE MANDATORY requirements.

Try my fix here - https://community.plus.net/t5/Email/Mail-bouncing-to-gmail/m-p/1907102#M41985

That will add SPF records for your personal domain name.

Your other correspondents on Gmail - is that all from the same device connected in the same way?  I would suspect that there is nothing different at your end of the Plusnet end between those which do get through and those which do not ... other than the possibility that you were on a different dynamic IP address.  However given how long you have been a customer, I would guess that you took the option of the free static IP address when they were available.  If that is indeed the case the only difference, is the variable behaviours of Gmail.

Whose "fault" is it?  I will let you decide...

• Gmail has unilaterally declared that it will (from Nov 2022) mandate that the non-mandatory SPF / DKIM RFCs must be present on inbound emails
• Plusnet has not fully implemented these non-mandatory RFCs in respect of their email services
  • Plusnet attempted SPF on the *.plus.com email address, but that created more issues than the problem such sought to fix
  • DKIM has been implemented for *.plus.net domains and that somewhat mitigates the Gmail bulling tactics
  • Nothing has been done in respect of facilitating non-mandatory measures for hosted domain names, beyond the unsupported "facilitation" referred to above

I also suspected that unauthenticated SMTP connections will not help in this space.

[#7]

---

@kaspencer wrote:

The history shows that there have been many communication issues between PlusNet and GMail.com. Are these problems generally or mainly of Plusnet's making or the fault of GMail.com? If gmail.com are intentionally blocking emails from my domain I'd like to know why! If they are not intentionally blocking them, there is a fault or malconfiguration somewhere, and I'd like that resolved. And, to finish, why os *that* gmail account rejecting my emails, and others not!

---

Hi Kenneth,

Following on from your deep questions, picking up another topic from elsewhere, someone else has encountered issues where the end recipient is Gmail.com, though in that case the addressee was @btinternet.com ... which was forwarded to @gmail.com.  It would appear that BT has not implemented SRS and thus Gmail.com is black-balling the emails because the SPF SOFTFAIL directive is being ignored.  Again an illustration of a wring implementation on non-mandatory RFCs.

That thread lead to this - Help prevent spoofing and spam with DKIM - Google Workspace Admin Help

"Starting November 2022, new senders who send email to personal Gmail accounts must set up either SPF or DKIM. Google performs random checks on new sender messages to personal Gmail accounts to verify they’re authenticated. Messages without at least one of these authentication methods will be rejected or marked as spam. This requirement doesn’t apply to you if you’re an existing sender."

So in answer to your key question...

• Gmail has imposed change on the world
• It applies the changes to some senders, not everyone
• It applies the changes to some recipients, not everyone
• It checks some of the time, but not all of the time

In short, Gmail is unpredictable which effectively equates to it being not fit for purpose.  Note that this practice only applies to their not-paying-for-a-service customers - clearly they do not want to risk hacking-off paying customers, so they have selectively chosen not to mandate non-mandatory measures one those accounts ... less paying customers justifiably call "foul".

[#8]

I have been spending (wasting) a considerable amount of time investigating possible (your) Plusnet configurations and settings to allow me to send messages to colleagues and friends who use GMail for their email. But I have not been at all successful.

Then, talking to a friend who was also having GMail reject his messages (from his own domain, as in my case) who said that he had a similar issue with GMail rejections. He approached his domain host (ionos I believe). They instanty responded and set up SPF against his domain account/configuration, and the issue was resolved.

I have seen references to SPF in this forum. I would like PlusNet to respond properly to this issue, and tell me clearly and understandably what I need to do to resolve this issue, whether by implementing SPF or any other mechanism. I'm afraid that comments thus far have either been unclear, ambiguous or have required rather more information than I have seem to have at my disposal.

Before I end this message, I would like futher comment on the use of "relay.plus.net" for sending outgoing domain addressed messages, as apparently this can be a cause of rejection, presumably because the outgoing server address in question is not matched to the originating domain. One of my other domain hosts seems to provide an outgoing mail server name which matches the domain name. Why cannot PlusNet do that too if that would solve the problem.

Is alll this an indication that PlusNet has fallen behind the times and failed to keep their technology and practices up-to-date over all those years that have elapsed since they sold out to BT? There does seem to be a reluctance to bite the bullet and take corrective action.

I really do hope that someone will give me a professional and effective answer to this issue.

Many thanks

Kenneth Spencer

[#9]

Being clear and concise...

GMail have unilaterally mandated that email to free(but not paid) email accounts MUST be authenticated with either SPF and/or DKIM  ( Note that neither SPF or DKIM are mandated by the email RFC definition )

Email and domain hosting are legacy services , provided free at the time but are no longer available to new customers.

Despite the above, Plusnet have implemented DKIM for all <accountname>.plus.com address. This is not possible for hosted domains, neither is the direct creation of SPF records by users. For hosted domains, a workaround was developed that allowed an SPF record to be created which is valid providing mail is sent via the Plusnet servers. That workaround is outlined in the previous link but for clarity it involves creating a dummy MX record, which a periodic script monitors and creates the correct SPF record for the domain.

Hope that helps

[#10]

@kaspencer, if I've understood what your asking about in the 2nd half of your message, then having the server you are sending as set to something like mail.domain.com rather than relay.plus.com, would have no affect on any rejections. That used to be quite popular from hosting companies a number of years ago, as it is easier for the users to remember and could be considered to "look better".  It's rarely done now as it's much more preferred to use encryption when sending and receiving.  To set up mail.domain.com certificates on their mail platform for every domain for even a relatively small hosting company wouldn't be workable.

[#11]

@pjmarsh @Townman @MisterW 

Thanks chaps (if you are all chaps) for those messages.

Now, I admit that I should have looked closer at Townman's couple of previous posts on this subject but I did look back and found the suggestion of the additional, rather odd, DNS entry, which looks as though it is some kind of coded instruction or request to have SPF implemented on the domain (if implemented is the correct word). (By the way, shouldn't "soley" really be spelt "solely" ?).

So I have added the entry, and will see what happens. Am I correct in thinking that dns entry will disappear once the SPF "fix" has been created?

Thanks

Kenneth Spencer

[#12]

Am I correct in thinking that dns entry will disappear once the SPF "fix" has been created?

No, it will stay there. If you ever wish to delete the SPF record, then remove the mx record and the spf record will be removed.

found the suggestion of the additional, rather odd, DNS entry, which looks as though it is some kind of coded instruction or request to have SPF implemented on the domain

it is exactly that. Since its not possible for the user to create TXT records, we needed some form of record that COULD be  related, for the script to recognise,  without causing any problem. Hence the mx with a priority of 999999 which means it would never effectively be used as a real mx

[#13]

@MisterW @pjmarsh @Townman @Baldrick1 @jab1 

Thanks to all for the replies.

I added the SPF DNS record as advised, and waited a week or so. However the issue persists and is getting to be very irritating.

I would like comments from the experts on the following:

Google have a thing called "Postmaster Tools", which looks promising. There are two options under "Domain verification" which might enable progress.

The first method allows verification of the domain via a TEXT record: a long string beginning "google-site-verification=". However, I do not know how to create this type of record nor exactly into which field I put the text supplied, and what I put into the remaining of the LEFT, TYPE, PRI and RIGHT fields of my Domain Records. And I don't wish to break my domain accessibility!

The second method allows verification by adding a CNAME record. It requires a CNAME Label Host, supplied by Google -  presumably this goes into the left field of the record, and a CNAME DESTINATION/TARGET (supplied by google) which I imagine goes into the right field. I don't know what if abnything, goes into the PRI field, so if anyone else knows I'd be interested.

So: if I try these possible solutions (it seems that these entries have the effect of verifying the domain onwership with google) does anyone think they'll break anything (permanently?).

I will await views with interest!

Thanks in advance ...

Kenneth Spencer

[#14]

I added the SPF DNS record as advised, and waited a week or so. However the issue persists and is getting to be very irritating.

@kaspencer assuming the domain is the one you previously mentioned, I have checked and there is no SPF record for that domain. It doesnt look like you added the dummy MX record.

[#15]

@MisterW
Thanks for that. I'm seeing this at the moment:

maybe it needs a few more days. I presume it follows the normal DNS propagation process?:

Thanks

Kenneth Spencer