office 365 "Cannot connect to SMTP server" "SSL negotiation failed"

Same issue on our end with our Ricoh device, just started last week. Some scans go through fine, but most of them fail (inconsistent). Also checked Exchange Online settings for the scanner account and "SmtpClientAuthenticationDisabled" was not set.

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission

Get-CASMailbox -Identity 'accountname'

Name ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled

accountname True True True True True

But even setting it to $false(which should allow SMTP Auth) does not resolve the issue.

Set-CASMailbox -Identity 'accountname' -SmtpClientAuthenticationDisabled $false

Name ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled

accountname True True True True True False

Any idea how to fix this?

Same here. 30 RICOH devices and all have the same errors.

Same issue in Brazil using Konica Minolta devices. Started Today.

Same problem here. Has anyone found a workaround?

Same here. if any workaround let us know

Same here! The problem started last week Monday, 27.01.2025.

I got the same issue with Konica Minolta 5020i some scans work some i get the SSL error. Dose any one have an ideea about this issue ? Or how can we check with MS to fix this ?

We are experiencing the same issue with Sharp MFPs, they are able to intermittently send out scan to emails but mostly error out when authenticating and we receive:"ERROR[3332]: Connection to SMTP server test failed", just started a day ago, more printers now starting to have this issue.

Same issue with us running Sharp copiers. Sometimes it works, sometimes it does not. Microsoft support does not recongize this as an issue, something is obviously broken.

Same issue for our Org with Konica MFP's (error 107), would love a solution here.

Same problem with Konica and Oki printers/multidevice. I found that problem is related with automatic group policy upadate in inspection journal.

Date 30.01.2025, 08:34

Type of action GroupLifecyclePolicies_Get

Corelation ID: 6b8e81e6-623a-4b58-a090-d8326f2b404b

Category GroupManagement

Stansuccess

ID Object 4e3a7a89-1115-4f9f-a415-9cc830d92408

I can't find how to undo these settings. Changing group settings or creating an exclusion group from MFA doesn't make any changes

Hello! Same here with xerox printers (affected model Versalink B7030 Fault Code 016-781: SMTP Server Connect Error), they work intermittently with send&mail function. No way to debug more the error. We have an open ticket with ms.

Same error with all sorts of printers (Brother, Sharp, Ricoh, Canon...). Always some SSL-error. We hade some customers with a 50/50 chance, every other try works.

Just noticed troubles are with Xerox Versalink C7030 (supports up to TLS 1.2), but it's working 100% with Kyocera TASKalfa 3554ci (supports tls 1.3).

Hi,
It's not a solution, but temporarily use the Google SMT server with an app password. On an old device, due to multi-factor authentication, it only works with an app password. This solves the problem while keeping encryption intact. You can also try using a Microsoft app password, but I'm not sure if that will work...
Server: smtp.gmail.com
TLS: 587

Any fix for sharp copiers?

We have the same issue with the Sharp MX-B455W but not with the Sharp MX-4070V. We will get a firmware update update tomorrow that is suppose to fix the issue.

Firmware Update did not fix it. Error is still coming up

We have the same issue with Ricoh IM350 and Ricoh MPC2003. But not all recipients are affected within the same or external organisation. Maybe it depends on wich server is contacted? In the firewall logs i can see outgoing smtp traffic to different ip addresses of Microsoft. Some of them do not accept the connection, some do.

Good morning everyone,

I did a few analyses yesterday.

I sent several queries via dig for smtp.office365.com via the large known European DNS servers. The result was 116 servers.

Only one of these 116 servers still supports TLS_RSA. All others only support Elliptic Curve.

Then I sent further queries via dig to DNS servers outside Europe and received 14 servers. Of these 14, 7 still support TLS_RSA.

Please add one of these servers as smtp server for testing.

Since the TTL of the IP addresses after resolution is less than 10 seconds, this also explains why about 1/4 scans work because a different mail server is addressed with each scan (DNS Round Robin).

Unfortunately, I have not found any information from Microsoft that Microsoft disables TLS_RSA on its mail servers. Moreover, Microsoft does not seem to have done this on all mail servers (or not yet).

List of servers that support TLS_RSA:

40.99.148.242

52.97.129.242

52.97.146.162

52.97.146.194

52.97.211.210

52.97.211.226

52.98.207.2

52.97.173.18

40.99.218.98

Great find but its not possible to connect to smtp.office365.com via an IP - the connection will be rejected due to how the cert is set up their side.

Just for clarification, these are DNS server options, not SMTP servers. Your smtp server should remain as smtp.office365.com

We're now facing this problem with around 150 Ricoh multifunction printers within our network.

Disabling SSL works fine, but that is not an option in our environment.

Seems that the two posters above said it was working again (2 days ago). Is anyone else still having the issue?

"Please add one of these servers as smtp server for testing." is not possible due to how Microsoft Implement Certs. Try sending an SMTP Mail via PowerShell using any IP instead of the DNS Name - it will fail.

Those IPs are also not DNS Server Options, they are Endpoints relating to SMTP.Office365.com which is in itself a CNAME.

Setting your DNS server on your device to one of those IPs is not going to fix the issue.

Yes - Still having the Issue on Networks in USA, Europe and APAC. Disabling SSL is not an option for us either. We want an official update from Microsoft on this as this was not communicated effectively and is an "under the radar" Change with massive impact.

I opened case in MS. They told me that issue is solved. Our MFP started to work two days ago.

still ssl negotiation issues with RICOH C300

Our issue started yesterday for all of our Ricoh's at 1929 UTC.

Our other SMTP devices via software on windows and linux machines is working. It is only affecting the Ricoh's at this point.

Put in a ticket for support with Microsoft, so far its the basic "here are links for setting up your smtp".

We have a mixture of Ricoh devices, some of them are really old and don't support TLS/SSL anyway. The "solution" (workaround) for us was to re-configure each device to point to an Azure load balancer with two Linux machines running postfix sitting behind it. The postfix servers authenticate with smtp.office365.com using TLS and an impersonation account, so all our devices can now securely send email regardless of if they support TLS or not.

We already had those mail servers in place for some other legacy applications anyway, so it wasn't a huge amount of work to do this.

Good luck to others finding a solution and hope Microsoft sort out their servers.

Yes, still having the problem here. It's affecting Option 2 at https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#option-2-send-mail-directly-from-your-printer-or-application-to-microsoft-365-or-office-365-direct-send (i.e Direct Send to MX record) so it's not just the smtp.office365.com cluster

I've gotten nowhere with support yet myself. We changed to authenticated smtp, and it still fails.

My vendor for our Ricoh's has reached out to ricoh and they say is not their devices causing the issue, so no firmware updates to fix it at this point.

The SSL Handshake Doesn't Actually Fail from the RICOH's either - its a misnomer:

The Server Helo Gets done, and they agree to use mutual Cipher:

Microsoft Support Struggling in our case.

Doesn't Actually seem to be a TLS issue....

Is there any official word from Microsoft regarding this change?

Microsoft took screenshots of my logs and how I have my smtp relay configured.

I also provided this subject page to them to review what findings others have had so far regarding the Ricoh - non-elliptic curves.

I'll update when I get more updates.

We have IM C300 and IM C3000 that stopped working at the same time. We are using option 3 with a send connector on port 25 to [tenantname].mail.protection.outlook.com both stopped working with the following errors.

#[dcs_nas(104)]25/02/13 10:26:52 SMTPC: failed to connect smtp server.  ERR: 
#[dcs_nas(104)]25/02/13 10:26:52 SMTPC: SSL Negotiation failed.  ERR: 

Will try the legacy option. We have an engineer visiting tomorrow to try a firmware update on the C3000 but already tried an update on the C300 with no change. :(

I tried various combinations or TLS 1.2 and 1.3 options in the Ricoh settings but no joy.Anyone resolved yet? I will try the legacy smtp option if I have time.

Anyone have a clear solutions for this yet? I've tried the legacy office smtp and that didn't work. I tried the Google app password and that didn't work. Any other final thoughts or solutions to this issue?

Microsoft reported that their security team did make a change, but have rolled it back.
Our tenant still cannot send emails that use encryption.

They had me capture packets with Wireshark and send it back to them.

They've escalated my ticket, but have not heard back in a couple of days.