As of today, Negotiate/Kerberos with SmtpClient is broken (#105938). This was fixed in #105939 which I can confirm resolves the problem. However, there is no remedy that is available for .NET 8 / LTS for this regression. Third party mail libraries do not yet support Negotiate with SMTP.

Quoting @kedia990 from #105939:
This is a clear regression vs. .NET Framework. Sending authenticated mail using Negotiate works in Framework, and it did not in Core until this patched was implemented. This was verified against both stock Microsoft Exchange, as well as Postfix, using .NET 9 RC 1. So it's not SMTP server dependent either, at least in any way that we can tell.

As to why it's a problem for us and nobody else - I can only speculate. Maybe authenticated mail (at least using Negotiate) isn't being used by a lot of folks out there. Maybe enterprises that have that kind of code are still on Framework. Or maybe they're using MailKit with .NET Core (based on Microsoft's recommendation) and therefore haven't run into SmtpClient-specific limitations. (To be clear, we would have followed that recommendation and used MailKit too, except it doesn't support Kerberos yet for authenticated email.)

That said, it's not clear that that should matter - this PR fixes the regression from Framework, and more importantly, a regression that forces us into an insecure posture. .NET 8 is the LTS release which the overwhelming majority of our applications are on and we intend to stick to that for mission-critical apps due to lifecycle reasons. Those are also the areas where we require authenticated mail for security policy reasons. So as far as this capability is concerned, we're currently at a disadvantage because we migrated from Framework to Core.

If you have suggestions for any workaround that would allow us to use Negotiate for authentication with SmtpClient in .NET 8 without backporting this, we're listening. And if you have a compelling argument for why it would be unsafe to backport this, we'd like to understand that as well. But absent either, I'd respectfully contend that this should be backported into .NET 8 as the active LTS release.