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

[#1]

Well, as Plusnet made no changes (AFAIK) to their mail services, and MS  announced 'enhanced security' on their inbound servers - who moved the goalposts?

[#2]

@PhilipHeyes 

So you do not like what appears to be blindingly obvious - there is widespread inconsistency in Microsoft’s processing of inbound emails.  Given different experiences arising from sending from the same source service what are your theories and the evidence which supports them, to contribute to understanding what is happening?

Mencken’s comment on social philosophy comes to mind here: “It is the nature of the human species to reject what is true but unpleasant and to embrace what is obviously false but comforting”.

I understand that wanting to blame Plusnet in the absence of identifiable causes is warm and comforting if only because getting a fix from Microsoft might be seen as being more difficult.  It does though presume that a fix is in the gift of Plusnet’s.

Why are folks so determined to completely ignore the well reported body of evidence relating to Microsoft DKIM verification failures due to DNS performance issues, coupled with different regimes rendering variable SCL metrics for the same email sent to different domains?  There are 100’s of reports to be found by anyone caring to do a Google search.

If there were no DKIM lookup failures, consistent SCL metrics across all services and predictable failures … I’d be looking at the source service.  Uncomfortable as might be, that’s not a true reflection of what we see here.

I did another escalation late yesterday evening (23:30) and have received an acknowledgment within 8 hours.

[#3]

@jab1 

Things are a bit more subtle than that.

Microsoft changed their bulk sender definition policy which made it neigh impossible to send any email to Microsoft domains.  Plusnet implemented SPF configuration on every *.plus.com subdomain.

That fixed the major change.  However further to that for as yet inexplicable reasons Microsoft is playing silly beggars with emails having multiple addressees.  If I had to put money on this, I’d wager that Microsoft has gone a stage further with their unilateral rules etc.

Not only is the *.plus.com space being treated as a bulk sender, but emails having multiple addressees are being deemed mailing list recipients and thereby want to impose / demand that the sender embed unsubscribe links - regardless of if such is applicable / appropriate.

[#4]

This may have been already discounted and ay be completely irrelevant but its worth posting just the same :

We have found a solution!

After analysing the affected emails, which were blocked by the Microsoft servers with "DKIM=Fail", we noticed that these emails all have a Content-Transfer-Encoding of 8bit. These mails are not sent from Exchange servers, but automatically via another third-party software for customer communication (with MailKit framework).

We then opened a support case at Microsoft and received the following response/solution:
Issue Resolution: 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, which seems to resolve the issue. Additionally, there have been reports that non-ASCII characters in the email body can also cause DKIM failures.

Subsequently, we have changed the email template for mail-creation in the third-party software to Base64 Content-Transfer-Encoding and now have no more problems with the Microsoft servers.

Perhaps this will help some of those affected.

[#5]

"It does though presume that a fix is in the gift of Plusnet"

Should "no fix possible" become Plusnet's conclusion, please do not delay in notifying us.

[#6]

@Townman Thanks for the clarifications in msg #558 - must admit I'm not following this debacle closely as (fortunately) it doesn't affect me directly, but it does appear they constantly shift the goalposts.

[#7]

@JaAm said (quoting Microsoft):
"One workaround is to change the Content-Transfer-Encoding header to quoted-printable,"

Good luck getting 1.5 million non-technical Plusnet customers to implement that.

At least it's an acknowledgement by Microsoft that there is an issue on their side, which requires a fix.

[#8]

@JaAm 

Thank you - that potentially looks interesting and starts to point to a possibility of an email client contribution to the issue as has been hinted at.  It does not though explain how the multiple addressee factor seems complicit, nor the inconsistent behaviour between MS domains.

I have previously referenced code set complications with subject content and DKIM failure to (IIRC) @PhilipHeyes who (at the time) confirmed there were no 'special' characters in the subject; your contribution suggests that the same in the body text could be a factor.

Do you have a link to he source of your quote please?

A codebase issue and an association with Microsoft Outlook would point to a Microsoft issue at one or the other ends ... possibly in conjunction with something else.  One also wonders if the locale settings (which includes the codebase) on the PCs encountering the issues could be a factor.

[#9]

The initial link I looked at was :

https://www.reddit.com/r/sysadmin/comments/1kb9ta6/microsoft_to_reject_emails_with_550_5715_error/

And this pointed to the microsoft blog :

https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosy...

I hope this helps.

[#10]

To confirm we do not have special characters in the Subject or the Body of emails,
our business emails cover property management / renovations and it is all in plain English.

Using the same retail HP Laptop & current MS Outlook installation we successfully send similar business
emails via gmail.com and 123Reg to multiple destinations including to one or more Microsoft destinations.

[#11]

@JaAm 

Do you have a link to the discussion on the code base complication please.

The Microsoft article is the technical explanation of their utter arrogance…

”Outlook is pushing the broader industry toward best practices…reinforce the best practices across the industry. We believe that by raising the bar for large senders..,”

I seem to have missed the memo appointing them as the internet enforcement officers.

[#12]

@PhilipHeyes
We understand all that. The biggest issue is a recent Microsoft change, which hits Plusnet because of the xxx.plus.com address format. The individual username comes after the '@' symbol. So it's different from your Gmail and (I assume) your 123Reg-based account.
Microsoft is then applying stringent new requirements which lump all xxx.plus.com accounts together as if they were one bulk sender. They don't do that for Gmail etc.
Then people are discussing possible workarounds for the stringent new requirements. But none would be necessary if Microsoft weren't wrongly classifying individual Plusnet accounts as one big bulk sender.

[#13]

---

@JaAm wrote:

...One workaround is to change the Content-Transfer-Encoding header to quoted-printable...

---

My mail client is Outlook 2016, which does not have the option for me to change that header.  However, a search on:

change the Content-Transfer-Encoding header to quoted-printable outlook 2016

returned the idea of sending the message as plain text / rich text instead of as HTML.

So far I've only sent one test message to two MS accounts using plain text and I've not heard back yet from the recipients but I've not had the instant bounces that all previous attempts to send, simultaneously, to multiple MS accounts have generated.

I will test sending as rich text later today and report back but my (non-statistically valid) sample of one supports the idea that the feedback that @JaAm got from MS is an important step forward towards resolving this problem of MS servers not being able to handle DKIM validation.

[#14]

@Tim-J 

Hi Tim,

Whilst that is fundamentally true, I think we are past the bulk sender foundation issue.  In general Plusnet users can send email to Microsoft addressees successfully, following the augmentation of the original DKIM and DMARC configuration with SPF.

The issue @PhilipHeyes and others are encountering is the very variable behaviour when sending emails to multiple Microsoft addressees.  The base bulk sender rigour if still an issue would inhibit sending any email to Microsoft.

[#15]

@PhilipHeyes 

I guess this would not be a direction of travel which will fit well for you, but given you’ve a highly dependable scenario for repeating the issue … is there any possibly you could try a test using plain text rather than HTML formatting for the email please?

If that proves successful then there’s a clear angle to persue.