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

Question 1

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.

Question 2

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.

Question 3

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.

Question 4

We use an A record for our root domain and this works fine, as @Jezbers mentioned in his answer. The A record won't break email. However, the CNAME record affects the other records (it allows you to have "redirect domain" functionality so foo@mydomain.com also works for foo@mynewdomain.com).

If you were looking for a better "work-around" solution than the SMTP Listener work-around, then you can consider the following:

Host your site at a www subdomain and put the CNAME there. Have something else host a 301 redirect to www and use an A record to point your root domain to this redirect site.

Not perfect but an option that's better than the SMTP option, most likely.