0

There seems to be some debate (eg. here) about whether its acceptable to have an MX record which refers to a domain which has a CNAME record.

10.3 of RFC 2181 says it's definitely not allowed, but the first link about suggests people do it anyway and it works. RFC 2181 is dated 1997, what works and doesn't work could well have changed a lot in that time.

I want to use amazon SES to send and receive emails including using customers' own domains. However I would like the service to be as white labels as possible (both to look smart and leave the option to switch to other email services in future). I've confirmed I can white label both SPF and DKIM records, my only concern is MX but that's kind of the most important. :-(

Will it work to have a subdomain of my service with a CNAME record

mail.theservice.com CNAME amazonses.com

Then ask customers to set a MX record

thecustomer.com MX 5 mail.theservice.com

I'm then hoping an email sent to jane.joe@thecustomer.com to be delivered to amazonses.com.

Is it possible it will have patchy success with some SMTP servers not respecting the CNAME alias?

Is there an authoritative answer on this anywhere?

(Note this not the same as this related question. I'm asking about MX > CNAME, that's about CNAME > MX)

Community
  • 1
  • 1
SColvin
  • 11,584
  • 6
  • 57
  • 71
  • I'm voting to close this question as off-topic because you are effectively asking whether a configuration contravening the practices documented in the RFCs is acceptable, which can only really be answered in one of two ways: "no, it isn't, even if it works" or with a variety of subjective opinions. – Michael - sqlbot Dec 10 '16 at 02:17
  • That's inaccurate. The RFC could well have been replaced by a newer one, I can't find it but it might well exist and someone might be able to point me to it. It could also be answered by someone's experience " have been doing this for x years receiving x thousand emails and it works fine, or works x% of the time". – SColvin Dec 10 '16 at 12:15
  • After thinking about this for a night, it occurs to me that the best solution might be to run a server at `mail.theservice.com` with postfix forwarding mail to `amazonses.com`, it would add slight latency but be more canonical. Suggesting that would have helped the community rather more than suggesting the question be closed because you don't know the answer. – SColvin Dec 10 '16 at 12:17
  • I believe I *do* know the answer, but this does not seem like a productive question, since the RFC -- which you've already cited -- leaves little room for any alternative *factual and objective* answer, which is what SO is about. I could have simply cast my anonymous vote as "primarily opinion based," but instead I offered you what was intended to be a courtesy -- an explanation for my reasoning for the vote. Still, as of now, no one has concurred with my vote, so the question remains open. – Michael - sqlbot Dec 10 '16 at 17:49
  • 1
    As for your alternate suggestion: while technically much more correct, it would not be as applicable now as it would have been a few years ago. The problem with it now is that the usefulnees of SES's anti-spam heuristics will be limited to an extent, because the mail will come from your machine, not the machine that sent the spam to you. Spam detection will probably be impaired and if your recipients receive spam, your machine's spamminess will likely have some non-zero value from SES's perspective. Email is one of the most difficult infrastructures, for largely non-technical reasons. – Michael - sqlbot Dec 10 '16 at 17:57
  • Spam problem makes sense. I was under the impress that MTAs include the original IP and act as a transparent forwarder so SES to see who originally sent the email. Perhaps not. – SColvin Dec 10 '16 at 18:07
  • It will be in the headers, but the headers in an incoming message are intrinsically untrustworthy when they are provided by a machine you do not control, which would be the case here (SES doesn't control your machine, therefore shouldn't trust it). SES may or may not make use of them for this purpose. Whether they do, or to what extent, is not public information. Spam mediation is a dark art. – Michael - sqlbot Dec 10 '16 at 18:40
  • This is completely off-topic for stackoverflow anyway - this site is for _programming_ questions. – Alnitak Dec 12 '16 at 12:44

0 Answers0