Thanks for the replys...

> Drop the forwarders. It gains you nothing but exposure to
> vulnerabilities and external dependencies.

Dropping the forwarders made no difference..however,
I have been under the impression for many years from
training/certification and experience that it is the very much
preferred method to disable recursion on private DNS servers and
forward all queries to public ones (also under your control) to provide
the greatest security. Is that not the case?

> Try some digs to make sure you're getting the right hosts. Try dig -t mx
> @server domain on the internal and external DNS servers and compare the
> result.

Dig's/nslookups return identical information on both the private and
public DNS servers.

> If the results to the dig above are not as expected, add the external
> domains to the Win2k servers as secondaries and see if that resolves it.
> You can also try playing with the hosts file on BSD box.

There are thousands of domains hosted on the public DNS servers. This
problem is apparent for all of them. I cannot run secondaries for all
of the possible domains mail could be required to be sent to on our
private DNS servers.

Does anyone know what is causing this problem? The DNS is definately
correct. Can sendmail/bsd/bind/m$ dns just not play together? I would
rather try and fix the global issue than per box/per domain solutions,
i.e. host files or secondaries on the private servers.

All greatly appreciated as this is getting extremely frustrating.
I have tried smart host and nullclient in my config but still get host
name lookup failure. -

[root@* ~]# sendmail -v -qR

Running /var/spool/mqueue/k8L95YTf015444 (sequence 1 of 2)
<me@domain.net>... Connecting to *.domain.net. via esmtp...
<me@domain.net>... Connecting to *.domain.net. via esmtp...
<me@domain.net>... Connecting to *.domain.net. via esmtp...
<me@domain.net>... Deferred: Name server: *domain.net.: host name
lookup failure

the *'s represent the correct servers listed in domain.net's zone
records.