Rodar um servidor de e-mail que chega à caixa de entrada

O Postfix não é o problema. Ele vem entregando e-mail com competência desde 1998, e vai fazer exatamente o que você configurar para ele fazer. O problema é que o SMTP não concede nenhuma credibilidade a ninguém por padrão, então um gateway de recebimento precisa decidir se acredita ou não em um servidor desconhecido — e ele toma essa decisão em uma ordem fixa, quase sempre antes de examinar sua mensagem:

• O IP que se conecta, primeiro e mais difícil. Antes de o seu servidor dizer qualquer coisa além de EHLO, o gateway já consultou o endereço em blocklists públicas (Spamhaus SBL, XBL, PBL e CSS, Barracuda, SpamCop) e no seu próprio banco de reputação privado, que também acompanha o /24 ao redor e o ASN. Um endereço listado é recusado já na conexão, com uma rejeição que você talvez nunca veja, se ninguém estiver lendo os logs.
• O nome que esse endereço afirma ter. Um PTR ausente faz várias grandes provedoras recusarem a conexão de cara. Um PTR genérico atribuído pelo provedor, no estilo ip-203-0-113-10.example-host.net, é pior do que parece — é a assinatura exata de linhas residenciais e máquinas sem monitoramento, que é onde vivem as botnets.
• Autenticação. SPF, DKIM e depois DMARC, avaliados nessa ordem e combinados pela regra de alinhamento da próxima seção. É aqui que uma configuração que parece certa no papel costuma falhar.
• Só então, a mensagem. Heurísticas de conteúdo, higiene da lista, a taxa de reclamações que você gera, e como os destinatários se comportam nas semanas seguintes.

Três desses quatro pontos são decididos antes de um único byte do seu conteúdo ser avaliado, o que reformula todo o exercício: você não está escrevendo e-mails melhores, você está construindo uma credencial. As duas maiores provedoras de recebimento colocaram o mínimo por escrito, então não há chute quanto ao piso. Todo remetente precisa de SPF ou DKIM, DNS direto e reverso válidos, TLS na conexão, e uma taxa de reclamações de spam abaixo de 0.3%; qualquer coisa enviada em volume precisa de SPF e DKIM e um registro DMARC com alinhamento, mais cancelamento de inscrição em um clique. Trate isso como o pedágio de entrada, não como a meta.

Cada registro responde a uma pergunta diferente, e o jeito útil de guardar isso na cabeça é pensar no que um falsificador precisaria controlar para fraudar cada um.

• PTR — quem é dono do endereço concorda com você. A zona reversa de um IP é delegada a quem detém a alocação, e é por isso que este é o único registro que você não consegue adicionar no seu registrador. Um PTR apontando para mail.example.com, mais um registro A para mail.example.com apontando de volta para o mesmo IP, é FCrDNS — DNS reverso confirmado no sentido direto. Isso prova que quem detém o endereço e quem detém o domínio são a mesma parte, ou pelo menos estão em bons termos.
• SPF — este servidor tinha permissão para enviar por este envelope. Um registro TXT listando os hosts autorizados a enviar por um domínio. A armadilha é o escopo: o SPF autentica o remetente do envelope (o MAIL FROM, que vira Return-Path) e o nome do HELO. Ele não diz absolutamente nada sobre o cabeçalho From: que o destinatário realmente lê, e é por isso que o SPF sozinho nunca impediu ninguém de se passar por você.
• DKIM — esta mensagem foi assinada por um domínio e não foi alterada. Seu servidor assina cabeçalhos selecionados e o corpo com uma chave privada; a metade pública fica no DNS em <selector>._domainkey.<domain>. Ao contrário do SPF, ele sobrevive a ser encaminhado, porque a prova viaja dentro da mensagem, em vez de depender de qual IP fez a entrega.
• DMARC — e este é o que todo mundo erra. O DMARC não exige apenas que o SPF ou o DKIM tenham passado. Ele exige que um mecanismo aprovado esteja alinhado com o domínio no cabeçalho From: visível. O alinhamento relaxado aceita um domínio organizacional correspondente (então mail.example.com se alinha com example.com); o alinhamento estrito exige uma correspondência exata.

Essa regra de alinhamento merece ser dita à parte, porque ela produz a discussão de suporte mais exasperante que existe em e-mail auto-hospedado: uma mensagem pode passar no SPF, passar no DKIM, e mesmo assim falhar no DMARC — quando os dois passaram para um domínio que não é o do From:. Isso acontece no momento em que o e-mail sai por um relay que reescreve o envelope, ou quando um pacote assina com o próprio hostname em vez do seu domínio. Tudo parece verde nos seus logs e a mensagem continua em quarentena. Leia o alinhamento, não a aprovação.

Menos hardware do que você imagina, e mais compromisso do que você gostaria.

• Um domínio que você pretende manter. A reputação se liga ao domínio com a mesma força que ao endereço, e ela se acumula ao longo de meses. Um domínio que você pode largar ano que vem não vale a pena aquecer.
• Um plano modesto, dimensionado para filtragem, não para e-mail. A entrega de mensagens quase não custa nada; a filtragem de spam e a indexação é que consomem RAM. O Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) roda Postfix, Dovecot e Rspamd para um domínio e um punhado de caixas de entrada sem reclamar. O Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) é o piso honesto para um pacote containerizado que também quer ClamAV e um índice de busca. O disco é a parte que cresce, então dimensione para o arquivo, não para hoje.
• Um IPv4 dedicado sem histórico, e um IPv6 /64 roteado. Todo plano vem com os dois. Este é o componente que você não consegue consertar depois com configuração, e o motivo pelo qual endereços reciclados de nuvens baratas são uma falsa economia para e-mail.
• Porta 25 de saída. Aberta em todo plano, sem chamado de desbloqueio para abrir. A política de uso aceitável proíbe e-mail em massa não solicitado e relays abertos, que é exatamente o que mantém as faixas de IP entregáveis para todo mundo que envia de forma legítima.
• Debian 13 da biblioteca de templates, e uma jurisdição escolhida de propósito. E-mail não é sensível a latência, então escolha o local pensando em onde a caixa de e-mail deve ficar legalmente, não em alguns milissegundos.

Existem três formatos, e escolher o errado é assim que fins de semana desaparecem.

• Montado à mão. Postfix como MTA, Dovecot para IMAP e autenticação, Rspamd para filtragem e assinatura DKIM. Talvez duzentas linhas de configuração no total, todas as quais você pode ler e nenhuma das quais fica escondida. É o que dá mais controle, exige mais entendimento, e é a versão que este guia assume.
• Um pacote pronto. O mailcow é completo em recursos e baseado em containers, e realmente quer 4 GB antes de ficar confortável. O Mail-in-a-Box é opinativo e agradável se você aceitar as escolhas dele exatamente como são. O Stalwart é um binário único que cobre SMTP, IMAP, JMAP e filtragem em um só processo, e é de longe o mais leve dos três. Todos eles instalam em uma hora; nenhum deles vai cuidar do seu DNS por você.
• Um relay que você não roda. Se o requisito é “minha aplicação precisa mandar redefinições de senha” e nunca vai existir uma caixa de entrada, um MTA é o formato errado por completo. Configure um smarthost e gaste a tarde com outra coisa.

A stack não decide a sua capacidade de entrega. Ela decide quanto do seu sábado isso custa. Tudo que determina se o seu e-mail chega acontece no DNS e na reputação de um endereço — que é o assunto inteiro da próxima seção.

Um endereço sem reputação não começa neutro. A expectativa padrão de um gateway para um IP de datacenter desconhecido que de repente começou a enviar mensagens é mais perto de “provavelmente indesejado”, porque é isso que a esmagadora maioria desses endereços acaba sendo. O aquecimento é o processo de substituir essa expectativa por evidência, e nenhum atalho técnico consegue acelerá-lo.

• Comece pequeno e suba devagar. Dezenas de mensagens por dia na primeira semana, dobrando mais ou menos a cada poucos dias, até chegar ao volume normal em duas a quatro semanas. Um remetente que vai de zero a mil da noite para o dia é indistinguível de uma máquina comprometida, e é tratado como uma.
• Engajamento pesa mais que volume. Mensagens que são abertas, respondidas e tiradas do spam por pessoas de verdade valem muito mais do que throughput. Envie primeiro para os destinatários com mais chance de interagir — você mesmo, colegas, correspondentes que já te conhecem.
• Seja consistente. Duzentas mensagens em um dia e nada por três semanas nunca constrói um perfil estável. Um fluxo constante e modesto vence uma explosão errática com o mesmo total mensal.
• Mantenha as reclamações sob controle. O limite publicado é 0.3%, e acima disso quase nada mais do que você faz importa muito. Abaixo de 0.1% é onde você quer viver.
• Não misture fluxos. Newsletters e redefinições de senha no mesmo endereço significam que uma taxa de reclamação de marketing arrasta a recuperação de conta da sua empresa para o spam. Se separar isso vale a pena, um segundo IPv4 limpo e dedicado custa $2.00/mo, com seu próprio rDNS.

Configuração é reproduzível em uma hora. Reputação leva meses e pode ser destruída em uma única noite por um formulário de contato comprometido. Trate o endereço como a coisa que você está realmente protegendo.

• Monitore em vez de reagir. Confira as grandes provedoras em um cronograma, em vez de depois de uma reclamação — o nosso passo a passo sobre como verificar se um IP está na lista negra cobre quais listas têm peso, como ler uma listagem e como a remoção realmente funciona.
• Limite a taxa da sua própria saída. Um teto no MTA é o que fica entre um script comprometido e dez mil mensagens saindo antes de você acordar. Essa única configuração já salvou mais endereços do que qualquer filtro.
• Aposente hard bounces imediatamente. Entregar repetidamente para endereços mortos é um sinal de spam trap, e spam traps reciclados são exatamente como remetentes legítimos acabam entrando em listas.
• Leia postmaster@ e abuse@. Eles são obrigatórios por definição, e é ali que você descobre um problema antes de uma blocklist descobrir. As duas maiores provedoras também publicam painéis de reputação gratuitos para domínios que você verificou; eles vão te contar coisas que nenhuma lista pública jamais conta.
• Não brigue uma briga que você herdou. Se o endereço tiver uma listagem anterior a você, ou estiver bloqueado em algum lugar que importa comercialmente, peça uma troca pela área do cliente, em vez de passar três semanas em filas de remoção por causa do histórico de outra pessoa.

Por que o endereço chegou limpo, para começo de conversa, é a outra metade disso. Nuvens baratas de alta rotatividade reciclam IPv4 entre um número enorme de clientes de vida curta, então um endereço “novo” costuma chegar pré-usado em todo sentido que importa para um gateway. Todo plano aqui vem com um endereço dedicado e triado, em vez de uma fatia de um pool compartilhado — o que um IP limpo realmente significa define isso e mostra como verificar você mesmo, antes de confiar nele.

A contabilidade honesta, porque um guia que só lista as vantagens é propaganda.

• Não torna o seu e-mail privado. O SMTP criptografa salto a salto e de forma oportunista; o provedor de recebimento descriptografa e lê tudo que você manda para os usuários dele, exatamente como antes. Se o objetivo é confidencialidade do conteúdo, isso é criptografia de ponta a ponta, não um servidor que você possui.
• Não esconde os metadados. Quem, para quem, quando, com que frequência e a linha de assunto atravessam a rede intactos — e agora o seu próprio servidor também registra tudo isso, em uma máquina pela qual você é responsável.
• Não te livra das grandes provedoras. Você ainda está pedindo para duas empresas aceitarem o seu e-mail, e elas ainda ditam os termos unilateralmente. Hospedar seu próprio e-mail move o ponto de controle; não o remove.
• Não se administra sozinho. Certificados vencem, chaves pedem rotação, discos enchem, e um servidor de e-mail que silenciosamente para de aceitar mensagens perde e-mails que os remetentes não vão tentar reenviar para sempre. É um serviço com uma dimensão de plantão, por menor que seja.
• Não torna a máquina anônima. Um servidor de e-mail é possivelmente a coisa mais autoidentificável que você pode rodar, porque publicar o seu domínio no DNS e se responsabilizar por ele é o mecanismo inteiro. Um cadastro sem KYC limita o que o seu host sabe sobre você; não muda nada sobre o que um destinatário consegue ver. Explicamos essa distinção com cuidado em um VPS pago em cripto é realmente anônimo, e vale dez minutos antes de você presumir o contrário.

Depois que os registros estiverem certos e o endereço estiver aquecido, tudo que resta é sobre onde a caixa de e-mail mora e quem sabe que ela é sua.

A jurisdição decide quem pode exigir divulgação. Um servidor de e-mail é um arquivo pesquisável de correspondência, o que torna a localização uma escolha mais consequente aqui do que para quase qualquer outro serviço. Nossa presença abrange oito localidades pela Holanda, França, Romênia, Bulgária, Suécia, Islândia, Suíça e Malásia, e nenhum aviso de remoção ao estilo americano tem força em nenhuma delas. Isso é política operacional declarada com clareza, não imunidade legal — uma ordem vinculante de um tribunal local competente ainda se aplica, e existe um piso inegociável de abuso que não movemos. A hospedagem offshore explica essa diferença sem o marketing.

A conta é a parte que as pessoas pulam. O cadastro pede um endereço de e-mail para a entrega das credenciais, e mais nada — sem identificação, sem cartão, sem endereço postal, sem número de telefone. Não há documento de verificação nenhum para entregar depois, porque nunca coletamos um; o que significa hospedagem no-KYC cobre os limites disso com honestidade.

E o pagamento. Um cartão liga um servidor a um registro bancário e a um nome legal guardado em um banco de dados que nenhum de nós dois controla. O checkout aqui é liquidado on chain, com o Monero tratado como uma opção de primeira classe, não como um acréscimo tardio: como pagar um VPS com XMR percorre o fluxo inteiro, e como comprar sem cartão de crédito cobre como chegar lá partindo de nenhuma cripto. O deploy leva cerca de sessenta segundos após a confirmação.

O que importa mais aqui do que para uma máquina descartável. Um servidor de e-mail é um compromisso longo com um domínio e um endereço — a reputação que você está prestes a passar um mês construindo não é portátil. Decida a jurisdição, a conta e o pagamento antes do aquecimento, não depois.