From address doesn't meet the authentication requirements defined for the sender

[#1]

talktalk.net has today produce another  smtp; 550 5.7.1 rejection on an address that has regularly worked in the past.

[84.93.230.244]  is present in SPF record for _spf-internal.plus.net 

Reporting-MTA: dns; avasout-ptp-003 [84.93.230.244]
Received-From-MTA: dns; Clarelaptop [86.30.96.254]
Arrival-Date: Wed, 06 Aug 2025 19:05:26 +0100


Final-recipient: rfc822; xxxxxxx@talktalk.net
Diagnostic-Code: smtp; 550 5.7.1 Connection refused - [84.93.230.244] blocked by Validity - https://senderscore.org/blocklist-lookup/ - OXSEU001_102 - https://postmaster-oxseu.vadesecure.com/inbound_error_codes/#_102

Last-attempt-Date: Wed, 06 Aug 2025 19:05:26 +0100

[#2]

I seem to remember from a long, long time ago dealing with a problem  where a receiving mail server could refuse emails but force the sending server to resend the emails after a predetermined period depending on various conditions.....     It would be interesting to see if anyone who's had their emails moved to Greenby now have the same problems ?

[#3]

Very unlikely as the bands moved thus far are not deemed bulk senders.

[#4]

(Possibly useless info)

1468 is a product of 3 prime numbers

367 x 2 x 2

But I could be wrongs.

[#5]

2379 is a product of 3 prime numbers 3, 13, 61

[#6]

Sweet!!

367 is three minutes and 7 seconds, a bit of an untidy offset, which if doubled on each 'go away and do not bother me again for a while' back-off would (a) give a random distribution of retry times, which get progressively longer.

EDIT: OK maybe not!!  The back off time being the product of three prime numbers would be fairly random!!

To have back worked those figures to be the product of three primes is either pure genius or madness ... really not sure, but definitely interesting!!  Respect!!

[#7]

Blame Countdown and Rachel Riley's "product of two primes" when it comes to the numbers.

It took me more than 30 seconds to see the primes. The 'lock' for me was the double factor of two (the one and only even prime). I must admit I had to look up that the four digit prime was a prime. After that my interest was piqued.

However, two samples may not be representative (statistically).

I've some rather random ideas as to how Google's e-mail configurations could cause things to disappear into the digital ether (I think that such occurences have been reported?)

(aren't security certificates based on large primes?)

[#8]

In an attempt to get this thread back on topic, I sent an email to xxxx@groups.outlook.com (via Outlook, not webmail). The MS-related addresses all responded with:

...
The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , DMARC= Fail
...

So, not just DKIM failing in this case.

It's been over 3 weeks since the last update (Sending emails to Microsoft-owned domains such as ... - Plusnet Community) so isn't it about time someone from Plusnet gave us a better indication of when the problem might get fixed?

P.S. I believe the place for discussing the current gmail delivery delay issues is here:
Problems sending PN email to Gmail addresses - Plusnet Community

[#9]

---

@abitpedantic wrote:

In an attempt to get this thread back on topic, I sent an email to xxxx@groups.outlook.com (via Outlook, not webmail). The MS-related addresses all responded with:

...
The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , DMARC= Fail
...

So, even MS domains don't meet MS's crazy rules! No great surprise there, TBH.

---

[#10]

This business email sent from MS Outlook via Plusnet's SMTP to six colleges included just one MS destination, 
the one rejected as follow...


Reporting-MTA: dns; avasout-peh-002 [212.159.14.18]
Received-From-MTA: dns; Clarelaptop [86.30.96.254]
Arrival-Date: Fri, 08 Aug 2025 15:30:17 +0100


Final-recipient: rfc822; xxxxxx@live.com
Diagnostic-Code: smtp; 550 5.7.515 Access denied, sending domain KEYLINE.PLUS.COM doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , DMARC= Pass [PAWPR08MB10237.eurprd08.prod.outlook.com 2025-08-08T14:30:20.856Z 08DDD3C56A56C23F] [CH0PR07CA0027.namprd07.prod.outlook.com 2025-08-08T14:30:20.899Z 08DDD6314A689693] [CH2PEPF00000149.namprd02.prod.outlook.com 2025-08-08T14:30:20.944Z 08DDD635F5C97422]

Last-attempt-Date: Fri, 08 Aug 2025 15:30:20 +0100

[#11]

Today we have a different rejection response from an outlook.com destination.


Reporting-MTA: dns; avasout-ptp-003 [84.93.230.244]
Received-From-MTA: dns; [192.168.0.16] [86.30.96.254]
Arrival-Date: Sat, 09 Aug 2025 08:48:07 +0100


Final-recipient: rfc822; xxxxxxxxxxxxx@outlook.com
Diagnostic-Code: smtp; 550 5.7.1 Service unavailable, Client host [84.93.230.244] blocked using Spamhaus. To request removal from this list see https://www.spamhaus.org/query/ip/84.93.230.244 (AS3130). [Name=Protocol Filter Agent][AGT=PFA][MxId=11BBAD7AFD4AD4B4] [CH3PEPF0000000E.namprd04.prod.outlook.com 2025-08-09T07:48:13.313Z 08DDD6BD7EF6950B]

Last-attempt-Date: Sat, 09 Aug 2025 08:48:13 +0100



Previously server avasout-ptp-003 [84.93.230.244] was also rejected by talktalk.com

Reporting-MTA: dns; avasout-ptp-003 [84.93.230.244]
Received-From-MTA: dns; Clarelaptop [86.30.96.254]
Arrival-Date: Wed, 06 Aug 2025 19:05:26 +0100


Final-recipient: rfc822; xxxxxxxxx@talktalk.net
Diagnostic-Code: smtp; 550 5.7.1 Connection refused - [84.93.230.244] blocked by Validity - https://senderscore.org/blocklist-lookup/ - OXSEU001_102 - https://postmaster-oxseu.vadesecure.com/inbound_error_codes/#_102

Last-attempt-Date: Wed, 06 Aug 2025 19:05:26 +0100

[#12]

I'm not sure 'outlook.com' are correctly interpreting the Spamhaus block list. Many  mail providers use that, so ifthat server was allowing spam, you  would expect rejections from more sources.

Similarly, although they use a different 'checker' , I would suggest that either/or 'senderscore'/'vadesecure.com' have some dodgy entries  in their databases.

[#13]

Great, more speculation.

[#14]

You think so? OK, as I've only been around this space for fourteen years, and consequentially picked up a fair amount of knowledge, I'll bow to your greater experience.

[#15]

A whipper-snapper !

I've 35+ years of experience in telecoms, sat comms and business technology delivery.

Enjoy the weekend.