This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
getting these two error messages when sending to yahoo
1/11/2024 3:34:15 PM - Server at DS0PR14MB7526.namprd14.prod.outlook.com returned '550 5.4.300 Message expired -> 421 4.4.2 Connection dropped due to SocketError'
1/11/2024 3:24:36 PM - Server at PH0PR14MB6715.namprd14.prod.outlook.com returned '550 5.4.300 Message expired -> 421 4.4.2 Connection dropped due to ConnectionReset'
Using Classic Outlook on Windows for personal email, calendar, and contact management
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
After reading replies from some others here it triggered a vague memory of something I read recently. I did a little digging and found it:
Microsoft & Yahoo did in fact announce new email authentication requirements to be effective FEBRUARY 2024. Looks like somebody jumped the gun a bit.
S**t! One of the changes we made to my account involved the SPF record, and now it's fixed. We also made changes to the DMARC records.
I like your theory of an enforcement change at Yahoo. Even so, refusing the socket hardly seems like the correct response to an SPF failure.
Agreed that the response seems incorrect. I suppose they are more interested in foiling spoofers, so dropping the socket connection is the easiest thing to do. Not that I agree with it, just that it makes sense.
we got the problem resolved. Microsoft had us update the SPF, DKIMand DMARC
S**t! One of the changes we made to my account involved the SPF record, and now it's fixed. We also made changes to the DMARC records.
I like your theory of an enforcement change at Yahoo. Even so, refusing the socket hardly seems like the correct response to an SPF failure.
I might have got this fixed. I found a second SPF record in DNS -- that's Sender Policy Framework, not Sun Protection Factor :-)
There must be only one. In my case the first record was created about 10 years ago when we used a different service. That was abandoned about 5 years ago but nobody thought or new to remove the old record when they created the one for Microsoft 365. My guess is that Yahoo has made a change to more strictly enforce SPF. If you have more than one SPF record then the check will fail and your messages will bounce.