RFC7505 Means Yes, Your Domain Can Refuse to Handle Mail. Please Leave Us a TXT If You Do.

If you do not want a domain to receive any mail, there is a way to be at last somewhat civil about it. There's a different DNS trick for that.

It used to be that if you went to the trouble of registering a domain, one of the duties that came with it was set up somewhere to receive mail.

Note: This piece is also available with trackers but nice formatting here.

A number of networking professionals, myself included, have been know to insist that not only should a valid domain receive mail, at least a significant subset of the identities listed in RFC2142 (dated May 1997) should exist and mail sent there should be read at some reasonable interval.

Then of course we all know that a number of things happened in networking in the years between 1997 and today.

As regular or returning readers of this column will be aware, one of the phenomena that rose to become a prominent irritation and possible risk factor was spam, otherwise known as unsolicited commercial email, and of course some of the unsolicited traffic carried payloads that were part of various kinds of criminal activity.

I have written fairly extensively on how to suppress spam and other malicious traffic and have fun doing so, all the while assuming that if you run a domain you will want at least some mail to have a chance of making it to an inbox that is actually read by a person or perhaps processed by your robotic underlings.

Then there is that other consideration that with the proliferation of top level domains means that organizations that own trademarks and would in the early days see the need only for .com or .net domain (the latter was in fact originally intended for organizations involved in networking) or perhaps a country domain such as a .no or .se one would tend to hoard domains in other top level domains too.

There are of course those who try to exploit trademark protection too, as we have seen in among other things my brush with a certain Chinese registrar or that time when what could only be seen as an extortion attempt a little too forcefully telemarketed landed me an otherwise white-elephant .se domain.

Now with the combination of potentially for most practical purposes redundant domains and the likely burden of handling spam for the same, it is understandable that attitudes started to shift. Finally in June 2015 RFC7505 was issued, with a simple and practical solution, dubbed the NULL MX record. The RFC explains how to set one up, though in language that is not too easy to penetrate.

For any domain that runs a mail service, there should be at least one MX record. Looking up, say, bsdly.net with dig bsdly.net mx yields a response where the answer section gives

;; ANSWER SECTION:

  bsdly.net.		300	IN	MX	1 skapet.bsdly.net.

  bsdly.net.		300	IN	MX	5 portal.nuug.no.

In your zone file, you would probably have similar lines, likely with only the MX <priority> hostname part on the actual line, the rest taken care of by the zone file it's all wrapped in.

If you want to make your domain an RFC7505-adherent one, you would remove your current MX records and replace with

MX 0 .

I did that for my little white elephant domain last week, since I did not by then remember when I last received anything sensible via that domain.

So if you run dig bsdly.se mx now, it will yield

;; ANSWER SECTION:

bsdly.se.		300	IN	MX	0 .

Which means nobody will ever see mail you attempt to send to bsdly.se. The delivery will fail immediately and produce a bounce message that likely references the RFC if your mailer is a reasonably recent version.

But while I was doing the change it struck me that it would be useful to let the world know why I did not want that domain to handle mail. Fortunately there is already an appropriate DNS record type for the purpose: the TXT record.

TXT records are used for some specific purposes such as the SPF records used to list allowed outoing SMTP senders for the domain, and a few other variants tied to specific services. But fundamentally a TXT record is simply a string of characters most applications will not actually attempt to handle. This means you have the option of fitting a message on your own in one. Now, if you do a lookup on that white elephant domain's TXT records, you will get

;; ANSWER SECTION:

bsdly.se.		300	IN	TXT	"v=spf1 -all"

bsdly.se.		300	IN	TXT	"This exists only because https://bsdly.blogspot.com/2011/07/sek-1995-for-six-months-worth-of.html happened."

bsdly.se.		300	IN	TXT	"For actual contact info please check the corresponding net domain."

Note the first TXT record here, which carries the domain's SPF specification that had been in place for a while already. It says essentially in terse if eloquent SPF speak, "This domain does not send mail".

So wrapping up, with these simple changes, quick to implement if you are in a position to edit your DNS zones we achieved:

Ridding ourselves of an entry point that produced only annoyances

Letting the world know (or at least the subset that knows how to operate common DNS tools) what the status of the mail service is and why, plus a small hint on how to make contact in case that is actually required.

A little DNS will sometimes go a long way.

A big Thank You to Security Evangelist Per Thorsheim (yes, that is his actual title) who brought RFC7505 to my attention again with this somewhat shorter blog post in Norwegian (also in English here).

Update 2021-02-23: After gentle prodding in this tweet (via JP Mens)

I would add a dmarc with p=reject too
— Simon (@sa7sse) February 23, 2021

-- also preserved as a screenshot -

I added a dmarc record for the domain too (kind of overkill, but can't hurt I suppose).