emails rejected by gmail

[#1]

I know that this topic has been raised before but I am still unclear how to resolve the issue. I am responding to an email using reply all - one of the recipients has a gmail.com account.

I receive the response below indicating that my email is rejected. It rather suggests that it is my plusnet address [myplusnetname.plus.com] which needs amending but I have no idea how to do this. Can anyone point me in the right direction?

This is the mail system at host relay.mailchannels.net.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
                   The mail system
<redacted to address>: host gmail-smtp-in.l.google.com[142.250.99.26] said:
    550-5.7.26 Your email has been blocked because the sender is
    unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with
    either SPF or DKIM. 550-5.7.26  550-5.7.26  Authentication results:
    550-5.7.26  DKIM = did not pass 550-5.7.26  SPF [my plusnet name.plus.com] with
    ip: [23.83.220.6] = did not pass 550-5.7.26  550-5.7.26  For instructions
    on setting up authentication, go to 550 5.7.26
    https://support.google.com/mail/answer/81126#authentication
    d9443c01a7336-21f368bcc9csi123489935ad.432 - gsmtp (in reply to end of DATA
    command)

Reporting-MTA: dns; relay.mailchannels.net
X-Postfix-Queue-ID: 83DF6322BBB
X-Postfix-Sender: rfc822; address@my user name.plus.com
Arrival-Date: Mon, 10 Feb 2025 07:53:45 +0000 (UTC)

[#2]

550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [my plusnet name.plus.com] with ip: [23.83.220.6]

Are you sending this email via relay.plus.net?

Are you sending the email DIRECT to the Gmail addressee?

The mentioned IP address [ 23.83.220.6 ] is someone else's relay service [ aye.yew.relay.mailchannels.net ] which is clearly not a permitted sender for @accountname.plus.com

Plusnet implements DKIM for all @accountname.plus.com addresses - the above reports that DKIM failed and SPF was checked ... but with a non Plusnet relay server address.

A logical conclusion might be

1. You are not using Plusnet's relay server (relay.plus.net) to send this email
2. The addressee you are sending this email to is not @gmail.com, but rather some other address and ...
   1. They are forwarding mail sent to that address to their Gmail account
   2. Their email hosting / forwarding provider is not implementing SRS

SRS is a mechanism which enables the final receiving service to understand that the the ORIGIONAL sender did NOT use the middle man's relay service to send the email.

Without SRS it looks as though YOU sent the mail using the addressee's redirection service.

If you can clarify if either of these scenarios are relevant, further advice can be provided.

[#3]

Hi Townman

I have checked my email client and I am not using relay.plus.net. I must confess I had forgotten that I had changed this. There were problems a couple of years back sending emails and following a suggestion on this forum I changed this to 212.159.8.107 - a whois reveals that this address belongs to plus net.

On this other question as far as I understand the gmail address I was attempting to send an email to does not redirect.

Maybe reinstating relay.plus.net will solve the problem - I will await your response before I change my email client.

[#4]

On this other question as far as I understand the gmail address I was attempting to send an email to does not redirect.

As @Townman says, Its not a gmail address, that you are sending to, that is forwarding. Its another email address, probably someone who has their own domain name, who is forwarding it on to their own gmail account. Their forwarding service does not implement SRS or DKIM authentication, so when the email is forwarded to gmail it fails SPF & DKIM checks.

Maybe reinstating relay.plus.net will solve the problem 

Its certainly not a good idea to use an IP address but the one you are using is actually one of the relay.plus.net IPs. SO yes its a good idea to change it, but I dont expect it to make a difference since you are already effectively sending via relay.plus.net and so DKIM will be implemented on your email

[#5]

Having checked - the email was sent via a redirection - I will contact the person who set this up.

[#6]

@Harold1066 

Good result on chasing down the issue to one of the logical candidates.

Either you need to obtain the @gmail address and mail that direct or the addressee needs to investigate SRS enablement with their hosting provider.  For some providers...

• SRS is not available at all (will cause no end of difficulties if Gmail and similar are the final destination)
• SRS is optional per redirection
• SRS is on by default (logically there is no reason why it should not be)

[#7]

I started getting exactly the same thing today to gmail only, never had a problem before, sending through ..

relay.plus.net port 587.

Final-recipient: rfc822; REMOVED
Diagnostic-Code: smtp; 550-5.7.26 Your email has been blocked because the sender is unauthenticated.

 Tried 3 times, instantly bounced. Tried to another non gmail email address I have, straight through instantly.

EDIT: There is nothing fancy in the address I'm sending to, this is to a normal blahblah@gmail.com address.

I am sending with the "from" as a domain but I set up all the things for security for that ages ago, it'll have something like 

v=spf1 a mx include:madasafish.com + stuff

for it.

[#8]

I just checked and my domain has type TXT for it:

v=spf1 a mx include:madasafish.com include:[anoher email host] ~all

I tried sending to my OWN gmail address and it bounced same as my previous email and the OP.

Is this SPF1 wrong? It's always been strange that it was madasafish for plusnet, which doesn't match .. plusnet, but that's what everyone always said to use.

Is it perhaps not a coincidence that BOTH people on this thread are talking about gmail rejecting emails referencing "madasafish"?

[#9]

@Kwak the include:madasafish.com was the early recommendation. More recent posts have instead recommended

include:_spf-internal.plus.net include:_spf-internal2.plus.net

might be worth trying that ...

[#10]

It probably does not help that there are temporary issues with MAAF name resolution.

[#11]

Well the plus net spfs are new from last time I looked when I configured these settings.

It's still not working with madasafishas of 5 minutes ago. I've just changed the domain to (belt and braces, old and new)

.. include:madasafish.com include:_spf-internal.plus.net include:_spf-internal2.plus.net ..

As I'm assuming the algorithm checks until it sees something it likes, lets see if that works, I assume it'll take maybe an hour to propogate or something as I see a TTL setting in there

[#12]

Just ran some more tests - can connect over PN network to the MAAF website (www.madasafish.com) but not when connected over EE mobile.

Looks as though the MAAF DNS promulgation is still a work in progress.

[#13]

Thank you.

I waited a bit and tried the above SPF I set and it failed .. I flipped the order and tried again later (madasafish AFTER plusnet)  it started working, I can send emails again. Not sure if madasafish still was wrong but plusnet was now ahead in order, but I'd have assumed unless blacklisted or something in a way I wouldn't expect, order shouldn't have mattered? I had ~all at end as well (but this was for gmail so .. ).

I'm aware of the TTL setting for caching, for me it was an hour (3600) and I think I'd waited longer .. but anyway. Maybe google ignore that.

A funny little thing I noticed was I did nslookup -type=txt from a windows command line on this domain, and it was using it said cdns01.plus.net, and it flipped which surprised me, so over a few minutes I did it a number of times and it went back and forth then settled.

Not what I'd have expected, and I'm not complaining, and don't want anyone to waste time to look into that But it wasn't what I expected, and made me ponder why. Multiple servers on that "server address" and it depends which one it hit I presume?

[#14]

The DNS “service” is a farm of servers (behind a load balancer) each with their own data set. These update independently. Therefore request to request results will come from different servers, hence the observed variable results.