Under what circumstances (if any) should an MX record point to localhost?
Solution 1:
Short answer: It shouldn't.
Long answer: If the domain in question (DIQ) should not receive email, then putting a loopback address in for the MX record causes the sending server to attempt to connect to itself. This saves the DIQ a few measley bytes and possibly cleans up the firewall logs (if anyone is even watching) when other mail servers attempt to connect. However, in my opinion, the bandwidth savings is not enough to justify violating RFC 3330.
Solution 2:
Definitely a NO, not with a 127.0.0.0 IP.The entire 127.0.0.0 range on IPv4 works as loopback addresses, thus when any machine connects to IPs in that range it will try to connect to itself.
Your MX record IP address should be accessible from the outside world and what that result is telling any server doing a MX query, to try to connect to itself.
If my server was trying to send you email, it would lookup the MX record and then connect its own IP address, send the email and fail.
Solution 3:
The relevant RFCs say:
-
The MX resource record MUST point to a fully qualified domain name (not an IP address) of a server on the public Internet which accepts mail for the domain. Note that this server does not necessarily have to be in the same domain as the MX record. RFC 1035 section 3.3.9
-
Addresses in the 127.0.0.0/8 range MUST NOT ever appear on the public Internet. RFC 5735 section 3
Note that some mail servers will reject email from senders not in compliance with the relevant RFCs.
Solution 4:
When a host must be able to send mail to itself across different hosted domains but does not accept external mail, "MX 0 localhost." is acceptable. To indicate that a host has no mail server whatsoever, use "MX 0 ."
The "MX 0 ." is detailed in RFC7505.
Solution 5:
Well, I have a situation where setting a domain's MX to localhost appears to be necessary.
In March of 2012 I registered a cute domain that I was surprised to find available. It was for an artistic collaboration site my daughter wanted to set up. I set the MX to one of my other smtp servers. This worked well, but then I started to get lots of "unknown user" mail bounces to [email protected] (not the real domain name). So I used MailScanner to block all incoming messages to that domain except for one legitimate address. It seems that the domain was a free email service starting in 2001 but had apparently gone dark and gave up their cute domain name.
This worked well until a couple of days ago (11/20/12) when the smtp server started to reject incoming messages due to excessive open connections. These were smtp processes waiting for "receipt to" responses, I think. I looked at the traffic and I was getting bombarded by thousands of incoming messages for [email protected] from just as many smtp relays all over the world. (17,000 messages in one 24-hour period)
So I changed the MX to point to another server not running smtp with port 25 blocked. Sure enough, thousands of dropped sessions started showing up. Since this behavior looks like some sort of a spam torrent, maybe from a botnet, I figured that setting the MX to localhost might be called for.
I'll leave it like this for a while. We don't need email at all for the cute.domain.com, so nothing is lost except cycles for the botnet.