Second (and even if all of the hosts are truly unreachable), there is one somewhat important service that has a markedly different failure mode if the server appears to not exist - email (smtp). Folks sending mail to a domain that doesn't resolve usually get an immediate "delivery failure" response. But those sending to a resolvable domain when the target mail server is simply unreachable get their mail queued. It will typically get retried by the mail system for a few days.
If "doesn't resolve" means "the target domain itself exists but none of the authoritative name servers for the domain respond", those mail systems doing as mentioned above should most probably be replaced, because they do not properly and reasonably distinguish between "hard" and "soft" errors when using the DNS. If "doesn't resolve" on the other hand means "the target domain does not exist in the DNS, and a reply to that effect is returned (ultimately originating from one of the name servers of the relevant parent domain)", then I agree; the mail should be bounced immediately. Quoting RFC 974 (which was the best quote I could find at the moment): Mailers are expected to do something reasonable in the face of an error. The behaviour for each type of error is not specified here, but implementors should note that different types of errors should probably be treated differently. For example, a response code of "non-existent domain" should probably cause the message to be returned to the sender as invalid, while a response code of "server failure" should probably cause the message to be retried later. Regards, - Håvard