4

Today we have 5 companies that all use Google for email services

example1.com.         3w   IN      MX  10   mail.Google.com.
example2.com.         3w   IN      MX  10   mail.Google.com.
example3.com.         3w   IN      MX  10   mail.Google.com.
example4.com.         3w   IN      MX  10   mail.Google.com.
example5.com.         3w   IN      MX  10   mail.Google.com.

Next week we will be using another vendor (Cisco). Is it OK for us to point to an A or CNAME in the MX?

example1.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example2.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example3.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example4.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example5.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.

The idea is that I can change myCNAMEToCisco.example.com to any other vendor. My concern is that there might be some odd validation when the client says helo domain.com and the 220 response may contain an unexpected host or domain name.

Is there any issue with using a CNAME or A record with email in this manner?

18

It would definitely create a problem if you were to point your MX records at CNAME records since it is against the standards. The clearest explanation is provided by RFC2181 §10.3:

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

Searching for either NS or MX records causes "additional section processing" in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made.

Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias. Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query. It is trivial for the DNS administrator to avoid this by resolving the alias and placing the canonical name directly in the affected record just once when it is updated or installed. In some particular hard cases the lack of the additional section address records in the results of a NS lookup can cause the request to fail.

You might be able to find anecdotal evidence through search engines that some DNS and MTA software support this, but that should be considered the exception and not the rule. Lack of this support will not be considered a bug by most software authors. Always avoid pointing a MX record at a CNAME.


The biggest problem you face right now is that the TTL for the MX records in your example are all three weeks, and your change is next week. I strongly recommend that you request that this switchover be delayed, and lower your TTLs to somewhere in the neighborhood of ten minutes. You can raise the TTL again once the cutover is complete.

  • So to solve my issue an A record would be supported? – random65537 Mar 12 '15 at 12:12
  • Yes, MX records are always used with A records. The biggest concern I'd have in your scenario are making sure the reverse DNS records for the servers sending e-mail match up with the MX records, but that's pretty standard for mail configuration and there are many Q&As covering that particular topic. – Andrew B Mar 12 '15 at 13:44
  • Ah, so that's what you meant! A records can only point at IP addresses. CNAME records can point at other names, but the quoted RFC verbiage is very clear that aliases cannot be used with MX records. (so regardless of how the aliasing occurs, it's still forbidden) I've also edited the answer to reflect the best course of action. – Andrew B Mar 12 '15 at 13:53
  • Can I take the result of an A record (GoogleApps SMTP IP), and call it SMTP.mycompany.com, set up the reverse so it matches. Must the SMTP banner of the MTA match the DNS data? – random65537 Mar 12 '15 at 13:57
  • Helo doesn't matter so much. You could do that, but that would cause things to break if Google changes the IP address. (they'd be under no obligation to notify you) I recommend setting the MX to point at an A record that is managed by the company who owns the mail servers. Also, if you have any DNS records that restrict who is allowed to send mail for your domain (SPF related TXT or SPF records, etc.), make sure those are updated too. The mail provider should have documentation instructing you on how to change them. – Andrew B Mar 12 '15 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.