There are situations in which domains should never legitimately be used to originate email. One example might be domain or host names that simply aren’t used for email at all: web-only domains, administrative host names (such as ssh.example.com), and so on.
Note that this does not necessarily apply to domains which need to either send or receive email (just not both), nor, obviously, domains that are used for two-way email traffic. Some of it may apply, but the thrust of this is about DNS names that are never used for either.
For domains that truly should never originate email, there are a few relatively trivial things that a domain owner can do to indicate this to mail servers elsewhere on the Internet. All of the techniques listed here requires control over the domain’s DNS records, and especially when used together can significantly reduce the risk of that domain being used as an origin address for spam resulting in loss of trust or backscatter bounces.
All of these are also trivial to reverse, should you later on change your mind and decide that the domain in question really should be used for email.
Publish a null MX
RFC 7505 defines a “null MX” resource record. Whereas a domain name with no MX (mail exchanger) resource record (RR) in DNS can still both send and receive mail, publishing a null MX RR explicitly states that this domain does not accept (receive) mail.
In part because this also precludes even the possibility of sending a bounce, many mail servers take it as a strong signal to not accept any mail from that domain. This behavior is even spelled out in the standard, using “SHOULD NOT” language about publishing a null MX record for domains that originate email.
To publish a null MX, publish only one single MX record to the domain or host name in question, with priority 0 and a zero-length MX hostname (often expressed as .). In BIND DNS master file syntax, this becomes something very similar to:
@ IN MX 0 .
Publish a deny-all SPF policy
Sender Policy Framework (SPF) is a way for domain owners to specify which hosts are allowed to use a domain name in the envelope sender, which is used during the SMTP exchange and typically for such purposes as sending bounces. The current SPF standard is RFC 7208 with updates, and covers primarily the SMTP HELO/EHLO and MAIL FROM (envelope sender) commands. It can also be used as a spam scoring signal with the user-visible sender address, which can differ from the envelope sender address, although DMARC (see below) is specifically designed for use with the user-visible sender address.
A SPF record is technically a DNS TXT (text) type resource record on the host name that would be used as the envelope sender address domain part or the HELO/EHLO host name.
There can be only one SPF TXT record on a single host name; having more than one is an error and can lead to unpredictable or undesirable behavior, especially if they are in conflict. The contents of this record starts with v=spf1 (the whitespace is important) to identify it as a SPF version 1 record, and continues to list authorization terms (which the standard refers to as “mechanisms”).
SPF includes a term all which “always matches”, regardless of where the SMTP connection is coming from. Each term is optionally preceded by a qualifier; the qualifier - means “fail”. Thus, an authorization term -all means “always fail”. If this is the only authorization term published, then SPF will indicate that email is not allowed to use this domain as the domain part of the envelope sender from any host.
Again in BIND DNS master file syntax:
@ IN TXT "v=spf1 -all"
Publish a deny-all DMARC policy
Whereas SPF is designed for use on the SMTP-level domain and host names, DMARC (RFC 7489 with updates) uses the user-visible (RFC 5322) sender address. It is designed to prevent phishing in the form of making an email appear to come from an address that the sender is not authorized to use as a user-visible sender address.
DMARC is potentially more complex than SPF, but in its simplest form, a deny-all policy must include only the DMARC version and a simple policy. DMARC also supports for example applying a policy to only a subset sampling of traffic, or applying a different policy to subdomains.
The definition of the DMARC TXT record is given primarily in the RFC’s sections 6.1 and 6.3. Unlike SPF, it uses a dedicated record under the domain name in question, _dmarc. Therefore, for example, the policy for a user-visible sender address of some.one@email.example.com is found at _dmarc.email.example.com.
Again in BIND DNS master file syntax, and assuming that the zone origin is set correctly (in other words, that @ would map to the user-visible sender address domain name of interest):
_dmarc IN TXT "v=DMARC1;p=reject;"
In summary
You can indicate that a domain name will never legitimately originate emails, and that any emails that claim to originate from it should be rejected, by publishing the following three DNS records at the domain name in question:
@ IN MX 0 .
@ IN TXT "v=spf1 -all"
_dmarc IN TXT "v=DMARC1;p=reject;"
Given this, most modern mail servers on the Internet should reject email claiming to come from this domain outright, regardless of its origin on the network.
Should you later change your mind, then simply delete or update the above records as appropriate and wait for any DNS caching to expire.