376 mil milhões de emails circularam por dia no mundo em 2025, segundo o relatório Email Statistics Report 2024-2028 do Radicati Group. Cada um deles passa pelo mesmo diálogo em texto, praticamente inalterado desde 1982. O SMTP (Simple Mail Transfer Protocol) é o protocolo que transporta um email desde o software do remetente até ao servidor do destinatário. Apoia-se numa sequência de comandos curtos trocados através de uma ligação TCP. Não trata da receção nem do armazenamento da mensagem, duas tarefas confiadas a outros protocolos.
Aquilo que o SMTP faz na realidade resume-se a três gestos: abrir uma ligação ao servidor correto, transmitir o envelope que indica quem envia e para quem, e depois entregar o conteúdo da mensagem. O resto da cadeia assenta em camadas acrescentadas mais tarde, muito depois da publicação do protocolo original. Autenticação e encriptação formam a primeira camada; filtragem antispam e organização na caixa de entrada, a segunda.
O papel do SMTP no envio de um email
Um email atravessa quatro etapas antes de chegar a uma caixa de entrada e o SMTP cobre apenas duas. O MUA, o software de correio eletrónico que o remetente utiliza para redigir a mensagem (Outlook, Gmail, Thunderbird), transmite-a a um MSA, o servidor que aceita o envio depois de verificar a identidade do remetente. O MSA passa depois a mensagem a um MTA, que a retransmite de servidor em servidor até ao que aloja a caixa do destinatário. Este último servidor entrega finalmente a mensagem a um MDA, encarregue de a depositar na caixa correspondente. O SMTP controla os dois elos do meio: o envio pelo MSA e a transferência pelo MTA. Na prática, um mesmo software servidor (Postfix, Exim, Microsoft Exchange) assume frequentemente ambos os papéis ao mesmo tempo, o que esbate a distinção no dia a dia, mas não a faz desaparecer na troca de comandos em si.
RFC 5321 e RFC 5322: o envelope e a mensagem
«The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.» RFC 5321, IETF, 2008.
Duas normas distintas regem um email e a confusão entre ambas explica boa parte dos equívocos sobre deliverability. A RFC 5321 enquadra o próprio SMTP: define os comandos, os códigos de resposta e as regras de transporte do envelope. A RFC 5322, publicada no mesmo mês de outubro de 2008, rege um objeto diferente: o formato da mensagem transportada, com os seus cabeçalhos From, To, Subject, Date e Message-ID. Esta separação remonta ao primeiro antepassado do protocolo, a RFC 821, publicada em agosto de 1982 por Jonathan Postel no Information Sciences Institute da Universidade do Sul da Califórnia. Foi substituída pela RFC 2821 em 2001, por sua vez substituída pela atual RFC 5321 em 2008. Desde então, nada exigiu uma reescrita completa do transporte em si, apenas extensões sucessivas enxertadas sobre o mesmo esqueleto de comandos.
A consequência prática resume-se num ponto técnico frequentemente ignorado: o endereço declarado no comando MAIL FROM (o envelope, chamado 5321.From) e o endereço apresentado no campo From da mensagem (o cabeçalho, chamado 5322.From) não têm qualquer obrigação de coincidir. Um serviço de gestão de listas de distribuição, uma ferramenta de acompanhamento de campanhas ou um mecanismo de forwarding alteram legitimamente um sem tocar no outro. É precisamente essa diferença que o SPF verifica do lado do envelope. O DKIM e o DMARC concentram-se antes no cabeçalho visível pelo destinatário, o que explica porque os três mecanismos se complementam sem se sobreporem.
O diálogo SMTP, comando a comando
Abra uma sessão em texto simples na porta de submissão de um servidor de correio e o diálogo assemelha-se a uma troca de cortesias muito rigorosamente coreografada. O servidor responde primeiro com um código 220, sinal de que aceita a ligação. O cliente envia EHLO seguido do seu próprio nome de domínio, o que anuncia a sua capacidade de falar a versão estendida do protocolo (ESMTP) e desencadeia em resposta a lista das extensões disponíveis, SIZE para o tamanho máximo da mensagem ou AUTH para a autenticação, por exemplo. Segue-se MAIL FROM, que declara o remetente do envelope; depois RCPT TO, repetido tantas vezes quantos os destinatários. O comando DATA abre então a janela de transmissão do conteúdo propriamente dito, terminada por uma linha composta por um único ponto. O cliente encerra educadamente com QUIT.
Cada etapa devolve um código numérico de três dígitos que vale como veredito. Um código a começar por 2 significa sucesso (250 para um comando aceite). Um código em 3 convida a prosseguir, como o 354 que autoriza o início do bloco DATA. Um código em 4 assinala uma falha temporária, a repetir mais tarde. Um código em 5 fecha definitivamente a porta, sem retorno possível para esta mensagem. Esta grelha assenta em quatro famílias, nada mais. Não mudou desde a primeira especificação do protocolo, mesmo tendo o volume de emails trocados sido multiplicado por várias centenas desde 1982.
Submissão e depois transferência: o trajeto em duas etapas
A submissão e a transferência respondem a lógicas opostas. A submissão passa por um MSA que exige autenticação (identificador e palavra-passe ou token) antes de aceitar qualquer mensagem: sem ela, qualquer pessoa poderia usurpar um endereço de envio. A transferência entre MTA, por seu lado, não requer tradicionalmente qualquer autenticação deste tipo. Este vazio histórico é preenchido a posteriori por SPF, DKIM e DMARC, décadas depois da escrita do protocolo original.
Encontrar o servidor SMTP do seu email
O nome do servidor SMTP a indicar num cliente de email depende do fornecedor de email utilizado e não de um padrão universal. Gmail, Outlook, OVH ou um alojamento partilhado publicam cada um os seus próprios endereços de servidor, com variantes consoante se trate de um endereço profissional ou de uma conta de particular e, por vezes, consoante o país de faturação da conta. Este parâmetro raramente se encontra no mesmo sítio de uma interface para outra, o que leva muitos utilizadores a procurá-lo cada vez que mudam de software de email. Como encontrar o servidor SMTP do seu email reúne estes endereços fornecedor a fornecedor, com o procedimento para os localizar quando não estão documentados.
Escolher a porta SMTP
O SMTP assenta historicamente em quatro portas: 25 para a transferência entre servidores, 587 para a submissão autenticada, 465 para uma ligação encriptada desde a abertura e 2525 como alternativa quando um fornecedor de acesso bloqueia as anteriores. A porta 25, em particular, mantém-se fechada por defeito na maioria das ligações residenciais e em muitas redes empresariais, para limitar o envio de spam a partir de máquinas comprometidas sem o conhecimento do respetivo proprietário. A escolha da porta certa depende, portanto, tanto do software utilizado como da rede a partir da qual o envio realmente parte. Como determinar a porta SMTP correta detalha os casos de uso de cada uma consoante o contexto de envio.
Recorrer a um relay SMTP
Um envio gerido a partir de um servidor próprio expõe a um problema de reputação: basta um único endereço mal configurado para fazer cair a deliverability de todo o domínio. A maioria das empresas confia, por isso, o envio a um relay SMTP externo (Twilio SendGrid, Brevo, Amazon SES), que partilha uma IP pool já aquecida e trata o IP warmup em seu lugar. A escolha entre IP dedicado e IP partilhado depende sobretudo do volume enviado por mês. O funcionamento de um relay SMTP detalha estes compromissos.
Autenticação SMTP: AUTH, STARTTLS, SPF, DKIM, DMARC, BIMI
O protocolo original não previa nem encriptação nem verificação de identidade. O comando AUTH, acrescentado mais tarde, exige credenciais antes de aceitar qualquer submissão. O STARTTLS permite depois passar uma ligação em texto simples para uma ligação encriptada a meio da sessão, em vez de abrir um canal encriptado desde o início. Uma opção de conceção que permanece, ainda hoje, oportunista em vez de obrigatória numa boa parte do parque mundial de servidores. Sobre esta camada de transporte sobrepõe-se um trio que se tornou generalizado para a deliverability. O SPF verifica se o servidor emissor está autorizado a enviar por este domínio. O DKIM assina criptograficamente o conteúdo e o DMARC decide o destino de uma mensagem que falhe em ambos, até ao DMARC reject, que rejeita pura e simplesmente o email não conforme. O detalhe do SPF, DKIM, DMARC e BIMI explica como estas camadas se articulam, sendo que o BIMI acrescenta, no final da cadeia, a apresentação de um logótipo verificado nalguns clientes de email. O Postmaster Tools do Gmail continua a ser, até à data, a ferramenta mais consultada para observar o efeito real destas configurações na reputação de um domínio.
Aquilo que o SMTP não faz
O SMTP termina na entrega da mensagem no servidor do destinatário. Nunca consulta uma caixa de entrada nem armazena nada por si próprio. A leitura, a organização e a sincronização entre dispositivos competem ao IMAP e POP3, dois protocolos que intervêm depois de o SMTP terminar o seu trabalho.
Códigos de resposta e falhas de envio
Um código 550 devolvido a um comando RCPT TO assinala um hard bounce: o endereço não existe ou o servidor recusa definitivamente a mensagem. Um código 421 ou 450 corresponde a um soft bounce, uma falha temporária (caixa cheia, servidor indisponível, limite de débito atingido ou filtro temporário ativo) que o MTA emissor tentará novamente de forma automática, segundo o seu próprio calendário de deferrals. As versões recentes do protocolo acompanham frequentemente este código com um Enhanced Status Code de três grupos de dígitos, 5.1.1 para um endereço inexistente, por exemplo, que precisa a causa sem alterar a natureza do veredito. Persiste uma armadilha nos domínios configurados como catchall: o servidor devolve um 250 para qualquer endereço local, incluindo uma caixa que nunca existiu, o que torna este código de sucesso enganador para quem pretende avaliar a validade real de um endereço. A lista completa dos códigos de resposta SMTP e o detalhe dos mecanismos de hard bounce e soft bounce ajudam a diagnosticar com precisão uma campanha que se degrada. Um endereço inválido que acumula hard bounces danifica a sender reputation do IP emissor ainda antes de um problema de autenticação entrar em jogo. Um controlo da lista antes do envio continua a ser a única forma de saber onde se situa realmente o dano.
Limites e evolução do protocolo
O SMTP foi concebido para texto ASCII e endereços em caracteres latinos, uma opção que excluía de facto os alfabetos não latinos dos endereços de email. A extensão SMTPUTF8 corrige este ponto ao autorizar endereços em unicode, mas a sua adoção mantém-se marginal fora de alguns mercados asiáticos. Duas outras evoluções procuram proteger o transporte entre servidores, onde o STARTTLS continua facultativo: o MTA-STS (Mail Transfer Agent Strict Transport Security) impõe a encriptação através de uma política publicada em DNS e HTTPS, enquanto o DANE se apoia diretamente no DNSSEC para autenticar o certificado do servidor destinatário. Menos de 1% dos domínios do top 1 milhão publicam uma política MTA-STS, uma taxa que mais do que duplicou entre 2024 e 2026 sem nunca ultrapassar este limiar (Uriports, 2026). O paradoxo assenta no peso dos grandes fornecedores no tráfego real: nos Países Baixos, um estudo Zivver de setembro de 2025 mede que 19,1% do volume de emails já passa por uma ligação protegida por MTA-STS, sustentado quase inteiramente pelo Gmail e pelo Hotmail. O DANE continua a ser uma curiosidade técnica: a sua adoção depende do DNSSEC, uma camada que a maioria dos alojamentos ainda não implementou a montante, o que bloqueia o mecanismo ainda antes de este ter alguma hipótese de ser configurado do lado do cliente. O protocolo avança pela margem, nunca por uma substituição de conjunto.
