A registered DNS entry resolves on the internet. We seem to be having an internal network issue. I imagine 192.168.x.x has a private use entry internet wide (e.g. on Cox Communications). Your question of how this started happening in a stable system is a good one. A backup restoration should solve it. Perhaps an external file was changed. Updates also have odd results, although not usually in critical network files. This usually becomes apparent after a solution is found.

The OP hasn't supplied hostnames. If the domain is hostname.ohprs.org, and hosts are resolved in the server, it should work. I don't see a way to resolve 192.168.0.x addresses at the moment. That's why I suggested the hosts file.

It's now working. I added 192.168.0.5 (sending) to 192.168.0.3's (receiving) /etc/hosts file, then restarted sendmail on both 192.1680.3 and 192.168.0.5. All of the pending undelivered email then got delivered with no "does not resolve" log messages thereafter. I then removed the hosts entry from 192.168.0.3 and restarted sendmail on 192.168.0.3 to see if that made any difference. So far (a day later) mail continues to be delivered sent from 192.168.0.5.

I'm not entirely sure what made the difference. Perhaps restarting sendmail on one or both hosts. Host 192.168.0.5 was rebooted a few days before the OP in this thread, so I would think that would constitute a fresh restart of sendmail on that host. 192.168.0.3 was rebooted only 9 days ago. A mystery, but it's now working. Perhaps one or both sendmail restarts did the trick.

I still can't do 'dig @192.168.0.3 hostname', but that's another problem I'll deal with later in a different thread.

Thanks for all the feedback!