-1

Let's say I have an webspace with a mailserver at mail.webspace.com and an own domain called mail.mydomain.com.

mail.webspace.com is the domain I got from my hosting provider to enter for IMAP and SMTP whenever I'm configuring an email client.

What I want to achieve now is to somehow have mail.mydomain.com work for that mailserver as well, but without any config changes on the mailserver since I have no access to it. The goal is to be able to enter either mail.webspace.com or mail.mydomain.com for IMAP/SMTP in any email client. The clients should be able to connect via SSL on both domains, not just mail.webspace.com, which always works.

From my understanding I would need something at DNS level for mail.mydomain.com to do this (like a 301 redirect or CNAME), however I don't know how and whether this is the right way of doing it.

So, is there a way to do this?

wielauritz
  • 1
  • 2

1 Answers1

0

Do you want mail.mydomain.com to be MX for the domain mydomain.com, so it can receive messages sent to ...@mydomain.com, or do you want only for the mail clients to be able to connect to it using the name mail.mydomain.com in order to fetch/send mail?

Generally, in first case you can't do it without changes on the mailserver, because the mailserver must know which domains are "local" for it, ie. for which domains it should receive mail and try to deliver it to the users mailboxes. All domains that are not in "local" list are treated as external and the mailserver will try to relay mail (if allowed by the config) to the MX proper for that domain. If it detects that it is the MX itself, but the domain is not listed as local, it will reject mail.

In second case it is theoretically possible if you define in DNS an A record for mail.mydomain.com with the same IP address as in existing A record for mail.webspace.com, or you define a CNAME record for mail.mydomain.com pointing to mail.webspace.com.

However, there will be a certificate problem. As the TLS certficate is most probably issued only for the name mail.websapce.com, your mail clients upon connection to mail.mydomain.com will complain about certificate mismatch (ie. name on certificate is mail.webspace.com while the name used to connect was mail.mydomain.com) - it's a standard security feature. Maybe you can disable it in mail client's config, but it depends on the client.

Without changing the certificate on the server (which will probably involve purchasing a new certificate) you can't fix this.

raj
  • 542
  • 2
  • 8
  • 1
    "CNAME record for mail.mydomain.com pointing to mail.webspace.com". DNS specifications prohibit , in an MX record, to use a name that is a CNAME to something else. – Patrick Mevzek Aug 08 '22 at 21:00
  • Yes, but it is not stated in the question that this server is necessarily a MX (that's why I asked about it). The OP asks specifically about using this name in mail client configuration as an IMAP/SMTP server. In this case CNAME is acceptable. – raj Aug 08 '22 at 21:03
  • No, all ...@mydomain.com stuff is already handled by the webspace, so I just want to have mail.mydomain.com as the name to connect for mailclients, instead of using the hoster-provided mail.webspace.com address. I had the CNAME-idea aswell, but never tested past the certificate warning. I assume and will test if this works, however from what I understand, unless the certificate at mail.webspace.com is changed (which I can't), mails won't be able to be sent over TLS/SSL and therefore not encrypted, right? – wielauritz Aug 08 '22 at 21:16
  • You can usually make the mail client accept the certificate despite the warning, and then encryption will work normally. The only downside is the warning message you get when your client connects to the server. – raj Aug 09 '22 at 11:15