Quais são as configurações SMTP do Office 365 e como elas afetam o e-mail da aplicação?

Os detalhes de SMTP do Office 365 descrevem várias rotas

A documentação do Microsoft 365 e do Office 365 diferencia a submissão SMTP de cliente, o relay SMTP e o Direct Send. A submissão de cliente se autentica como uma caixa postal do Exchange Online e envia por smtp.office365.com. O relay SMTP trata a aplicação ou o dispositivo como um servidor de e-mail da organização e autentica a conexão com um conector de entrada. O Direct Send envia de forma anônima ao endpoint MX do Microsoft 365 do tenant, para destinatários da organização. São produtos operacionalmente diferentes por trás de comandos SMTP parecidos. Não copie um hostname e uma porta de um fórum sem decidir qual rota se pretende usar. Registre primeiro o tenant, os domínios aceitos, o administrador, a carga de trabalho, as identidades de remetente, a rede de origem, o escopo de destinatários, o método de autenticação, a política de TLS, o volume e o responsável pelas falhas. O transporte SMTP não autoriza o evento de negócio de origem, não estabelece o consentimento do destinatário e não torna durável a fila da aplicação.

Configurações de submissão SMTP de cliente

O guia de configuração atual da Microsoft documenta smtp.office365.com como o nome DNS da submissão de cliente e diz para não substituí-lo por um endereço IP. Ele recomenda a porta TCP 587, permite a porta 25 no cenário documentado e exige TLS 1.2 ou TLS 1.3 com STARTTLS habilitado. A aplicação se autentica como uma caixa postal licenciada do Microsoft 365 ou do Office 365 e pode enviar para destinatários internos e externos dentro dos limites documentados. Use o endereço da caixa postal como uma identidade explícita e teste as permissões de Send As quando o From visível for diferente. Mantenha credenciais ou tokens em um gerenciador de segredos no servidor. Um login bem-sucedido na conta não prova que o From visível é permitido, que o destinatário é válido nem que a mensagem chegará a uma caixa de entrada. A submissão de cliente é um caminho com escopo de caixa postal, então a suspensão do usuário, mudanças de licença, decisões de acesso condicional e as configurações de SMTP AUTH podem interromper uma aplicação que não mudou.

Use OAuth e habilite o SMTP AUTH de forma restrita

A Microsoft recomenda a autenticação moderna com OAuth para a submissão SMTP de cliente. A documentação de OAuth dela define o escopo SMTP.Send e o formato SASL XOAUTH2, com fluxos delegados e orientados a aplicações sujeitos ao registro no Microsoft Entra e às permissões do Exchange. Trate os tokens de acesso e de atualização como segredos, solicite apenas as permissões necessárias, valide o vínculo com o tenant e a caixa postal, rotacione as credenciais da aplicação e remova concessões não usadas. A Microsoft também recomenda desabilitar o SMTP AUTH na organização do Exchange Online e habilitá-lo apenas para as caixas postais que ainda precisam dele. Existem uma configuração para toda a organização e uma substituição por caixa postal, e a configuração da caixa postal pode ter precedência. Os padrões de segurança (Security defaults) desabilitam o SMTP AUTH. Não desabilite uma linha de base de segurança de todo o tenant apenas para manter um dispositivo legado. Prefira um conector, um cliente moderno suportado, um relay local ou outro serviço documentado quando a carga de trabalho não conseguir atender aos requisitos de OAuth e TLS.

Os limites da submissão de cliente afetam o desenho da aplicação

A comparação atual da Microsoft documenta um throttling da submissão SMTP de cliente de 10.000 destinatários por dia e 30 mensagens por minuto. Trate esses valores como limites atuais do serviço, que podem mudar e interagir com outros limites do Exchange Online. Conte destinatários, e não apenas mensagens, somando To, Cc, Bcc, novas tentativas e fan-out. Posicione os controles de taxa da aplicação, de equidade entre tenants, de concorrência, de tentativas e de idade na fila abaixo do teto do serviço. Um caminho por caixa postal compartilhada pode gerar disputa entre o uso humano e o automatizado, enquanto uma única credencial usada por muitas aplicações esconde quem é o responsável. Monitore a margem de taxa e de destinatários, mas nunca contorne um limite alternando caixas postais ou domínios de remetente. Se a carga de trabalho chegar com frequência perto dos limites de submissão da caixa postal, avalie o relay por conector, o High Volume Email para tráfego interno elegível, o Azure Communication Services Email para entrega de aplicações ou outro transporte feito para esse fim, seguindo as orientações atuais da Microsoft.

Detalhes do relay SMTP baseado em conector

O relay SMTP do Microsoft 365 usa o endpoint MX do tenant, e não smtp.office365.com, e um conector de entrada que identifica o sistema de envio da organização. A Microsoft recomenda autenticar o conector com um certificado TLS, sendo um endereço IP público estático outro método de identidade documentado. A aplicação se conecta pela porta TCP 25 e pode enviar a partir de endereços de um domínio aceito sem exigir uma caixa postal licenciada para cada remetente. Esse padrão serve para servidores de e-mail, appliances ou gateways controlados, com responsáveis estáveis pelo certificado e pela rede. Ele exige mais administração: escopo do conector, ciclo de vida do certificado, mudanças de IP público, DNS reverso, política de domínios aceitos, prevenção de abuso e monitoramento de listas de bloqueio. Nunca crie um open relay. Restrinja quais sistemas internos, tenants, remetentes, destinatários e classes de mensagem o gateway aceita. Um conector reconhece a conexão como sendo da organização; ele não verifica se uma entrada arbitrária da aplicação é legítima.

O Direct Send é entrega para destinatários internos, não um relay genérico

O Direct Send envia ao endpoint MX do tenant como um servidor SMTP externo, sem se autenticar como caixa postal ou conector. A Microsoft o documenta para entregas a destinatários da organização do Microsoft 365 ou do Office 365, e não como rota para endereços externos arbitrários. O dispositivo ou a aplicação precisa de acesso à porta TCP 25 e deve usar um remetente de um domínio aceito. Como o caminho é anônimo do ponto de vista do serviço exposto à Internet, a reputação do remetente, o DNS, o IP de origem e as decisões antispoofing importam. Não exponha um gateway de Direct Send a redes não confiáveis nem o use para contornar a autenticação por caixa postal. Planeje os relatórios de não entrega e quem cuida do suporte, porque uma impressora ou aplicação pode não receber mensagens de bounce com segurança. Se a entrega externa for necessária, escolha a submissão de cliente, o relay por conector, o Azure Communication Services Email ou outro método suportado, depois de avaliar a identidade e o volume.

Mantenha separados a identidade do envelope, o From visível e a autenticação

Toda rota carrega um remetente de envelope SMTP e comandos de destinatário, além dos cabeçalhos visíveis da RFC 5322. O remetente do envelope controla os bounces de transporte e muitas vezes a identidade do SPF; o From visível controla o que os leitores veem e é a identidade central do DMARC. A autenticação da caixa postal por OAuth, a identidade do conector ou a aceitação por IP de origem não criam automaticamente alinhamento de SPF, DKIM ou DMARC para todo domínio From personalizado. Faça o inventário exato de MAIL FROM, From, Reply-To, domínio d= e seletor do DKIM e IP de conexão em amostras controladas recebidas. Publique uma única política SPF válida para o domínio aplicável, configure a assinatura DKIM onde houver suporte e avalie o alinhamento DMARC. Não adicione um segundo registro SPF nem afrouxe a política DMARC da organização para consertar um dispositivo. Separe, nos modelos de status, a aceitação pela Microsoft, a aceitação pelo servidor de destino, o bounce posterior, a filtragem da caixa postal, a chegada à caixa de entrada e a ação humana.

Implemente uma fronteira de aplicação durável

Coloque o SMTP do Microsoft 365 atrás de um worker de servidor autorizado ou de um relay controlado. Persista um evento de negócio antes de conectar, incluindo uma chave de idempotência estável, o tenant, a classe da mensagem, a revisão do template, o remetente e os destinatários aprovados, a base de consentimento ou necessidade, o estado de supressão e o histórico de tentativas. Aplique as regras de remetente e destinatário por tenant antes de gerar os comandos SMTP. Limite o tamanho da mensagem, o fan-out de destinatários, os anexos e os valores de cabeçalho. Armazene tokens, senhas, chaves privadas de certificados e a administração de conectores fora do código-fonte, dos logs, dos analytics, dos tickets e dos prompts. Defina timeouts finitos e classifique as respostas 4xx como candidatas a novas tentativas limitadas e as 5xx como permanentes para aquela tentativa, usando o diagnóstico estendido completo e as orientações da Microsoft. Uma desconexão depois do DATA, mas antes da resposta final, é ambígua; preserve a tentativa e faça a conciliação antes de reenviar. O SMTP não oferece garantia de exatamente uma vez no nível do produto.

Teste a configuração e os modos de falha antes da implantação

Use destinatários controlados dedicados e uma rede de origem com formato de produção. Verifique a resolução DNS, o alcance das portas, a negociação STARTTLS, o hostname e a cadeia do certificado, a obtenção e o escopo do token OAuth, as configurações de SMTP AUTH da organização e da caixa postal, a autorização de Send As, a correspondência do conector, os domínios aceitos e a seleção do endpoint MX. Envie amostras em texto simples, HTML, com anexo, com Unicode, de bounce e com o volume esperado. Registre cabeçalhos brutos, Authentication-Results confiáveis, respostas SMTP, identificadores de rastreamento e evidências do message trace, sem reter conteúdo de clientes. Os testes negativos devem cobrir tokens revogados, certificados de conector expirados, IP público alterado, SMTP AUTH desabilitado na caixa postal, Security defaults, From inválido, destinatário externo via Direct Send, limites por minuto e de destinatários, adiamento temporário, rejeição permanente e perda de conexão em torno do DATA. Ensaie pausar a carga de trabalho e mover jobs duráveis sem contornar falhas permanentes de política ou de destinatário.

Use as orientações atuais da Microsoft e teste seu tenant

A configuração SMTP do Microsoft 365 depende das políticas, identidades, conectores e ambiente de rede do tenant. Use a documentação atual do Microsoft Learn e teste a rota selecionada no seu tenant antes de depender dela para e-mail de produção.

Perguntas frequentes

Fontes

• Set up a multifunction device or application to send email using Microsoft 365 or Office 365 — Microsoft Learn (em inglês)
• Authenticate an IMAP, POP or SMTP connection using OAuth — Microsoft Learn (em inglês)
• Enable or disable authenticated client SMTP submission in Exchange Online — Microsoft Learn (em inglês)
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor (em inglês)
• RFC 3207: SMTP Service Extension for Secure SMTP over TLS — RFC Editor (em inglês)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor (em inglês)