10

I'm thinking that there's absolutely no reason or justification for this, but before I open my mouth and get some admin in deep kimchi, I thought I should ask.

Is there any circumstance in which an MX record should point to a loopback address? To me, this says any mail server that tries to send to this domain will instead send to themselves, and fail, but I'm not a mail guru, so maybe I'm missing something.

I came across the below when troubleshooting a why-aren't-we-getting-email?? issue for a client, and I'm having trouble wrapping my head around it. Maybe I'm overthinking things, though.

enter image description here

Improve this question
6
  • 7
    This is basically saying, don't send mail to us... talk to the hand
    – Mike Pennington
    Aug 3, 2012 at 15:48
  • @MikePennington If you wanted to not get email form anyone, why would you do this instead of, say, removing your MX record?
    – HopelessN00b
    Aug 3, 2012 at 15:56
  • 5
    if you remove the MX record, mail is sent to the A record for the domain portion of the email address. with no MX record, you get a bunch of people knocking on your door looking for a mail server that isn't answering. with a loopback address, the sender knocks on their own door and doesn't waste your bandwidth.
    – longneck
    Aug 3, 2012 at 16:33
  • @longneck That's the end result, but it's probably not the best way to go about it. IMHO polluting the public DNS is a pretty dick move to get rid of spammers who would only cost you a few bytes for an RST packet if you're not running a mail server...
    – voretaq7
    Aug 3, 2012 at 17:44
  • i didn't say it was a good idea. i was just explaining what happens when you remove your MX record, and how removing the MX records does not replicate the configuration asked about.
    – longneck
    Aug 3, 2012 at 17:57

6 Answers 6

Reset to default
4

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.

Improve this answer
1
  • It's an ugly practice but not a violation of RFC 3330 or RFC 1700. The restrictions there have nothing to do with hostnames. Those standards only prohibit letting an IP packet having a 127.0.0.0/8 address in the source or destination field escape the host. For example, ping 127.0.0.1 should never, ever cause an ICMP packet to be seen by any other host on the LAN.
    – MetaEd
    May 21, 2022 at 15:18
10

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.

Improve this answer
4
  • 1
    +1 - The is NO good reason to EVER set a public DNS record to an address in 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/8... (As with all internet "rules" you can of course ignore it, but you do so at your own peril, and should only do so with full knowledge of what you're doing and why...)
    – voretaq7
    Aug 3, 2012 at 17:41
  • @voretaq7 warez IN A 127.0.0.1
    – Michael Hampton
    May 18, 2013 at 0:44
  • @MichaelHampton served from public, world-facing DNS? I'm pretty sure theres something in the RFCs that says doing so is the equivalent of drowning kittens...
    – voretaq7
    May 19, 2013 at 2:01
  • @voretaq7 Yes, I've seen that, and in many places. It dates back at least to the 1990s. The way it was used was: someone would ask where to find warez, and be given the address warez.example.com which has this particular record...
    – Michael Hampton
    May 19, 2013 at 2:03
6

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.

Improve this answer
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.

Improve this answer
1
  • That is partially correct, localhost is not valid. The RFC state: "To indicate that a domain does not accept email, it advertises a single MX RR [...] 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."
    – Cyrbil
    Feb 13, 2023 at 12:58
3

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.

Improve this answer
-1

Why not use a MX target that doesn't resolve to anything? E.g.:

example.com. IN MX 10 something.invalid.

Spammers will see the resolution error and not bother with the next MX record, thinking the target is misconfigured. Real servers will try the next record. This won't bother anyone's closed TCP port 25 - i.e. no smtp traffic, only DNS.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .