You have to look at the what before the why.
The what is how email flows. User transfers a mail from his client to the mail server. Mail server first accepts the transfer and then responds with a completed transfer. Client shifts the message from outbox to sent item.
Mail server relays message to another mail server based on header info. Next mail server first accepts message and then responds with a completed transfer. If this mail server instead rejects the message, the rejection message is used to respond to the original client with a failed delivery message.
The next mail server sends the message to either another mail server or a client. The next point accepts the message and responds with a completed transter, or rejects the message. At this point there is no requirement for the interim server to pass the rejection message back.
This can go for any number of interim servers. At these transfer points, a message that fails to complete transfer or that does not get the completed transfer message within a set time frame will resend the message (this is why recipients will sometimes get multiple copies of an email sent once).
The final server or the client may receive the message and then decide based on filters that it does not want it. It can then auto compose a response (new message) back to sender based on header or simply delete the message before the user sees it. This is why the sobig.f virus results in users receiving messages about sending viruses to recipients who are not even in the recipient's address book - the virus spoofed the sender address when it sent the email with a copy of itself.
Now why did the message fail to reach the recipient? DNS is one possibility at any interim server, and except for the first server the user sent it to this will not necessarily result in an error message back. Other problems include circuit outages, server failure after receipt, and a filter at the final server or recipient.
