7

Lets say I have the following DNS active for domain example.com (leaving out priority and ttl)

   example.com A    123.45.67.89
mx.example.com A    123.45.67.89
   example.com MX   mx.example.com

Now, this is a valid DNS record. If I were to add the following mx record, would that cause any problems?

mx.example.com MX   mx.example.com

I have tested this, and it seems to work, but I want to be sure.

The reason is, I always used mailaddress@mx.example.com to email without this last mx record added. But some services fail because they're not using the main domain, but rather check for the subdomain if that mx record is present. Adding the mx record seems to allwo the services to work, but I now am worried it may cause problems for actually sending/receiving email.

Also, I have set the priority for the new mx record to be lower to the original one, so in theory that should make it always choose the first one, but I'm curious it would even work if the priorities were reversed.

LPChip
  • 333
  • 2
  • 12

3 Answers3

16

An MX RR pointing to itself is perfectly valid and will cause no problems. It may be considered redundant, though, because of the general rule that if a domain name has no MX RR but an A RR, the latter shall be used for mail delivery. In other words, an MX RR pointing to itself is implicitly assumed when no explicit MX RR is present.

Note that your example code has syntactic problems. The FQDNs lack final dots, and the MX RRs lack priority fields. It should read:

   example.com.    A    123.45.67.89
   mx.example.com. A    123.45.67.89
   example.com.    MX   10 mx.example.com.
   mx.example.com. MX   10 mx.example.com.

or, equivalently:

   $ORIGIN example.com.
   @               A    123.45.67.89
                   MX   10 mx
   mx              A    123.45.67.89
                   MX   10 mx

(The $ORIGIN directive being redundant if the whole is part of the zone file for domain example.com.)

Tilman Schmidt
  • 3,778
  • 10
  • 23
  • Thanks. I forgot about the . though on my configuration panel they're not required, but I've also worked with DirectAdmin where they are required. And the lack of not using priorities was only to make things less confusing. But that aside, your answer I fully understood, and for that reason I've accepted it. Thanks. :) – LPChip Oct 04 '15 at 15:33
  • 1
    I would not consider it completely redundant though. The presence of the MX record could be seen as indication that the domain is intended to receive mails. If the domain has no MX record but it does have an A record, you can still try to deliver the mail. But if you cannot connect to port 25, do you then want to fail immediately or retry for several days to deliver an email in which the domain name was mistyped? – kasperd Oct 04 '15 at 15:47
  • 4
    @kasperd: A human reader might see it as such an indication, but a mail server has no choice but to do the retries if it wants to be RFC compliant. Nor do I consider that a big problem. The resource consumption of those useless retries is negligible, and address typos that just by chance change the domain part into the FQDN of an existing server without mail service are sufficiently improbable that they won't add significantly to the volume of useless retries you regularly see on any mail server. – Tilman Schmidt Oct 04 '15 at 18:49
  • In some situations ther *is* a difference between having a self-referential MX ecord in addition to an A record or not: If there is an *additional* MX record pointing to another MTA then the implicit assumption of an MX pointing to to the host is not made. – Hagen von Eitzen Oct 04 '15 at 20:38
  • Correct. That's why I wrote "when no explicit MX RR is present" in my answer. – Tilman Schmidt Oct 04 '15 at 22:36
5

You seemed to confuse yourself. DNS MX-RR format domain MX pref name is used to say that server with a name name will be an MX for the domain domain.

In your case you are saying that server with name mx.example.com will handle mail for mx.example.com domain. This is perfectltly valid, but it seems to me that you want to set up an MX for example.com.

drookie
  • 8,051
  • 1
  • 17
  • 27
  • As my example shows, I have an MX record for example.com already, but some services faill because mx.example.com is what I use for emailing, and thus they say emailaddress@mx.example.com is not valid. So by adding this mx record I fixed it, but I worried it may not work as expected. So hench my question. – LPChip Oct 04 '15 at 13:05
  • 1
    The part about self-confusing still stands. – drookie Oct 04 '15 at 13:27
  • @LPChip I have to agree with drookie - either you've got some edge case here that needs further qualification before someone can say anything especially helpful about it or you're over-complicating things. – Rob Moir Oct 04 '15 at 13:40
  • @RobM might be both. I probably am concerned about something that does not exist and thus overcomplicate things. Basically my question is: can an MX record point to itself and not cause any problems? – LPChip Oct 04 '15 at 15:31
5

I guess the core of your question has been answered, but you might want to clear up some confusion:

  1. There is no "second MX record with lower priority", MX record priorities are scoped to names, both names in your example have only one MX each, so the priority is completely without consequence. An MTA looks up the MX records for exactly the host part it's trying to deliver to, nothing else (except for the A/AAAA lookup if the MX lookup gives zero result records).
  2. Also, the MX record doesn't "point to itself" - it only happens to contain the same hostname that it's stored under, but that name points to A and AAAA records, which are distinct from the MX record stored under that same name. In DNS, you can store any number of different records under the same name, and there is nothing wrong with one record under one name pointing to another record under the same name - the only thing that's not a good idea is actually pointing to the same record, like having a CNAME record with its own name in it, as that in turn would point at the same CNAME record, etc., ad infinitum.