As far as I'm aware Exchange already checks for address validity. It's a tricky thing to check as although RFC2822[^] lists the valid characters, in practice some email systems do not conform to this specification and permit characters not permitted in RFC2822. If a user specifies an address that is not a valid domain (right-hand side of @), Exchange (if configured for direct delivery) will be unable to resolve the MX records in DNS for that domain, and will abandon the message with a non-delivery report [NDR] (a type of delivery status notification [DSN]). If a user specifies an invalid local-part (left-hand side of @), the receiving server will abandon the message with its own NDR. If the return address is invalid or incorrect, Exchange will abandon sending the NDR. If it detects that it would be trying to send an NDR for an NDR in response to a message that it originated (detecting its own address in the Received headers), it will not send the NDR. If you're configured to use a Smart Host, Exchange will pass outgoing messages directly onto the smart host rather than checking the domain part. If the domain part is invalid the smart host will generate an NDR. By default Exchange attaches the whole of the original message to the NDR when it is generated. We have had a problem with our upstream ISP blocking access to their SMTP server (we use a Smart Host configuration) due to a large amount of viral content originating from our server. Investigation showed that this was incoming viral content that couldn't be delivered to a user on our server (invalid destination address), and therefore was attached to the NDRs. I've now limited the maximum size of any DSN to strip off any attachments, which saves bandwidth. To do this, see XCON: Option to Strip Attachments for Messages That Generate an NDR[^]. You must spell the registry keys exactly as written - even if you think it's misspelled! This originally caught me out. To check your Exchange setup for errors, download the Exchange Best Practices Analyzer Tool