CNAME for Azure application causes email problems with MX and A records ignored CNAME for Azure application causes email problems with MX and A records ignored azure azure

CNAME for Azure application causes email problems with MX and A records ignored


It is not possible to use a CNAME record on the domain-level, as CNAMEs is an alias for all RR types so it will always cause redirection for MX, SOA, NS, etc. lookups as well.

The following excerpt from RFC1912 section 2.4 says it very clearly:

A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record. Especially do not try to combine CNAMEs and NS
records like this!:

       podunk.xx.      IN      NS      ns1                       IN      NS      ns2                       IN      CNAME   mary       mary            IN      A       1.2.3.4

This is often attempted by inexperienced administrators as an obvious way to allow your domain name to also be a host. However, DNS servers like BIND will see the CNAME and refuse to add any other resources for that name. Since no other records are allowed to coexist with a CNAME, the NS entries are ignored. Therefore all the hosts in the podunk.xx domain are ignored as well!

So you must not use a CNAME-record for mydomain.com!

So you must set an A-record for mydomain.com (among MX:s and other records as needed), because that is the only working solution DNS-wise.


Yes, there is a better solution - use a second level domain for your app. Let it be portal.mydomain.com and use a CNAME to map portal.mydomain.com to the mydomainapp.cloudapp.net and setup the MX record for mydomain.com and have all addresses in the form user@mydomain.com. This way it's still clear that you own mydomain.com and all your emails still look serious - user@mydomain.com, not john1094@gmail.com.

Btw technically the setup described above indeed means you don't have a domain level CNAME.


OK, after much research it seems the best (at least to my mind) solution is to use an A record rather than CNAME for the domain level record.

You may be screaming "what! but the IP address is dynamically assigned!". Yes, but only if you tear down your deployment and replace it. Windows Azure will keep you VIP address so long as you publish to staging and use the "swap production and staging" option. Doing so preserves your VIP address so you can use an A record in your DNS instead of a CNAME.

See http://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns/ for some background.

Note MS official line is to recommend CNAME rather than A record due to the possible swapping of an IP address, but I guess they are not thinking about people wanting to run http://mydomain.com on the Azure platform.

I did also find other possible solutions including building an SMTP listener into you app that reads mail on port 25 and forwards it back out. Technically good, but sledgehammer and nut spring to mind, plus it's one more thing to go wrong, and of course one more bunch of resources to pay for.