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?
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.
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.
A record holds an IPv4 address (4 bytes of data, fixed length).
AAAArecord holds an IPv6 address (16 bytes of data, fixed length).
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.
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.
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.
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.
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.
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.
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.
184.108.40.206.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 220.127.116.11
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 18.104.22.168
could always be replaced with
. MX 10 dummy dummy A 22.214.171.124
(and would be supported by also DNS clients not knowing about