We have an application running on Microsoft Azure and have set up a CNAME record to cover the domain so we can have the nice URL of http://example.com (note I am replacing our real domain with example.com throughout this).
CNAME
mydomain.com -> mydomainapp.cloudapp.net
We have MX and A records setup correctly so MX contains mailserver.example.com and an A record that points mailserver to the correct IP address.
MX
mailserver.example.com
A
mailserver -> 198.168.111.111 (note this IP is fictitious)
All fine, for most email BUT for some mailservers (not sure what technology yet) they are now using the CNAME instead of the MX and A records.
So an email addressed to [email protected] is actually sent to [email protected] where example.cloudapp.net is the domain on Azure that we have mapped with the CNAME.
EMAIL TO: [email protected]
BECOMES: [email protected]
The only suggestions I can find simply say DO NOT have domain level CNAME or do not use CNAME at all, but of course Azure IP addresses can change so we have to use CNAME. We could prefix everything www.example.com but surely there must be a better solution.
Any ideas much appreciated.
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.