Servidor de e-mail próprio em VPS: porta 25, DNS reverso e por que o e-mail cai no spam

O que um provedor de e-mail realmente decide, e em que ordem

Um servidor de e-mail que recebe mensagens toma uma série de decisões, e toma a maioria delas antes de ler um único byte da sua mensagem. A ordem é a parte útil, porque um problema na etapa de conexão não se resolve com um conteúdo melhor, e uma mensagem perfeitamente autenticada vinda de um endereço sem histórico ainda assim cai na pasta de spam. Ler essa cadeia em ordem mostra onde o seu esforço realmente importa — o que quase nunca é onde as pessoas o colocam.

A primeira decisão acontece na conexão TCP: quem é essa origem, e vale a pena sequer conversar com ela? Nesse momento o provedor tem o seu endereço IP, o DNS reverso dele, e a reputação que ele ou seus provedores de blocklist atribuem a esse endereço. A segunda acontece no envelope SMTP — HELO e MAIL FROM — onde o SPF é avaliado contra o IP que está conectando. A terceira chega com os dados da mensagem, onde as assinaturas DKIM são verificadas e o DMARC decide se algum dos resultados de autenticação se alinha com o domínio no cabeçalho From: visível. Só depois de tudo isso é que começa algo parecido com filtragem de conteúdo, e nesse ponto a maior parte do resultado já está definida.

Daí seguem duas consequências. As vitórias mais baratas ficam no topo da cadeia: um registro PTR correto custa um campo preenchido num painel de controle e elimina uma categoria inteira de rejeição. E o fim da cadeia — a parte com que todo mundo se preocupa, o texto da mensagem — é justamente onde você tem menos controle, e só passa a importar depois que tudo acima dela já está limpo.

A porta 25 é a parte mais barata do problema

Quase toda grande nuvem bloqueia a porta 25 de saída por padrão, e desbloqueá-la significa pedir permissão. AWS, Google Cloud, Azure, Oracle Cloud e a maioria das grandes marcas de VPS já vêm com a saída na porta 25 filtrada, e o pedido de liberação é um formulário anexado a uma conta que já carrega sua identidade, seu cartão e seu telefone. É aí que um plano de auto-hospedagem mais costuma morrer em silêncio, e é por isso que a busca que traz a maioria das pessoas até uma página como esta é alguma variação de qual VPS tem a porta 25 liberada.

Vale a pena ser preciso sobre o que cada porta faz, porque as três são constantemente confundidas. A porta 25 é servidor-a-servidor: é como um MX entrega uma mensagem a outro, nunca é autenticada, e é a única porta que importa para entregar e-mail a quem não é seu usuário. A porta 587 é de submissão — seus próprios clientes se autenticando no seu servidor antes de ele retransmitir por eles. A porta 465 é a mesma coisa com TLS desde o primeiro byte; foi descontinuada nos anos noventa, depois oficialmente retomada pela RFC 8314, e hoje é o padrão sensato. Perder a porta 25 de saída te impede de enviar para o mundo; perder a porta 25 de entrada impede o mundo de te enviar algo, e é perfeitamente possível ter uma sem a outra e passar uma tarde inteira culpando o DNS.

Na BitVPS a porta 25 de saída já vem liberada por padrão em todos os planos e em todas as localizações. Não existe formulário nem processo de exceção porque não há nada a liberar. As portas 25, 465 e 587 de entrada ficam atrás de uma limpeza (scrubbing) que entende SMTP, em vez de um filtro genérico de camada 3, e essa é a diferença que importa durante um ataque: um filtro que entende SMTP consegue absorver uma inundação de tráfego sem descartar junto a conversa legítima de MX. A página sobre servidor de e-mail traz os detalhes, e o guia sobre DDoS explica o que essa limpeza significa e o que não significa, de forma geral.

Uma porta 25 aberta é uma condição necessária e está longe de ser suficiente — e é exatamente por isso que este guia continua por mais umas três mil palavras.

O endereço que você recebe pesa mais do que a sua configuração

A sua configuração é um punhado de registros DNS e um dia de trabalho. O endereço IP é uma história que você não escreveu. Um /24 que passou 2019 enviando spam de farmácia é lembrado; um endereço reciclado de um cliente banido no mês passado chega pré-julgado; uma faixa cujos vizinhos são barulhentos é julgada por associação em provedores que pontuam no nível do /24. Nada disso é visível de dentro da máquina, e nada disso melhora com um main.cf mais bem escrito.

Por isso, verifique antes de se comprometer, não depois. As blocklists públicas contam parte da história: a Spamhaus é a que realmente afeta a entrega, com a SBL e a CSS listando remetentes observados, a PBL listando faixas cujo operador declarou que elas não deveriam enviar e-mail diretamente, e a DBL listando domínios em vez de endereços. Vale a pena olhar a Barracuda e a SpamCop, e ambas são rápidas para limpar assim que a causa é corrigida. As duas reputações que realmente decidem a maior parte do seu resultado, porém, são privadas: Google e Microsoft mantêm cada um pontuações por IP e por domínio que você não consegue consultar de jeito nenhum, exceto pelo Postmaster Tools e pelo SNDS, e só depois que você estiver enviando volume suficiente para eles terem uma opinião formada.

Dois alertas sobre as checklists que você vai encontrar por aí. Metade delas ainda manda verificar a SORBS: a SORBS foi desativada pelo próprio dono em 5 de junho de 2024 e suas zonas hoje não respondem nada, então uma consulta contra ela não é um atestado de saúde, é uma consulta morta. E trate o UCEPROTECT nível 2 e nível 3 com ceticismo — eles listam vizinhos e sistemas autônomos inteiros por associação, e depois convidam você a pagar por uma remoção expressa, motivo pelo qual a maioria dos provedores sérios simplesmente os ignora. Correr atrás de uma listagem de nível 3 é uma boa forma de passar um fim de semana sem conseguir nada. O portal de reputação da própria Spamhaus é o que merece ser levado a sério.

Essa também é a parte em que um provedor ajuda ou não ajuda. A BitVPS verifica cada endereço contra as principais listas no momento do provisionamento e o troca antes mesmo de você fazer o primeiro login se ele aparecer listado, aloca clientes de e-mail a partir de blocos /29 que não foram reciclados de um cliente de e-mail anterior nos últimos doze meses, e consegue mover um /29 entre máquinas do mesmo datacenter sem trocar o seu IP — o que importa enormemente quando um endereço já tem uma reputação que levou seis meses para construir. Nada disso torna um endereço bom; torna-o neutro, que é o máximo que qualquer provedor pode honestamente oferecer.

PTR, HELO e o registro A precisam contar a mesma história

Este é, disparado, o motivo mais comum pelo qual um servidor de e-mail bem instalado é rejeitado, e é a coisa mais barata desta página para acertar. Três nomes precisam concordar entre si. Seu servidor anuncia um hostname no HELO; esse hostname tem um registro A apontando para o endereço de onde ele está conectando; e esse endereço tem um registro PTR apontando de volta para o hostname. Resolvendo para frente você chega ao endereço; resolvendo para trás você chega ao nome. Essa ida e volta se chama DNS reverso com confirmação direta (forward-confirmed reverse DNS), e desde fevereiro de 2024 um PTR válido deixou de ser um detalhe simpático no Gmail para virar uma exigência declarada para todo remetente, em massa ou não.

Quatro formas de isso dar errado, em ordem decrescente de frequência. Não existe PTR nenhum, porque o provedor não oferece esse campo. Existe um PTR, mas é o genérico do provedor — algo terminando no domínio da empresa de hospedagem, o que anuncia a todo provedor que aquele é um endereço alugado numa faixa que, no geral, não envia e-mail. O nome no HELO está errado: o padrão de fábrica do instalador, um hostname curto e não qualificado, ou localhost, nenhum dos quais resolve. E o que pega até gente cuidadosa: a máquina tem IPv6, o MTA prefere IPv6 quando o provedor publica um registro AAAA, e não há PTR no endereço v6 — então o e-mail para o Gmail via IPv4 funciona perfeitamente enquanto o mesmo e-mail via IPv6 é rejeitado. Configure o PTR de v6 corretamente ou trave o transporte com smtp_address_preference = ipv4 até resolver isso.

Na BitVPS, o campo de PTR é self-service no painel para todo endereço IPv4 e IPv6, aceita qualquer FQDN que você quiser sem sufixo do provedor forçado, as mudanças se propagam globalmente em menos de cinco minutos, e a edição em lote cobre até dez endereços de uma vez. A página de rede tem os detalhes, e o motivo para se importar com isso é exatamente esta seção: um provedor que obriga você a abrir um chamado para configurar o DNS reverso é um provedor que vai obrigar você a abrir um chamado toda vez que reconstruir o servidor.

SPF, DKIM e DMARC: o que cada um prova, e o que significa alinhamento

Esses três são publicados como registros DNS, levam uma hora para configurar, e são mal explicados em quase todo lugar — geralmente como três amuletos anti-spam intercambiáveis, em vez de três afirmações diferentes. O SPF (RFC 7208) diz quais endereços podem enviar e-mail em nome de um determinado remetente de envelope. O DKIM (RFC 6376) anexa uma assinatura criptográfica sobre os cabeçalhos e o corpo, para que a mensagem possa provar qual domínio assumiu a responsabilidade por ela. Nenhum dos dois diz absolutamente nada sobre o endereço que o seu destinatário realmente vê.

Esse é o trabalho do DMARC (RFC 7489), e é por isso que alinhamento é a palavra que importa. O DMARC passa quando o SPF ou o DKIM passam e o domínio autenticado corresponde ao domínio no cabeçalho From: visível. É aqui que mora a falha clássica: seu e-mail passa no SPF porque o endereço de retorno está num domínio que o servidor de envio controla, mas esse domínio não é o que aparece no From:, então não há alinhamento, e sem uma assinatura DKIM para segurar a peteca, o DMARC falha numa mensagem que parecia perfeitamente autenticada nos logs. A outra falha clássica é publicar p=reject no primeiro dia, antes de ler um único relatório, e descobrir um mês depois que o sistema de faturamento vinha sendo rejeitado em silêncio o tempo todo. Comece com p=none e um endereço rua, leia o que chegar, e só depois aperte o controle.

Duas notas operacionais que valem mais do que parecem. Mantenha o registro SPF dentro do limite de dez consultas DNS — cada include: consome uma, e encadear três fornecedores SaaS estoura o limite e vira um erro permanente, não uma falha leve. E gire os seletores DKIM de vez em quando, em vez de nunca: um seletor novo é barato de adicionar, e já ter um segundo publicado é a diferença entre uma rotação de chave de cinco minutos e uma indisponibilidade.

O piso mudou em 2024, e mudou de novo em 2025

Por vinte anos, a régua mínima para enviar e-mail foi mais ou menos «ter um PTR e não estar na Spamhaus». Isso mudou em fevereiro de 2024, quando Google e Yahoo publicaram requisitos para remetentes praticamente idênticos e passaram a aplicá-los. Todo remetente — inclusive você, enviando quatro mensagens por dia — agora precisa de um PTR válido com confirmação direta, TLS na conexão, e pelo menos um entre SPF ou DKIM. Remetentes acima de aproximadamente cinco mil mensagens por dia para um único provedor precisam de SPF e DKIM e um registro DMARC, um cabeçalho funcional de cancelamento em um clique conforme a RFC 8058, e uma taxa de reclamações de spam mantida abaixo de 0.3%.

A Microsoft seguiu o exemplo em 5 de maio de 2025 com uma regra no mesmo formato para Outlook.com, Hotmail e Live: domínios que enviam mais de cinco mil mensagens por dia para essas caixas de consumidor precisam ter SPF, DKIM e DMARC, com e-mail fora de conformidade sendo primeiro roteado para o Lixo Eletrônico e depois rejeitado de vez. O suporte a remetentes da Microsoft e as boas práticas do Yahoo valem dez minutos de leitura antes de você enviar qualquer coisa.

A consequência prática para um servidor pessoal ou de uma equipe pequena não é que os limiares vão te pegar — não vão — mas que a linha de base sem autenticação hoje é genuinamente anômala. E-mail sem registro DMARC vindo de um endereço sem histórico já foi algo comum. Em 2026, isso se parece com o perfil exato de tudo que os filtros foram criados para barrar. Configure como se você fosse um remetente em massa, mesmo sem ser — porque o custo é uma tarde de trabalho, e a alternativa é ser avaliado junto de uma população à qual você não pertence.

Aquecendo um endereço que ninguém nunca viu

Um endereço novo não começa exatamente neutro, começa desconhecido, e o desconhecido é tratado com suspeita na proporção do quanto você envia. A rampa que funciona é entediante: comece com correspondência genuína para pessoas que realmente vão abrir e responder, mantenha o volume diário mais ou menos estável e deixe-o crescer aos poucos em vez de aos saltos, e nunca aponte uma lista comprada ou exportada de algum lugar para um endereço recém-criado. Engajamento é o sinal que transforma desconhecido em confiável, e não existe atalho que produza isso.

Meça com as ferramentas que os próprios provedores oferecem, em vez de olhar para a sua própria caixa de entrada. O Postmaster Tools do Google mostra reputação de domínio e de IP, taxa de reclamações de spam e taxa de aprovação na autenticação assim que você verifica o domínio — embora fique vazio até você enviar volume suficiente para haver algo a agregar, o que para um servidor pessoal pode significar nunca, e tudo bem. O SNDS da Microsoft faz o mesmo para o Outlook.com e se combina com o Junk Mail Reporting Program, que encaminha reclamações direto para você. Um serviço de pontuação de disparo único é útil para pegar um registro quebrado em dez segundos, e inútil para qualquer outra coisa — ele não diz nada sobre reputação, porque também não tem histórico com você.

Seja honesto sobre qual é o provedor mais difícil. O Outlook.com é onde um endereço novo sofre por mais tempo: é comum um servidor corretamente configurado, com autenticação perfeita, ficar preso no Lixo Eletrônico lá por semanas, enquanto o Gmail já aceita desde a primeira mensagem. O remédio é tempo, consistência e destinatários que tirem a mensagem do Lixo Eletrônico — não mais um registro DNS. Se a entregabilidade no Outlook.com desde o primeiro dia é uma exigência de negócio, e não apenas uma preferência, esse é um dos sinais de que você quer um relay em vez de um remetente auto-hospedado, assunto da última seção.

O que rodar, e quanta máquina isso exige

Quatro formatos cobrem quase todo mundo. O Postfix combinado com o Dovecot para IMAP e o rspamd para filtragem é a implantação de referência: três daemons, configuração em texto puro, e todo erro que você algum dia vai ver já foi respondido em algum lugar. O OpenSMTPD faz o mesmo trabalho com um arquivo de configuração que dá para ler de uma sentada só, o que vale mais do que parece às três da manhã. O Stalwart é um binário único que fala SMTP, IMAP e JMAP com filtragem embutida, e é a opção mais agradável para quem está começando do zero hoje em dia. E o Mailcow ou o Mail-in-a-Box montam tudo para você, webmail incluso, ao preço de uma stack que você não escolheu e não consegue desmontar com facilidade.

O dimensionamento depende menos das caixas de e-mail do que do que você acopla na frente delas. SMTP e IMAP em si são baratos; algumas dezenas de caixas são um arredondamento em qualquer máquina moderna. A memória vai para a filtragem. O rspamd é modesto, algumas centenas de megabytes com seus mapas carregados. O ClamAV não é: só o banco de assinaturas já empurra o uso para bem além de um gigabyte de memória residente, e é o componente com maior chance de fazer uma instância pequena começar a sofrer swap — o que, num servidor de e-mail, significa fila entupida e entrega cada vez mais lenta, até o ponto em que os provedores passam a adiar (defer) suas mensagens. Rode-o se você tiver a RAM, pule-o se não tiver, e deixe o rspamd carregar o peso.

Traduzindo para planos reais: um Starter a $8.50 com 2 vCPU, 4 GB de RAM e 60 GB de NVMe roda Postfix, Dovecot e rspamd confortavelmente para um domínio pessoal, desde que você deixe o ClamAV de fora. Um Growth a $13.50 com 4 vCPU, 8 GB e 120 GB é o tamanho em que você para de se preocupar com isso — vinte a trinta caixas de e-mail com filtragem completa, e bastante folga para um armazenamento de e-mail que cresce por anos. O armazenamento é o eixo que realmente se esgota primeiro, porque e-mail é guardado para sempre por todo mundo que já recebeu algum.

Colocando tudo no ar, na ordem certa

1. Aponte o domínio e implante a instância. Decida o hostname com o qual o servidor vai se identificar — mail.example.com é a convenção — publique o registro A dele, adicione AAAA só se você pretende enviar via IPv6, e publique o MX do domínio apontando para esse nome. Escolha a localização mais próxima das pessoas com quem você troca e-mail; na BitVPS a instância fica no ar cerca de sessenta segundos depois da confirmação do pagamento, já com a porta 25 de saída aberta.

2. Configure o DNS reverso para condizer. Ajuste o PTR do endereço IPv4 — e do endereço IPv6, se você publicou um AAAA — para exatamente o hostname do passo um. A resolução direta e a reversa precisam concordar nos dois sentidos. É um único campo no painel, e é o minuto de maior valor de todo o procedimento.

3. Abra as portas certas nos dois sentidos. 25 de saída para entregar, 25 de entrada para receber, 587 e 465 para seus próprios usuários enviarem, 993 para IMAP, tudo o mais fechado. Um firewall que permite a 25 de saída mas não a de entrada parece exatamente um problema de DNS na primeira hora de depuração, e não é.

4. Instale o MTA e dê a ele uma identidade de verdade. Postfix, OpenSMTPD ou Stalwart; defina o nome do HELO como o hostname do passo um; ative o TLS com um certificado para esse nome. O Let's Encrypt é gratuito e é o que a maior parte da internet apresenta. Envie uma mensagem para si mesmo e leia os cabeçalhos antes de continuar — todo passo seguinte assume que este funcionou.

5. Publique SPF, DKIM e DMARC. Um registro SPF listando o endereço de envio, terminando em ~all enquanto você testa. Uma chave DKIM de 2048-bit com o seletor publicado e a assinatura ativada. Um registro DMARC em p=none com um endereço rua para os relatórios começarem a chegar. Três registros DNS, sem custo nenhum, uma hora no máximo.

6. Leia os resultados de autenticação, não a caixa de entrada. Envie para o Gmail, para o Outlook.com e para um provedor corporativo, depois abra o Authentication-Results de cada um. Você quer ver spf=pass, dkim=pass, dmarc=pass, e o alinhamento contra o domínio no From: visível. Cair no spam com os três aprovados é um problema de reputação; cair no spam com uma falha é um problema de configuração. Eles se resolvem de formas completamente diferentes, e confundi-los desperdiça semanas.

7. Aperte o controle quando os relatórios estiverem limpos. Depois de uma ou duas semanas de relatórios DMARC sem nenhuma fonte legítima falhando, passe para p=quarantine, depois para p=reject, e mude o SPF de ~all para -all. Apertar antes de ler os relatórios é como as pessoas acabam bloqueando suas próprias faturas por um mês sem perceber.

8. Adicione as partes que todo mundo esquece. Publique MTA-STS e TLS-RPT para que outros remetentes saibam que devem insistir em TLS com você, adicione DANE se a sua zona for assinada, coloque o rspamd na frente da caixa de entrada, faça backup do armazenamento de e-mail em algum lugar que não seja esta máquina, e criptografe-o em repouso — o guia de criptografia total de disco explica o que isso protege e o que não protege. Depois fique de olho na fila de saída: uma fila que cresce silenciosamente é o primeiro sintoma de um problema de reputação, e ela aparece dias antes de você notar respostas que faltam.

Quando auto-hospedar é a ferramenta errada

Existem casos em que manter seu próprio remetente é uma má troca, e ser claro sobre eles é mais útil do que mais um parágrafo de incentivo. Marketing em massa a partir de um endereço novo é o caso óbvio: um endereço recém-criado, sem histórico, enviando milhares de mensagens é exatamente a assinatura que os filtros existem para pegar, e nenhuma configuração salva isso. E-mail transacional em que uma mensagem perdida custa dinheiro — redefinição de senha, confirmação de pedido, códigos de dois fatores — pertence a uma infraestrutura com reputação já estabelecida, porque as duas semanas que um endereço novo passa provando seu valor são duas semanas de chamados de suporte. E qualquer equipe sem alguém disposto a olhar a fila de e-mail num domingo é uma equipe que vai descobrir que o envio está represado desde sexta-feira.

Existe também uma troca envolvendo anonimato que a maioria dos artigos pula. Um servidor de e-mail é a coisa menos anônima que você pode rodar. Ele publica um domínio, um endereço estável, um registro PTR nomeando esse domínio, um registro MX amarrando tudo isso, e entrega a cada destinatário um conjunto completo de cabeçalhos descrevendo o caminho percorrido. Anonimato e um MX público puxam em direções opostas, e se o motivo de você estar aqui é privacidade e não controle, leia o quão rastreável a hospedagem paga em cripto realmente é antes de construir qualquer coisa. Auto-hospedar realmente remove um terceiro do seu e-mail armazenado e dos metadados dele, o que é um ganho real e que vale a pena — mas isso não torna o e-mail em si anônimo, e não pode tornar, porque metade de toda conversa vive na caixa de entrada de outra pessoa.

O arranjo que funciona para a maioria das pessoas é uma divisão. Mantenha o e-mail que precisa chegar mesmo num provedor com reputação estabelecida, auto-hospede um segundo domínio para a correspondência que você quer tirar de infraestrutura de terceiros, e deixe cada um carregar o peso no qual é bom. Custa uma zona DNS extra, significa que nenhum dos dois sistemas está fazendo um trabalho para o qual não serve, e é o que boa parte de quem roda um servidor de e-mail na BitVPS realmente faz. Seja o que for que você envie, apenas com opt-in — listas compradas ficam fora da nossa política de uso aceitável, e são a forma mais rápida de queimar um endereço que estava limpo quando o entregamos a você.