rfc-7505

A "Null MX" No Service Resource Record for Domains That Accept No Mail

J. Levine, M. Delany

date2015-06 streamIETF areaart wgappsawg statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc7505 doi10.17487/RFC7505

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

Extracted elements (13)

design-rationale §4.1

Null MX enables SMTP servers receiving mail with a null-MX sender domain to be more confident that DSNs for other messages will reach a recipient SMTP server, improving the reliability of bounce handling.

design-rationale §4.2

Null MX is not a replacement for the null reverse-path (RFC 5321 Section 4.5.5) and does not change the meaning or use of a null reverse-path; the two mechanisms serve different purposes.

design-rationale §3

The use of "." as a pseudo-hostname meaning "no service available" is modeled on the SRV RR (RFC 2782), where it carries the same meaning, providing consistency across DNS service discovery mechanisms.

email, dns

design-rationale §1

Without null MX, if a domain has no MX records, senders fall back to A/AAAA records and repeatedly attempt delivery for typically a week before giving up. Null MX causes all delivery attempts to fail immediately, saving sender resources and providing faster failure notification.

email, dns

interoperability-note §4.2

Operators of domains that do not send mail may also publish SPF "-all" policies (RFC 7208) as an explicit declaration that the domain sends no mail, complementing null MX publication.

email, security

normative-requirement §3 MUST NOT

A domain that advertises a null MX MUST NOT advertise any other MX RR.

email, dns

normative-requirement §4.2 SHOULD NOT

Mail systems SHOULD NOT publish a null MX record for domains they use in RFC5321.MailFrom or RFC5322.From addresses, as doing so risks having outbound mail rejected by receiving systems.

normative-requirement §4.1 SHOULD

SMTP servers that reject mail because a RFC5321.MailFrom or RFC5322.From domain has a null MX record SHOULD use a 550 reply code and a 5.7.27 enhanced status code (Sender address has null MX).

normative-requirement §4.1 SHOULD

When a submission or SMTP relay server rejects an envelope recipient due to a domain's null MX record, it SHOULD use a 556 reply code and a 5.1.10 enhanced status code (Recipient address has null MX).

protocol-element §3

A null MX record is a single MX RR with preference number 0 and a zero-length label written as ".", indicating a domain accepts no mail. Because "." is not a valid hostname, it cannot be confused with an ordinary MX record.

email, dns

registry §6

IANA added enhanced status code X.1.10 ("Recipient address has null MX", associated basic status code 556) to the SMTP Enhanced Status Codes Registry.

email, registry

registry §6

IANA added enhanced status code X.7.27 ("Sender address has null MX", associated basic status code 550) to the SMTP Enhanced Status Codes Registry, for use when a receiver rejects mail because the sender address has a null MX.

email, registry

security-consideration §5

Within the DNS, a null MX RR is an ordinary MX record and presents no new security issues. It can be secured using DNSSEC in the same manner as any other DNS record.

email, dns, security