The IETF appears to have had a draft to specify a null mx record whereby a domain would not handle mail and mail delivery systems would fail and return a undeliverable system immediately by directing a domain's only MX record to '.' (c/f https://datatracker.ietf.org/doc/html/draft-delany-nullmx-00)
Is this draft specification followed by most mail servers out there and worth setting up? Alternately, what's the best way to configure mail to not be delivered for a domain in the process of deprication?
As for depreciation: removing the MX record and blocking port 25 at corresponding A address for the domain is the normal thing to do...
@Hubert's solution should prevent email from being delivered.
You could also configure the email server to redirect to the new domain and send a fake bounce message indicating the new domain. This approach is discussed in the Exim documentation.
You may also want to setup an SPF record indicating the site as not sending e-mail would be an additional indication that the domain is not involved in e-mail exchange.
I like the concept of being able to specify the domain as non-email with a null MX. It would help determine if incoming mail is arriving from a bogus domain, or is being sent to a bogus domain. SPF does a good job of this but the null MX would fill in some edge cases.
I also validate incoming servers using SPF and refuse email the SPF record exists, but the server is not allowed to send email from the originating IP address. This is outside the design, but fits the requirements as the mail servers need to be able to send and receive administrative email.