Os limites são públicos desde fevereiro de 2024: as diretrizes para remetentes do Gmail fixam um hard requirement em 0,3% de reclamações de spam, e a maioria das plataformas considera que um hard bounce rate acima de 2% por campanha aciona um throttling. O código SMTP 501 faz parte dos rejeitos permanentes que pesam nesse cálculo, e ele mente por omissão. O diagnóstico real está no sub-código Enhanced Status que o acompanha: 5.1.3, 5.1.7, 5.5.4 ou outras variantes dependendo do servidor destinatário. Cada sub-código tem uma causa distinta e uma correção que não se parece com a anterior. Reenviar sem ter lido esse sub-código equivale a inserir um segundo hard bounce na sua fila, o que prejudica diretamente sua sender reputation.
O que o código 501 realmente significa
Um código SMTP que começa com 5 é um rejeito permanente. O servidor remoto está dizendo: não tentará entregar esta mensagem novamente, nem agora nem mais tarde. Ao contrário dos erros 4xx (temporários), um 501 não se resolve esperando ou reenviando exatamente da mesma forma.
A sintaxe completa de uma mensagem de erro 501 aparece assim no seu NDR (Non-Delivery Report):
501 5.1.3 Invalid address format
O primeiro dígito (5) indica o rejeito permanente. O segundo dígito indica a categoria do erro Enhanced Status: 1 = problema de endereço, 5 = problema de protocolo ou de sintaxe de comando. O terceiro dígito refina o diagnóstico exato. São esses três dígitos depois do 501 que dizem o que corrigir.
Na prática, muitas equipes leem o “501” e param por aí. O sub-código desaparece na lógica de reporting dos ESPs (Email Service Providers). O resultado: tratam um problema do remetente como um problema do destinatário, ou vice-versa.
Sub-código 5.1.3: formato de endereço do destinatário inválido
O sub-código 5.1.3 indica que o endereço do destinatário contém um erro de formato que o servidor SMTP remoto se recusa a processar. O servidor não tenta verificar se essa caixa realmente existe: ele detectou uma anomalia sintática antes mesmo de chegar a essa etapa.
As causas mais frequentes:
- Arroba duplo:
prenom@domaine@example.com - Domínio ausente:
prenom.nom@ - Caracteres proibidos na parte local (espaços não codificados, parênteses, colchetes fora de aspas)
- Extensão de domínio ausente:
prenom@domaine - Ponto no início ou fim da parte local:
.prenom@domaine.com
Esses endereços entram nas suas listas por meio de formulários sem validação no servidor, de importações CSV mal processadas ou de entradas manuais no CRM. A correção não está no SMTP. Começa antes, no dado em si.
Passe sua lista por um validador de formato que aplique a sintaxe RFC 5321 antes de cada campanha. Parte desses endereços tem recuperação: você busca o dado correto por outro canal ou tira o contato da lista de uma vez. Manter um contato com esse status garante um hard bounce no próximo envio.
Sub-código 5.1.7: endereço do remetente incorreto ou recusado
Aqui o problema muda de lado. O sub-código 5.1.7 diz respeito ao endereço do remetente, não do destinatário. O servidor remoto recusou o comando MAIL FROM porque o endereço de envio não é válido segundo seus critérios.
Esse sub-código aparece em duas situações. Na primeira, o endereço de envio tem um erro de formato (domínio inexistente, sintaxe inválida). Na segunda, o servidor destinatário tem uma política que bloqueia remetentes cujo endereço From ou Return-Path não passa nos controles de autenticação.
Um 5.1.7 pode, portanto, revelar um problema de SPF mal configurado no seu domínio de envio. Se o seu registro SPF não incluir o endereço IP ou o domínio do seu ESP, alguns servidores receptores rejeitam o comando MAIL FROM com esse sub-código em vez de um 550 clássico.
Abra o NDR completo e veja qual endereço está sendo sinalizado. Se for o seu Return-Path (endereço técnico de rejeito), verifique se o seu registro SPF inclui o domínio da sua plataforma de envio. Se for o seu endereço From visível, verifique se o domínio de envio corresponde ao seu domínio SPF autorizado.
Verifique também o alinhamento DMARC: um remetente cujo domínio From difere do domínio SPF (ou DKIM) pode acionar rejeitos 5.1.7 em servidores que aplicam uma política DMARC restrita na recepção.
Sub-código 5.5.4: comando SMTP inválido
O sub-código 5.5.4 difere dos dois anteriores. Não se trata mais do endereço, mas do próprio comando SMTP. O servidor remoto recebeu um comando malformado ou parâmetros que não reconhece.
Na prática, esse sub-código raramente aparece em envios padrão via um ESP reconhecido (Brevo, Mailgun, Postmark, Amazon SES). É mais comum quando você envia por um servidor SMTP próprio, um relay SMTP configurado manualmente ou uma integração via API que constrói a sessão SMTP diretamente.
As causas típicas de um 5.5.4:
- Cabeçalhos SMTP mal formatados (codificação incorreta no
EHLOou noMAIL FROM) - Parâmetros não suportados passados no comando (ex.: extensões SMTP não negociadas via
EHLO) - Inconsistência entre o nome do host anunciado no
EHLOe o endereço IP do servidor de envio - Conector ou middleware que insere caracteres de controle na sessão
A correção passa pelos logs SMTP brutos, não apenas pelo NDR. Ative o modo debug no seu servidor ou relay para capturar a transação completa e identificar o comando exato que provoca o rejeito.
Outras variantes do 501: leia o texto da mensagem
Nem todos os servidores implementam os códigos Enhanced Status de forma uniforme. Alguns retornam um 501 sem sub-código ou com um sub-código proprietário (5.0.0, 5.7.1, etc.). Nesse caso, o diagnóstico depende inteiramente do texto da mensagem que acompanha o código.
Mensagens que você pode ver:
501 Syntax: MAIL FROM: <address>, problema de formato no comando MAIL FROM, do lado do remetente501 Bad recipient address syntax, variante do 5.1.3, problema do lado do destinatário501 Domain must be present in address, domínio ausente no endereço, variante 5.1.3501 Too many invalid addresses, o servidor atingiu seu limite de tolerância para uma sessão com vários destinatários inválidos
Esse último caso merece atenção. Se a sua lista contém uma alta taxa de endereços inválidos para um mesmo domínio destinatário, alguns servidores bloqueiam a sessão inteira após N erros consecutivos. Você acaba recebendo um 501 em endereços que poderiam ter passado. O hard bounce rate aparente ultrapassa então a taxa de endereços realmente inválidos.
Leia o NDR para identificar o sub-código correto
O seu ESP normalmente exibe um resumo do erro. Esse resumo costuma ser truncado. Para diagnosticar corretamente, você precisa do NDR completo.
No Gmail / Google Workspace: o NDR chega na caixa de entrada do remetente. Abra a mensagem, clique nos três pontos no canto superior direito, selecione Mostrar original. O código SMTP completo aparece no cabeçalho Diagnostic-Code.
No Outlook / Exchange: mesmo princípio. O NDR contém uma seção Diagnostic information for administrators com o código completo retornado pelo servidor remoto.
No seu ESP (Brevo, Mailchimp, Postmark): acesse a atividade da mensagem ou o relatório de bounce. A maioria dos ESPs exibe o código Enhanced Status e o texto bruto da mensagem na ficha de atividade de cada envio. Se o seu ESP não mostrar isso, exporte os logs de atividade e filtre pelo código 501.
Depois de identificar o sub-código, aplique a correção correspondente. Corrija o endereço para os 5.1.3, corrija o remetente ou o SPF para os 5.1.7, corrija a sessão SMTP para os 5.5.4.
Evitar os 501 antes do envio: verificação de endereços
A correção após o bounce é cara: um hard bounce registrado, um contato a eliminar, uma reputação de IP levemente afetada. A prevenção age mais cedo no ciclo.
Para os erros 5.1.3 (formato de endereço inválido), a verificação sintática antes da importação é uma primeira barreira. Ela captura arrobas duplos, domínios ausentes e caracteres proibidos. Não tem custo e se aplica na importação do arquivo ou no envio do formulário.
Uma verificação SMTP live — ping no servidor destinatário, sem enviar mensagem — detecta domínios que não existem ou que pararam de aceitar e-mail, o que também gera bounces 5.1.x. Serviços como o Captain Verify combinam a verificação sintática, a resolução DNS e o ping SMTP em uma única passagem, com um resultado por endereço que distingue os catchall, os inválidos e os válidos.
Para os erros 5.1.7, a prevenção passa por uma auditoria da sua configuração de autenticação (SPF, DKIM, alinhamento DMARC) antes de mexer na lista. Um domínio de envio mal configurado gera 5.1.7 independentemente da qualidade dos seus endereços destinatários.
Uma list hygiene regular — remoção de bounces, inativos de longa data e catchall não verificados — reduz o risco de acumular 501 em série durante o envio.
O que os guias não dizem: o efeito de acumulação na reputação
Um 501 isolado não destrói uma reputação. O problema aparece quando eles se acumulam ao longo de várias campanhas consecutivas a partir do mesmo IP ou do mesmo domínio de envio. Gmail Postmaster Tools e Microsoft SNDS rastreiam o hard bounce rate por domínio remetente. Um hard bounce rate acima de 2% em uma campanha é suficiente para acionar um throttling ou um bloqueio temporário por parte de alguns servidores.
Os servidores destinatários se comunicam entre si por meio de sistemas de reputação compartilhada (Spamhaus, Senderscore, Microsoft SNDS) — algo que a maioria dos guias sobre erros SMTP não menciona. Um remetente que acumula bounces permanentes no Gmail pode ter seu IP warmup comprometido no Outlook algumas semanas depois, mesmo sem ter tido problemas diretos com esse servidor.
A boa prática, documentada nas diretrizes para remetentes do Gmail atualizadas em 2024, recomenda manter o spam rate abaixo de 0,1% e fixa o limite rígido de rejeição em 0,3%. A tolerância com rejeitos permanentes repetidos está na mesma ordem de grandeza.
Um 501 se lê. Trinta segundos a mais do que ignorar o bounce. É a única diferença entre uma correção que resolve e um reenvio que piora.
