Respostas automáticas, mensagens de ausência e loops de e-mail: como usar corretamente o cabeçalho Auto-Submitted

O cabeçalho Auto-Submitted é o pequeno metadado que impede máquinas de responderem a máquinas. Sem ele, uma resposta de ausência encontra uma confirmação automática, cada uma dispara a outra e, em poucos minutos, uma caixa de e-mail guarda milhares de mensagens que ninguém escreveu. Este guia explica como respostas automáticas, respondedores de férias e bounces devem ser marcados, como reconhecê-los no processamento de e-mails recebidos e como evitar que as suas próprias confirmações transacionais iniciem um loop.

Por que os loops de e-mail acontecem e por que saem caros

Um loop precisa de duas partes automáticas e de uma regra que diga: responda a tudo o que chegar. Imagine um endereço de suporte que responde a cada mensagem recebida com uma confirmação e um cliente que está de férias com um respondedor de férias. O cliente escreve, o sistema de suporte confirma, o respondedor de férias responde à confirmação, o sistema de suporte confirma essa resposta, e assim por diante. Nenhum dos lados está com defeito. Cada um está seguindo as próprias instruções.

O custo é real mesmo quando um loop dura apenas alguns minutos. As filas se enchem, as caixas de e-mail atingem a cota e o volume de mensagens quase idênticas pode levar os servidores receptores a tratar o seu domínio como abusivo. Se o loop envolve um terceiro, como uma lista de e-mail ou uma caixa compartilhada sem monitoramento, muito mais pessoas o veem. Evitar isso é barato: alguns cabeçalhos, uma regra de envelope e um contador.

Padrão de loop	Como começa	O que o interrompe
Confirmação automática encontra respondedor de férias	Seu sistema confirma todas as mensagens recebidas, inclusive as automáticas	Não responda a mensagens marcadas como automáticas e limite a taxa por remetente
Bounce encontra resposta automática	Uma resposta automática que falha gera um bounce que, por sua vez, recebe resposta	Envie respostas automáticas com remetente nulo, para que as falhas não possam voltar
Duas regras de encaminhamento	A caixa A encaminha para B e B encaminha para A	Detecção de loop por contagem de saltos, geralmente nos cabeçalhos Received; corrija as regras
Reply-To apontando para a sua própria entrada	Um formulário define o Reply-To como um endereço que confirma automaticamente	Proteja a rota de entrada e use outro endereço para respostas humanas
Eco de lista de e-mail	Uma resposta automática vai para o endereço da lista em vez de ir para o remetente	Responda somente ao remetente do envelope, nunca à lista

O cabeçalho Auto-Submitted na RFC 3834

A RFC 3834 descreve como as respostas automáticas a e-mails devem se comportar. Sua principal contribuição é o campo de cabeçalho Auto-Submitted, que qualquer sistema que gere e-mails sem que uma pessoa os digite pode usar. Ele tem três valores que você precisa conhecer.

Valor	Significado	Uso típico
no	Uma pessoa escreveu e enviou a mensagem (o padrão quando o cabeçalho está ausente)	E-mails normais enviados de um cliente de e-mail
auto-generated	Uma máquina criou a mensagem, não como resposta direta a outra mensagem	Recibos, alertas, relatórios agendados, avisos de redefinição de senha
auto-replied	Uma máquina criou a mensagem como resposta direta a uma mensagem recebida específica	Respondedores de férias, confirmações de recebimento de uma solicitação

A regra para os receptores é simples. Se o cabeçalho estiver presente com qualquer valor diferente de no, um respondedor automático não deve enviar outra resposta automática a ele. Essa única regra quebra o loop entre dois sistemas compatíveis, porque a segunda mensagem carrega a marca que o primeiro sistema respeita.

Como é uma resposta automática compatível

Uma resposta automática bem formada se identifica em vários lugares ao mesmo tempo. O remetente do envelope está vazio, o cabeçalho Auto-Submitted indica auto-replied e a mensagem aponta de volta para aquela a que responde por meio de In-Reply-To e References, de modo que os clientes de e-mail a agrupem corretamente na conversa. Um cabeçalho Precedence é opcional, mas ajuda softwares mais antigos. Veja a seguir um conjunto de exemplo de cabeçalhos com endereços fictícios.

Return-Path: <>
Received: from mail.example.net (mail.example.net [192.0.2.25])
        by mx.example.org with ESMTPS; Tue, 06 Oct 2026 09:14:02 +0000
From: Support <support@example.net>
To: customer@example.org
Subject: We received your request
Auto-Submitted: auto-replied
Precedence: auto_reply
In-Reply-To: <req-8841@example.org>
References: <req-8841@example.org>
Message-ID: <ack-8841@example.net>
Date: Tue, 06 Oct 2026 09:14:01 +0000
X-Auto-Response-Suppress: All

Hello, we have received your request and a person will answer
within one business day. This is an automatic message.

Observe que a linha Return-Path mostra colchetes angulares vazios. Esse cabeçalho é adicionado pelo servidor receptor a partir do envelope SMTP, e é assim que um sistema posterior enxerga o remetente nulo. A próxima seção o explica.

O remetente nulo: por que bounces e respostas automáticas usam um Return-Path vazio

Durante uma conversa SMTP, o servidor remetente anuncia um remetente de envelope com o comando MAIL FROM. Em e-mails comuns, trata-se de um endereço real que receberá os bounces. Para notificações de status de entrega e para respostas automáticas, o remetente do envelope é vazio, escrito como MAIL FROM:<>. A RFC 5321 define esse reverse-path nulo e diz que ele é usado para que nunca sejam geradas notificações sobre notificações.

Isso importa por dois motivos. Primeiro, se a sua resposta automática não puder ser entregue, o servidor receptor não tem a quem avisar; portanto, nenhum bounce é criado e o loop não consegue se prolongar. Segundo, o seu processamento de e-mails recebidos ganha um filtro muito barato e confiável: uma mensagem com Return-Path vazio é um bounce ou uma mensagem automática e, por isso, nunca deve receber resposta automática.

Os bounces usam o mesmo mecanismo, no formato descrito na RFC 3464 para notificações de status de entrega. Se você quiser distinguir um bounce real de uma mensagem de ausência, o nosso guia sobre códigos de bounce SMTP trata do lado das falhas em detalhes. Para saber onde o Return-Path vai parar quando você usa o seu próprio domínio de bounce, veja Return-Path personalizado e domínios de rastreamento.

Precedence e outros sinais de resposta automática

O cabeçalho Auto-Submitted é o sinal documentado e atual, mas as caixas de entrada reais também carregam sinais mais antigos e específicos de fornecedores. Um respondedor robusto verifica vários deles e só responde quando nenhum indica que a mensagem é automática.

Sinal	Origem	Como tratar
Auto-Submitted diferente de no	RFC 3834	Não responder automaticamente
Return-Path vazio (MAIL FROM:<>)	Reverse-path nulo da RFC 5321	Não responder automaticamente
Precedence: bulk, junk ou list	Convenção antiga, não é um padrão atual	Não responder automaticamente
List-Id, List-Unsubscribe ou List-Post	Cabeçalhos de lista de e-mail (por exemplo, a RFC 2919 para o List-Id)	Não responder automaticamente; a mensagem veio de uma lista ou de um remetente em massa
X-Auto-Response-Suppress	Definido pelo Microsoft Exchange para pedir que não haja respostas automáticas	Respeitar quando aparecer
Assunto como Resposta automática ou Fora do escritório	Texto escrito por um respondedor	Sinal fraco; use somente depois dos cabeçalhos

Nos seus próprios e-mails automáticos de saída, adicione Auto-Submitted e, se quiser, Precedence e X-Auto-Response-Suppress. Eles não custam nada e protegem você de respondedores alheios. Suas campanhas em massa devem levar os cabeçalhos de lista descritos no nosso guia de List-Unsubscribe, que também pedem aos respondedores que fiquem em silêncio.

Regras para enviar seus próprios e-mails de confirmação automática

As confirmações transacionais são a fonte de loops mais comum de que temos notícia. Um formulário, um helpdesk ou um sistema de tickets envia uma mensagem como Recebemos sua solicitação sempre que algo chega. É um bom hábito para os clientes e precisa de proteções. Aplique-as nesta ordem.

1. Verifique primeiro a mensagem recebida. Se ela tiver Auto-Submitted diferente de no, um Return-Path vazio, um Precedence bulk, junk ou list, ou cabeçalhos de lista, não envie confirmação.
2. Responda ao remetente do envelope. Use o Return-Path da mensagem recebida. Não use o Reply-To e não use o cabeçalho From quando os dois forem diferentes. Se não houver um endereço de envelope utilizável, não responda.
3. Envie com remetente de envelope vazio. Sua confirmação deve usar MAIL FROM:<> e levar Auto-Submitted: auto-replied.
4. Limite por remetente. Guarde o horário da última confirmação de cada endereço de remetente e envie no máximo uma por janela escolhida.
5. Aplique um teto global. Defina um limite para o total de respostas automáticas por hora. Se ele for atingido, pare e alerte uma pessoa em vez de enviar.
6. Nunca inclua a mensagem original. Citar o texto recebido na resposta pode espalhar conteúdo indesejado e faz os loops crescerem a cada rodada.

Se as suas confirmações vêm de um formulário web, e não de um e-mail recebido, as mesmas ideias se aplicam de outra forma: o visitante enviou um formulário, então você envia uma confirmação por envio, protege o formulário com CAPTCHA e limites de taxa e nunca deixa o formulário decidir o destinatário. Nosso guia de e-mail de formulário de contato trata desse lado, e separar os fluxos transacional e de marketing explica por que as confirmações não devem dividir um fluxo com as promoções.

Um limitador simples por remetente

O limitador precisa apenas de uma tabela com o endereço do remetente e o horário da última resposta. Antes de enviar, consulte o endereço. Se a última resposta estiver dentro da sua janela, pule. Se não, envie e atualize a linha. Normalize o endereço antes, convertendo-o para minúsculas e removendo as tags com sinal de mais, se a sua política permitir, para que uma pessoa não consiga burlar o limite com variações. Guarde os registros apenas pelo tempo que a janela exigir e trate-os como dados pessoais de acordo com as suas regras de retenção.

Detectando respostas de ausência e de férias no processamento de e-mails recebidos

Quando você recebe e-mails por webhook ou por uma caixa analisada por parser, como descrito em nosso guia de processamento de e-mails recebidos, toda mensagem merece uma classificação rápida antes de qualquer outra coisa. As respostas de ausência são mensagens legítimas de caixas de e-mail reais. Elas simplesmente não são o que você estava esperando e não devem disparar ações voltadas ao cliente nem alterações em listas.

Uma ordem prática de classificação

1. Verifique o Auto-Submitted. Qualquer valor diferente de no significa automático.
2. Verifique o Return-Path. Vazio significa um bounce ou uma mensagem automática. Depois, decida entre os dois no passo seguinte.
3. Procure um relatório de status de entrega. Uma mensagem multipart/report com uma parte delivery-status (RFC 3464) é um bounce e segue para o seu tratamento de bounces.
4. Verifique Precedence, X-Auto-Response-Suppress e os cabeçalhos de lista.
5. Só então examine o assunto e as primeiras linhas do texto em busca de frases típicas, como Resposta automática, Fora do escritório ou Estarei ausente até. Trate isso como uma pista, porque a redação varia conforme o idioma e o cliente.
6. Se nada corresponder, trate a mensagem como uma resposta humana e encaminhe-a normalmente.

As verificações de cabeçalho devem sempre vir antes das verificações de texto. Os padrões de texto dependem do idioma e são fáceis de enganar, e um cliente que escreve as palavras fora do escritório em uma pergunta real não deve ser silenciado.

Classificação	Sinais típicos	Ação
Resposta humana	Sem marcadores automáticos; Return-Path normal	Encaminhar a uma pessoa ou ao seu parser de respostas
Resposta de ausência ou de férias	Auto-Submitted: auto-replied, texto de férias, endereço normal que existe	Registrar, sem ação com o cliente, sem alteração na lista, não responder
Bounce (falha de entrega)	Return-Path vazio e um relatório de status de entrega	Enviar ao tratamento de bounces e de supressão
Lista de e-mail ou tráfego em massa	Cabeçalhos de lista ou Precedence bulk	Não responder; tratar conforme as suas regras
Mensagem automática duvidosa	Alguns marcadores, mas sem relatório nem texto de resposta	Guardar para revisão; não tomar nenhuma ação automática

Tratando respostas de ausência como não bounces na higiene de lista

Uma resposta de ausência prova que a caixa de e-mail existe e aceitou a sua mensagem. Contá-la como bounce é um erro que prejudica a sua lista silenciosamente. O endereço seria suprimido mesmo funcionando, sua taxa de bounce subiria sem motivo e um contato engajado que está de férias deixaria de receber suas mensagens.

• Não suprima. Uma resposta de ausência não é uma falha de entrega, uma reclamação nem um cancelamento de inscrição. Mantenha o endereço ativo.
• Não conte como bounce. Reserve as métricas de bounce para falhas reais de entrega, de modo que possam ser comparadas ao longo do tempo. Veja o que medir em entregabilidade.
• Também não conte como engajamento. É uma resposta automática, não um sinal de interesse. Não a use para zerar um relógio de sunset.
• Opcionalmente, pause. Se a resposta informar uma data de retorno e a sua ferramenta puder lê-la, você pode adiar o próximo envio até lá. Não adivinhe a data a partir de texto livre.
• Fique atento a respostas automáticas repetidas de outro tipo. Uma resposta dizendo que a pessoa saiu da empresa é um sinal para revisão humana, mesmo que não seja um bounce técnico.

Para o processo mais amplo de suprimir falhas reais, reclamações e cancelamentos de inscrição, veja gerenciamento de listas de supressão.

Caixas de Reply-To e quem as responde

Quando você envia campanhas ou notificações de um endereço que ninguém lê, normalmente define o Reply-To como uma caixa de e-mail que alguém lê. Essa caixa é o lugar onde chegam juntas as respostas de ausência, as respostas humanas e, às vezes, bounces de regras de encaminhamento; por isso, ela exige o mesmo cuidado que qualquer rota de entrada.

• Garanta que a caixa de Reply-To exista, aceite e-mails externos e tenha espaço suficiente. Uma caixa cheia ou inexistente produz bounces na visão do remetente das pessoas que responderam.
• Não aponte o Reply-To para uma caixa que envia confirmações automáticas, a menos que essa confirmação siga as barreiras descritas acima.
• Trate o Reply-To como um canal humano. Sistemas automáticos devem responder ao remetente do envelope, não a este campo.
• Se você analisa respostas automaticamente, classifique primeiro e faça o parse depois, para que o texto de ausência não vire o corpo de um ticket.
• Mantenha o endereço From visível em um domínio que você autenticou, como explicado em autenticação do domínio de envio.

Um exemplo prático: encontrando um loop nos números

Uma pequena empresa mantém um endereço de suporte que confirma todas as mensagens recebidas e permite até 40 confirmações automáticas por hora como única rede de segurança. Certa manhã, um funcionário de uma empresa cliente sai de férias e ativa um respondedor de férias. Um e-mail do cliente chega às 09:00 e o sistema de suporte o confirma. O respondedor de férias responde à confirmação. O sistema de suporte, que não verifica o Auto-Submitted, confirma essa resposta também.

Cada rodada leva cerca de 30 segundos, de modo que o par troca 2 mensagens por minuto. O teto de 40 confirmações por hora é atingido após cerca de 20 minutos e, a partir daí, o sistema de suporte enfileira o restante e um membro da equipe é alertado. Até então, a caixa do cliente contém cerca de 40 respostas de férias e a caixa de suporte, aproximadamente o mesmo número de tickets inúteis. Nada se perde de forma permanente, mas a limpeza toma a maior parte de uma hora.

Depois do incidente, a equipe faz quatro mudanças. As confirmações agora levam Auto-Submitted: auto-replied e saem com remetente de envelope vazio. Os e-mails recebidos com qualquer valor de Auto-Submitted diferente de no, com Return-Path vazio ou com cabeçalhos de lista nunca são confirmados. Cada endereço de remetente recebe uma confirmação a cada 24 horas. O teto por hora continua como última linha de defesa. Repetir o mesmo cenário de férias em staging agora produz uma confirmação e uma resposta de férias, e então silêncio: 2 mensagens em vez de cerca de 80.

Uma lista de verificação rápida

1. Toda mensagem automatizada leva Auto-Submitted: auto-generated ou auto-replied.
2. As respostas automáticas usam um remetente de envelope vazio (MAIL FROM:<>).
3. A barreira de entrada verifica Auto-Submitted, Return-Path, Precedence e cabeçalhos de lista antes de qualquer resposta.
4. As respostas vão para o remetente do envelope, não para o Reply-To nem para um endereço de lista.
5. Uma confirmação por remetente por janela, com teto global por hora e um alerta.
6. O texto da mensagem original nunca é citado de volta automaticamente.
7. As respostas de ausência são registradas, não contadas como bounces, não suprimidas e não tratadas como engajamento.
8. As caixas de Reply-To existem, são monitoradas e aplicam as mesmas barreiras.
9. Os cenários de loop são testados em staging antes do lançamento, usando os métodos de nosso guia de staging e mail catcher.

Leitura complementar e fontes

• RFC 3834: Recommendations for Automatic Responses to Electronic Mail
• RFC 5321: Simple Mail Transfer Protocol (null reverse-path)
• RFC 3464: An Extensible Message Format for Delivery Status Notifications
• RFC 2919: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists