Um servidor de e-mail auto-hospedado pode ter registros de domínio corretos e ainda assim não conseguir se conectar aos trocadores de e-mail dos destinatários. A porta TCP de saída 25 é o destino SMTP normal de servidor para servidor e algumas redes a restringem. A questão útil é se esse caminho de rede específico está bloqueado e qual arquitetura de envio a operadora está autorizada a usar.
Separe a entrega direta do envio
A entrega direta conecta o envio MTA para hosts MX de destino. O envio de mensagens conecta um cliente a um serviço designado que aceita responsabilidade sob suas próprias regras de autenticação e autorização. Alterar a porta de destino em uma configuração de entrega direta não transforma cada destinatário MX em um serviço de envio autenticado. RFC 5321 seções 2 e 3.
RFC 6409 distingue o envio de mensagens e reserva a porta 587 para esse serviço. RFC 8314 descreve o envio implícito TLS na porta 465 e recomenda proteger o envio com TLS . Estas são funções de serviço, não portas de bypass universais para uma conexão bloqueada. Use apenas um endpoint de retransmissão ou envio que o operador esteja autorizado a usar, seguindo as instruções atuais desse serviço.
Teste a hipótese da rede cuidadosamente
Comece com o ouvinte local do host remetente e configuração de saída, roteamento, política de firewall e logs. Registre o destino real, o endereço resolvido, a família de endereços, o carimbo de data/hora da conexão e o erro. Uma recusa, um tempo limite e uma falha na pesquisa DNS são observações diferentes. Um site de verificação portuária testa sua própria localização e direção, a menos que sua documentação estabeleça o contrário.
Compare um pequeno conjunto de destinos aprovados e, se disponível, um segundo caminho de rede autorizado. A falha em vários destinos em um caminho com sucesso em outro apoia uma hipótese específica do caminho, mas não identifica o dispositivo exato ou a regra do provedor. Procure o registro de firewall relevante ou a política atual do provedor de hospedagem antes de declarar que o provedor bloqueia a porta 25. Não verifique hosts arbitrários em escala.
Interpretar uma comparação de caminho hipotético
Suponha que o mesmo host de envio expire para dois destinos MX aprovados, enquanto outra rede autorizada atinge esses pontos finais. Isso apoia uma investigação específica do caminho, mas não identifica o dispositivo responsável. Um log de firewall local ou uma restrição de hospedagem específica da conta atual forneceria evidências mais fortes da causa.
Agora suponha que o TCP se conecte, mas o peer se desconecte imediatamente antes de 220. Essa é uma observação diferente: o estabelecimento da conexão foi bem-sucedido, enquanto a disponibilidade do serviço SMTP não. Não a rotule novamente como uma porta TCP bloqueada simplesmente para corresponder à hipótese original.
Estes são casos de diagnóstico inventados, não varreduras executadas ou políticas de provedores medidas. Se o proprietário da rede confirmar restrições de saída intencionais, solicite uma arquitetura de envio aprovada. Não trate uma porta, proxy ou rota diferente como permissão para contornar essa restrição.
Escolha um reparo autorizado
Se a entrega direta for permitida e necessária, trabalhe com o proprietário da rede responsável para corrigir a restrição documentada através do seu processo normal. Se o ambiente proibir isso intencionalmente, use uma arquitetura de retransmissão de saída aprovada ou altere o design de implantação. Não desative amplamente os controles de segurança nem contorne uma restrição organizacional sem autorização.
Uma migração de retransmissão muda mais do que a conectividade. Faça um inventário do serviço remetente do envelope comportamento, DKIM assinatura, visível de alinhamento, identidades de remetentes permitidas e limites de envio. Verifique-os na documentação de serviço atual e em uma mensagem controlada. Uma retransmissão que aceita uma conexão ainda pode recusar um remetente não autorizado ou destinatário externo.
Verifique a conectividade e a entrega separadamente
Após a alteração aprovada, registre a conexão bem-sucedida e o envio autenticado ou autorizado pelo conector, quando aplicável. Em seguida, rastreie uma mensagem autorizada através do relé até o lado receptor. Confirme a drenagem da fila e verifique se há duplicatas de tentativas anteriores. O sucesso do TCP não estabelece autenticação de domínio, entrega final ou posicionamento na caixa de entrada. Mantenha cada resultado anexado à sua camada real e ao escopo do destinatário testado.
Escolha uma arquitetura de envio permitida
- Entrega Direct MX necessária: confirme a política de rede real com seu proprietário.
- Entrega direta intencionalmente restrita: obtenha aprovação para um projeto de relé suportado.
- Retransmissão selecionada: verifique remetentes permitidos, credenciais ou escopo do conector, assinatura e limites.
- Após a alteração: registre conexão, envio autorizado, autenticação de domínio e resultado do destinatário separadamente.