Você está ficando confuso ao pensar sobre como a informação flui entre as camadas da pilha do protocolo TCP / IP - entre o DNS e os protocolos da camada de aplicação, especificamente.
Você tem um endereço IP público. Seu DNS certamente pode resolver os mail.example.com e example.com para o mesmo endereço IP público.
Em geral, os datagramas IP contendo solicitações para o 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 magicamente "saber" qual hostname o cliente remoto resolveu, já que ambos os nomes de host resolvem o mesmo endereço IP. A camada IP não está ciente do nome do host usado na camada do 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 seu firewall NAT para enviar solicitações recebidas para a porta TCP 80 (HTTP) para o servidor da Web enquanto envia porta TCP de entrada 25 (SMTP) para o seu servidor de email.
Se, no entanto, você planeja hospedar o mesmo serviço em ambas as máquinas, essa estratégia se torna problemática. Suponha que você irá hospedar um site seguro em seu servidor da Web (para acesso do Cliente) e um site seguro em seu servidor de e-mail (para webmail). As 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 esta situação é ter mais endereços IP públicos. Porque os endereços IPv4 estão se tornando escassos, o que também pode ser problemático.
Acabamos trabalhando em torno da escassez de endereços IP públicos em alguns protocolos na camada de aplicação. Por exemplo, o HTTP / 1.1 adicionou o cabeçalho Host: 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 Indicação do nome do servidor (SNI) 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 aplicativo significa que todo protocolo da camada de aplicativo precisaria de sua própria "correção" (e, em seguida, todo o software do servidor e do 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 múltiplos hosts usando software que pode "rotear" requisições. Isso provavelmente vai além do que um simples firewall NAT é capaz, porque os pacotes precisam ser inspecionados na camada de aplicação. Usando um proxy reverso como nginx é um bom exemplo desse tipo de "multiplexação" (ou regras de publicação na Web no Forefront TMG ou no ISA Server em um ambiente Microsoft) para o protocolo HTTP. Em teoria, qualquer protocolo poderia ser multiplexado por meio de um proxy reverso, mas quanto mais esotérico for o protocolo, maior a probabilidade de você estar falando sobre como ter código personalizado escrito.
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 notação http://example.com:XXX (em que XXX é o número de porta não padrão). Se isso seria problemático na sua situação é algo que só você pode decidir. (Minha experiência mostrou que praticamente nenhum usuário final é capaz de manipular a notação :XXX port em qualquer URL que tenha que inserir manualmente.)