Completely replaced all old servers (running Server 2003 and Exchange 2003) and replaced them with Server 2012R2 and Exchange 2013.
Completely rebuilt existing network infrastructure and moved from a /24 to a /16 network.

We have a vendor that was having similar issues when sending us mail, with the same error.. If you are receiving mail from Spiceworks and other outside sources, it shouldn't be a problem with your receive connector. But, the whole "client wasn't authenticated" bit would indicate the anonymous user box isn't checked... very strange. Try just safelisting that email address and see what it does.

Has anything recently changed within the last month, upgrade to 2010 which changed your MX record or anything? I have seen where changes to the MX record go through fine but whatever service the other side is using never updated their side of the MX record thus it is pointing to the old when they try to send to you and thus getting denied since it doesn't really exist.

The only thing that has changed was we began decommissioning our transport server. It is still active and mail can pass through it but everything has been going directly to our exchange server. The old MX records are still active and all that was changed was the Exchange server went from priority 20 to 10 and the transport server went from 10 to 20. No other changes have been made. Like I said before, we get mail just fine (around 4,000/hr) but they are getting the error.

I would be curious to see if it's consistent with multiple users from their side sending to your side. Are they trying to email a group? Have them type in the name without letting an autocomplete try to finish it. Have someone from IT (yeah I know good luck) do a telnet to your server, if it passes by doing a direct telnet then I would say it's something from when they send the mail and whoever they are using to continue the passage.

There are some logs you can enable specifically for diagnosing SMTP between domains if it comes to that.

I'm looking at the NDR and the MX Toolbox and while you clearly obfuscated your IPs your the first 2 octets of the server claiming to be reporting the rejection in the NDR (208.95.555.555) and what you tested with MX Toolbox aren't the same (64.20.555.555.) is the IP in the NDR actually your server?

What are your own SMTP logs showing for the rejection?

If you don't see the connection at all might the remote side have a misconfiguration and a connector/relay on their side might be requiring authentication when it shouldn't be?

The 64.20.555.555 probably did not need to be obfuscated as it was the IP of the MX Toolbox server that connected to our server. If you notice in my attachment, when I did it from my desktop, it showed my computers IP in that same spot.