Todos os dias, mais de 300 bilhões de emails percorrem a internet. Eles viajam entre servidores de que você nunca ouviu falar, por redes que você nunca verá, usando um protocolo projetado em 1982. Esse protocolo é SMTP—Simple Mail Transfer Protocol—e, apesar da idade, continua sendo a espinha dorsal da comunicação por email.
A maioria dos desenvolvedores interage com email por meio de APIs de alto nível que abstraem a mecânica subjacente. Você chama uma função, passa alguns parâmetros e o email acontece. Mas quando as coisas dão errado — e elas vão dar errado — entender o que está realmente acontecendo por baixo do capô é a diferença entre depurar de forma eficaz e ficar tateando no escuro.
A conversa SMTP
SMTP é um protocolo baseado em texto, o que significa que você pode literalmente ter uma conversa com um servidor de email usando telnet ou netcat. Isso não é só uma curiosidade — é uma técnica poderosa de depuração. Vamos ver como essa conversa acontece.
Quando seu servidor de email quer enviar um email, ele primeiro procura o servidor de email do destinatário usando registros MX no DNS. Se você está enviando para [email protected], ele consulta os registros MX de example.com para descobrir qual servidor lida com o email desse domínio.
Em seguida, abre uma conexão TCP com esse servidor, normalmente na porta 25 (ou 587 para submission, ou 465 para TLS implícito). O servidor que recebe responde com uma saudação — geralmente um código de status 220 e alguma informação de identificação.
Seu servidor se apresenta com EHLO (ou o mais antigo HELO), anunciando seu hostname. O servidor receptor responde com uma lista de extensões que suporta — coisas como STARTTLS para criptografia, AUTH para autenticação e limites de SIZE.
Se ambos os servidores suportam STARTTLS, eles negociam uma conexão criptografada neste ponto. Isso é criptografia oportunista — se falhar, eles podem voltar para transmissão não criptografada (a menos que um dos lados exija criptografia).
Agora vem a transmissão real do email. Seu servidor envia MAIL FROM com o endereço do remetente do envelope. Depois RCPT TO com o endereço do destinatário (repetido para vários destinatários). O servidor receptor pode aceitar ou rejeitar em cada etapa — talvez o destinatário não exista, ou o remetente esteja em uma lista de bloqueio.
Por fim, seu servidor envia DATA, seguido pelo conteúdo real do email (cabeçalhos e corpo), terminado por uma linha contendo apenas um ponto. O servidor receptor aceita a mensagem (250 OK) ou a rejeita com um código de erro.
Envelope vs. cabeçalhos
Algo que confunde muitos desenvolvedores: os endereços na conversa SMTP (o 'envelope') são separados dos endereços nos cabeçalhos do email. Eles podem ser — e frequentemente são — diferentes.
Os endereços do envelope (MAIL FROM e RCPT TO) são usados para roteamento. Eles determinam para onde o email realmente vai e para onde os bounces são enviados. Os endereços de cabeçalho (From, To, Cc) são o que os destinatários veem no cliente de email.
A separação existe por razões legítimas. Listas de discussão usam isso: o remetente do envelope é o endereço de bounce da lista, enquanto o cabeçalho From mostra o autor original. Encaminhamento usa isso: o envelope muda a cada salto, mas os cabeçalhos preservam o remetente original.
Mas essa separação também é o que possibilita spoofing. Um atacante pode definir o cabeçalho From para qualquer endereço que quiser enquanto usa seu próprio servidor para o envelope. É por isso que SPF verifica o remetente do envelope, DKIM assina os cabeçalhos e DMARC exige alinhamento entre eles.
Relaying e smart hosts
Nos primórdios do email, os servidores retransmitiam mensagens para qualquer um. Você podia se conectar a qualquer servidor SMTP e pedir que ele entregasse correio em seu nome. Esse modelo de open relay era conveniente, mas se tornou insustentável conforme o spam explodiu.
Hoje, a maioria dos servidores SMTP está configurada para fazer relay apenas para usuários autenticados ou faixas de IP específicas. Se você tentar enviar por um servidor que não está autorizado a usar, receberá um erro '550 relay not permitted'.
Muitas organizações usam uma configuração de 'smart host': sistemas internos enviam todo o email de saída para um servidor central, que cuida da autenticação, do enfileiramento e da entrega para a internet. Isso centraliza a gestão de email e facilita implementar políticas consistentes.
Serviços de email na nuvem funcionam de maneira semelhante. Quando você usa uma API para enviar email, está essencialmente usando os servidores deles como um smart host. Eles lidam com a complexidade de SMTP, mantêm a reputação de IP e tratam dos problemas de entrega para que você não precise.
Códigos de erro e o que significam
SMTP usa códigos de status de três dígitos, e entendê-los ajuda a diagnosticar problemas de entrega.
Códigos que começam com 2 indicam sucesso. 250 é a resposta padrão 'OK'. 251 significa que o usuário não é local, mas o servidor irá encaminhar a mensagem.
Códigos que começam com 4 são falhas temporárias. 421 significa que o servidor está temporariamente indisponível. 450 significa que a caixa de correio está temporariamente indisponível (talvez acima da cota). 451 é um 'tente novamente mais tarde' genérico. Seu servidor deve re-tentar esses automaticamente.
Códigos que começam com 5 são falhas permanentes. 550 é a rejeição genérica — usuário não existe, relay negado, rejeição por política. 551 significa que o usuário mudou. 552 significa que a mensagem é grande demais. 553 significa que a sintaxe do endereço é inválida. 554 é um 'transação falhou' genérico.
O segundo dígito fornece mais contexto: x0x é sintaxe, x1x é informação, x2x é conexões, x5x é status do sistema de email. Mas na prática, o texto legível após o código costuma ser mais informativo do que o próprio código.
Servidores modernos frequentemente incluem códigos de status estendidos (como 5.1.1 para 'bad destination mailbox address') e explicações detalhadas. Ao depurar problemas de entrega, sempre olhe a mensagem de erro completa, não apenas o código.
SMTP no mundo moderno
SMTP evoluiu significativamente desde 1982, embora o protocolo central permaneça reconhecível. Várias extensões se tornaram essenciais para o email moderno.
STARTTLS habilita criptografia para conexões SMTP. Não é perfeito — é oportunista e vulnerável a ataques de downgrade — mas é amplamente implementado e fornece proteção significativa contra espionagem passiva.
SMTP AUTH permite que servidores exijam autenticação antes de aceitar email para relay. É assim que você faz login para enviar email pelos servidores do seu provedor.
CHUNKING e BINARYMIME permitem transmissão mais eficiente de mensagens grandes e conteúdo binário, evitando o overhead do encoding base64.
Apesar dessas melhorias, SMTP mostra sua idade. É síncrono e orientado à conexão, o que não escala bem. Não tem autenticação embutida de remetentes (daí a necessidade de SPF/DKIM/DMARC). É baseado em texto, o que é ótimo para depuração mas ineficiente para grandes volumes.
Já houve propostas para substituir SMTP por algo mais moderno, mas nenhuma ganhou tração. A base instalada é grande demais, os requisitos de interoperabilidade são rígidos demais. No futuro previsível, SMTP continua sendo a língua franca do email.
Frequently asked questions
Qual é a diferença entre as portas 25, 465 e 587?
A porta 25 é para comunicação entre servidores. A porta 587 é para submission do cliente (seu cliente de email para o servidor do seu provedor) com STARTTLS. A porta 465 é para TLS implícito (criptografado desde o início). A maioria dos provedores agora prefere 587 ou 465 para conexões de clientes.
Por que meus emails são rejeitados com 'relay denied'?
O servidor não confia em você para enviar através dele. Ou você não está autenticado, está tentando enviar para um domínio que o servidor não trata, ou seu IP não está na lista permitida. Verifique suas configurações de autenticação.
Posso enviar email diretamente sem usar um serviço de email?
Tecnicamente sim, mas é impraticável. Você precisaria gerenciar reputação de IP, lidar com bounces, implementar autenticação, lidar com rate limiting e manter a entregabilidade — todas coisas que serviços de email fazem por você.
O que acontece se o servidor do destinatário estiver fora do ar?
Seu servidor coloca a mensagem em fila e re-tenta periodicamente. A maioria dos servidores re-tenta por 4-5 dias antes de desistir e enviar uma mensagem de bounce. A programação de tentativas varia, mas normalmente começa frequente e vai espaçando ao longo do tempo.