117 de 117 códigos
Códigos de resposta básicos
Status do sistema ou resposta de ajuda do sistema. Pouco usado na prática.
Mensagem de ajuda em resposta ao comando HELP, com informações sobre como usar o servidor ou um comando específico.
Saudação inicial do servidor ao abrir a conexão: o serviço está pronto. Também é a resposta a STARTTLS para indicar que a negociação TLS pode começar.
O servidor está encerrando a conexão, normalmente em resposta ao comando QUIT.
A autenticação com AUTH foi bem-sucedida. Costuma vir acompanhada do código aprimorado 2.7.0.
A ação solicitada foi concluída. É a resposta habitual a EHLO, MAIL FROM, RCPT TO e ao final de DATA, quando o servidor aceita a mensagem.
O destinatário não é local, mas o servidor aceita a mensagem e vai encaminhá-la para o endereço indicado.
O servidor não confirma se o usuário existe (VRFY desativado para evitar a enumeração de contas), mas aceitará a mensagem e tentará entregá-la.
Resposta a ETRN: o servidor começou a entregar as mensagens que estavam na fila para o domínio ou nó solicitado.
Desafio do servidor durante o AUTH, codificado em Base64. O cliente deve responder com o próximo dado do mecanismo (por exemplo, o usuário ou a senha no AUTH LOGIN).
Resposta a DATA: o servidor aguarda o conteúdo da mensagem, que termina com uma linha contendo apenas um ponto.
O serviço não está disponível e o servidor está encerrando a conexão: desligamento, sobrecarga, conexões demais ou limite de envio temporário. O remetente deve tentar novamente mais tarde.
O usuário precisa trocar a senha ou migrar para outro mecanismo de autenticação antes de conseguir se autenticar. Vem acompanhado do código aprimorado 4.7.12.
A caixa de correio está temporariamente indisponível: ocupada, bloqueada ou rejeitada de forma temporária por políticas. O greylisting costuma responder com este código ou com 451.
A ação foi abortada por um erro local do servidor, como uma falha ao consultar o DNS ou um filtro que não respondeu. O remetente deve tentar novamente mais tarde.
O servidor não tem espaço suficiente para aceitar a mensagem no momento. Também indica que a quantidade de destinatários por mensagem foi excedida: o cliente deve enviar o restante em outra transação.
Falha temporária de autenticação (por exemplo, o servidor de credenciais não responde) ou TLS momentaneamente indisponível ao solicitar STARTTLS.
O servidor não consegue atender no momento os parâmetros enviados em MAIL FROM ou RCPT TO, mas poderá aceitá-los mais tarde.
Resposta a ETRN: o servidor não consegue processar no momento a fila de mensagens do nó solicitado.
Resposta a ETRN: o nó ou domínio solicitado não tem permissão para pedir a entrega da sua fila.
O servidor não reconhece o comando ou a linha é longa demais. O AUTH também o usa quando uma linha da troca excede o tamanho máximo permitido.
O comando é válido, mas seus parâmetros ou argumentos não: por exemplo, um endereço malformado em MAIL FROM ou um nome inválido em EHLO.
O servidor reconhece o comando, mas não o implementa ou o mantém desativado, como VRFY ou EXPN em muitos servidores.
Os comandos chegaram em uma ordem incorreta, por exemplo RCPT TO antes de MAIL FROM, ou DATA sem destinatários válidos. Alguns servidores o retornam quando se tenta enviar sem autenticação.
O servidor não aceita o parâmetro indicado, por exemplo um mecanismo de AUTH que ele não suporta.
O host não aceita e-mail de nenhum tipo. É enviado como saudação no lugar do 220, e o cliente não deve tentar novamente.
O servidor exige autenticação, ou o início do TLS com STARTTLS, antes de aceitar o comando. Típico ao usar a porta de envio 587 sem credenciais.
O mecanismo de autenticação escolhido é fraco demais segundo a política do servidor. Alguns provedores o retornam quando exigem senhas de app ou OAuth.
Usuário ou senha incorretos, ou credenciais rejeitadas. Vem acompanhado do código aprimorado 5.7.8.
O mecanismo de autenticação escolhido só é permitido em uma conexão criptografada: é preciso executar STARTTLS primeiro.
A caixa de correio não existe ou não está disponível, ou a mensagem foi rejeitada por políticas (spam, blacklists, SPF, DKIM ou DMARC). O código aprimorado que o acompanha indica a causa específica.
O destinatário não é local e o servidor não encaminha a mensagem; ele pode indicar para qual endereço enviá-la.
O espaço alocado foi excedido: a caixa de correio do destinatário está cheia ou a mensagem ultrapassa o tamanho máximo anunciado pela extensão SIZE.
O endereço de e-mail não é válido ou não é permitido, por exemplo por sintaxe incorreta ou porque o remetente não pode usar esse endereço.
A transação falhou. Como saudação inicial, significa que não há serviço SMTP para esse cliente; após DATA, que a mensagem foi rejeitada, muitas vezes pelo conteúdo ou pela reputação do remetente.
O servidor não reconhece ou não implementa um parâmetro de extensão enviado em MAIL FROM ou RCPT TO.
O domínio do destinatário publica um null MX (um registro MX que aponta para “.”): declara que não recebe e-mails, então não faz sentido tentar novamente.
Códigos de status aprimorados (RFC 3463)
Status sem mais detalhes: usado quando só se conhece a classe do resultado (sucesso, falha temporária ou permanente).
Há um problema com algum endereço da mensagem que não se enquadra nos códigos mais específicos.
A caixa de correio do destinatário não existe no servidor de destino. É a devolução clássica por um endereço digitado errado ou uma conta desativada.
O domínio ou sistema de destino não existe ou não pode aceitar e-mails, por exemplo porque o domínio não resolve.
O endereço do destinatário tem uma sintaxe inválida.
O endereço do destinatário corresponde a mais de uma caixa de correio no sistema de destino.
O endereço do destinatário é válido. Aparece como 2.1.5 na resposta positiva a RCPT TO.
A caixa de correio existia, mas foi transferida e não há um endereço de encaminhamento conhecido.
O endereço do remetente tem uma sintaxe inválida.
O domínio do remetente não existe ou não aceita respostas, por exemplo porque não tem registros MX nem A.
A mensagem foi entregue a um sistema que não suporta notificações de status, então não será possível confirmar sua entrega final.
O domínio do destinatário publica um null MX: declara que não recebe e-mails.
A caixa de correio existe, mas algo relacionado a ela impediu a entrega e não há um código mais específico.
A caixa de correio existe, mas está desativada e não aceita mensagens, por exemplo uma conta suspensa.
A caixa de correio do destinatário excedeu sua cota de armazenamento.
A mensagem ultrapassa o tamanho máximo que o destinatário tem permissão para receber.
O destinatário é uma lista de distribuição e não foi possível expandi-la em seus membros.
O sistema de destino teve um problema que não se enquadra nos códigos mais específicos.
O armazenamento do sistema de e-mail de destino está cheio.
O host de destino não está aceitando mensagens, por um desligamento iminente, sobrecarga ou manutenção.
O sistema de destino não suporta algum recurso exigido pela mensagem.
A mensagem ultrapassa o tamanho máximo que o servidor aceita para qualquer destinatário.
O sistema de destino está mal configurado e não pode aceitar a mensagem.
A mensagem foi aceita, mas com uma prioridade diferente da solicitada (extensão MT-PRIORITY).
Houve um problema de rede ou de roteamento que não se enquadra nos códigos mais específicos.
O servidor de destino não respondeu à tentativa de conexão.
A conexão foi estabelecida, mas caiu ou ficou instável antes de concluir a entrega.
Falhou um serviço de diretório necessário para a entrega, tipicamente a resolução DNS.
Não foi encontrada uma rota até o destino, por exemplo porque o domínio não tem registros MX nem A utilizáveis.
O sistema de e-mail está congestionado e não consegue processar a mensagem no momento.
Foi detectado um loop de roteamento: a mensagem passou vezes demais pelos mesmos servidores.
O tempo máximo de novas tentativas expirou e a mensagem é descartada sem ter sido entregue.
Houve um problema com o protocolo de entrega que não se enquadra nos códigos mais específicos.
O comando não é válido, não é permitido naquele momento ou não é reconhecido.
O comando tem um erro de sintaxe e o servidor não consegue interpretá-lo.
A mensagem tem mais destinatários do que o servidor aceita em uma transação.
O comando é válido, mas seus argumentos não são ou não são suportados.
Há uma incompatibilidade de versão do protocolo entre o cliente e o servidor.
Uma linha da troca de AUTH excede o tamanho máximo suportado pelo servidor.
Houve um problema com o conteúdo da mensagem que não se enquadra nos códigos mais específicos.
O destino não suporta o tipo de conteúdo da mensagem ou de algum de seus anexos.
Para entregar a mensagem seria preciso converter seu conteúdo, mas o remetente proibiu isso.
Para entregar a mensagem seria preciso converter seu conteúdo, e o servidor não sabe fazer isso.
A mensagem foi entregue, mas a conversão do conteúdo perdeu informações.
A conversão do conteúdo da mensagem falhou.
Não foi possível obter o conteúdo da mensagem referenciado por URL (extensão BURL).
O remetente ou o destinatário não suporta endereços com caracteres fora do ASCII (e-mail internacionalizado, SMTPUTF8).
O servidor precisa responder com texto UTF-8, mas o cliente não anunciou suporte a SMTPUTF8.
A mensagem tem cabeçalhos UTF-8 e não pode ser transferida para um ou mais destinatários que não os suportam, por isso é rejeitada.
Status de segurança sem mais detalhes. Aparece em autenticações bem-sucedidas (2.7.0), em falhas temporárias de AUTH (4.7.0) e em rejeições por política.
O remetente não está autorizado a enviar para esse destinatário: bloqueio por blacklist, reputação, antispam ou tentativa de relay não permitida. Na variante 4.7.1, costuma indicar greylisting.
O remetente não tem permissão para enviar para essa lista de distribuição.
Seria preciso converter a mensagem de um protocolo de segurança para outro, e isso não é possível.
A mensagem exige recursos de segurança que o destino não suporta.
Uma operação criptográfica falhou no transporte, por exemplo a verificação de uma assinatura ou a descriptografia.
O destino não suporta o algoritmo criptográfico usado na mensagem.
A verificação de integridade falhou: a mensagem foi modificada em trânsito ou o checksum não confere.
As credenciais de autenticação não são válidas: usuário ou senha incorretos.
O mecanismo de autenticação escolhido é mais fraco do que a política do servidor exige.
É necessária uma camada de criptografia externa, como TLS, para usar o mecanismo de autenticação solicitado. Pensado principalmente para mecanismos que enviam a senha em texto puro.
O mecanismo de autenticação solicitado só é permitido em uma conexão criptografada.
O usuário precisa trocar a senha ou passar para outro mecanismo de autenticação.
A conta do usuário que tenta se autenticar está desativada.
O servidor só aceita mensagens de sistemas com os quais tem uma relação de confiança estabelecida.
A prioridade da mensagem é baixa demais para aceitá-la neste momento (extensão MT-PRIORITY).
A mensagem é grande demais para a prioridade indicada (extensão MT-PRIORITY).
A caixa de correio mudou de dono desde a data indicada pelo remetente, por isso a mensagem não é entregue (extensão RRVS).
O domínio do destinatário mudou de dono desde a data indicada pelo remetente (extensão RRVS).
O servidor não consegue verificar se a caixa de correio mudou de dono, como o remetente solicitou (extensão RRVS).
A mensagem não tem nenhuma assinatura DKIM válida e a política do receptor a exige.
A mensagem tem assinaturas DKIM válidas, mas nenhuma atende à política do receptor (por exemplo, pelo domínio assinante ou pelo algoritmo).
A mensagem não tem uma assinatura DKIM válida do mesmo domínio que aparece no cabeçalho From.
O IP de envio não está autorizado no registro SPF do domínio remetente.
A avaliação do SPF retornou erro, por exemplo por um registro malformado ou consultas DNS demais.
O IP de envio não tem DNS reverso (PTR), ou o nome retornado não resolve de volta para esse IP.
Várias verificações de autenticação da mensagem falharam ao mesmo tempo, como SPF e DKIM.
O domínio do remetente publica um null MX, então não poderia receber respostas nem devoluções, e a mensagem é rejeitada.
A mensagem parece fazer parte de um envio em massa de mensagens abusivas semelhantes.
A validação da cadeia ARC falhou; o ARC preserva os resultados de autenticação quando a mensagem passa por encaminhadores ou listas de discussão.
A mensagem exige REQUIRETLS e o próximo servidor da rota não suporta essa extensão, por isso ela não pode ser entregue com garantia de criptografia.
Cole a resposta completa do servidor, por exemplo 550 5.7.1 Message rejected, para ver ao mesmo tempo o código básico e o aprimorado. Em um código básico, a pesquisa também mostra os códigos aprimorados que costumam acompanhá-lo.
Como funciona
Em uma sessão SMTP, cada comando do cliente (EHLO, MAIL FROM, RCPT TO, DATA…) recebe uma resposta do servidor que começa com um código de três dígitos. O primeiro diz como terminou: 2 significa sucesso, 3 que o servidor espera mais dados, 4 um erro temporário e 5 um erro permanente. O segundo indica a área: x0z sintaxe, x1z informação, x2z conexão e x5z sistema de e-mail. O texto que vem depois do código é livre e cada servidor escreve o seu; os programas só olham o número.
Como três dígitos dizem pouco sobre a causa, a RFC 3463 definiu os códigos de status aprimorados, no formato classe.assunto.detalhe: 5.1.1 é uma falha permanente (5) de endereçamento (1) porque a caixa de correio não existe (1). A classe repete o sentido do primeiro dígito (2, 4 ou 5), o assunto agrupa a causa e o detalhe a especifica. Os servidores que os usam anunciam isso com a extensão ENHANCEDSTATUSCODES na resposta ao EHLO, e o mesmo código aparece no campo Status das mensagens de devolução.
A tabela reúne os códigos básicos da RFC 5321 e os que as extensões de uso comum adicionam (AUTH, STARTTLS, ETRN e null MX), além de todos os códigos aprimorados do registro da IANA, com os códigos básicos com os quais cada um costuma aparecer. Os grandes provedores acrescentam seus próprios textos e links de ajuda, mas sempre sobre esses mesmos números.
Exemplos
550 5.1.1 <nadie@example.com>: Recipient address rejected: User unknown in local recipient table5xx Permanent · X.1.1 Bad destination mailbox addressA devolução típica do Postfix quando a conta não existe. Tentar novamente não adianta: é preciso corrigir o endereço. Se o mesmo destinatário funcionava antes, o mais provável é que a conta tenha sido desativada.450 4.2.0 <ana@example.com>: Recipient address rejected: Greylisted4xx Transient · X.2.0 Other or undefined mailbox statusGreylisting: o servidor rejeita temporariamente o remetente desconhecido e espera que ele tente de novo. Um servidor de e-mail legítimo faz isso sozinho após alguns minutos e a mensagem entra; muitos programas de spam nunca tentam novamente.AUTH LOGIN334 VXNlcm5hbWU6O 334 traz o desafio em Base64: VXNlcm5hbWU6 é “Username:” e o seguinte, UGFzc3dvcmQ6, é “Password:”. Se as credenciais estiverem incorretas, o servidor responde 535 5.7.8; se exigir criptografia antes, 538 ou 530.Casos de uso
- Entender por que um e-mail foi devolvido a partir da mensagem de erro retornada pelo servidor.
- Distinguir se um erro é temporário e a fila vai tentar novamente, ou permanente e é preciso agir.
- Diagnosticar falhas de autenticação ao configurar o envio de e-mail a partir de uma aplicação, uma impressora ou um servidor.
- Interpretar rejeições por SPF, DKIM, DMARC, DNS reverso ou blacklists nos logs do servidor de e-mail.
- Classificar devoluções em uma plataforma de e-mail marketing para remover os endereços inexistentes.
- Ler uma sessão SMTP capturada com telnet, openssl s_client ou swaks.
Perguntas frequentes
Qual é a diferença entre um erro 4xx e um 5xx?
Um 4xx é temporário: o servidor que envia mantém a mensagem na fila e tenta novamente de tempos em tempos, em geral durante quatro ou cinco dias, antes de desistir e gerar uma devolução. Um 5xx é permanente: a devolução é imediata, e reenviar a mesma mensagem sem mudar nada vai falhar de novo.
Por que a resposta traz dois códigos, como 550 5.1.1?
O primeiro é o código básico de três dígitos exigido pela RFC 5321. O segundo é o código de status aprimorado da RFC 3463, que especifica a causa: um 550 pode ser causado por uma caixa de correio inexistente (5.1.1), por um bloqueio por política (5.7.1) ou por uma falha de SPF (5.7.23). Para diagnosticar, vale olhar principalmente o aprimorado.
O que significa o hífen em 550-5.7.1?
Que a resposta ocupa várias linhas. Todas trazem o mesmo código, mas as intermediárias o separam do texto com um hífen e a última com um espaço, e assim o cliente sabe quando a resposta terminou. É o mesmo que se vê na lista de extensões retornada pelo EHLO.
Por que recebo 550 5.7.1 se o endereço existe?
Porque o 5.7.1 não fala do destinatário, e sim do remetente: o servidor não autoriza você a entregar aquela mensagem. As causas comuns são que o IP de envio está em uma blacklist, que a verificação SPF, DKIM ou DMARC do domínio falha, que o IP não tem DNS reverso ou que houve uma tentativa de usar o servidor como relay sem autenticação. O texto que acompanha o código costuma dar a pista.
Por que recebo 530 ou 535 ao enviar e-mail de uma aplicação?
O 530 indica que o servidor exige autenticação, ou o início do TLS, antes de aceitar a mensagem; o 535, que o usuário ou a senha estão incorretos. Verifique se a aplicação usa a porta 587 com STARTTLS ou a 465 com TLS implícito, se a autenticação está ativada e, em provedores como Gmail ou Microsoft 365, se você está usando uma senha de app ou OAuth em vez da senha normal.