Qual porta SMTP devo usar?

Quatro portas aparecem sempre que uma aplicação precisa enviar e-mail: 25, 465, 587 e 2525. Duas delas são padrões de submissão, 587 e 465, e a orientação mais repetida sobre a 465 está desatualizada desde 2018. A porta 25 não é para submissão, e a 2525 é uma convenção sem nenhum padrão por trás.

Resposta curta: use 587 com STARTTLS. Use 465 se o seu cliente funciona melhor abrindo uma conexão TLS diretamente. Use 2525 se algo na sua rede bloqueia a 587. Não use 25 para submeter e-mail a partir de uma aplicação.

O que cada porta realmente faz?

As portas diferem em dois eixos: se são destinadas a submissão ou relay, e em que momento da conexão a criptografia começa.

• 25 é a porta de relay. É assim que um servidor de e-mail entrega uma mensagem a outro. Ela é anterior à submissão autenticada e não pressupõe nenhuma das duas coisas.
• 587 é a porta de submissão, definida para esse fim pela RFC 6409. A conexão abre em texto puro e é promovida para TLS com o comando STARTTLS antes que as credenciais sejam enviadas.
• 465 é a porta de submissão com TLS implícito. O handshake TLS acontece primeiro e todo o diálogo SMTP roda dentro dele, então nada é enviado em texto puro. As bibliotecas geralmente chamam isso de "SSL/TLS" ou "SMTPS".
• 2525 não tem nenhum padrão que a atribua a SMTP. Os provedores a oferecem como alternativa à 587 para redes que bloqueiam a porta padrão.

A diferença entre 465 e 587 é sobre quando TLS começa, não sobre a força da criptografia. Na 465, a conexão é criptografada desde o primeiro byte. Na 587, ela passa a ser criptografada um round trip depois, e um servidor configurado corretamente recusa AUTH até que isso aconteça.

A porta 465 está descontinuada?

Não, e essa é a orientação desatualizada sobre SMTP mais comum que existe.

O histórico é genuinamente confuso. A porta 465 foi atribuída a SMTP sobre TLS no início, depois retirada em favor da abordagem STARTTLS na 587, que é de onde vem a orientação de "465 is deprecated". Essa orientação esteve correta por um período. Então a RFC 8314, publicada em janeiro de 2018, recomendou TLS implícito para submissão de e-mail e restabeleceu a 465 como a porta para isso, sob o nome de serviço submissions.

Portanto, uma página dizendo que a 465 é obsoleta descreve o estado das coisas antes de 2018. Tanto a 465 quanto a 587 são atuais. Escolha a que o seu cliente suporta de forma mais limpa, e prefira a 465 se você não quer depender de uma atualização de texto puro para TLS.

Por que a porta 25 é bloqueada, e como verifico?

A porta 25 de saída é bloqueada por muitos ISPs de consumo e por provedores de nuvem e hospedagem, porque uma porta de relay sem autenticação em uma máquina comprometida é o caminho pelo qual spam em massa é enviado. Se o bloqueio pode ser removido depende de quem o definiu. Um ISP de consumo geralmente não o remove para uma linha residencial, enquanto provedores de nuvem variam: alguns aceitam uma solicitação de remoção, e pelo menos um não oferece nenhuma exceção. Verifique a política que o seu próprio provedor publica em vez de presumir qualquer coisa.

Você pode confirmar um bloqueio abrindo uma conexão com um servidor de e-mail conhecido na porta 25 e verificando se recebe uma saudação 220 ou um timeout. Uma sessão manual é a forma mais clara de ver isso, e verificar uma conexão SMTP com uma sessão telnet mostra como fazer.

Se a porta 25 está bloqueada, esse não é o problema a resolver. Uma aplicação deve submeter na 587 ou na 465 de qualquer forma.

Qual é a diferença entre submissão e relay?

Submissão é quando um cliente de e-mail ou aplicação entrega uma nova mensagem a um servidor no qual se autenticou. Relay é quando um servidor repassa uma mensagem existente em direção ao seu destino.

A diferença determina qual porta e quais regras se aplicam. A submissão exige autenticação, permite que o servidor ajuste e assine a mensagem na saída, e acontece na 587 ou na 465. O relay acontece na 25, entre servidores, e é o que os sistemas de spam e reputação do lado receptor avaliam.

Uma aplicação que envia seu próprio e-mail está sempre fazendo submissão. Se você está configurando algo e escolhendo a porta 25, a configuração está descrevendo a metade errada do sistema.

Quais portas Bird aceita?

Três, e a porta 25 deliberadamente não está entre elas:

Na 587 e na 2525, AUTH é recusado até que STARTTLS tenha sido executado, então as credenciais nunca trafegam em texto puro em nenhuma das três. A porta 25 não é oferecida para submissão.

O host depende da região da sua chave, que é o prefixo na própria chave: uma chave bk_eu1_... envia por eu1.smtp.bird.com, uma chave bk_us1_... por us1.smtp.bird.com. A autenticação usa sua chave API normal em vez de uma credencial SMTP separada: o nome de usuário é a string literal bird e a senha é a chave.

E-mail submetido via SMTP é tratado exatamente como e-mail enviado pela API de email, com a mesma verificação de domínio, assinatura DKIM, tratamento de supressão, rastreamento e eventos. Enviar email via SMTP tem a referência completa de conexão, duas sessões anotadas, uma na 465 e outra compartilhada pela 587 e 2525, e os padrões por chave que definem um envio.

Como descubro qual porta meu cliente está usando?

Onde procurar depende do software, e o padrão é consistente:

• Frameworks de aplicação colocam isso na configuração de e-mail, geralmente ao lado do host, como uma configuração port ou MAIL_PORT.
• Sistemas de gerenciamento de conteúdo expõem isso na página de configurações de um plugin SMTP, junto com um dropdown de criptografia. Esse dropdown é a configuração que as pessoas erram: "SSL/TLS" significa 465 e "STARTTLS" significa 587 ou 2525, e combinar errado os dois produz uma conexão que trava ou é recusada em vez de um erro útil.
• Dispositivos como impressoras e scanners mantêm isso em uma tela de notificação ou de scan-to-email.

Se o e-mail está falhando e você suspeita da porta, teste a conexão diretamente antes de alterar o código da aplicação. Uma sessão manual mostra se a porta está acessível, se TLS é negociado e se a autenticação é aceita, o que separa um bloqueio de rede de um problema de credencial.