Servidor de e-mail próprio: teste num laboratório antes de arriscar o seu domínio

Sábado, 20 minutos de tutorial: o container do Postfix sobe, o Thunderbird conecta, uma mensagem de uma conta local para outra chega. Na segunda, o primeiro e-mail para um cliente no Gmail não aparece nem no spam. Pior: o IP da VPS já estava numa lista de bloqueio antes de você contratá-la, e o domínio principal da empresa agora tem histórico de envio esquisito.

A resposta curta: subir o SMTP é a parte fácil; ser aceito pelos outros servidores é que dá trabalho. Para aprender, use um subdomínio de laboratório, nunca o domínio principal, e confirme que o servidor não aceita retransmitir mensagem de qualquer um. Para produção, a configuração que dói menos é deixar a recepção onde quiser e enviar por um serviço de relay que já tem reputação, com SPF, DKIM e DMARC do jeito que ele pede.

Por que a mensagem não chega mesmo com o servidor no ar

Quem recebe não confia em quem envia por padrão. Gmail, Outlook e afins olham, entre outras coisas: se o IP tem DNS reverso coerente com o nome do servidor, se o domínio autoriza aquele IP no SPF, se a mensagem tem assinatura DKIM válida, se existe política DMARC e se aquele IP e aquele domínio têm histórico de envio limpo. Gmail e Yahoo endureceram as exigências de autenticação para remetentes desde 2024. Um IP novo, sem histórico, começa desconfiado.

A infraestrutura também atrapalha. Muitos provedores de nuvem bloqueiam ou limitam a porta 25 de saída por padrão, e liberar exige pedido e justificativa. E nem todo provedor deixa você configurar o DNS reverso do IP. O tutorial comemorou a porta escutando; a entrega depende de coisas que nenhum container configura sozinho.

A configuração de SPF, DKIM, DMARC e DNS reverso em detalhe está no guia servidor de e-mail próprio: entregar na caixa dos outros é a parte difícil. Este aqui é sobre a decisão e sobre como experimentar sem estragar o domínio de verdade.

Quando vale ter o seu próprio servidor

Seja honesto com estas perguntas antes de começar:

• Alguém vai olhar fila, logs e listas de bloqueio toda semana, inclusive nas férias?
• O provedor libera a porta 25 e o DNS reverso do IP?
• Existe um motivo concreto (regulatório, custo em escala, aprendizado) que um serviço pronto não atende?
• Se o servidor cair num domingo, quanto custa ficar sem receber pedidos e notificações?

Se a maioria das respostas for "não sei", o serviço gerenciado custa menos do que o seu tempo. Ter um servidor próprio faz sentido para aprender, para quem tem equipe de operação, ou num modelo híbrido: recepção e caixas no seu servidor, envio por relay.

Como montar um laboratório seguro, passo a passo

O exemplo: a Loja Exemplo quer aprender, sem arriscar lojaexemplo.com.br. O laboratório usa lab.lojaexemplo.com.br numa VPS com IP 203.0.113.10.

1. Use um subdomínio separado para o laboratório, com MX, SPF e DMARC próprios. A reputação dele não contamina o domínio principal.
2. Verifique o IP antes de configurar qualquer coisa: consulte listas de bloqueio públicas e confirme com o provedor a política da porta 25 e do DNS reverso.
3. Configure o DNS reverso para mail.lab.lojaexemplo.com.br e um registro A com o mesmo nome apontando para o IP.
4. Instale e restrinja a retransmissão: só aceite mensagens para os seus domínios ou de usuários autenticados.
5. Teste de fora se o servidor é open relay.
6. Envie para uma conta sua no Gmail e leia os cabeçalhos.

Conferir o DNS do laboratório

dig +short MX lab.lojaexemplo.com.br
# 10 mail.lab.lojaexemplo.com.br.
dig +short TXT lab.lojaexemplo.com.br
# "v=spf1 ip4:203.0.113.10 -all"
dig +short TXT _dmarc.lab.lojaexemplo.com.br
# "v=DMARC1; p=none; rua=mailto:dmarc@lojaexemplo.com.br"
dig +short -x 203.0.113.10
# mail.lab.lojaexemplo.com.br.

Não virar open relay

No Postfix, a regra que decide quem pode retransmitir é smtpd_relay_restrictions. O padrão das versões atuais já é seguro; o perigo é alguém "consertar" um erro de envio ampliando mynetworks.

# /etc/postfix/main.cf (trecho)
myhostname = mail.lab.lojaexemplo.com.br
mydestination = $myhostname, localhost
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Teste de uma máquina de fora, tentando usar o seu servidor para mandar de um domínio externo para outro domínio externo:

swaks --server mail.lab.lojaexemplo.com.br \
  --from teste@exemplo.org --to alguem@exemplo.net
# esperado: 554 5.7.1 <alguem@exemplo.net>: Relay access denied

Se a mensagem for aceita, desligue o serviço até corrigir. Um open relay é encontrado por robôs em pouco tempo e o IP vai para lista de bloqueio antes do fim do dia.

Como enviar por relay sem abrir mão do seu servidor

No modelo híbrido, o Postfix entrega a mensagem de saída para um serviço de envio autenticado na porta 587, com TLS obrigatório. O serviço cuida da reputação; você publica no DNS os registros SPF e DKIM que ele indicar.

# /etc/postfix/main.cf (trecho)
relayhost = [smtp.provedor-de-envio.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

# /etc/postfix/sasl_passwd (permissão 600, fora do Git)
[smtp.provedor-de-envio.com]:587 usuario-smtp:SENHA_GERADA_NO_PROVEDOR

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix
postqueue -p

O postqueue -p mostra a fila. Mensagem parada com "deferred" é o primeiro sinal de problema, e é por isso que alguém precisa olhar a fila com frequência. Se o servidor roda em container, a senha do relay segue a mesma regra de qualquer segredo: fica no host, nunca no repositório, como em variável do servidor de e-mail não vai para o repositório.

Ler o veredito do Gmail

Envie para uma conta sua no Gmail, abra a mensagem e use "Mostrar original". O topo da página mostra o resultado de SPF, DKIM e DMARC. Qualquer coisa diferente de PASS nos três é o que você corrige antes de mandar o primeiro e-mail para um cliente. Para testar a recepção, o roteiro está em testar se o seu domínio recebe e-mail.

Erros comuns

• Experimentar com o domínio principal. Uma configuração errada no laboratório derruba a reputação do domínio que envia boletos e notas.
• Ampliar mynetworks para resolver um erro de envio. O servidor passa a retransmitir para qualquer um e entra em lista de bloqueio.
• Não checar o IP antes. Você herda o histórico ruim de quem usou aquele endereço e perde dias culpando a própria configuração.
• Mandar senha ou link sensível no corpo para testar. Mensagem de teste também fica em caixa de entrada, backup e log de servidor alheio.
• Não monitorar a fila. Mensagens adiadas se acumulam e somem depois do prazo de expiração, sem ninguém saber.
• Medir sucesso por "o servidor está no ar". O que importa é a mensagem chegar na caixa de entrada de quem recebe.

Checklist

• O laboratório usa um subdomínio separado do domínio principal.
• O IP foi consultado em listas de bloqueio antes do uso.
• O DNS reverso do IP aponta para o nome do servidor, e esse nome aponta de volta para o IP.
• O teste de relay a partir de uma máquina externa recebe "Relay access denied".
• SPF, DKIM e DMARC aparecem como PASS no "Mostrar original" do Gmail.
• A senha do relay está num arquivo com permissão 600, fora do Git.
• Alguém tem a tarefa de olhar a fila e os logs toda semana.

Mande agora uma mensagem do seu servidor para uma conta sua no Gmail: ela chega na caixa de entrada com SPF, DKIM e DMARC em PASS, ou nem chega?