Um email dá bounce com o erro 550 5.4.1 num cliente Microsoft 365, embora a autenticação SPF/DKIM/DMARC indique PASS. Porquê? A resposta cabe numa frase: o código 550 5.4.1 significa que o endereço do destinatário não existe no diretório do servidor que recebe a mensagem, ou que o acesso lhe foi explicitamente recusado. É uma rejeição de diretório, distinta das rejeições de sender reputation. O contexto aponta para uma de 4 causas, e um endereço isolado e um domínio inteiro não se tratam da mesma maneira.
No Exchange Online, esta resposta vem em geral do Directory-Based Edge Blocking, um mecanismo que filtra os endereços inválidos antes de o conteúdo da mensagem ser analisado. Muitas campanhas encravam aqui: o CMO pergunta porque é que o open rate desce, a ferramenta de emailing mostra uma configuração técnica irrepreensível e o NDR (Non-Delivery Report) continua incompreensível sem saber ler o texto exato.
O que significa o código 550 5.4.1
550 é um código de estado permanente (classe 5yz da RFC 5321, publicada em outubro de 2008): o servidor não volta a tentar o envio, ao contrário dos erros temporários 4xx, que a mesma RFC manda repetir durante pelo menos 4 a 5 dias. O subcódigo 5.4.1 (Enhanced Status Code no sentido da RFC 3463 de janeiro de 2003) designa um problema de encaminhamento ou de acesso do lado do destinatário, e não um problema de conteúdo ou de blocklist. É a grande diferença face ao 550 5.7.1, em que a rejeição resulta de uma política de filtragem ou de uma reputação de remetente degradada. Aqui, a troca EHLO e depois MAIL FROM correu sem problemas, o comando RCPT TO foi aceite do ponto de vista sintático e só depois o endereço foi rejeitado, quando o servidor o procurou no diretório. Para uma visão geral das famílias de códigos 4xx e 5xx, a taxonomia completa dos erros SMTP dá o enquadramento.
Caixa de correio eliminada ou nunca criada: o caso mais frequente
O NDR mostra “550 5.4.1 Recipient address rejected: Access denied”. O endereço nunca existiu no diretório do Exchange Online, ou foi eliminado depois de uma saída ou do encerramento de uma conta. Repetir o envio não muda nada: o destino da mensagem não existe do lado do destinatário.
O primeiro reflexo é verificar a ortografia exata do endereço, porque um domínio mal copiado basta para provocar esta rejeição. Se o endereço estiver correto e a rejeição durar vários dias, o endereço está morto. Pertence a um antigo contacto ou a um posto eliminado, muitas vezes herdado de uma importação de CRM nunca atualizada.
Domínio aceite mal configurado em Internal Relay ou Authoritative
Um sintoma identifica esta causa: a rejeição afeta todos os destinatários do mesmo domínio, e não um único endereço. No Exchange Online, um domínio aceite pode ser do tipo Authoritative (o diretório M365 é a referência e qualquer endereço ausente é rejeitado pelo DBEB) ou Internal Relay (parte das caixas de correio vive noutro local e o fluxo segue para outro sistema através de um conector).
O problema surge sobretudo em ambiente híbrido: o tenant Microsoft 365 está como Authoritative, mas ainda existem caixas num servidor Exchange local que não está totalmente sincronizado. O Exchange Online rejeita então endereços perfeitamente válidos, porque não os encontra no diretório. Segundo a Microsoft Learn, o procedimento DBEB mantém o domínio aceite em Internal Relay enquanto os utilizadores são sincronizados. Só se passa para Authoritative quando todos os destinatários estiverem no Microsoft 365.
A correção clássica, quando o domínio já devia estar correto mas endereços válidos continuam a dar bounce: mudar o domínio aceite de Authoritative para Internal Relay no centro de administração do Exchange (Fluxo de correio > Domínios aceites), guardar e voltar a Authoritative. Em PowerShell, faz-se o mesmo com o cmdlet Set-AcceptedDomain e o parâmetro -DomainType. A alternância obriga o Exchange Online a reprovisionar o estado do diretório e limpa uma cache desatualizada.
Directory-Based Edge Blocking: a rejeição na fronteira, antes de qualquer filtro
“Se o endereço não constar do diretório, o serviço bloqueia a mensagem antes mesmo de a filtragem começar.” (documentação do Exchange Online, Microsoft Learn)
O DBEB (Directory-Based Edge Blocking) rejeita os endereços desconhecidos no perímetro de rede do serviço, antes de a mensagem entrar no pipeline antispam do Microsoft 365. Não é um bloqueio de relay nem uma recusa de ligação a montante, caso tratado à parte no artigo sobre o erro SMTP 554 5.0.0, em que é a própria ligação que é recusada. Aqui a ligação é bem-sucedida e só a resolução do endereço falha, depois. Em ambiente híbrido, o DBEB só funciona se o MX record do domínio apontar para o Microsoft 365, precisa a mesma página. A Microsoft estima em 5 a 10 minutos o tempo de ativação.
O NDR completo traz muitas vezes um código adicional: “550 5.4.1 Recipient address rejected: Access denied. AS(201806281)”. Esse código identifica uma rejeição DBEB. Confirma que o bloqueio vem do diretório do Exchange Online, mas não diz porque falta lá o endereço. Quando aparece logo a seguir à criação de uma caixa em ambiente híbrido, a causa mais provável é um atraso de sincronização entre o diretório local (Microsoft Entra Connect, o antigo Azure AD Connect, renomeado em 2023) e o Exchange Online: a caixa existe do lado local, mas a alteração ainda espera replicação. O administrador força então um ciclo delta com Start-ADSyncSyncCycle -PolicyType Delta no servidor Entra Connect, antes de procurar mais longe.
Alias ou lista de distribuição inativa
Quarto caso: o endereço rejeitado é um alias ou uma lista de distribuição desativada. Um grupo de distribuição eliminado e um alias retirado de uma caixa partilhada dão exatamente o mesmo sintoma no ecrã. O caso mais difícil é o grupo de distribuição dinâmico on-premises num ambiente híbrido: não pode ser sincronizado para o Exchange Online, por mais que se espere.
A solução documentada para este caso consiste em criar um contacto de correio no Exchange Online que reutilize o endereço externo do grupo dinâmico local. Para um simples alias eliminado, basta recriá-lo na caixa de destino ou avisar o remetente de que o endereço mudou.
O que o 550 5.4.1 revela sobre o estado da lista
“As minhas campanhas acabam em rejeições e, no entanto, a minha ferramenta de emailing mostra uma configuração técnica impecável.” Ouve-se muito esta frase entre os responsáveis de growth ou de lifecycle que descobrem o 550 5.4.1 pela primeira vez. A tentação é investigar SPF, DKIM, IP warming, sender reputation, como em qualquer rejeição clássica de deliverability. Neste código esse trabalho não serve de nada: as 4 causas acima estão todas do lado do destinatário, no diretório dele.
O reflexo SPF, DKIM, warming vem de um bom hábito. Mas nenhum ESP verifica por defeito se o endereço ainda existe no destinatário, apenas se o formato é válido. É esse ponto cego que uma verificação de lista cobre, sem acrescentar mais uma camada para vigiar todos os dias.
Um endereço eliminado, um alias morto, um domínio inteiro mal configurado por falta de sincronização: nos 4 casos, o ponto comum é uma lista com entradas mortas. Acumulam-se depressa. A CaptainVerify verificou 126 milhões de endereços em 2025, e só 57 % eram válidos. Além disso, uma lista perde cerca de 23 % dos seus endereços válidos por ano, segundo a análise sobre quanto vale realmente um endereço de email.
Uma verificação de lista a montante resolve isto. Atua antes do envio e elimina toda a categoria de erro, sem mexer no DNS nem na configuração do Exchange. Um endereço que já não existe no diretório do destinatário é detetado na verificação, e não no bounce de uma campanha que já partiu. Antes do próximo envio, passar uma amostra da lista por uma verificação chega para ver quantos endereços dariam 550 5.4.1, sem aquecer o IP em vão. É list hygiene, tratada antes de qualquer trabalho na infraestrutura de envio.
Perguntas frequentes
O 550 5.4.1 é igual ao 550 5.7.1? Não. O 5.4.1 assinala um problema de encaminhamento ou de acesso ao endereço no diretório, o 5.7.1 assinala uma política de filtragem ou uma reputação de remetente degradada. As correções são diferentes: do lado do diretório num caso, do lado da reputação no outro.
Quanto tempo esperar depois de uma ressincronização do diretório híbrido? O Microsoft Entra Connect sincroniza por defeito a cada 30 minutos, segundo a Microsoft Learn, e depois o Exchange Online ainda tem de tomar a alteração em conta. Conte com algumas horas antes de concluir que a causa é outra: tentar mais cedo reproduz a mesma rejeição.
Uma rejeição 550 5.4.1 faz subir a minha taxa global de hard bounce? Sim, cada ocorrência conta como hard bounce nas estatísticas da ferramenta de emailing e nas dos serviços de correio dos destinatários. Acumular este tipo de rejeição na mesma lista degrada a sender reputation, mesmo que nenhum outro erro de deliverability esteja em causa. Para uma visão mais ampla do aumento destas rejeições, o artigo sobre as rejeições SMTP e o seu aumento detalha a mecânica da degradação.
