Códigos de rejeição SMTP explicados: o que significam 421, 451, 550 e os 5.7.x

Quando um correio não chega, quase sempre há um código esperando nos registros que explica por quê. Os servidores de correio não rejeitam em silêncio: devolvem um código SMTP, e aprender a lê-lo converte um mistério em um diagnóstico de um minuto. Desde que Gmail, Yahoo e Microsoft passaram de filtrar o correio não conforme a rejeitá-lo no próprio SMTP, esses códigos deixaram de ser coisa de administradores de sistemas e viraram a diferença entre uma campanha que entra e uma que volta. Esta é a referência que nós mesmos usamos, ordenada para você encontrar o seu rápido.

Anatomia de um código SMTP

Uma mensagem de erro SMTP tem até três partes, e cada uma acrescenta precisão. Primeiro, um código básico de três dígitos, como 421, 450 ou 550. Depois, de forma opcional, um código de estado melhorado de três números separados por pontos, como 4.2.2 ou 5.7.1. E por último, muitas vezes, um texto legível, como «Authentication required». Os três juntos dizem a você se reintentar ou corrigir algo antes.

O primeiro dígito do código básico é o que mais decide. Marca a classe da resposta, e só com ele você já sabe se tem tempo ou um problema definitivo.

O que diz o código de estado melhorado

O código de estado melhorado, definido na RFC 3463, é onde está o detalhe útil. Tem a forma classe.tema.detalhe: o primeiro número repete a classe (2, 4 ou 5), o segundo sinaliza o tema do problema e o terceiro afina o motivo. O segundo número é o que convém memorizar, porque leva você direto à família da causa.

Na prática, o .7 é o que você mais vai ver hoje. Um 5.7.x é uma rejeição de política e segurança — autenticação, reputação, regras do receptor — e é justo a família que os grandes provedores endureceram em 2024 e 2025. Quando você vir um segundo dígito 7, pense em SPF, DKIM, DMARC e reputação antes que em caixas ou endereços.

Temporário frente a permanente: a distinção que mais importa

Antes de ler qualquer outra coisa, olhe o primeiro dígito. Um 4xx é uma falha transitória persistente: o receptor diz a você «agora não», e os sistemas de correio reintentam a entrega por um tempo. Uma caixa cheia, um servidor ocupado ou um limite de frequência caem aqui. Um 5xx é uma falha permanente: o receptor marca a tentativa como bounce duro e não a reintentará. Um endereço inexistente, um domínio mal configurado ou uma rejeição por política caem aqui.

A consequência operativa é simples e se ignora com frequência. Um 4xx que se repete não é ruído para reintentar às cegas: é o aviso prévio a um 5xx, sobretudo quando o motivo é de autenticação. E um 5xx não se arruma reenviando; se arruma corrigindo o que o código sinaliza. Confundir os dois é o que converte um incidente menor em uma fila travada ou em uma reputação danificada.

Códigos temporários (4xx) mais habituais

Estes pedem que você espere, reintente ou afrouxe o ritmo. São recuperáveis, mas alguns — os de autenticação — são uma contagem regressiva.

O greylisting merece uma nota, porque assusta sem motivo: muitos servidores devolvem um 450 ou um 451 na primeira vez que veem você e aceitam a mensagem na retentativa, como filtro antispam barato. Se o seu MTA reintenta com normalidade, você não tem que fazer nada. Onde sim há que agir é nos 4.7.26: um adiamento por correio não autenticado é o Gmail pedindo SPF ou DKIM alinhado antes de o aviso virar rejeição.

Códigos permanentes (5xx) mais habituais

Estes são bounces. A mensagem não chegou e não chegará até que você mude algo; o código diz a você o quê.

Convém separar dois grupos que se confundem. O 550 5.1.1 é um problema de endereço: o destinatário não existe, e por mais reputação que você tenha, esse correio nunca chegará; revise o endereço ou limpe a lista. O 550 5.7.1 e companhia são de política: o receptor conhece você e decide não aceitar você, quase sempre por autenticação ou reputação. Tratar um problema de endereço como se fosse de reputação — ou ao contrário — é perder horas na causa errada.

As rejeições de autenticação que mais vemos hoje

Se hoje volta correio legítimo para você nos grandes provedores, o mais provável é que seja um de três códigos, e os três apontam para o mesmo: autenticação ausente ou mal alinhada. O 550 5.7.26 do Gmail bloqueia o correio não autenticado. O 550 5.7.515 da Microsoft rejeita o remetente que não cumpre os requisitos que exige desde maio de 2025. E o 4.7.26 — em 421 ou 451 — é o adiamento prévio, por falta de autenticação ou pela política DMARC do domínio.

A tradução para tarefas é direta. Publique um SPF que cubra todas as suas fontes de envio e não supere o limite de dez consultas. Assine com DKIM e confira que o domínio da assinatura se alinha com o do remetente visível. Publique DMARC e faça-o avançar de p=none para quarentena e rejeição à medida que os seus relatórios se limpam. Três de cada quatro rejeições da família 5.7 que nos pedem explicar se resolvem nesse trio, e quase sempre a falha está no alinhamento, não na mera presença dos registros. Por isso, diante de uma rejeição persistente do Gmail por correio não autenticado, a tarefa não é tocar o conteúdo, e sim publicar e alinhar SPF ou DKIM com o domínio que o destinatário vê.

Um exemplo real: dois bounces, duas causas

Dois bounces muito parecidos podem pedir ações opostas. Um 550 5.7.26 This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM diz exatamente o que falta: nem SPF nem DKIM se validaram e alinharam, então a tarefa é publicar e alinhar esses registros, não mexer no conteúdo nem na lista. Um 550 5.7.515 Access denied, sender does not meet authentication requirements da Microsoft aponta para o mesmo a partir de outro provedor, com um detalhe: a Microsoft exige além disso uma política DMARC mínima, de modo que um domínio com SPF e DKIM mas sem DMARC publicado pode seguir voltando aqui ainda que passe no Gmail.

O método é sempre o mesmo: isole o código básico, leia o estado melhorado para situar a família, e fique com o texto só para confirmar. Um envio que volta na Microsoft com 5.7.515 e entra no Gmail não tem «má sorte com a Microsoft»: tem um buraco de DMARC que o Gmail ainda não penaliza com a mesma dureza. Ler os dois códigos juntos poupa você de tratar um único problema como se fossem dois.

Códigos de conexão e rede: a família 4.4.x

Nem todas as falhas são de autenticação ou de caixa; algumas ocorrem antes, na própria conexão. A família 4.4.x cobre rede e roteamento, e convém reconhecê-la porque raramente se arruma no conteúdo da mensagem. Um 4.4.2 é uma conexão que se cortou no meio da entrega. Um 4.4.5 indica congestão ou conexões simultâneas demais a partir do seu host — o receptor ficou sem capacidade para você naquele momento. Um 4.4.7 sinaliza que a mensagem esperou demais na fila e expirou o seu tempo de entrega, e um 4.4.6, um laço de roteamento por tabelas mal configuradas.

A resposta a quase toda a família 4.4.x é a mesma: deixar o MTA reintentar com intervalos crescentes e, se o 4.4.5 persiste, reduzir o número de conexões concorrentes para aquele provedor. Há ainda uma causa de conexão específica do Brasil que vale reconhecer: se o seu servidor está em uma rede que bloqueia a saída pela porta 25 — as redes residenciais o fazem pela Gerência de Porta 25 do CGI.br, e nuvens como a AWS bloqueiam por padrão —, a entrega entre servidores nem chega a se estabelecer, e o sintoma é uma falha de conexão, não um código de conteúdo. Nesse caso a solução não está no MTA, e sim em mover o envio para um ambiente com a 25 liberada e o DNS reverso em ordem.

Por que os códigos pesam mais que há dois anos

Durante muito tempo, o correio não conforme acabava na pasta de spam, e os códigos de rejeição eram um assunto de nicho. Isso mudou por fases: Google e Yahoo anunciaram os seus requisitos em outubro de 2023, começaram a aplicá-los em fevereiro de 2024, a Microsoft se somou com a sua aplicação em maio de 2025 e o Gmail passou a rejeições ativas no fim de 2025. O efeito acumulado é que hoje uma parte do correio que antes se filtrava se devolve com um código, e esse código é a única explicação que você vai receber. Saber lê-lo deixou de ser uma habilidade de administrador para virar uma competência de qualquer um que envie a escala.

Como ler um bounce real

Um bounce traz mais informação do que parece. Além do código básico e do estado melhorado, costuma incluir um texto que nomeia o motivo e, conforme o provedor, identificadores que localizam a causa. O Gmail acrescenta gsmtp a todos os seus erros e gcdp quando a rejeição vem de uma regra personalizada criada por um administrador do Google Workspace, então um 550 5.7.1 com gcdp não é um problema da sua autenticação, e sim de uma política do domínio receptor. Os provedores brasileiros — UOL, Terra e BOL — costumam nomear a causa no texto, então vale lê-lo. Leia também o nome do host que rejeita e a marca de tempo: dizem a você que servidor e que envio concreto falharam, que é por onde começa qualquer diagnóstico sério.

DMARCbis: o que vem

O padrão DMARC está em revisão — o setor a chama de DMARCbis —, e convém tê-lo no radar sem alarme. Para quem envia, o essencial não muda: SPF e DKIM válidos e alinhados, uma política DMARC publicada e um avanço ordenado rumo à rejeição. Quem já tem essa base montada chegará ao DMARCbis sem sobressaltos; quem segue em p=none «porque cumpre» terá mais um motivo para terminar o trabalho.

Onde ver os códigos antes de chegarem como bounce

O melhor é não esperar o bounce. Cada grande provedor oferece uma janela para como ele vê você, e revisá-la adianta você aos códigos. No Google, o Postmaster Tools v2 mostra desde o fim de 2025 um estado de conformidade que diz a você sem rodeios se o seu domínio passa os requisitos. Na Microsoft, os Smart Network Data Services e o programa de feedback loop de reclamações expõem a reputação dos seus IPs e as reclamações que eles geram. No Yahoo, o painel para remetentes e o seu laço de reclamações cumprem um papel parecido. Conectar essas três fontes e olhá-las com regularidade converte o diagnóstico reativo — ler bounces quando já doem — em um preventivo, onde você corrige a causa antes de um 4.x endurecer em um 5.x.

O que você não deve fazer

Diante de uma onda de bounces, a reação instintiva costuma piorar as coisas. Reintentar um 5xx permanente não muda o resultado e repete ao provedor um sinal ruim. Trocar de IP sem corrigir a autenticação só transfere o problema para um IP novo e sem histórico, que parte do zero. Baixar o volume ajuda a reputação, mas não resolve uma falha de alinhamento: um correio não autenticado seguirá sendo rejeitado envie você mil ou cem mil. E não existe uma alavanca para «pedir que deixem você passar»: a aplicação é automática e se baseia no que o seu correio demonstra em cada conexão. O único que reabre a porta é corrigir o que o código sinaliza.

Se você opera o seu próprio MTA

Para quem envia com a sua própria infraestrutura de PowerMTA ou KumoMTA, estes códigos não são teoria: são a linguagem na qual o MTA decide o que fazer com cada mensagem. Um bom MTA distingue o bounce duro do transitório, registra ambos por separado e aplica regras de retentativa por código: reintenta os 4xx com intervalos crescentes e um teto sensato, e trata os 5xx como bounce sem moer a fila. A parte que mais se descuida é o backoff: quando um receptor responde com um 421 de limite de frequência, está pedindo que você afrouxe, e um MTA que o ignora batendo na mesma fila ganha o trato duro antes. Modelar o tráfego por provedor e respeitar de verdade os adiamentos é, hoje, parte de cumprir e não só de enviar rápido. Essa é a camada na qual trabalhamos, e onde ler bem os códigos se traduz diretamente em entrega.

Em resumo

Se você ficar com quatro ideias, que sejam estas. O primeiro dígito manda: 4xx é temporário e se reintenta, 5xx é permanente e se corrige. O segundo número do estado melhorado leva você à família da causa, e o .7 — política e segurança — é o que você mais vai ver hoje. As três rejeições de autenticação do momento — 5.7.26, 5.7.515 e 4.7.26 — se resolvem com o mesmo trio de SPF, DKIM e DMARC alinhados. E um código repetido não é ruído: é a causa falando com você, então leia-a antes de reenviar.

Fontes: documentação de erros SMTP do Gmail e «Sobre as mensagens de erro de SMTP» (Google Workspace); requisitos de autenticação da Microsoft (maio de 2025); RFC 3463 (códigos de estado melhorados); cobertura do setor, 2025–2026. Verifique o texto exato de cada código na documentação do provedor.