Capítulo 09 Transporte de e-mail & defesa Admin: #pSmtpQueue

Recomendação: Proxmox Mail Gateway como camada adicional na frente do nextxch

Um gateway de e-mail à frente aceita todos os e-mails da internet, verifica-os com um segundo mecanismo antispam e antivírus independente e encaminha ao nextxch apenas e-mails limpos. Esta página mostra a arquitetura, uma configuração passo a passo do Proxmox Mail Gateway (código aberto, AGPLv3) à frente do nextxch e as configurações relevantes do nextxch.

Dica operacional & nota de arquitetura

O gateway é opcional: o nextxch tem sua própria proteção contra spam e vírus. Importante, se você o usar: adicione o IP do gateway no nextxch como gateway confiável (passo 5). O nextxch então lê o IP real do remetente no cabeçalho Received do gateway e continua avaliando SPF, DMARC, greylisting e DNSBL corretamente, em vez de verificar o IP do gateway.

Por que um gateway na frente pode fazer sentido

Defesa em profundidade: dois sistemas independentes precisam falhar antes que uma mensagem maliciosa chegue a uma caixa de correio. Uma fraqueza em um produto não basta por si só.
Segundo mecanismo antispam e antivírus: o Proxmox Mail Gateway usa regras próprias, filtro bayesiano, SPF, DNSBL e ClamAV. O que um filtro deixa passar, o outro muitas vezes pega.
Quarentena: mensagens suspeitas ficam retidas no gateway e podem ser analisadas e liberadas por administradores ou usuários por meio do relatório de spam.
Desacoplamento da internet: somente o gateway aceita conexões da internet na porta 25. O nextxch fica atrás dele, com a porta 25 aberta apenas para o gateway.
Armazenamento temporário durante a manutenção: se o nextxch ficar brevemente indisponível por uma atualização ou manutenção, o gateway mantém as mensagens recebidas em sua fila e as entrega depois.

Uma avaliação honesta: o nextxch vem com proteção contra spam própria (SpamGuard com filtro adaptativo, SPF/DKIM/DMARC/ARC, greylisting, DNSBL, heurísticas de phishing) e integra o ClamAV. Para a maioria das instalações, isso é suficiente. Um gateway à frente é opcional e compensa para requisitos mais altos: políticas que exigem filtragem em várias etapas, uma quarentena central, vários servidores de e-mail atrás de um único MX ou separação rigorosa de redes.

Arquitetura: internet -> Proxmox Mail Gateway -> nextxch

O registro MX aponta para o gateway. Ele aceita e-mails na porta 25, filtra-os e os encaminha via SMTP para o nextxch. Opcionalmente, o nextxch envia e-mails de saída pela porta interna 26 do gateway.

Contínua: caminho de entrada (obrigatório). Tracejada: caminho de saída pelo gateway como smart host (opcional). Sem smart host, o nextxch continua entregando o e-mail de saída diretamente via DNS MX.

Proxmox® é uma marca registrada da Proxmox Server Solutions GmbH. O nome é usado apenas de forma descritiva; o nextxch não é afiliado à Proxmox Server Solutions GmbH e não é endossado nem certificado por ela.

Configuração em resumo

A ordem evita a perda de e-mails: primeiro configure e teste o gateway por completo, depois altere o registro MX e, por último, feche a porta 25 no nextxch.

Referência / configuração

1. Install Proxmox Mail Gateway (ISO, on Debian or as an LXC container)
2. Add relay domains (every domain nextxch accepts)
3. Default relay = nextxch host, port 25 (Mail Proxy -> Relaying)
4. Enable receiver verification, TLS and a certificate in the gateway
5. nextxch: add the gateway IP as a trusted gateway (SpamGuard)
6. Send a test message through the gateway, check Message Trace in nextxch
7. Switch the MX record to the gateway (remove the old MX only after the TTL expires)
8. Firewall: allow port 25 on nextxch from the gateway only
9. Optional outbound: gateway as smart host in nextxch (port 26, STARTTLS)

Example values on this page:
  Gateway:  pmg.company.com   203.0.113.25   (public, MX)
  nextxch:  mail.company.com  10.0.0.20      (internal, mailboxes)

1. Instalar o Proxmox Mail Gateway

O Proxmox Mail Gateway roda como appliance independente (instalador ISO em hardware ou como VM), como pacotes em um sistema Debian existente ou como contêiner LXC. Se você usa o Proxmox VE, há um template de contêiner pronto no gerenciador de appliances. Depois, você o gerencia pela interface web na porta 8006.

Referência / configuração

Option A: ISO installer (hardware or VM)
  Download the ISO from proxmox.com/downloads -> boot -> run the installer
  Host name: pmg.company.com   (FQDN, matching the future MX and PTR)
  IP:        static IP, e.g. 203.0.113.25 or a DMZ address behind NAT

Option B: on an existing Debian system
  Add the Proxmox package repository and install the packages as described in
  "Install Proxmox Mail Gateway on Debian" in the PMG admin guide

Option C: LXC container in Proxmox VE
  Proxmox VE -> Storage -> CT Templates -> Templates -> section "mail"
  -> download the Proxmox Mail Gateway template -> create the container

Web interface:  https://pmg.company.com:8006   (port 8006 from the admin network only)

Repositories: without a subscription, add the "pmg-no-subscription" repository.
For production, Proxmox recommends the enterprise repository (with subscription).

2. Domínios de relay, relay padrão e verificação de destinatário no gateway

Todas as configurações estão na interface web do PMG em Configuration -> Mail Proxy. O gateway aceita e-mails apenas para os domínios de relay listados e os repassa ao relay padrão após a filtragem.

Referência / configuração

Configuration -> Mail Proxy -> Relay Domains
  company.com
  company-group.com        (every domain configured in nextxch, including alias domains)

Configuration -> Mail Proxy -> Relaying
  Default Relay:      mail.company.com  (or 10.0.0.20)
  Relay Port:         25
  Relay Protocol:     SMTP
  Disable MX lookup:  yes               (address the nextxch host directly)

Configuration -> Mail Proxy -> Ports
  External SMTP Port: 25   (from the internet, untrusted)
  Internal SMTP Port: 26   (from nextxch, trusted, for outbound mail)

Configuration -> Mail Proxy -> Options
  Verify Receivers:   550   (reject unknown recipients right away)
  SPF:                yes
  DNSBL Sites:        e.g. zen.spamhaus.org   (observe the list's terms of use)

Several internal servers: Configuration -> Mail Proxy -> Transports
(domain or single address -> its own target server)

3. Apontar o registro MX para o gateway

Faça a troca somente depois que uma mensagem de teste enviada pelo gateway tiver chegado ao nextxch (Message Trace em /admin/). Antes, reduza o TTL do registro MX para alguns minutos. Não altere os registros do próprio nextxch (A/AAAA, PTR, Autodiscover): os clientes continuam se conectando diretamente ao nextxch.

Referência / configuração

; Gateway
pmg.company.com.      3600  IN  A     203.0.113.25
; PTR for 203.0.113.25 at your provider: pmg.company.com

; MX points to the gateway only
company.com.          3600  IN  MX 10 pmg.company.com.

; nextxch stays reachable for clients (IMAP, SMTP submission, webmail)
mail.company.com.     3600  IN  A     198.51.100.20

Test beforehand, without a DNS change:
  swaks --to anna.weber@company.com --server pmg.company.com --port 25 --tls

4. Saída opcional: gateway como smart host no nextxch

Os e-mails de saída passam então também pelos filtros do gateway (por exemplo, verificação de vírus, estatísticas). No Admin Cockpit, em SMTP, controles de fila & testador de MX ao vivo (#pSmtpQueue), informe o gateway como smart host global, ou use rotas SMTP para enviar apenas determinados remetentes pelo gateway. Importante: o IP público do gateway deve então constar no registro SPF dos seus domínios, e o PTR dele deve corresponder ao nome HELO do gateway.

Referência / configuração

# A) Global smart host: all outbound mail through the gateway
nextxch-cli update SmtpQueue --set outboundSmartHost=pmg.company.com \
  --set outboundSmartPort=26 --set outboundSmartHostTlsMode=StartTlsRequired

# B) Exception: one partner domain still directly via DNS MX (route without target host)
nextxch-cli create Route --set domain=partner.com --set bypassSmartHost=true \
  --set description="direct via MX, not through the gateway"

# C) Only certain senders through the gateway (#pSmtpQueue -> domain routes)
#    Destination domain:   *
#    Only for senders:     company.com, *.company.com   (SenderDomains)
#    Target host:          pmg.company.com:26           (several, comma-separated = failover)
#    TLS mode:             StartTlsRequired
#    Priority:             50                           (smaller = first; default 100)

# Add the gateway IP to the SPF record of the sender domain:
company.com.  IN  TXT  "v=spf1 mx ip4:203.0.113.25 -all"

# In the gateway: add the nextxch IP under Configuration -> Mail Proxy -> Networks
# if nextxch is not in the same subnet as the gateway.

5. Adicionar o IP do gateway no nextxch como confiável

Um gateway de e-mail aceita a própria mensagem e a entrega novamente. Para o nextxch, o IP de entrega passa então a ser sempre o IP do gateway. Para que SPF, DMARC, greylisting, DNSBL e a verificação de DNS reverso continuem avaliando o remetente real, adicione o gateway em SpamGuard & ClamAV (#pSpam) em "Gateways confiáveis". Para conexões vindas desses IPs, o nextxch lê o IP do remetente no cabeçalho Received escrito pelo gateway. Os cabeçalhos só são avaliados em conexões de IPs listados, portanto um remetente que entrega diretamente não consegue falsificar seu IP dessa forma. TrustedProxyCidrs (Cluster:EnableProxyProtocol) é outra coisa: aplica-se apenas a proxies TCP, como o HAProxy, que usam o protocolo PROXY.

Referência / configuração

# nextxch: add the gateway as trusted (public and internal IP, CIDR allowed)
# (admin cockpit: SpamGuard & ClamAV (#pSpam) -> "Trusted gateways")
nextxch-cli update SpamGuard --set trustedRelayCidrs=203.0.113.25,10.0.0.25

# Check: send a test message through the gateway, then in the spam analyzer or Message Trace
#   TRUSTED_RELAY  Via gateway 10.0.0.25, sender IP 198.51.100.7 from Received header
#   SPF_PASS       (SPF now checked against 198.51.100.7)

# Stays active in nextxch:
#   SPF/DKIM/DMARC/ARC, greylisting, DNSBL, adaptive content filter,
#   phishing heuristics, allow/block lists, ClamAV (if enabled)

# Connection limit: all inbound mail comes from one IP.
# Check MaxConnectionsPerIp (#pSmtpQueue, default 48) for high volumes.

6. Firewall e TLS nos dois trechos

Feche a porta 25 do nextxch no firewall do host ou de perímetro (Windows Firewall, nftables, pfSense/OPNsense). As regras de IP do nextxch não são adequadas para isso, pois se aplicam a todas as portas SMTP em conjunto e, portanto, também atingiriam as portas 465 e 587 dos clientes. Criptografe os dois trechos: internet <-> gateway e gateway <-> nextxch.

Referência / configuração

Firewall nextxch (inbound)
  TCP 25         only from 203.0.113.25 / 10.0.0.25 (gateway)
  TCP 465, 587   clients (SMTP submission)  -> stay open
  TCP 993, 443   clients (IMAP, webmail, DAV, push) -> stay open

Firewall gateway (inbound)
  TCP 25         from the internet
  TCP 26         from nextxch only (smart host, if used)
  TCP 8006       from the admin network only

TLS internet <-> gateway
  Configuration -> Mail Proxy -> TLS: "Enable TLS" on
  Certificate: Certificates -> ACME (Let's Encrypt) for pmg.company.com

TLS gateway -> nextxch
  nextxch offers STARTTLS on port 25 with the certificate of mail.company.com
  Gateway: TLS destination policy for mail.company.com = encrypt
           (or verify if the default relay is entered as a host name)

TLS nextxch -> gateway (smart host)
  outboundSmartHostTlsMode = StartTlsRequired

7. DKIM/DMARC, greylisting e backscatter

Três pontos frequentemente ignorados na prática. O gateway não pode alterar e-mails de saída, o greylisting deve ser executado em um único lugar e destinatários desconhecidos devem ser rejeitados durante o diálogo SMTP.

Referência / configuração

DKIM / DMARC
  - nextxch signs outbound mail with DKIM. The gateway forwards it unchanged.
  - No disclaimer rule for outbound mail and no content changes in the gateway
    (otherwise the DKIM signature breaks and DMARC fails at the recipient).
  - Leave DKIM signing off in the gateway; maintain disclaimers in nextxch if needed.

Greylisting
  - Slows down spam bots but delays first messages from new senders (usually < 30 minutes per PMG docs).
  - Run it in the gateway only; behind the gateway it would be ineffective in nextxch.
  - For time-critical senders (e.g. login codes, order confirmations) use the welcomelist,
    or skip greylisting entirely if the other filters are sufficient.

Avoid backscatter
  - Verify Receivers = 550: the gateway asks nextxch via RCPT TO whether the address exists.
  - nextxch rejects unknown recipients at RCPT TO, so the check takes effect immediately.
  - Catch-all addresses in nextxch defeat the check and should be avoided.

8. Licença e custo (em 1º de nov. de 2026)

O Proxmox Mail Gateway é de código aberto sob a GNU AGPLv3 e totalmente utilizável sem assinatura; nesse caso, as atualizações vêm do repositório pmg-no-subscription, que a Proxmox destina a sistemas de teste e não produtivos. Uma assinatura vale por host e ano, inclui, segundo a Proxmox, usuários e domínios ilimitados e dá acesso ao repositório enterprise. Os preços abaixo vêm da página de preços da Proxmox e podem mudar; proxmox.com é sempre a referência. O nextxch não vende assinaturas Proxmox.

Referência / configuração

Licence:  GNU Affero General Public License v3 (AGPLv3), since PMG 5.0

Optional subscriptions per host and year (net, per proxmox.com, as of 1 Nov 2026):
  Community    EUR 190      no ticket support (forum)
  Basic        EUR 540      5 tickets/year, response 1 business day
  Standard     EUR 1,260    15 tickets/year, response 4 hours
  Premium      EUR 1,900    unlimited tickets, response 2 hours
  (response = first reply to critical requests within business hours)

Sources:
  https://www.proxmox.com/en/products/proxmox-mail-gateway/pricing
  https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html   (admin guide 9.1.1: licence, repositories, ports)

Configurações, valores padrão e boas práticas

Configuração / local	Descrição	Valor padrão	Boa prática para produção
`PMG: Relay Domains (Mail Proxy)`	Lista de domínios para os quais o gateway aceita e encaminha e-mails. E-mails para outros domínios são rejeitados.	`leer`	Adicione todos os domínios configurados no nextxch, incluindo domínios de alias. Ao adicionar um domínio no nextxch, adicione-o também ao gateway.
`PMG: Default Relay + Port (Mail Proxy -> Relaying)`	Destino do e-mail de entrada após a filtragem (transporte do Postfix). Servidores internos adicionais por domínio via Transports.	`Port 25 · SMTP`	mail.company.com ou 10.0.0.20, porta 25, protocolo SMTP. Ative "Disable MX lookup" se você informar um nome de host que tenha um registro MX próprio.
`PMG: Verify Receivers (Mail Proxy -> Options)`	Verificação de destinatário: antes de aceitar, o gateway pergunta ao nextxch via RCPT TO se o endereço existe e rejeita destinatários desconhecidos durante o diálogo SMTP.	`aus`	Defina como 550. Evita backscatter, porque o gateway nunca aceita e-mails para endereços inventados que depois teria de devolver.
`PMG: TLS + Zertifikat`	STARTTLS para conexões de entrada e de saída do gateway. Sem certificado próprio, o PMG gera um autoassinado.	`TLS aus`	Ative o TLS, obtenha um certificado confiável via ACME (Let's Encrypt) para pmg.company.com e defina uma política TLS "encrypt" para o host do nextxch.
`PMG: Disclaimer & DKIM-Signatur`	A ação de regra Disclaimer acrescenta texto ao corpo; DKIM Signing assina e-mails recebidos na porta interna.	`aus`	Deixe ambos desativados. O nextxch assina com DKIM; qualquer alteração no conteúdo dentro do gateway quebra a assinatura e, portanto, o DMARC. Mantenha os disclaimers somente no nextxch (adicionados antes da assinatura).
`nextxch: Smart-Host (#pSmtpQueue · outboundSmartHost)`	Smart host global: todos os e-mails de saída vão para este relay em vez de diretamente para o MX do destinatário.	`leer (direkt per MX) · Port 25`	pmg.company.com, porta de relay 26 (a porta interna do gateway), modo TLS StartTlsRequired, sem SMTP AUTH. No gateway, o IP do nextxch deve estar listado em Networks (a mesma sub-rede é permitida automaticamente).
`nextxch: Route · SenderDomains`	Condição de remetente de uma rota SMTP: domínios (company.com, .company.com) ou endereços (billing@company.com, @company.com). Vazio = qualquer remetente.	`leer`	Enviar apenas determinados locatários pelo gateway: uma rota com domínio de destino * e SenderDomains = company.com, host de destino pmg.company.com:26.
`nextxch: Route · Priority`	Ordem entre rotas do mesmo nível; o número menor vence, depois o padrão mais específico.	`100`	A classificação vem antes da prioridade: remetente + domínio de destino, depois domínio de destino, depois apenas remetente (destino ), depois , depois smart host global, depois DNS MX.
`nextxch: Route · BypassSmartHost`	Somente para rotas sem host de destino: e-mails para este domínio vão diretamente via DNS MX, mesmo quando há um smart host global configurado.	`false`	Para domínios de parceiros específicos que não devem passar pelo gateway. Se a rota tiver um host de destino, a opção é ignorada.
`nextxch: Vertrauenswürdige Gateways (#pSpam · trustedRelayCidrs)`	IPs ou redes CIDR de gateways upstream. Quando uma conexão vem deles, o nextxch obtém o IP do remetente e o HELO do cabeçalho Received mais alto que não tenha sido escrito por um gateway listado ou pelo localhost.	`leer`	Adicione o IP público e o IP interno do gateway, por exemplo 203.0.113.25 e 10.0.0.25. Somente seus próprios gateways: cabeçalhos Received de IPs listados são considerados verdadeiros. O analisador de spam então mostra a regra TRUSTED_RELAY com o IP do remetente detectado.
`nextxch: SPF, DKIM, DMARC & ARC, Greylisting, DNSBL (#pSpam)`	Com o gateway listado, eles verificam o IP real do remetente. Sem ele, veriam apenas o IP do gateway, e o SPF retornaria na maioria das vezes softfail ou fail para outros domínios.	`abhängig von der Konfiguration`	Deixe ativados. Verificar tanto no gateway quanto no nextxch é inofensivo; se quiser greylisting em um só lugar, mantenha-o no gateway e desative-o no nextxch.
`Firewall: Port 25 auf nextxch`	Após a troca do MX, somente o gateway pode alcançar o nextxch na porta 25.	`offen für alle`	No firewall do host ou de perímetro, permita a porta 25 somente a partir de 203.0.113.25 ou do IP interno do gateway. As portas 465, 587, 993 e 443 permanecem abertas para os clientes.