Hello, I hope this message finds you well. These are great questions, so I will clarify them to be documented and help others in the future:
- You cannot, and it is not possible to use a proxy for email domain names, such as “mail.mydomain.com”. This is a global security practice to prevent spammers or any other type of email abuse and masking. If your email domain is configured with a proxy, your email server will not function because the service requires a direct connection to the server.
1.1 The PTR record (rDNS) operates at the domain and IP (host) level. Therefore, if you want to use a local email service, such as on a VPS or a dedicated server, you must configure the PTR record for it to function correctly (required by Google and Yahoo). Similar to the previous practice, this is a global security measure against spammers and other abuses, mainly to prevent malicious individuals from sending emails masquerading as a legitimate company. It serves to ensure the ownership and authenticity of a real email server that aims to follow best practices and comply with global security rules. It works in conjunction with SPF and DKIM.
1.2 Honestly, I do not recommend any friend, acquaintance, or client to use this type of local email service. Each day it becomes more difficult to have a self-hosted email server that functions without problems and with proper ownership and authenticity (without ending up in the spam folder). I suggest using dedicated email and SMTP services that offer high reliability. There are services that cost the equivalent of a cup of coffee per month and allow you to use as many email accounts as you need, according to your storage space. I do not see the need for the headache or time lost configuring a local email server. Although it works most of the time if well configured, email delivery is rarely 100% (in most cases, it does not even reach 60%). I do not think it is worth the time, effort, and risk unless you provide large-scale hosting services as a professional business. In this case, the configuration would be much more robust and complex, done directly at the level of your clusters and your range of dedicated IPs as an authentic provider… ISP → BGP → CIDR.
-
Yes, you can do this, as it is not limited to just one reverse proxy. You can replicate the mentioned tutorial for any local service on your server configured as a reverse proxy, and for any port, as long as it is properly configured in the application and the server.
-
No, this should not happen in any way. The updates will be done in the server administration console, and this configuration mentioned is only at the layer of your domain and host (your websites - hostnames). Although you access the panel through the configured hostname (web panel access), when managing your server, you should make the standard SSH connection “ssh root@YourServerIP”. The server will establish a direct connection with the CyberPanel update repository via curl, and there should not be a proxy in this process; I believe it is not even possible to do this at the management layer.
Final details and conclusions:
This type of configuration, which I taught in this tutorial, is for those who, like me, like to keep a server 100% secure and shielded against any type of “direct attack,” keeping your main IP completely hidden from the entire internet, using exclusively communication via services like CloudFlare or others for security, load balancing, CDN, caching, etc.
To be more specific, if in your DNS manager there is any configuration that points directly to your main server’s IP without a proxy configured, this tutorial would be useless and would not serve its purpose. CloudFlare itself, when detecting a direct IP pointing, notifies and clarifies this with a small alert above the pointing. Thus, any DNS analysis service can easily expose your IP.
A good practice to circumvent these issues would be to configure a dedicated IP exclusively for server management, with effective protection configured directly on the local network, using advanced protection services against the most common types of attacks, and limiting access exclusively to specific ports such as SSH, SFTP, FTP, etc.
Additionally, it is advisable to configure exclusive IPs for each of your applications and/or set of websites if the goal is complete and professional security. However, this is very advanced and would require a separate, extensive tutorial. This way, you would have full control over access and dedicated configurations for each one without exposing IPs to vulnerabilities. 
