Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 7505 Taughannock Networks
Category: Standards Track M. Delany
ISSN: 2070-1721 Apple Inc.
June 2015
A "Null MX" No Service Resource Record for Domains That Accept No Mail
Levine & Delany Standards Track [Page 1]
RFC 7505 Null MX June 2015
Table of Contents
1. Introduction
This document defines the No Service MX, informally called "null MX", as a simple mechanism by which a domain can indicate that it does not accept email.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms "RFC5321.MailFrom" and "RFC5322.From" are used as defined in [RFC5598].
Levine & Delany Standards Track [Page 2]
RFC 7505 Null MX June 2015 3. MX Resource Records Specifying Null MXTo indicate that a domain does not accept email, it advertises a single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section consisting of preference number 0 and a zero-length label, written in master files as ".", as the exchange domain, to denote that there exists no mail exchanger for a domain. Since "." is not a valid host name, a null MX record cannot be confused with an ordinary MX record. The use of "." as a pseudo-hostname meaning no service available is modeled on the SRV RR [RFC2782] where it has a similar meaning.
4. Effects of Null MX
The null MX record has a variety of efficiency and usability benefits.
4.1. SMTP Server Benefits
Mail often has an incorrect address due to user error, where the address was mistranscribed or misunderstood, for example, to alice@www.example.com, alice@example.org, or alice@examp1e.com rather than alice@example.com. Null MX allows a mail system to report the delivery failure when the user sends the message, rather than hours or days later.
Levine & Delany Standards Track [Page 3]
RFC 7505 Null MX June 2015
SMTP servers that reject mail because a RFC5321.MailFrom or RFC5322.From domain has a null MX record SHOULD use a 550 reply code (Requested action not taken: mailbox unavailable) and a 5.7.27 enhanced status code (Permanent failure: Sender address has null MX).
4.2. Sending Mail from Domains That Publish Null MX
Null MX is primarily intended for domains that do not send or receive any mail, but have mail sent to them anyway due to mistakes or malice. Many receiving systems reject mail that has an invalid return address. Return addresses are needed to allow the sender to handle message delivery errors. An invalid return address often signals that the message is spam. Hence, mail systems SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses. If a system nonetheless does so, it risks having its mail rejected.
5. Security Considerations
Within the DNS, a null MX RR is an ordinary MX record and presents no new security issues. If desired, it can be secured in the same manner as any other DNS record using DNSSEC.
Levine & Delany Standards Track [Page 4]
RFC 7505 Null MX June 2015 6. IANA ConsiderationsIANA has added the following entries to the "Enumerated Status Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry".
7. References 7.1. Normative References[RFC1035] Mockapetris, P., "Domain names - implementation and
Levine & Delany Standards Track [Page 5]
RFC 7505 Null MX June 2015 7.2. Informative References[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
