dns mx record for virtual domain

Question

I am setting up several virtual domains on a single VPS and I'm a little confused about MX records. My desire is for users with email accounts on the various virtually hosted domains to be able to use something like mail.their-virtualdomain.com as incoming and outgoing (smtp) server names when setting up their email client software. This would be opposed to having them use the FQDN of the VPS where the email server is running (say, server1.mycompany.com). Here's what I think so far:

Some people try to use CNAME records for this, and it might even sort of work when communicating with some external email servers. But it's against the RFC and it will fail in some situations. So we don't want to do this.

I think better is the suggestion to make an A record for mail.their-virtualdomain.com with the IP address of the VPS server, and then an MX record using mail.their-virtualdomain.com. I believe this works at least to some extent. But I'm unclear on at least two possible problems here:

1) At least with my VPS host (and I think this is normal) only my FQDN (server1.mycompany.com) gets a PTR record. So I think reverse DNS will only work with the FQDN. Does this mean my goal is impossible because users using mail.their-virtualdomain.com as an outgoing SMTP server will fail reverse DNS checks and thus be more likely to be marked as spam? Or maybe I'm not understanding reverse DNS.

and if 1) isn't a show stopper, then:

2) If users want to connect using SSL for sending and receiving mail, I would have to get an SSL certificate for each virtual domain? (whereas if all users use the FQDN as their mail server then I can just get a single certificate.) I know I can do self signed certs for free, but this doesn't strike me as a bulletproof solution (users might still get warnings that certificate is self signed and not secure?)

I'm guessing other people must have this desire. What do people do? What am I missing? Thanks.

Answer 1

There's no reason why the "A" record that an "MX" record refers to needs to be in the same domain as the MX record. That is to say that in the "their-virtualdomain.com" you can have:

 @ MX 10 server1.mycompany.com

The mail for "@their-virtualdomain.com" recipient will be sent to the SMTP server at server1.mycompany.com.

re: point 1 - A recipient's SMTP server receiving a message from server1.mycompany.com doesn't "know" what server name the message sender used to deliver that message to the server1.mycompany.com machine. Your Customers' SPF records should reflect that server1.mycompany.com is a valid server from which they can send email for their domain, but the reverse DNS doesn't need to "match" the name the Customer uses to get mail to the server1.mycompany.com server.

re: point 2 - This just depends on what you want your Customers to see. If you want them to use the name "mail.their-virtualdomain.com" then you'll need a certificate and static IPv4 address for each Customer. It probably makes more sense if you just tell your customers to use the server1.mycompany.com name (or an alias) as their SMTP server and get a certificate for that name. Just the requirement to get the certificates for each Customer alone, aside from the need for dedicated IPv4 addresses, is probably burdensome to you.