99

I understand you should not point a MX record at an IP address directly, but should instead point it to an A record, which, in turns, points to the IP address of your mail server.

But, in principle, why is this required?

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
dayuloli
  • 1,223
  • 1
  • 10
  • 18
  • If you can set up an MX record you can also set up an A record. I don't see the problem here. – joshudson Jan 30 '15 at 16:15
  • 30
    @joshudson It's not a problem at all, just me trying to understand why rather than simply follow what everyone else does. – dayuloli Jan 30 '15 at 16:16
  • I just tried in CloudFlare. It doesn't accept IP address as a value for MX record. – LinuxBabe Aug 13 '17 at 08:02
  • I had never cared about this until I added an SPF record, and had too many lookups. Had to find a different way to cut some out. – gbryant Feb 06 '19 at 22:29

6 Answers6

97

The whole idea behind the MX record is to specify a host or hosts which can accept mail for a domain. As specified in RFC 1035, the MX record contains a domain name. It must therefore point to a host which itself can be resolved in the DNS. An IP address could not be used as it would be interpreted as an unqualified domain name, which cannot be resolved.

The reasons for this in the 1980s, when the specs were originally written, are almost the same as the reasons for it today: A host may be connected to multiple networks and use multiple protocols.

Back in the 80s, it was not uncommon to have mail gateways which connected both to the (relatively new) Internet which used TCP/IP and to other legacy networks, which often used other protocols. Specifying MX in this way allowed for DNS records which could identify how to reach such a host on a network other than the Internet, such as Chaosnet. In practice, though, this almost never happened; virtually everyone re-engineered their networks to become part of the Internet instead.

Today, the situation is that a host may be reached by multiple protocols (IPv4 and IPv6) and by multiple IP addresses in each protocol. A single MX record can't possibly list more than one address, so the only option is to point to a host, where all of that host's addresses can then be looked up. (As a performance optimization, the DNS server will send along the address records for the host in the response additional section if it has authoritative records for them, saving a round trip.)

There is also the situation that arises when your mail exchangers are provided by a third party (e.g. Google Apps or Office 365). You point your MX records to their hostnames, but it may occur that the service provider needs to change the mail servers' IP addresses. Since you have pointed to a host, the service provider can do this transparently and you don't have to make any changes to your records.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 3
    That's not really preventing compatibility with IP addresses; in fact, most SMTP servers/clients work just fine with IP addresses in MX records from the little testing I've done. I think the intention was to discourage the industry from using IP addresses en masse--which is likely what would have happened, had that rule not been stated--rather than on a case-by-case basis. Hence, "should", as opposed to "must". +1 for the great info, though. I had never considered most of that. – Zenexer Jan 29 '15 at 02:50
  • 16
    @Zenexer Traffic laws aren't there for the inconvenience of relatively few expert drivers who know exactly what's safe and what isn't. They exist because of the much larger subset of fucking idiots who *think* they know what they're doing but don't. – Shadur Jan 29 '15 at 09:59
  • 7
    @Zenexer You may find that a particular MTA tolerates it today, and doesn't tomorrow. It is, after all, not behavior permitted by the standard. And of course, not all MTAs will support it, so doing this means you are guaranteed to lose mail. – Michael Hampton Jan 29 '15 at 14:30
  • 1
    @MichaelHampton: If an MX record _SHOULD_ contain a host name instead of an IP address, then an MTA _MUST_ accept an IP address. Hypothetically, if an MX record _MUST_ contain a host name then an MTA _SHOULD_ accept an IP address. That's how RFC's work. The counterparty to a "SHOULD" implementation advice may optimize on the assumption the advice is followed, but that's pretty much all you can do with it. – MSalters Feb 02 '15 at 10:05
  • 2
    @MSalters I think you are confused. I never said SHOULD anything. Indeed, I said that the MX record MUST contain a hostname, which is also what the RFCs say. – Michael Hampton Feb 02 '15 at 15:20
  • @MichaelHampton: I MUST have misunderstood your response to Zenexer ;) – MSalters Feb 02 '15 at 15:25
  • 2
    Actually, that was my fault; I was under the impression that it was a SHOULD-do, not a MUST-do. In that case, even @Shadur's awesome metaphor doesn't quite fit. – Zenexer Feb 04 '15 at 21:22
22

DNS as a protocol has some different types of values, these are not interchangable.

It's important to note that DNS is a binary protocol with strict mappings between the type of record and the type of data that such a record holds.

For example:
An A record holds an IPv4 address (4 bytes of data, fixed length).
An AAAArecord holds an IPv6 address (16 bytes of data, fixed length).

An MX record, on the other hand, holds a name (a sequence of labels on the format <int number of bytes> <label> <int number of bytes> <label> <int 0>, variable length).

It's not possible for an MX record to have an IP address as its data.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • You could make the label the textual representation of an IP address, but it wouldn't make any sense to do so, since it can't be resolved as a hostname. – Michael Hampton Jan 28 '15 at 18:13
  • @MichaelHampton Indeed, it's possible to have a name with all-numerical labels that in the normal human-friendly representation looks like an IPv4 address at first glance. That doesn't really change anything when it comes to the question, though, as it would still be a name and thus will be handled like a name (a name that, at least on the public Internet, will just be `NXDOMAIN`). – Håkan Lindqvist Jan 28 '15 at 18:29
  • This does not really answer the OP's question. You basically say *"because that's the way it is"*. – dr_ Sep 28 '16 at 10:38
  • 1
    @dr01 Considering that the question clearly demonstrates being unaware of "the way it is" ("you should not point a MX record at an IP address directly, but should instead point it to an A record" when it's in fact not a possibility to have any other value than a name), I don't think it's out of place to point out the way things are and why that makes any other option impossible. I get the feeling that you are reading a lot into the question that isn't actually there. – Håkan Lindqvist Sep 28 '16 at 16:11
  • 1
    @dr01 Ie, don't think the question reads as an academic question about the design decisions in the early days of DNS or anything like that but simply a question about how the `MX` records that actually exist in the world can or should be used. – Håkan Lindqvist Sep 28 '16 at 16:20
6

I'll throw this out as a guess. Course, I'm home with the flu so maybe I'm loopy.

RFC 974 states:

The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases.

By requiring a name instead of IP, it forcefully encourages this practice. Names can stay the same, and in the event of load balancing or DR you won't have to be concerned about changing the MX record itself and waiting for DNS propagation.

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • 8
    Answering stack exchange questions on your day off while you're sick with the flu... I tip my hat to you, good sir! – Mike B Jan 28 '15 at 19:45
3

Some email servers (like exim) specifically do not allow sending to MX records that point to a pure IP address, so you're required to use a FQDN for it instead to be compliant. This is because most servers expect the MX record to contain a hostname, not an IP (that's what A records are for).

Edit: To elaborate, in DNS each record has strict requirements for the type of data each record can hold. In the case of MX records, it's a hostname only.

Nathan C
  • 14,901
  • 4
  • 42
  • 62
  • So why did exim not allow MX records point to IP address in the first place? Seems odd to me! I understand I ***shouldn't*** because of convention, but I don't understand ***why*** it is made ***illegal***. – dayuloli Jan 28 '15 at 17:31
  • 1
    I don't see how any MTA could support this as an `MX` record cannot possibly have an IP address as its value. – Håkan Lindqvist Jan 28 '15 at 17:36
  • @HåkanLindqvist Your answer above clarified this point for me! Thank you! – dayuloli Jan 28 '15 at 17:38
2

IN RFC 1025 MX records only point to a RR (resource record) of an A Record or a CNAME.

So the mail server sending the mail asks for the RR of an MX record, the mx record lists A records of servers, the mail server does a forward lookup to get an A record and then forwards the mail via smtp to the service host listed as a mail server 'willing' to receive mail for that domain.

Your Question - Why Can't Mail Get Sent to an IP Address

Response - Because of Trust

Many of the rules in place regarding mail have evolved in order to maintain trust between domains that the messages sent back and forth are actually valid. All of this is to ultimately reduce SPAM.

  • Reverse IP Lookups
  • A Forward Name lookup for that matter

All of these essential components for a foundation to build a mail server on have at least some small component founded in creating trustworthy communications and reducing untrusted communication.

Reference - RFC 1035 and 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt

Community
  • 1
Citizen
  • 1,103
  • 1
  • 10
  • 19
2

The purpose of MXrecords is that an application (mail transfer) can learn about the host to be used. On application level, host names are the right thing to use (not IP addresss).

Also, adding the conceot of variant type record to DNS introduces a leverl of complication and hence an entry point for problems, implementation mishaps, security challenges. For example, 1.2.3.4.example.com. is a valid hostname (yes, it is, even in the light of RFC1034, 3.5). Specifying this host as MX in a bind configuration file for example.com might look like

.  MX 10  1.2.3.4

and presumably that is precisely the same an MX record with an IP should look like. And even to transfer the informatoin in a DNS datagram requires some quirky additoins; the simplest way would be to introduce a new resource record type, MXA say, for disambiguation. But then again, why introduce the burden such a new record type when 

. MXA 10 5.6.7.8

could always be replaced with

. MX 10 dummy
dummy A 5.6.7.8

(and would be supported by also DNS clients not knowing about MXA records)?

Hagen von Eitzen
  • 816
  • 3
  • 15
  • 41