Preciso de um IP dedicado para rodar um servidor de e-mail?

Efetivamente sim. A entregabilidade depende de um registro de DNS reverso (PTR) que combine com o hostname do seu e-mail, e você só pode definir um PTR num IP que é exclusivamente seu. Num endereço compartilhado ou NAT você não controla o PTR, então os servidores receptores veem um hostname genérico ou incompatível e te tratam como suspeito. Um IP dedicado é a base para e-mail de saída.

O que é um registro PTR e por que o e-mail precisa dele?

Um registro PTR é DNS reverso — ele mapeia seu IP de volta a um hostname, o oposto de um registro A normal. Quando seu servidor se conecta ao Gmail ou Outlook, o lado receptor busca quem é dono do seu IP. Se o PTR está faltando ou é genérico (como static.203-0-113-19.rev.example-isp.net), isso é um ponto imediato contra você. Servidores de e-mail esperam que o PTR combine com o nome que seu servidor anuncia no HELO.

Por que a porta 25 de saída é bloqueada por padrão na maioria dos hosts de VPS?

A porta 25 é o maior vetor de spam, então os hosts a mantêm fechada até você pedir e explicar o que está enviando. Não é um bug — é prevenção de abuso. Um script comprometido disparando spam pode queimar a reputação de um IP, e numa sub-rede compartilhada esse dano respinga em outros clientes. Hosts respeitáveis, EQVPS incluída, a abrem por pedido em vez de por padrão.

Posso rodar um servidor de e-mail num IP NAT ou compartilhado?

Você pode receber e-mail por encaminhamento de portas, mas enviar de forma confiável é outra história. Sem o próprio IP você não pode definir um PTR compatível, e você herda qualquer reputação que o endereço compartilhado já tem — boa ou má. Para qualquer coisa que você precisa entregar, use um IP dedicado com histórico limpo e um PTR que você controla.

Vale a pena auto-hospedar e-mail em 2026?

Depende do porquê. Se você quer controle sobre seus dados e seu domínio sem terceiros no circuito, é bem viável num VPS pequeno. Mas a entregabilidade é trabalho contínuo — você vigia listas de bloqueio, rotaciona chaves DKIM e mantém o IP limpo. Para um projeto paralelo de baixo risco, encaminhar por um provedor existente é menos dor. Auto-hospede quando o controle importa mais que a conveniência.

Rodando um servidor de e-mail num VPS: o que de fato te mantém fora do spam

Seu servidor de e-mail funciona. O Postfix inicia, os logs parecem limpos, você envia uma mensagem de teste para o seu Gmail — e ela cai no spam. Ou simplesmente some. Nada na sua config está quebrado. O software fez exatamente o que você mandou.

O problema é que o servidor do outro lado ainda não confia no seu IP, e o e-mail esconde uma pilha inteira de pequenas verificações de confiança que todas precisam se alinhar antes de a caixa de entrada de um estranho te deixar entrar. Acerte-as e a entrega em grande parte se resolve. Erre uma e você está gritando para uma pasta de spam.

Três coisas carregam a maior parte do peso: DNS reverso, autenticação do remetente e se o seu host sequer te deixa falar na porta 25. Nenhuma delas é difícil. Elas só são fáceis de esquecer, e cada uma é um veto silencioso.

A que todo mundo esquece: DNS reverso

O DNS direto é a parte que você conhece — um nome aponta para um IP. O DNS reverso é o espelho: um IP aponta de volta para um nome. Esse registro se chama PTR, e ele mora com quem controla o IP, não na zona do seu domínio.

Eis por que importa. Quando seu servidor abre uma conexão com o SMTP do Gmail, uma das primeiras coisas que o lado receptor faz é uma busca reversa no seu IP — quem é isto? Rode você mesmo:

dig -x 203.0.113.19 +short

Se isso voltar com algo como static.203-0-113-19.rev.example-isp.net, ou voltar vazio, você já perdeu pontos. Esse nome genérico diz "algum VPS aleatório" e, pior, não combina com o hostname pelo qual seu servidor se apresenta na saudação HELO. Servidores receptores marcam essa incompatibilidade com força. Alguns rejeitam de cara.

O que eles querem ver é um PTR que combine com o hostname do seu e-mail. Se o seu servidor diz HELO mail.example.com, a busca reversa no IP dele deve retornar mail.example.com. Direto e reverso concordam, a história é consistente, e você parece um servidor de e-mail de verdade em vez de uma máquina sequestrada.

Definir um PTR tradicionalmente significava abrir um ticket de suporte com quem é dono do bloco de IP e esperar. Nos planos com IP dedicado da EQVPS é um campo no seu painel — digite o hostname, ele escreve direto no registro pela API do provedor, e fica no ar em segundos. É esse todo o ponto de fazer isso self-service: o DNS reverso é a etapa que as pessoas pulam porque costumava ser irritante.

Autenticação: SPF, DKIM, DMARC

Esses três registros de DNS dizem aos servidores receptores que o e-mail alegando ser do seu domínio realmente é. Pule-os e você é um estranho não verificado.

SPF é um registro TXT listando quais servidores têm permissão para enviar pelo seu domínio. O Gmail o checa e pergunta: esta mensagem veio de um IP que você autorizou?
DKIM assina criptograficamente cada mensagem que sai. O receptor puxa sua chave pública do DNS e verifica que a assinatura não foi forjada em trânsito.
DMARC amarra os dois e diz aos receptores o que fazer quando uma verificação falha — nada, quarentena ou rejeição — e para onde enviar relatórios.

Você quer os três. SPF e DKIM provam que o e-mail é legitimamente seu; o DMARC transforma essa prova numa política. São talvez vinte minutos de edições de DNS, e é a diferença entre "remetente verificado" e "quem?".

A porta 25, e por que ela está fechada

Eis a que surpreende as pessoas. A porta 25 de saída — a porta que servidores de e-mail usam para conversar entre si — é bloqueada por padrão em essencialmente todo host de VPS. Nós também.

Isso é deliberado. A porta 25 é o canhão de spam clássico, então ela fica fechada até você pedir e dizer o que de fato está enviando. Nós a abrimos por pedido em vez de deixá-la aberta para qualquer um que sobe um servidor.

E há uma ressalva honesta aqui que vale dizer claramente: com uma porta 25 aberta vem responsabilidade. Um script comprometido ou um relay mal configurado bombeando spam, e a reputação do seu IP se foi — às vezes por semanas. Numa sub-rede compartilhada essa bagunça respinga nos seus vizinhos, que é exatamente por que os hosts são cautelosos com isso. Se você nos pedir para abrir a 25, mantenha seu servidor limpo, porque a reputação que você está protegendo é em parte nossa também.

Por que o IP dedicado não é opcional

Tudo isso volta a um requisito: o IP tem que ser seu. Num setup NAT ou num endereço compartilhado você não pode definir o próprio PTR, porque o endereço não é exclusivamente seu para apontar. Você também herda qualquer reputação que o IP compartilhado já carrega — e você não faz ideia do que o último inquilino fez com ela.

Um IP dedicado te dá um PTR que você controla, uma reputação que é sua para construir e um ponto de partida limpo. Para e-mail de saída isso não é um luxo; é o piso.

A conclusão honesta

Auto-hospedar e-mail em 2026 é trabalho real e contínuo. Não é definir-e-esquecer — você vai vigiar listas de bloqueio, rotacionar chaves DKIM e ocasionalmente descobrir por que um provedor específico começou a te fazer greylisting. Se isto é um projeto paralelo de baixo risco, honestamente, encaminhar por um provedor de e-mail existente vai te poupar dores de cabeça.

Mas se você quer controle de verdade — seus dados, seu domínio, ninguém mais lendo os cabeçalhos — é bem viável num VPS pequeno. O encanamento de confiança acima é cerca de 90% da batalha, e nada disso é exótico. Consiga um IP dedicado, defina o PTR para combinar com o seu hostname, publique SPF/DKIM/DMARC, peça-nos para abrir a porta 25, depois envie um teste por uma ferramenta como o mail-tester.com e conserte o que ela apontar. Faça isso e você não está mais gritando para uma pasta de spam — você é um servidor de e-mail em que as caixas de entrada das pessoas de fato confiam.