Você está ficando confuso ao pensar em como as informações fluem entre as camadas da pilha de protocolos TCP / IP - entre os protocolos DNS e da camada de aplicativos, especificamente.
Você tem um endereço IP público. Seu DNS certamente pode resolver ambos mail.example.come example.compara o mesmo endereço IP público.
Em geral, os datagramas IP que contêm solicitações para seu endereço IP público, que serão recebidos pela interface externa do seu firewall, não contêm o nome do host que o cliente remoto está tentando acessar. Seu firewall não pode "saber" magicamente qual nome de host o cliente remoto resolveu, pois os dois nomes de host são resolvidos para o mesmo endereço IP. A camada IP não está ciente do nome do host usado na camada de aplicativo.
Os protocolos TCP e UDP diferenciam serviços específicos oferecidos por um host usando números de porta. No caso do seu exemplo, pode ser possível usar o recurso de encaminhamento de porta (também chamado de conversão de endereço de porta ou PAT) do firewall NAT para enviar solicitações de entrada para a porta TCP 80 (HTTP) para o servidor da Web enquanto envia a porta TCP de entrada 25 (SMTP) para o seu servidor de email.
Se, no entanto, você planeja hospedar o mesmo serviço nas duas máquinas, essa estratégia se torna problemática. Suponha que você hospede um site seguro no servidor da Web (para acesso do Cliente) e um site seguro no servidor de email (para o Webmail). Solicitações que chegam ao endereço IP público do seu firewall NAT para a porta TCP 443 (HTTPS) só podem ser roteadas para um servidor ou outro.
A solução generalizada para essa situação é ter mais endereços IP públicos. Como os endereços IPv4 estão se tornando escassos, isso também pode ser problemático.
Acabamos trabalhando com a escassez de endereços IP públicos em alguns protocolos na camada de aplicação. Por exemplo, o HTTP / 1.1 adicionou o Host:cabeçalho especificamente para permitir que um servidor da Web hospede vários sites no mesmo endereço IP público. O TLS adiciona a extensão SNI ( Server Name Indication ) para permitir a seleção do certificado apropriado com base no nome do host inserido pelo cliente remoto.
Fazer esse tipo de solução alternativa na camada de aplicativos significa que cada protocolo da camada de aplicativos precisaria de sua própria "correção" (e todo o servidor e software cliente precisaria implementar essa "correção"). Essa é uma tarefa difícil.
Em vez de modificar o protocolo da camada de aplicação, alguns protocolos são facilmente passíveis de serem "multiplexados" entre vários hosts usando um software que pode "rotear" solicitações. Isso provavelmente vai além do que um simples firewall NAT é capaz, porque os pacotes precisam ser inspecionados na camada do aplicativo. O uso de um proxy reverso como o nginx é um bom exemplo desse tipo de "multiplexação" (ou regras de publicação na Web no Forefront TMG ou ISA Server em um ambiente Microsoft) para o protocolo HTTP. Em teoria, qualquer protocolo pode ser multiplexado por meio de um proxy reverso, mas quanto mais esotérico o protocolo, maior a probabilidade de você falar sobre a criação de código personalizado.
Quando você precisa oferecer o mesmo serviço de dois hosts diferentes em um único endereço IP público, sempre tem a opção de mover um dos hosts para uma porta não padrão. Isso exigirá que os clientes estejam cientes da porta não padrão, no entanto. No caso de HTTP (S), isso resulta em URLs com a http://example.com:XXXnotação (onde XXXé o número da porta não padrão). Se isso seria problemático em sua situação, é algo que somente você pode decidir. (Minha experiência demonstrou que praticamente nenhum usuário final é capaz de lidar com a :XXXnotação de porta em qualquer URL que precise inserir manualmente.)