Servidor de e-mail próprio: entregar na caixa dos outros é a parte difícil

O container do servidor de e-mail sobe em dez minutos. Você manda um teste para o Gmail e ele não chega, ou chega no spam. A resposta curta: o software é a parte fácil. Os servidores de quem recebe decidem se acreditam em você olhando o DNS do seu domínio, o IP reverso do servidor, o histórico daquele IP e o conteúdo. Antes de mandar qualquer mensagem, você precisa de nome do servidor apontando para o IP, IP reverso apontando de volta para o nome, SPF, DKIM e DMARC publicados, e a porta 25 de saída liberada pelo provedor. Se a necessidade é só o formulário do site ou e-mail transacional, um serviço de envio pronto resolve com menos risco.

Servidor de e-mail não é site. Site responde a quem pede. E-mail depende de outros servidores aceitarem o que você manda.

Por que o e-mail chega no spam ou nem chega

Quando o seu servidor entrega uma mensagem, ele se conecta na porta 25 do servidor de destino e se apresenta. O destino não conhece você. Ele faz uma série de verificações em segundos:

• IP reverso: o registro PTR do IP de origem aponta para um nome, e esse nome aponta de volta para o mesmo IP? IP sem reverso, ou com reverso genérico do provedor de nuvem, é sinal de máquina descartável.
• SPF: o domínio do remetente publica uma lista de quem pode enviar em nome dele. O IP de origem está nela?
• DKIM: a mensagem chega assinada, e a assinatura confere com a chave pública publicada no DNS do domínio?
• DMARC: o domínio diz o que fazer quando SPF e DKIM falham, e o domínio verificado bate com o do remetente visível?
• Reputação: o IP e o domínio têm histórico de mensagens que as pessoas abrem, ou de spam e reclamações? O IP está em alguma lista de bloqueio, como as do Spamhaus?

Um IP de nuvem recém-criado não tem histórico nenhum, e muitas faixas de IP de nuvem têm histórico ruim, porque é ali que spammers alugam máquinas. Grandes provedores de caixa postal, como Gmail e Yahoo, endureceram as exigências de autenticação a partir de 2024, especialmente para quem envia em volume. Sem SPF e DKIM corretos, a mensagem é recusada ou vai para o spam.

Há ainda o bloqueio na origem. Vários provedores de nuvem bloqueiam ou restringem a porta 25 de saída por padrão, justamente para conter spam. No Google Cloud, ela é bloqueada. Em outros, como AWS e Azure, existe restrição que depende do tipo de conta e pode exigir pedido de liberação. Confira a documentação do seu provedor antes de escolher onde hospedar.

Como preparar o DNS e o servidor

1. Confirme que o provedor libera a porta 25 de saída para a sua conta.
2. Escolha o nome do servidor, como mail.exemplo.com.br, e crie o registro A apontando para o IP.
3. Configure o IP reverso no painel do provedor de nuvem, apontando para esse mesmo nome. O reverso é do dono do IP, não do seu DNS.
4. Crie o registro MX do domínio apontando para mail.exemplo.com.br.
5. Publique o SPF, gere a chave DKIM no servidor e publique a parte pública.
6. Publique um DMARC em modo de observação e leia os relatórios antes de endurecer.
7. Configure TLS com certificado válido e exija autenticação para envio nas portas 587 ou 465.
8. Teste a entrega e leia os cabeçalhos da mensagem recebida.

A zona de DNS resultante, com dados fictícios:

mail.exemplo.com.br.              3600 IN A    203.0.113.25
exemplo.com.br.                   3600 IN MX   10 mail.exemplo.com.br.
exemplo.com.br.                   3600 IN TXT  "v=spf1 mx -all"
s2026._domainkey.exemplo.com.br.  3600 IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...chave-publica..."
_dmarc.exemplo.com.br.            3600 IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemplo.com.br"

O SPF v=spf1 mx -all diz que só os servidores do MX podem enviar pelo domínio. Se outro serviço também envia por você, como a plataforma de newsletter, ele precisa entrar no SPF, com o include que o próprio serviço informa. O s2026 é o seletor DKIM, um nome que você escolhe e que aparece na assinatura. A chave em si é gerada pelo software do servidor, e o docker-mailserver tem um comando próprio para isso, descrito na documentação da versão que você usa. O DMARC com p=none não bloqueia nada: só pede relatórios. Depois de semanas sem falhas legítimas, suba para quarantine e depois para reject.

Como testar cada item

dig -x 203.0.113.25 +short
dig mail.exemplo.com.br A +short
dig exemplo.com.br MX +short
dig exemplo.com.br TXT +short
dig s2026._domainkey.exemplo.com.br TXT +short
dig _dmarc.exemplo.com.br TXT +short

O primeiro precisa devolver mail.exemplo.com.br., e o segundo precisa devolver o mesmo IP. Depois, mande uma mensagem para uma conta do Gmail, abra a mensagem e use "Mostrar original". O Gmail exibe o resultado de SPF, DKIM e DMARC. Os três precisam aparecer como PASS. Qualquer outro resultado diz exatamente qual registro corrigir.

O que muda quando o servidor roda em container

Container não muda nada do que foi dito sobre DNS e reputação. Ele acrescenta cuidados próprios. As caixas postais, a fila de mensagens, as chaves DKIM e os certificados precisam ficar em volumes persistentes, com backup testado. Recriar o container sem os volumes apaga a caixa de todo mundo. O IP de saída que os outros servidores enxergam é o IP público do host, e é ele que precisa ter reverso e estar no SPF. E as portas publicadas precisam ser só as necessárias: 25 para receber de outros servidores, 587 ou 465 para os seus usuários enviarem com senha, 993 para IMAP com TLS.

Operar caixa postal também é cuidar de abuso. Um servidor que aceita repassar mensagem de qualquer um, o chamado relay aberto, entra em lista de bloqueio em poucas horas. Uma conta de usuário com senha fraca vira fonte de spam. Limite tentativas de login, monitore a fila de saída e acompanhe as listas de bloqueio.

Quando um serviço de envio é a escolha certa

Se o que você precisa é o e-mail de confirmação de cadastro, a recuperação de senha e o formulário de contato que chega, um serviço de envio transacional, como Amazon SES, Postmark ou similares, resolve a parte difícil: IPs com reputação, assinatura DKIM e painéis de entrega. Você ainda publica SPF e DKIM no seu DNS, mas não opera fila, caixa postal nem bloqueio. Servidor próprio faz sentido quando você opera caixas de verdade para pessoas e aceita o trabalho contínuo de reputação e abuso.

Erros comuns

• Esquecer o IP reverso. Muitos servidores recusam a conexão ou pontuam a mensagem como suspeita antes de ler o conteúdo.
• Publicar dois registros SPF. A especificação aceita só um por domínio. Com dois, a verificação falha e as mensagens perdem autenticação.
• Começar com DMARC em reject. Um serviço legítimo que você esqueceu no SPF, como o sistema de notas fiscais, passa a ter as mensagens recusadas.
• Testar só mandando para si mesmo. O próprio servidor aceita tudo que ele mesmo envia, e você conclui que funciona.
• Deixar caixas e chaves dentro do container, sem volume. A próxima atualização da imagem apaga mensagens e invalida a assinatura DKIM publicada.
• Relay aberto ou senha fraca. O IP entra em lista de bloqueio e todo o domínio sofre, inclusive as mensagens legítimas.

Checklist

• A porta 25 de saída está liberada pelo provedor.
• dig -x no IP devolve o nome do servidor, e o nome devolve o mesmo IP.
• Existe exatamente um registro SPF, com todos os serviços que enviam pelo domínio.
• A chave DKIM está publicada e as mensagens chegam assinadas.
• O DMARC está publicado e os relatórios são lidos.
• "Mostrar original" no Gmail exibe PASS para SPF, DKIM e DMARC.
• Caixas, fila, chaves e certificados estão em volumes com backup.
• O IP não aparece nas listas de bloqueio mais usadas.

Rode dig -x no IP do seu servidor de e-mail agora. O nome que aparece é o mesmo que o seu servidor anuncia ao se conectar nos outros?