Qual porta SMTP uma aplicação deve usar para enviar e-mail?

Uma porta SMTP seleciona uma função de protocolo e um modo de conexão

Um número de porta não é apenas uma porta de entrada intercambiável para o mesmo serviço. Ele ajuda a identificar qual função SMTP o servidor oferece e como a conexão começa. A submissão de mensagens é a primeira entrega de uma aplicação ou de um user agent para um serviço de submissão. O relay é a transferência de e-mail entre servidores de e-mail. Os padrões separam essas tarefas porque a submissão pode exigir autenticação, autorização do remetente e verificações de política de mensagem que não se aplicam da mesma forma ao relay público de e-mail. A porta também pode indicar se o cliente começa com comandos SMTP e depois faz o upgrade com STARTTLS ou se inicia imediatamente com um handshake TLS. Trate o hostname, a porta, o modo TLS e as instruções de autenticação do provedor como uma única tupla de configuração. Copiar a porta de um provedor não relacionado, ou mudar apenas a porta após um erro, pode transformar um problema de rede em uma falha de TLS ou de autenticação sem corrigir a causa original.

A porta 25 serve principalmente para relay entre servidores de e-mail

A porta 25 é a porta SMTP convencional de relay, usada quando um Message Transfer Agent entrega o e-mail a outro. A RFC 6409 mantém o relay na porta 25 e separa a submissão de novas mensagens na porta 587. Portanto, uma aplicação não deve presumir que conexões diretas aos servidores de e-mail dos destinatários na porta 25 sejam a forma normal de enviar e-mails do produto. O relay direto exige filas, roteamento por DNS, tratamento de bounces, controles contra abuso, gestão de reputação e novas tentativas conforme os padrões. Redes e provedores de hospedagem também podem restringir a porta 25 de saída. A AWS, por exemplo, documenta que limita por padrão o tráfego de e-mail do Amazon EC2 na porta 25. A porta 25 ainda pode ser uma opção documentada por um provedor ou dentro de uma infraestrutura controlada, mas estar disponível não a torna a escolha preferida para submissão. Use-a somente quando o serviço responsável documentar explicitamente esse endpoint, o modo de segurança e o modelo operacional.

A porta 587 é a porta padrão de submissão de mensagens

A RFC 6409 reserva a porta 587 para a submissão de mensagens e descreve um serviço de submissão que pode rejeitar e-mails não autorizados, exigir autenticação e aplicar políticas antes de aceitar uma nova mensagem. Uma sessão comum na porta 587 começa em SMTP, anuncia a extensão STARTTLS após o `EHLO`, faz o upgrade da conexão para TLS, repete o `EHLO`, autentica e então envia a mensagem. A palavra comum importa: os mecanismos e requisitos exatos de autenticação vêm da documentação atual do provedor e dos recursos do servidor. Um cliente seguro deve exigir o upgrade TLS esperado e validar o certificado do servidor, em vez de continuar em texto claro após uma negociação que falhou. Não confunda uma saudação inicial do protocolo sem criptografia com uma sessão autenticada desprotegida; o STARTTLS foi projetado para fazer o upgrade dessa conexão antes do envio das credenciais e dos dados da mensagem. A porta 587 identifica o serviço de submissão, enquanto a aplicação efetiva do TLS depende de uma política correta no cliente.

A porta 465 usa TLS implícito para submissão

A porta 465 é registrada para submissão de mensagens com TLS implícito. Com TLS implícito, o cliente faz o handshake TLS assim que a conexão TCP é aberta e envia comandos SMTP apenas dentro do canal protegido. Isso difere da porta 587 com STARTTLS, em que o cliente primeiro recebe uma saudação SMTP e depois solicita o upgrade. A RFC 8314 recomenda TLS implícito para submissão e também descreve uma transição em que provedores e clientes podem suportar tanto a porta 465 com TLS implícito quanto a porta 587 com STARTTLS. A RFC observa que clientes e servidores implementados corretamente podem oferecer segurança substancialmente equivalente em qualquer um dos modos quando o TLS é obrigatório. A regra prática é não declarar uma porta como universalmente correta. Use exatamente o endpoint e o modo que o provedor suporta. Configurar STARTTLS contra um listener de TLS implícito, ou TLS implícito contra um listener STARTTLS, geralmente falha antes da autenticação.

Portas alternativas específicas de provedores são contratos explícitos

Alguns provedores oferecem portas alternativas para contornar restrições de rede, mas esses números não são padrões SMTP universais para todos os serviços. O Amazon SES documenta atualmente STARTTLS nas portas 25, 587 e 2587, e TLS Wrapper, o termo dele para TLS implícito, nas portas 465 e 2465. O SES exige conexões criptografadas e publica endpoints SMTP específicos por região. Isso ilustra por que a porta deve vir da documentação do provedor escolhido, e não de uma lista genérica. A porta 2587 não significa STARTTLS em todo lugar, e a porta 2465 não identifica um serviço de TLS implícito em qualquer host. Portas alternativas também não contornam a verificação do remetente, o escopo das credenciais, as cotas nem a política do provedor. Registre a URL de origem e a data de verificação junto com a configuração de produção, para que um operador consiga distinguir uma configuração intencional do provedor de um número mágico sem explicação copiado para uma variável de ambiente anos antes.

Configure hostname, porta, TLS e autenticação em conjunto

Uma configuração SMTP robusta é um pacote: o hostname do provedor, a porta, o modo de segurança de transporte, a política de validação de certificado, o mecanismo de autenticação, o usuário, o segredo, o timeout de conexão e a identidade de envio. O hostname importa porque o certificado TLS é validado com base nele e porque os provedores podem expor endpoints regionais diferentes. A porta e o modo TLS precisam estar de acordo. A autenticação deve ocorrer somente depois que o canal protegido pretendido existir, e os segredos devem ficar em um gerenciador de segredos, e não em código-fonte, bundles do navegador, logs ou saídas de diagnóstico. Separe credenciais e configuração por ambiente, para que um teste local não envie acidentalmente pela produção. Defina timeouts finitos de conexão e de comando, mas deixe uma fila durável da aplicação controlar as novas tentativas de mensagens. Uma opção de biblioteca chamada `secure` pode significar TLS implícito em um SDK e apenas exigir STARTTLS em outro; por isso, verifique a definição da biblioteca e teste o comportamento negociado, em vez de confiar no nome da opção.

Teste a conexão em camadas sem expor segredos

Comece pela resolução DNS e pela alcançabilidade TCP a partir da mesma rede de execução da aplicação. Um timeout antes da conexão aponta para roteamento, firewall, política de saída do provedor, hostname errado ou porta fechada. Em seguida, teste o modo TLS esperado. Com TLS implícito, um cliente TLS deve receber um certificado e depois uma saudação SMTP. Com STARTTLS, um cliente que entende SMTP deve receber a saudação, enviar `EHLO`, ver o STARTTLS anunciado, solicitar o upgrade, validar o certificado e enviar `EHLO` novamente após o TLS. A RFC 3207 exige que cliente e servidor descartem as informações obtidas antes do handshake, e é por isso que o segundo `EHLO` importa. Só então teste a autenticação com uma conta controlada. Oculte usuários, tokens, endereços de destinatários, transcrições completas do servidor e conteúdo das mensagens antes de compartilhar logs. Um teste de conectividade não precisa de um envio de produção nem de um endereço real de cliente.

Classifique as falhas pela etapa que realmente falhou

Uma conexão recusada significa que o destino TCP recusou ativamente a conexão; um timeout significa que nenhuma resposta utilizável chegou dentro do limite. Um erro de handshake TLS aponta para incompatibilidade de modo, problema de certificado, incompatibilidade de protocolo, interceptação ou endpoint errado. Um erro de autenticação acontece depois e deve ser investigado como problema de credencial, mecanismo, conta ou configuração de autorização, e não corrigido com trocas aleatórias de porta. Os códigos de resposta SMTP durante `MAIL FROM`, `RCPT TO` ou `DATA` descrevem decisões ainda posteriores de política e de mensagem. Preserve a etapa, o timestamp, o endpoint, a contagem de tentativas, a resposta numérica e uma resposta filtrada para privacidade. Uma resposta SMTP 4xx normalmente é transitória e uma 5xx normalmente é permanente para o comando tentado, mas as novas tentativas precisam ser limitadas e considerar cada destinatário. Se o provedor aceitou os dados da mensagem, não envie uma duplicata às cegas só porque uma requisição posterior da aplicação deu timeout; reconcilie usando o identificador do provedor e o histórico de eventos.

Sucesso na porta não é entrega da mensagem nem chegada à caixa de entrada

Uma conexão TCP bem-sucedida comprova apenas que um listener respondeu. Um handshake TLS bem-sucedido comprova uma conexão protegida com o endpoint autenticado quando a validação do certificado é bem-sucedida. A autenticação comprova que o servidor aceitou a identidade do cliente apresentada naquela sessão. Uma resposta SMTP `250` após os dados da mensagem significa que o servidor que respondeu assumiu a responsabilidade segundo o protocolo, e não que uma pessoa recebeu ou leu a mensagem. Um relay posterior ainda pode falhar, e um sistema de destino pode aceitar o e-mail e classificá-lo fora da caixa de entrada principal. Mantenha esses estados separados nos registros da aplicação e no monitoramento. Disponibilidade de rede, negociação TLS, autenticação, aceitação pelo provedor, aceitação pelo servidor de destino, bounce, reclamação e engajamento são observações diferentes. Essa separação evita que um teste de porta seja relatado erroneamente como teste de entrega e evita que uma mensagem aceita seja reenviada só porque não é possível comprovar a chegada à caixa de entrada.

Escolha entre submissão SMTP e uma API de e-mail de forma deliberada

Use a submissão SMTP quando um sistema já tiver um cliente SMTP maduro, quando uma plataforma exigida expuser SMTP como integração compatível ou quando controles no nível de protocolo forem especificamente necessários. Uma API de e-mail HTTPS pode ser um limite de aplicação melhor quando requisições estruturadas, tokens com escopo, idempotência, recursos em lote e registros de eventos legíveis por máquina se ajustam à carga de trabalho. O provedor ainda pode usar SMTP posteriormente para chegar aos sistemas de e-mail dos destinatários; portanto, uma API não elimina o transporte de e-mail. Ela transfere a responsabilidade por porta, TLS, autenticação e novas tentativas da transferência voltada ao provedor para fora da configuração SMTP da aplicação.

Perguntas frequentes

Fontes

• RFC 6409: Message Submission for Mail — RFC Editor (em inglês)
• RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access — RFC Editor (em inglês)
• RFC 3207: SMTP Service Extension for Secure SMTP over TLS — RFC Editor (em inglês)
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor (em inglês)
• Connecting to an Amazon SES SMTP endpoint — Amazon Web Services (em inglês)