Skip to main content

Please log into UltraDNS for full Help Center and Community access

NULL MX Records

Completed
Mike Vevea
Edited

I'll start with a quick reminder of what MX records are, and why they exist.  MX records are a mechanism that allows specifying where to send mail for a particular domain. The rdata part of the record (the actual data part) has 2 fields, first a numeric priority, then the name of a server. To provide redundancy, it is possible to have multiple MX records for a domain, often with different priorities. For an example, isc.org (a company that does a lot of DNS work, including providing the "dig" utility) has two MX records:

dig MX isc.org.

returns:

isc.org.        300    IN    MX    5 mx.pao1.isc.org.
isc.org.        300    IN    MX    10 mx.ams1.isc.org.

which says "to send mail to isc.org. addresses, try the mail server called mx.pao1.isc.org.; if it doesn't work, try mx.ams1.isc.org.  (The first, numeric, field in the data is a priority (numerically lower values are the preferred servers). The second field is the name of the server.)

It's also possible to use a single MX record, but still provide redundancy, by having multiple A or AAAA records for the server's name (and of course, having and configuring all of those servers…). For example, vercara.com. has a single MX record:

dig mx vercara.com.

returns:

vercara.com.  3600  IN   MX  0 vercara-com.mail.protection.outlook.com.

which says “send mail for vercara.com to vercara-com.mail.protection.outlook.com.” Vercara only has a single MX for vercara.com, but if you look at the server name:

dig vercara-com.mail.protection.outlook.com

you'll find that it returns an RRSET with 7 different A records, so mail to vercara.com can be sent to any of the listed addresses; if one fails, the server trying to send mail can try another. 

Nothing requires redundancy, so it's also possible to use a single MX record and have only a single server address associated with it…but that means that if your mail server goes down, incoming mail is broken!

Finally, if a domain doesn't have any MX record, mail servers will try to send mail to the server(s) with A or AAAA records that match the domain name. So if there's no MX record for "mydomain.com", but "mydomain.com" has an A record, mail servers will try to send mail for the domain to the address in the A record. That means that simply omitting an MX record does NOT mean "no mail for this domain".

With all the flexibility of MX records, they historically lacked one important capability: they didn't allow saying "NEVER send email to somedomain.com". Relatively recently, at least at the rate that DNS standards evolve, RFC 7505 defined a modification to give a way to specify "no mail to this domain", called a "NULL MX record" If you want to read the specification (which is "standards track", though not yet fully standardized), you can see it at:

https://datatracker.ietf.org/doc/htiml/rfc7505

As that describes, a NULL MX record can be configured, and it means "no mail should be sent to this domain". A NULL MX record is just a single MX record (there can't be other MX records for the domain), with priority 0 and with the "Goes To" part just a single dot. In the UltraDNS portal, creating a NULL MX Record is as easy as opening the zone, expanding the MX section, checking to be sure that there aren't already MX records for the domain, clicking the "NULL MX" box and saving the record. 

To let you see a NULL MX record, I've configured a domain called “nullmxtest.mvevea.us”, which just has the bare minimum (an SOA and NS records) plus a NULL MX. You can look at the MX record for the domain with:

dig mx nullmxtest.mvevea.us.

which returns the answer:

nullmxtest.mvevea.us.    86400    IN    MX    0 .

To reiterate, a NULL MX Record:

  • must be the only MX record for the domain
  • must have priority 0
  • must have the “Goes To” field set to a single dot

That odd combination was selected because it would never actually work (the single dot isn't actually a valid host name, so there can never be a mail server with the name ".") In theory, it would be possible to enter the values (priority 0, and "Goes To" just a period), but in practice the UltraDNS portal requires you to create the NULL MX record by checking the "Null MX Record" box and telling it to save the record (this allows the portal to validate that there are no conflicting MX records, etc.)


Why would you want a NULL MX record? Many organizations have a number of subdomains, but don't want mail "from" them, or sent to them. For example, you might have several subdomains under "mydomain.com", such as "development.mydomain.com", “netengineering.mydomain.com”, etc., which shouldn't send or receive email (that is, all mail from anyone in or below "mydomain.com" should come from “mydomain.com” and incoming mail should all go to the main mail server for “mydomain.com”, so using NULL MX records in subdomains is useful.)

Note that the NULL MX technically just prevents remote mail servers from sending mail to addresses in the domain, so some servers might accept mail from it. To block that, you could use an SPF record that says that no mail should be accepted from the domain. (SPF records are beyond the scope of this article, though!)


Despite saying that lit might be possible to send mail from a domain with a NULL MX record, it's worth noting that many mail servers do not accept mail unless there's a way to respond; a NULL MX doesn't count as a way to respond, so the RFC that defines NULL MX Records says:

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.

In other words, "If you have a NULL MX record for a domain, you shouldn't send mail from that domain, because it's likely to be rejected!" (But it would be good security practice to add an SPF saying to reject all mail from the domain.)