Servidor de e-mail em VPS: SPF, DKIM, DMARC
Instalar o Postfix ou um pacote pronto como o Mailcow numa VPS leva uma hora. Fazer as mensagens chegarem à caixa de entrada, e não ao spam, é mais difícil: os serviços de e-mail olham a porta, o endereço do servidor, a reputação dele e três registros DNS. Vamos ver o que conferir no provedor antes da compra e como configurar SPF, DKIM e DMARC.
Um servidor de e-mail faz dois trabalhos diferentes: recebe mensagens para o seu domínio e envia as suas mensagens para servidores de terceiros. O recebimento quase sempre funciona de imediato, se houver um registro MX no DNS. O envio é mais complicado: o lado que recebe decide se confia no seu servidor e, para isso, verifica a rede, o endereço e as assinaturas. Se qualquer elo não estiver configurado, as mensagens são rejeitadas ou vão para o spam sem nenhum aviso.
A porta 25 nos provedores
Os servidores trocam e-mails entre si pela porta 25. As portas 587 e 465 servem para os programas que entregam a mensagem ao próprio servidor; até o servidor MX de outra pessoa, a mensagem só chega pela 25. Por isso, a condição principal para ter e-mail próprio é a porta 25 de saída aberta.
Muitos provedores a mantêm fechada por padrão: servidores novos são usados com frequência para tentar enviar spam, e as reclamações e a má reputação recaem sobre os endereços do provedor. Segundo o catálogo da accsly em 3 de novembro de 2026, foi possível descobrir as condições da porta 25 em 117 provedores: em 39% ela está fechada, em 37% é aberta mediante pedido, em 24% vem aberta de início. Grandes plataformas de nuvem muitas vezes a fecham de vez, sem possibilidade de abertura.
Se a porta é aberta mediante pedido, o provedor costuma querer saber o domínio, a finalidade do e-mail e, às vezes, que o servidor não foi pago ontem. Escreva diretamente: «e-mail corporativo do domínio, cerca de N mensagens por dia, sem envios em massa». Para verificar a porta num servidor já contratado: nc -vz -w 5 gmail-smtp-in.l.google.com 25; se não houver conexão, a porta está fechada do lado do provedor. Planos de provedores em que a porta está aberta ou é aberta mediante pedido estão na seleção VPS para servidor de e-mail.
PTR e nome do servidor
O Google exige de todos os remetentes que o endereço do servidor tenha um registro DNS reverso (PTR) e que ele corresponda ao direto. O esquema é este: o servidor tem um nome, por exemplo mail.example.com; o registro A desse nome aponta para o endereço do servidor, o PTR do endereço aponta de volta para mail.example.com, e o servidor se apresenta com esse mesmo nome no comando HELO. Quem define o PTR é o provedor, no painel ou pelo suporte. Se o envio também for feito por IPv6, o PTR é necessário também para o endereço IPv6. Detalhes no artigo IPv4 e IPv6 no servidor. Numa NAT VPS sem endereço próprio não dá para configurar um PTR próprio, e esse servidor não serve para e-mail.
Reputação do endereço IP
O endereço da VPS pode ter pertencido a qualquer pessoa antes de você. Se foi usado para enviar spam, ele pode constar em listas públicas de endereços conhecidos por enviar spam (DNSBL), e parte dos serviços de e-mail vai rejeitar suas mensagens desde o primeiro dia. Antes de começar, verifique o endereço em serviços públicos de consulta de reputação; se ele estiver nas listas, peça outro ao provedor ou solicite a remoção: a maioria das listas tem um formulário para isso.
Um endereço novo e limpo tem outro problema: não tem histórico, e os grandes serviços o tratam com desconfiança. Comece com um volume pequeno de mensagens para destinatários reais e aumente aos poucos. O Google exige manter abaixo de 0,3% a fração de mensagens marcadas como spam pelos destinatários; dá para acompanhá-la no Google Postmaster Tools, que é gratuito. Envios em massa devem sair por um serviço separado ou, pelo menos, de um endereço e subdomínio separados, para que a reputação deles não afete o e-mail de trabalho.
SPF: quem pode enviar em nome do domínio
O SPF (RFC 7208) é um registro TXT na raiz do domínio com a lista de servidores autorizados a enviar mensagens em nome dele. O servidor que recebe compara com ele o endereço do remetente no envelope da mensagem (MAIL FROM) e o nome no HELO.
example.com. TXT "v=spf1 mx ip4:203.0.113.10 -all"
mxeip4:são os seus servidores; se o e-mail também sai por um serviço externo, adicione oinclude:dele.-all: os demais estão proibidos de enviar (fail);~all: «provavelmente não» (softfail), útil durante a configuração.- O domínio deve ter exatamente um registro SPF. Os mecanismos que exigem consultas ao DNS (
include,a,mx,exists,redirect) podem ser usados no máximo 10 vezes, contando os aninhados; se o limite for ultrapassado, a verificação retorna erro (permerror) e o SPF simplesmente não funciona.
DKIM: assinatura das mensagens
O DKIM (RFC 6376) é uma assinatura digital dos cabeçalhos e do corpo da mensagem. O servidor assina cada mensagem com a chave privada, e a chave pública é publicada no DNS com o nome seletor._domainkey.example.com. O destinatário verifica a assinatura e se certifica de que a mensagem foi enviada pelo domínio da assinatura e não foi alterada no caminho.
mail2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
O tamanho da chave RSA é de no mínimo 1024 bits, como exigem o RFC 8301 e o Gmail; o recomendado é 2048. As chaves são geradas pelo OpenDKIM, pelo rspamd ou pelo painel do pacote de e-mail, que também preenche o registro pronto. O seletor serve para a troca de chave: você publica a chave nova com um seletor novo, muda a assinatura e apaga o registro antigo alguns dias depois, quando as mensagens já enviadas tiverem sido verificadas.
DMARC: política e relatórios
O DMARC (RFC 7489) liga o SPF e o DKIM ao endereço no campo «De», que o destinatário vê. Uma mensagem passa no DMARC se passou no SPF ou no DKIM e o domínio verificado coincide com o domínio do «De» (por padrão, basta coincidir o domínio principal). O registro é publicado com o nome _dmarc:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
p=none: só observar;p=quarantine: mensagens que não passam no DMARC vão para o spam;p=reject: rejeitá-las.rua: endereço para os relatórios agregados diários, que mostram quem envia mensagens em nome do domínio e de quais endereços.
Comece com p=none, leia os relatórios por 2–4 semanas, confirme que todas as suas fontes legítimas de e-mail passam na verificação e mude para quarantine e depois para reject.
O que o Gmail e o Outlook exigem
Desde 1º de fevereiro de 2024, o Gmail exige de todos os remetentes SPF ou DKIM, registro PTR correto, transmissão via TLS e taxa de reclamações de spam abaixo de 0,3%. Quem envia mais de 5.000 mensagens por dia para endereços do Gmail precisa de SPF e DKIM juntos, de um registro DMARC (basta p=none) com o domínio do «De» coincidindo com o domínio do SPF ou do DKIM e, nas mensagens promocionais, de cancelamento de inscrição com um clique. Desde 5 de maio de 2025, o Outlook.com adotou regras parecidas para remetentes a partir de 5.000 mensagens por dia: SPF e DKIM devem passar, e o DMARC deve ser no mínimo p=none, com coincidência de domínio; mensagens sem isso vão para o «Lixo Eletrônico» ou são rejeitadas.
Para um servidor pequeno a conclusão é simples: configure os três registros logo de início, mesmo que as mensagens sejam poucas. Para conferir o resultado, envie uma mensagem para a sua caixa no Gmail e abra «Mostrar original»: lá aparecem os resultados de SPF, DKIM e DMARC.
Quando não vale ter e-mail próprio
Um servidor próprio se justifica se você precisa de controle sobre as caixas e os dados ou de muitos endereços em vários domínios. Se o site só precisa enviar notificações e a porta 25 está fechada, é mais simples configurar o envio por um serviço de e-mail externo pela porta 587: SPF, DKIM e DMARC continuam sendo configurados para o seu domínio. Um servidor com e-mail completo e antispam se vira com 2 GB de memória; o espaço em disco precisa ter folga para as caixas e os backups. Quando o site e o e-mail devem sair da hospedagem para uma VPS está no artigo Quando migrar da hospedagem compartilhada para uma VPS.