5 equívocos sobre SMTP que atrapalham os remetentes de e-mail
O SMTP existe desde 1982. É de se pensar que já tivéssemos resolvido tudo a essa altura. E, no entanto, alguns dos problemas mais persistentes de entrega de e-mail remontam a alguns equívocos obstinados sobre o que o SMTP realmente faz.
O protocolo faz um trabalho – transportar e-mail entre servidores – e faz esse trabalho muito bem. Mas ele não autentica a sua identidade, não garante a entrega na caixa de entrada, não criptografa o seu conteúdo por padrão nem lida com devoluções da maneira que a maioria dos remetentes presume. Entender onde o SMTP termina e tudo o mais começa é a diferença entre uma infraestrutura de e-mail limpa e uma que está sempre pegando fogo.
O que realmente é o SMTP?
O SMTP – Simple Mail Transfer Protocol – é um protocolo de transporte. Ele move o e-mail de um servidor para outro. Esse é todo o seu trabalho. Pense no SMTP como o motorista de entrega que pega um pacote e o deixa na doca de carregamento do prédio do seu destinatário. O que acontece depois disso – se há alguém em casa, se o pacote é retido na segurança, se ele chega à mesa certa – está totalmente fora do controle do motorista.
O SMTP rege o handshake entre os servidores: a saudação EHLO, os comandos MAIL FROM e RCPT TO, a transferência da mensagem e a resposta final 250 OK que confirma a aceitação. Assim que esse 250 é recebido, o SMTP considera seu trabalho concluído. Se a mensagem chega à caixa de entrada, à pasta de spam ou a lugar nenhum é uma questão separada – e é aí que vive a maioria dos equívocos. Se você deseja um passo a passo completo de todo o processo de envio SMTP, nós o cobrimos em detalhes.
Mito 1: Entrega SMTP significa entrega na caixa de entrada
Esse é provavelmente o mal-entendido mais caro no e-mail. Uma resposta 250 OK de um servidor receptor significa que esse servidor aceitou a sua mensagem – não que ele a entregou na caixa de entrada. O servidor receptor é livre para fazer o que quiser com a mensagem após a aceitação: filtrá-la como spam, colocá-la em quarentena ou descartá-la silenciosamente.
O SMTP opera na camada de transporte. A entrega na caixa de entrada é uma questão de entregabilidade, governada pela reputação do remetente, sinais de autenticação, histórico de engajamento e sinais de conteúdo – nenhum dos quais o SMTP toca diretamente. Quando você estiver depurando baixas taxas de abertura ou alto posicionamento de spam, não olhe apenas para os logs do SMTP. Observe a reputação do remetente, sua configuração de autenticação e a integridade da sua lista. Nosso guia de mitos comuns sobre entregabilidade de e-mail é um bom lugar para começar a desembaraçar os dois.
Dica profissional: A confusão entre entrega e entregabilidade não é rara – é endêmica. O Estado da entregabilidade de e-mail de 2025 do Mailgun pesquisou mais de 1.100 remetentes e descobriu que quase 88% não sabiam definir corretamente o que a métrica de taxa de entrega mede. O relatório detalha o que os remetentes estão realmente fazendo (e não fazendo) para chegar à caixa de entrada, desde a adoção de autenticação até os hábitos de higiene da lista. Vale a leitura se você quiser comparar o seu programa com o do setor.
Mito 2: O SMTP lida com a autenticação do remetente
O SMTP foi projetado em uma época de mais confiança. O protocolo original não possui nenhum mecanismo para verificar se o remetente é quem afirma ser – ele apenas toma o endereço MAIL FROM como valor de face. É por isso que o spoofing de e-mail tem sido um problema há décadas.
A autenticação é uma camada sobre o SMTP, não integrada a ele. O SPF (Sender Policy Framework), o DKIM (DomainKeys Identified Mail) e o DMARC (Domain-based Message Authentication, Reporting, and Conformance) operam todos de forma independente do handshake SMTP. O SMTP AUTH – o mecanismo que exige um nome de usuário e uma senha antes de o seu cliente de e-mail entregar uma mensagem – também é um complemento separado, definido na RFC 4954, e não na especificação principal do SMTP.
O que isso significa na prática: um 250 OK de um servidor receptor não confirma que seus registros de autenticação estão em ordem. Você pode transmitir com sucesso uma mensagem por SMTP e ainda assim ser classificado como lixo ou rejeitado porque seu registro SPF está quebrado ou sua assinatura DKIM não é verificada. Corrija a autenticação primeiro – o SMTP não fará isso por você. Nosso guia de autenticação de e-mail mostra o passo a passo da configuração do SPF, DKIM e DMARC do zero.
Dica profissional: Os requisitos de autenticação estão se tornando mais rígidos em toda parte – e não apenas no Gmail e no Yahoo. Em maio de 2025, a Microsoft começou a aplicar os requisitos de SPF, DKIM e DMARC para remetentes que alcançam caixas de entrada do Outlook, Hotmail e Live.com. Se você está enviando mais de 5.000 mensagens por dia e não auditou seus registros ultimamente, agora é a hora. A análise do Mailgun sobre os requisitos do remetente da Microsoft para 2025 cobre exatamente o que mudou e o que você precisa fazer a respeito.
Mito 3: O SMTP é criptografado por padrão
Pronto para uso, o SMTP clássico envia tudo em texto simples. Cabeçalhos de e-mail, conteúdo da mensagem, credenciais – tudo isso potencialmente visível para qualquer pessoa que monitore a conexão. Isso não era uma preocupação crítica no início da internet; é um problema sério hoje.
A criptografia veio depois, como uma camada separada. Duas opções cobrem a maioria dos cenários de envio:
STARTTLS
STARTTLS é uma extensão de protocolo que permite que um cliente faça o upgrade de uma conexão SMTP de texto simples existente para uma criptografada. Ele tem suporte nas portas 25 e 587. A palavra-chave é “upgrade” – se o servidor receptor não tiver suporte para STARTTLS, a conexão poderá reverter para texto simples. Isso é algumas vezes chamado de TLS oportunista e é a abordagem dominante para retransmissão de servidor para servidor.
SMTPS (TLS implícito)
O SMTPS abre uma conexão criptografada por TLS desde o início, sem nenhuma fase de texto simples. Ele é executado na porta 465 (para envio de cliente para servidor) e é a opção mais segura quando ambos os lados oferecem suporte a ele. A conclusão prática: sempre configure o seu envio para usar TLS e confirme se o seu ESP o impõe. Nosso análise aprofundada sobre as portas SMTP cobre as implicações de segurança da escolha de cada porta. Não presuma que a conexão foi criptografada só porque sua mensagem foi aceita.
Mito 4: A porta 25 é a porta certa para envio
A porta 25 é a porta SMTP original, datando de 1982. É também a porta com maior probabilidade de causar problemas.
A maioria dos ISPs e provedores de hospedagem bloqueia a porta 25 de saída em redes que não são de servidor especificamente porque ela é muito abusada por spammers. Se você estiver criando um aplicativo que envia e-mail e estiver roteando pela porta 25, encontrará erros de conexão em muitas redes – e as suas mensagens não sairão.
As portas que você deve conhecer:
Porta 587: O padrão moderno para envio de e-mail autenticado (SMTP com STARTTLS). Use isso para envio de cliente para servidor em quase todos os casos.
Porta 465: Descontinuada por um período, mas agora amplamente usada para SMTPS (TLS implícito). Muitos ESPs, incluindo o Mailgun, oferecem suporte a ela.
Porta 2525: Uma alternativa prática quando a 587 está bloqueada. O Mailgun oferece suporte a isso.
Porta 25: Apenas para retransmissão de servidor para servidor. Não indicado para envio por clientes. Frequentemente bloqueado.
Para uma análise histórica completa e uma recomendação clara para a sua configuração, confira o nosso guia de portas SMTP.
Mito 5: Executar o seu próprio servidor SMTP é mais barato e fácil
Este mito costuma surgir quando as equipes desejam reduzir os custos de seu ESP ou manter a infraestrutura de e-mail internamente. A lógica parece razoável à primeira vista: quão difícil pode ser um servidor SMTP?
Na prática, manter a sua própria infraestrutura SMTP é uma das maneiras mais rápidas de degradar a sua entregabilidade sem perceber o porquê. Executar o seu próprio servidor significa que você é responsável por tudo que o SMTP não gerencia: aquecimento de IP, processamento de devolução e de reclamações, gestão de listas de supressão, registro de loop de feedback com os principais provedores de caixa de correio, manutenção de certificados TLS, monitoramento de lista de bloqueio e manter-se atualizado com os requisitos de remetente em constante evolução do Gmail, Yahoo e Microsoft. Esse é um trabalho em tempo integral, para o qual os ESPs passaram anos construindo ferramentas.
Além da sobrecarga operacional, servidores autogerenciados muitas vezes estão em blocos de IP compartilhado com reputações ruins, e novos endereços IP enfrentam grandes obstáculos de entrega na caixa de entrada até que um período de aquecimento estabeleça um histórico de envio.
Para a maioria das equipes, a retransmissão SMTP gerencia a complexidade da infraestrutura e oferece logs, análises e ferramentas de entregabilidade que, de outra forma, você teria que construir por conta própria. E se você está avaliando se deve continuar no SMTP ou mudar para uma integração com a API, o nosso comparativo entre SMTP e API expõe as vantagens e desvantagens de forma clara.
Conclusão: Acertando no SMTP
O SMTP não é o inimigo. É um protocolo notavelmente durável que roteia e-mails há mais de 40 anos, e entender o que ele realmente faz é o primeiro passo para construir uma configuração de envio limpa.
A versão curta: O SMTP move a sua mensagem do ponto A para o ponto B. Todo o resto – entrega na caixa de entrada, autenticação, criptografia, gestão de devolução – é de sua responsabilidade configurar sobre ele. A boa notícia é que a infraestrutura moderna de e-mail, desde os protocolos de autenticação até os serviços de retransmissão gerenciados, torna essa estruturação em camadas simples, se você souber por onde começar.
Se você estiver solucionando uma falha de envio específica, o nosso guia de códigos de erro SMTP ajudará você a decodificar exatamente o que o servidor de recebimento está informando e como corrigir isso.
