550 5.7.1 Message Rejected: como ler o código do bounce

Sua campanha travou diante de uma muralha de respostas 550 5.7.1, ou um contato encaminhou a você um bounce que termina nesses dígitos. O código parece específico. As correções que as pessoas sugerem online se contradizem, porque cada uma responde a um bounce diferente que compartilha o mesmo número.

550 significa falha permanente. 5.7.1 significa que o servidor destinatário não aceitou a entrega nem o conteúdo da mensagem, como define a RFC 3463. Tudo o que vem depois na linha é onde o servidor receptor diz o que realmente reprovou. Trate 5.7.1 como uma categoria, não como um diagnóstico.

O que realmente acontece

Quando um servidor destinatário recusa um email na camada SMTP, ele devolve um código de três dígitos, muitas vezes um status estendido como 5.7.1, mais uma explicação curta em inglês. Seu ESP salva essa string no log de bounces ou no relatório de entrega.

Duas falhas diferentes causam a maioria desses bounces.

Rejeição de política. O servidor aceitou a conexão, olhou quem você diz ser e o que enviou, e recusou a mensagem por causa da sua reputação ou da sua autenticação. Normalmente aparecem palavras como SPF, DKIM, DMARC, policy, spam, blocked, ou uma string específica do provedor, como o 5.7.515 da Microsoft.

Relay negado. O servidor não transportou seu email porque você não tem permissão para enviar por aquele host para aquele destinatário. Fique atento a relay, relaying denied, not permitted to relay ou unauthorized.

Esses dois formatos recebem os nomes de rejeição de política e relay negado. O mesmo número cobre os dois. Uma correção de permissão de relay não resolve uma falha de DMARC, e o inverso também vale.

Uma rejeição de política real costuma aparecer assim:

550 5.7.1 Message rejected due to SPF policy

Uma negação de relay real costuma aparecer assim:

550 5.7.1 <user@example.com>: Relay access denied

Cabeçalhos de uma mensagem que passou e depois foi filtrada são outra história. Este post cobre a rejeição no momento do SMTP, em que a mensagem nunca chega a nenhuma caixa de entrada. Se esse é o seu caso, siga para a próxima seção.

Rejeição de política: as três causas, em ordem

Quando o texto do bounce aponta para política, autenticação ou spam, percorra estas causas em ordem.

1. SPF, DKIM ou DMARC falharam no domínio que envia o email

Este é o 5.7.1 mais comum em email legítimo em 2026. Gmail, Yahoo e Microsoft publicam regras para remetentes que tratam autenticação ausente ou falha como motivo para rejeitar o email de uma vez, e não apenas jogá-lo no spam.

Leia o campo Authentication-Results em uma mensagem que chegou a uma caixa de entrada de teste, ou na cópia de saída que seu ESP guarda:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of bounce@esp.example does not designate 203.0.113.10 as permitted sender)
       dkim=pass header.i=@yourdomain.com
       dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Uma única verificação falhando basta para gerar um 5.7.1 em servidores rigorosos. A correção é o registro que falhou: publique ou repare o SPF para cada caminho de envio, ative a assinatura DKIM com o selector do seu domínio e leve o DMARC além do p=none rumo à aplicação quando os relatórios estiverem limpos. O guia de falha de SPF cobre o lado dos registros, e o post sobre requisitos do Gmail e do Yahoo traz as strings de aplicação que você verá nos logs. Os passos de configuração dos registros não se repetem aqui.

2. O domínio ou o IP de envio está em uma blocklist que o servidor usa

O texto de política às vezes cita Spamhaus, SpamCop, Barracuda ou um block list genérico. Uma listagem é um veredito de reputação, não um erro de sintaxe. Verifique o domínio e o IP de saída contra as listas que importam, corrija a origem das reclamações ou do comprometimento e só depois peça a remoção. O hub sobre email indo para o spam conecta listagens de blocklists ao padrão de sintomas quando todos os provedores rejeitam você ao mesmo tempo.

3. Conteúdo ou reclamações estouraram o limite de um provedor

Menos comum como um 5.7.1 puro, mas acontece quando o bounce menciona spam, bulk ou user complaints. O adiamento 421 4.7.0 [TSS04] do Yahoo costuma aparecer primeiro, enquanto as reclamações sobem. Sua autenticação pode estar perfeita e o email ainda para. Puxe a taxa de reclamações do Google Postmaster Tools para o tráfego do Gmail e cruze o horário do bounce com a campanha que saiu naquele dia.

Relay negado: as três causas, em ordem

Quando o bounce menciona relaying, seu email chegou a um servidor que não vai enviá-lo por você.

1. Host ou porta SMTP errados para a conta

Plataformas de marketing, APIs transacionais e provedores de caixa postal documentam, cada um, um host de submissão. Aponte um script ou um plugin mal configurado para o smtp.gmail.com com credenciais que não podem fazer relay, e você recebe exatamente esse formato. Compare sua configuração com a documentação atual do provedor e use o endpoint de submissão que ele indica para clientes autenticados.

2. Credenciais ausentes, expiradas ou da caixa postal errada

A permissão de relay pertence à conta que fez login. Uma chave de API rotacionada, uma app password revogada ou credenciais SMTP de um servidor de teste paradas em produção aparecem todas como erros de relay, não como falhas de SPF. Regenere as credenciais e envie um teste para você mesmo antes de reabrir a fila.

3. O servidor não permite o seu IP

Alguns hosts de email antigos, gerenciados por você mesmo, só fazem relay a partir de faixas de IP do escritório. Envio em nuvem a partir de um IP novo de datacenter falha com relay negado mesmo quando sua autenticação DNS está correta. Adicione o IP de envio à allowlist, ou roteie o email pelo relay autenticado do provedor em vez do host MX.

A correção e como conferi-la

Rejeições de política terminam quando a verificação que falhava passa em uma mensagem nova. Edite o DNS, espere a propagação e envie um teste. Cabeçalhos de ontem não provam nada sobre o registro de hoje.

Rode o domínio de envio no email health check para ver SPF, DKIM e DMARC juntos. Envie um teste para uma caixa postal que você controla e abra o código-fonte bruto no header analyzer. Você quer spf=pass, dkim=pass e dmarc=pass no domínio From que realmente usa.

Rejeições de relay terminam quando a sessão SMTP faz login no host correto. A prova é um envio bem-sucedido no log do provedor, sem nenhum 5.7.1. Não faça retry em massa da fila que falhou até um teste limpo passar.

O custo em escala

Um 5.7.1 no painel passa fácil despercebido quando atinge um segmento ou um provedor. A versão perigosa é o deslize lento: um selector DKIM expira numa terça-feira, um fornecedor novo envia sem o include de SPF, um IP compartilhado herda uma listagem de um vizinho. Cada falha parece um bounce isolado até uma campanha inteira devolver o mesmo código.

A leitura de um cabeçalho responde à pergunta de hoje para uma mensagem. Ela não conta que o SPF mudou de pass para fail há seis dias, enquanto você não olhava. Por isso o monitoramento é automatizado. A LitInboxes reverifica autenticação, blocklists e reputação em cada domínio monitorado a cada seis horas, guarda histórico datado para você relacionar um pico de bounces ao dia em que um registro mudou e alerta você por email, Slack, Discord ou webhook quando algo se move. Há um passo a passo aqui se você quiser ver isso em um domínio real.

Checklist

1. Copie o texto completo da resposta SMTP, não apenas 550 5.7.1.
2. Decida pelo texto: rejeição de política ou relay negado.
3. Caminho de política: leia o Authentication-Results, corrija o registro que falha e faça um health check no domínio.
4. Caminho de relay: confirme host, credenciais e allowlist de IP na documentação do provedor.
5. Envie uma mensagem de teste e confirme que o código sumiu antes de reprocessar a fila acumulada.
6. Se as rejeições se concentram em um provedor, confira o Postmaster e as blocklists para os sinais desse provedor.