RFC 5321 explains in detail how sending and receiving emails works.
Two important things in it I'll mention here
1) Mail that can't be delivered for whatever (temporary) reason MUST be queued and retried at a later time. Here the citation
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. It MAY
be appropriate to set a shorter maximum number of retries for non-
delivery notifications and equivalent error messages than for
standard messages. The parameters to the retry algorithm MUST be
configurable.
2) Mail that can't be delivered at all MUST be indicated to the sender. Here the citation:
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path).
So if all mail servers act accordingly to the standard there will be no mail loss at all. But it is said that there are some few mail servers that don't follow the rules. In this case it shouldn't be your responsibility to accept their mails in all cases only because they have crappy servers.
I would recommend to have a "cold-standby" mail server which you boot up only in case of a long Exchange down-time.