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

[#1]

Meanwhile back on the original topic of this topic.  What has been / is being done with the information uncovered by @JaAm about:

---

Microsoft Outlook servers may have trouble handling 8bit encoding when it comes to DKIM validation. One workaround is to change the Content-Transfer-Encoding header to quoted-printable

---

[#2]

@stuck 

Where do you suggest is this a setting / consideration?

User’s client environment, receiving email services … or some other intermediate party?

TBH though this looks enticing, one would expect to see the same failure arise on single addressee messages, if this were a contributing factor.

I would be more convinced of one thing or another being a factor if we saw the same bounce for the same email if sent to a single addressee as is being reported in the context of multiple addressees, be they visibly copied or blind copied.

None of the empirical evidence reported here makes coherent sense.

[#3]

My heart sinks.

Once again I read an attempt to draw attention away from these repeated failure occur only when sending via a Plusnet SMTP and from recent posts even in text format rejection and  with HTML and Unsubscribe links the still rejections from MS accounts.

Via other ISP SMTP servers  & email addresses  the same HTML email messages are delivered.

[#4]

Phillip,

No it’s not drawing attention away from matters.  It is very much a matter of trying to be objective, rather than just seeking to blame the Plusnet service in the abject absence of objective evidence to affirm that.

Your persistence in referring to other SMTP services is not objective unless those services use a domain addressing structure similar to Plusnet’s which Microsoft can treat in an identical (off hand) manner.

If this were a SMTP issue, then we should expect to see the same outcome for all emails, singly addressed as well as multiple addressed emails.  Be they sent from Microsoft Outlook or webmail.  The body of evidence does not support that conclusion.

Your comment above echoes my doubts about this being the character encoding issue, for you state that pure text emails fail too when sent to multiple addressees.  I need to re-read the supporting evidence offered around here as I believe one contributor contradicts that finding.

By all means offer a thought through assessment of all the evidence presented here, but please do not just seek to draw attention away from the possibility, in fact probable likelihood. that the issue IS somewhere else.

If this were a Plusnet service issue, I would expect to see the failure occur regardless of the email client, the message encoding or the number of addresses, as none of that makes a jot of difference to the operation of the SMTP server.

[#5]

@Townman 

I would be more convinced of one thing or another being a factor if we saw the same bounce for the same email if sent to a single addressee as is being reported in the context of multiple addressees, be they visibly copied or blind copied.

A possible explanation I've suggested several times before is that this is all part of a multi-factor spam scoring system operated by Microsoft, in which

• Multiple addressees score more highly than single addressees.
• The scoring lumps all xxx.plus.com addresses together as a single high volume sender, with much higher hurdles to jump over.
• HTML, rich text or plain text score differently.
• And the DKIM failures, which while possibly caused by a separate issue could also add a factor to the spam filter score.

All adding together to give the seemingly random results that people have experienced, but in which some factors (e.g. multiple recipients) often seem to be present.

I certainly accept this may be wrong, but I don't recall a clear explanation as to why, nor any better explanation.

[#6]

---

@Townman wrote:

@stuck 

Where do you suggest is this a setting / consideration?

---

Since it's not something a mere user can change, it's  system sttting, I assume that means a setting that Plusnet has to change somewhere in the outgoing server settings.

[#7]

@stuck 

A big assumption based on what knowledge?  Agreed something somewhere needs rectified but what gives you confidence that is in Plusnet’s space?

@Tim-J 

I would agree entirely with the theory if we saw things being delivered to the junk folder rather than the inbox inconsistently.  There is a good deal of evidence for this reported around the internet.  Same email sent to different Microsoft environments being assigned different SCL metrics (Spam Confidence Levels).  That suggests that different delivery environments have different assessment algorithms.

However what we are seeing here are variable DKIM pass / failures.  I believe DKIM is absolute - the verification should be the same in any environment … unless that environment has a flaw.

DKIM timeouts are a known issue in Microsoft’s environments but as Phillip has mentioned the failure he reports does not match the statical randomness of those reports.

What is required here is for Microsoft to come down out of their ivory tower and look at what is happening on the ground inside their systems.

[#8]

@Townman  wrote:  

What is required here is for Microsoft to come down out of their ivory tower and look at what is happening on the ground inside their systems

In the absence of any information directly from Plusnet themselves I wonder if you could let us know what efforts you are aware of Plusnet are making to actually extract some information from Microsoft.  It is over 8 weeks ago since @James_B  reported that  Plusnet were " working closely with them to identify and resolve the issue as quickly as possible" . 

I'm sure some inkling of the current status of this joint work would be appreciated by the long suffering Plusnet users.  Do Plusnet know if MS are actively investigating  and pursuing this problem?

My impression is that there is a lot of effort, speculation and helpful suggestions by members of this forum but a total lack of feedback from the Plusnet organisation itself.  Truly awful customer service!

[#9]

@James_B is on annual leave hence no recent update from him.  @JordanTA is there a status update available (which is different to the last user statement) please?

[#10]

Goodness the less I say the greater the landmine I step on 🐵

However, highlighting delivery success via other ISPs email accounts and services is a logical and an objective thing to do when the question of the eMail Client / Computer Platform / Email format are being raised as a possible reason for rejection.

[#11]

Phillip,

What analysis of your comparison systems do you believe helps to inform the user experience?

The only one which to me hints at some potential possibility is that the other SMTP services you’ve referenced are either not treated as bulk senders (the nub of this space) or do not have subdomain addressing structures.  The latter has a bearing on DKIM and DMARC alignment.

Here the alignment is relaxed therefore that for PLUS.COM applies to all.PLUS.COM however if that were the issue, then it would be reasonable to expect 100% failure.

There is something very obscure happening here; if I could replicate the issue with confidence, I would use my Microsoft365 subscription to poke Microsoft direct.  This issue has the same characteristics of false positives seen in numerous environments seeking to mitigate spam - some of the time it gets things totally wrong, as in send two emails with different URLs and all is OK, send an email containing both URLs and it’s not OK.  That’s the scenario @Tim-J has alluded to.

As I type this - an off the wall thought - where this is reproducible is there anything odd about any of the email addresses?  Special characters / formatting as in including < or > ?

I will double check later - I’m wondering what gets included in the DKIM verification.

[#12]

I've taken a look at the destinations they are all formatted :

name@outlook.com
name.name@outlook.com

may also be to msn / hotmail / live etc

as for spelling English alphabet and some digits  ( Eg name.name33@outlook.com )
no special characters

[#13]

@Townman  thanks for your reply #594.  I really do appreciate your efforts.  However I do feel you are doing Plusnet's job for them.

It would be useful  if @JordanTA  could also include some information about what the Plusnet business is doing to progress a solution. 

For example, is it trying to replicate some of the many scenarios described in this thread so that they can garner some prescise first hand diagnostics to present to Microsoft?  In my 30 years in IT support/maintenance/development that is precisely the first thing we would do when presented with a seemingly intractable user problem .  

[#14]

Further to my post #574, this morning I sent an email from MS Outlook as plain text to a list containing over 30 MS-related email addresses and a lot of others. Previously, sending a normal (HTML) message has resulted in delivery failure messages from typically about half of the MS-related addresses. Today, no failures.

[#15]

@PhilipHeyes and @abitpedantic 

Amongst other things I'm trying to do this morning, I have been crawling through the headers of emails received, but routed to my Outlook junk folder from to previous testing.  That suggests...

The TO addressees are included in the DKIM verification - off the wall thought are you CCing the addressees leaving the TO field blank?

I note these headers...

Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

Are you able to discern those for the bounced and not bounced recipients?

Similarly what about the DKIM result header?  You have shared the summary header, but what is in the detailed authentication results header...

Authentication-Results: spf=pass (sender IP is 212.159.14.19)
 smtp.mailfrom=*******.plus.com; dkim=pass (signature was verified)
 header.d=plus.com;dmarc=pass action=none
 header.from=******.plus.com;compauth=pass reason=100

Is there amplification of the failure in place of the above "(signature was verified)"?