46

We are trying to move all our websites we host to CNAMES as we are planning on moving servers in the new year and would like the ability to move some clients to one server and other clients somewhere else. We were planning on giving clients a unique CNAME which we can then change at a later date. (We have other reasons for doing this now but that is the main one)

We have been testing out this theory with a few of our own domains and it seemed to be fine. However when checking the MX records on a domain I got the CNAME value back rather than the MX record.

Sadly all of these domains are done via control panels, but I am guessing they are just writing zone files for me.

I want to create 2 CNAMEs for the company.com

company.com. IN CNAME client.dns.ourserver.com
www          IN CNAME client.dns.ourserver.com

The MX record is something like the following:

company.com  IN MX 10 mail.company.com

We have an A record for mail.company.com

Doing:

host -t mx company.com

Returns the CNAME value rather than the mx record.

Is this expected behaviour?

I have managed to get the above configuration working with the 123-reg.co.uk control panel, but not sure if that is more luck than anything.

Improve this question
2
  • This is a common question and has been asked many times before. See this link for an example: serverfault.com/questions/18000/…
    – Russell Heilling
    Dec 7, 2009 at 16:11
  • I did spend a little while looking for an answer but couldn't figure out if I was doing something different. Especially as it is working fine with one domain provider. I have my answer so that is cool and hopefully it will be of some use to someone.
    – johnwards
    Dec 7, 2009 at 18:02

6 Answers 6

Reset to default
59

This is a common error. You cannot use a CNAME RR for your root domain (e.g. company.com) and define additional resource records for the same zone.

See Why can't I create a CNAME record for the root record? and RFC1034 section 3.6.2 for details:

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

Improve this answer
2
7

RFC2181 section 10.3 says you can't point your MX record to a CNAME:

The domain name used as the value ... of a MX resource record must not be an alias.

Improve this answer
1
  • 5
    That isn't really the scenario that the question is about, though?
    – Håkan Lindqvist
    Mar 6, 2015 at 22:57
3

I just moved to Heroku which uses CNAMEs instead of A records and what I had to do was instead of making a CNAME with my_domain.com pointing to heroku, I did the CNAME with www.my_domain.com pointing to heroku, so the bare/root domain was not forwarding and my MX records would still work. Then I added a pointer to redirect my_domain.com to www.my_domain.com. It seems to work great. In my domain name provider the pointer was created using a 'pointers' setting which I set to 'standard' 'URL' and 'www.my_domain.com'

Improve this answer
4
  • Solid work! Thanks for sharing this!
    – duhaime
    Sep 10, 2019 at 0:32
  • Hi @Jesse Adamson, where did you add a pointer to redirect my_domain.com to www.my_domain.com ?
    – Utsav T
    Jun 20, 2020 at 14:46
  • @Utsav T, log into your domain name provider account and look for some kinda option to add a redirect or forward or something like that.
    – Jesse Adamson
    Jun 21, 2020 at 21:46
  • This worked for me. It seems like a lot of newer hosting services, (Vercel, AWS Amplify, etc) use CNAMEs. If you want your app pointed to a root domain and have an email address also at the root domain it seems like you're kind of out of luck. This "hack" works though. I wonder what the proper way to do this is...
    – ggrant
    Sep 8, 2023 at 17:17
0

I have found that SOME MX providers in tandem with SOME DNS providers will actually work alongside a bare CNAME, if you merely order the MX record ABOVE the CNAME in the top down record order.

It is working on Name.com registrar with Office 365 MX record and bare CNAME record directing HTTP to yet another domain. While testing MX queries I noticed my CNAME result came back first corresponding to my DNS entries order, so I figured why not try ordering MX first and see if that satisfied the MX provider. To my surprise Office 365 MX verification then passed and I can confirm inbound and outbound email is indeed flowing. And after testing several web clients, HTTP also indeed resolves desirably to specified CNAME destination host.

Caveat emptor - This is clearly going against the standard and therefore probably shouldn't be considered for anything critical. I'm assuming record order is not in the spec and therefore can't be officially relied upon... i.e. subject to change right after you forget about this hack.

Tip - MX Toolbox free page is very handy for checking the result of trying different DNS settings.

Shameless plug for my corresponding post.

Improve this answer
2
  • 3
    Being undocumented behavior, this is definitely not something I'd want to count on.
    – ceejayoz
    Jun 25, 2016 at 19:13
  • 3
    this behaviour can only be considered a bug, a caching nameserver may cache the CNAME response ans MDAs will never see the MX record tools.ietf.org/html/rfc5321#section-5.1
    – Jasen
    May 6, 2018 at 23:04
-1

I have come to realize that these two can be separated entirely

mydomain.com. -  A Record  - 01.0.0.1
mydomain.com - CNAME - www.cname.eg.com

Unless you are using your server as the mail server it wont really affect anything. The mail will look for mydomain.com MX records. Its will only be affected if its like this 

mydomain.com - MX - mail.mydomain.com

but if its like this (meaning you are using a separate mail server) it wont be affected

mydomain.com - MX - mail.mycustommailserver.com

You can't use an IP for Mail Servers.

Improve this answer
-3

You can use a CNAME on the root of the domain, however, those MX records must also be configured on the host record, so if you have mx1.mail.com configured on the zone for yourdomain.com, and the root of yourdomain.com is CNAME to thisrecord.cname.com, you must also make sure that mx1.mail.com is configured on that CNAME host; if not, all mail will be lost!

Improve this answer
2
  • 4
    The problem is, as per RFC1034, "if a CNAME RR is present at a node, no other data should be present" -- since the root needs to have NS records (to be useful, anyways), there will always be other data, which violates this section of the RFC.
    – Doktor J
    Sep 30, 2013 at 23:05
  • In my opinion the answer is correct, except that the MX record should be instead on the CNAME host (not also).
    – Alexander Taubenkorb
    Aug 13, 2015 at 5:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .