Runbook de incidentes de entregabilidade de e-mail: como responder a uma queda repentina

Um runbook de incidentes de entregabilidade de e-mail é o plano escrito que sua equipe segue quando a entrega cai de repente: os bounces disparam, as mensagens ficam paradas nas filas, as reclamações aumentam ou os clientes dizem que as mensagens nunca chegam. Ter os passos definidos com antecedência importa porque a primeira hora é quando a maior parte do dano é contida ou agravada. Este guia traz para nós um runbook prático: uma triagem de 30 minutos, uma tabela de decisão, evidências a coletar, passos de recuperação, modelos de mensagem, um formato de revisão e proteções.

O que conta como um incidente de entregabilidade

Nem toda oscilação é um incidente. O tráfego normal varia com o calendário, o público e o conteúdo. Chamamos algo de incidente quando uma métrica-chave sai rapidamente da sua faixa normal e a causa não é óbvia: taxa de bounce, volume de deferrals, taxa de reclamação, tempo de entrega de mensagens importantes ou posicionamento na caixa de entrada em um grande provedor de e-mail. Recorrer ao runbook cedo custa pouco. Esperar custa reputação.

Defina seus níveis de severidade por escrito com antecedência. Um esquema simples de três níveis funciona bem: um item de observação de nível baixo, monitorado por uma pessoa; um incidente padrão, com um líder nomeado e atualizações a cada hora; e um incidente crítico, em que e-mails transacionais, como redefinições de senha ou recibos de pagamento, são afetados ou uma credencial pode estar comprometida. As definições abaixo são exemplos a adaptar, não um padrão.

Nível	Gatilho de exemplo (ajuste ao seu tráfego)	Resposta
Observação	Uma métrica sai da faixa habitual em um único envio	O responsável verifica em até uma hora e registra os achados
Incidente	Uma métrica dobra em relação à linha de base, ou um grande provedor adia ou rejeita uma parcela expressiva das mensagens	Abrir o runbook, nomear um líder, pausar envios em massa não críticos, atualizar os stakeholders a cada hora
Crítico	E-mail transacional atrasado ou rejeitado, suspeita de credenciais comprometidas ou listagem em lista de bloqueio de um IP ou domínio principal de envio	Runbook completo, os quatro papéis ocupados, atualização a cada 30 minutos até a contenção

Os primeiros 30 minutos: triagem e contenção

O objetivo da primeira meia hora não é encontrar a causa raiz. É impedir que o dano cresça e classificar o problema bem o bastante para saber onde procurar. Siga estes passos em ordem e registre o horário de cada um.

1. Minutos 0 a 5: declarar. Abra um canal compartilhado, nomeie o líder do incidente e anote o horário em que o problema foi percebido pela primeira vez e o horário em que provavelmente começou. Use UTC em todos os registros de horário para que logs, relatórios e pessoas em lugares diferentes fiquem alinhados.
2. Minutos 5 a 10: proteger o e-mail transacional. Confirme que redefinições de senha, códigos de uso único e recibos continuam sendo entregues, enviando algumas mensagens de teste para caixas de e-mail que você controla nos principais provedores. Se estiverem falhando, trate o incidente como crítico.
3. Minutos 10 a 15: pausar ou limitar o restante. Pause campanhas promocionais, newsletters e qualquer automação agendada que possa esperar. Nos streams que não podem ser pausados por completo, reduza a taxa de envio. Não exclua ainda os e-mails na fila, pois eles são evidência.
4. Minutos 15 a 25: classificar. Leia as contagens de bounces, deferrals e reclamações por provedor de e-mail no último dia, comparadas com a semana anterior. Use a tabela de decisão abaixo para escolher a família de causas mais provável.
5. Minutos 25 a 30: distribuir tarefas e enviar a primeira atualização. Dê a cada investigador uma pergunta específica e envie uma breve atualização interna com os fatos conhecidos até o momento e o horário da próxima.

Manter o e-mail transacional em um stream, domínio e pool de IPs próprios torna esta triagem muito mais fácil, porque você pode pausar as promoções sem tocar nos recibos. Se você ainda não fez isso, consulte como separar os streams de e-mail transacional e de marketing e transforme isso em um projeto assim que o incidente terminar.

Tabela de decisão de sintoma para causa

Use esta tabela para transformar o que você vê na primeira coisa a verificar. Ela lista causas prováveis, não certezas, e várias podem ocorrer ao mesmo tempo. A primeira coluna é o que seus painéis mostram. A segunda indica qual pergunta fazer. A terceira aponta a verificação que confirma ou descarta a hipótese.

Sintoma	Abrangência	Causas prováveis	Primeiras verificações
Pico de bounces (rejeições 5xx)	Todos os provedores, começando em um horário exato	Autenticação quebrada, registro DNS expirado ou removido, credencial incorreta, envio de um domínio não verificado	Registros DNS de SPF, DKIM e DMARC; mudanças recentes de DNS ou de provedor; texto de erro nas respostas de bounce
Pico de bounces (rejeições 5xx)	Um provedor	Bloqueio por política ou listagem de reputação nesse provedor, mudança repentina de volume ou de conteúdo	Texto do bounce desse provedor, seus dados de postmaster, histórico recente de envios para esse provedor
Pico de bounces com erros de usuário desconhecido	Principalmente uma campanha ou importação	Endereços desatualizados, comprados ou digitados incorretamente adicionados a uma lista	Origem da lista, idade dos endereços, resultados de validação
Pico de deferrals (4xx)	Um ou dois provedores	Limitação de taxa, preocupações iniciais de reputação, conexões em excesso	Texto do deferral, taxa de envio e concorrência atuais, idade da fila
Pico de deferrals (4xx)	Todos os provedores	Problemas de rede ou de DNS do seu lado, falhas de TLS, limites de recursos nos servidores de envio	Timeouts e erros de TLS nos logs, resolução de DNS a partir dos hosts de envio
Pico de reclamações	Uma campanha ou segmento	Público inesperado, origem de cadastro pouco clara, link de cancelamento de inscrição difícil de encontrar	Definição do segmento, origem do cadastro, visibilidade do link de cancelamento, dados do feedback loop
Aberturas e cliques caem, bounces estáveis	Um provedor	E-mails indo para a pasta de spam sem nenhuma rejeição	Dados de postmaster, resultados de testes em caixas seed ou de painel, mudanças recentes de conteúdo ou volume
Aberturas e cliques caem, bounces estáveis	Todos os provedores	Problema no domínio de rastreamento, bloqueio de imagens, links quebrados ou mudança na medição	Certificado e DNS do domínio de rastreamento, testes de links, qualquer mudança recente de template
E-mails de fontes desconhecidas passam como o seu domínio nos relatórios DMARC	Aparece nos relatórios agregados	Spoofing, ou uma ferramenta de terceiros esquecida enviando em seu nome	Fontes nos relatórios agregados de DMARC, lista de remetentes aprovados, logs de acesso das suas credenciais de envio

Dois padrões merecem atenção especial. Um aumento repentino de volume que você não agendou, junto com um pico de reclamações, pode indicar uma conta comprometida ou uma chave vazada enviando em seu nome. Isso é, antes de tudo, um evento de segurança e, só depois, um evento de entregabilidade. Além disso, um problema em um único provedor costuma ser uma questão de reputação nesse provedor, enquanto um problema em todos os provedores que começou em um minuto exato geralmente aponta para algo que você mudou ou que expirou. Para um aprofundamento em cada família, nosso guia de códigos de bounce SMTP explica como ler respostas 4xx e 5xx, e o checklist de solução de problemas da pasta de spam cobre os problemas de posicionamento passo a passo.

Evidências a coletar antes de mudar qualquer coisa

As evidências desaparecem rápido. Os logs são rotacionados, as filas se esvaziam e os relatórios são sobrescritos. Colete primeiro, corrija depois. Salve tudo em uma pasta compartilhada com o horário de início do incidente no nome e anote o fuso horário de cada exportação.

Evidência	O que nos revela	Como capturar
Logs de eventos dos últimos 7 dias	Contagens de aceitos, adiados, bounces e reclamações por provedor, stream e campanha	Exporte pelo painel do MigoSMTP, pela API ou por webhooks; consulte sua conta MigoSMTP ou a documentação da API para ver as opções exatas
Respostas brutas de bounce e deferral	A redação exata que os provedores usam para explicar o problema	Copie uma amostra de cada mensagem distinta, com o código de status aprimorado, por provedor
Cabeçalhos completos de mensagens de teste entregues e que foram para spam	Resultados de autenticação, roteamento e quaisquer vereditos de filtros	Envie testes para caixas que você controla e salve o código-fonte original de cada um
Relatórios agregados de DMARC	Quais fontes enviam em nome do seu domínio e se SPF e DKIM passam e estão alinhados	Obtenha de 7 a 14 dias de relatórios e compare com o período anterior
Dados de postmaster dos provedores de e-mail	Sinais de reputação de domínio e IP, taxa de spam e resultados de autenticação, quando o provedor os publica	Faça capturas de tela ou exporte os painéis dos domínios afetados
Verificações de listas de bloqueio e de DNS	Se IPs ou domínios de envio estão listados e se os registros estão corretos hoje	Consulte as principais listas de bloqueio em que você confia e resolva seus registros de SPF, DKIM, DMARC, DNS reverso e rastreamento
Histórico de mudanças	O que foi implantado, editado ou trocado por volta do horário de início	Pergunte a toda a equipe: releases de código, edições de DNS, novas ferramentas, importações de listas, mudanças de template

Verificações rápidas de DNS podem ser executadas em qualquer terminal. Os comandos abaixo usam um domínio e um seletor inventados para mostrar o padrão; substitua-os pelos seus próprios valores.

# Is the SPF record still published and valid?
dig +short TXT example.com

# Is the DKIM key for the selector still published?
dig +short TXT selector1._domainkey.example.com

# What DMARC policy is published?
dig +short TXT _dmarc.example.com

# Does the sending IP have the expected reverse DNS name?
dig +short -x 192.0.2.25

Para ler cabeçalhos, siga nosso guia sobre como ler cabeçalhos de e-mail para depurar entrega e autenticação. Para painéis de reputação, o artigo sobre o Google Postmaster Tools explica o que os sinais significam e como configurá-los antes de você precisar deles.

Passos de contenção e recuperação

A contenção interrompe o dano. A recuperação traz o volume de volta com segurança. São fases separadas, e misturá-las é como as equipes reacendem o incêndio. Não retome os streams pausados só porque as métricas parecem melhores por uma hora.

Ações de contenção por causa

• Falha de autenticação: restaure ou corrija o registro DNS, confirme com uma mensagem de teste que SPF, DKIM e DMARC passam e estão alinhados, e só então retome o tráfego.
• Credencial ou conta comprometida: desative e substitua a credencial, revise o que foi enviado, avise o titular da conta e siga seu processo de segurança. A rotação de chaves é abordada em nossas orientações de segurança de chaves de API.
• Lista ou segmento ruim: remova o segmento, suprima os endereços que deram bounce ou reclamaram e investigue como esses endereços entraram na lista para que isso não se repita.
• Problema de conteúdo ou de link: retire o template, remova o link ou anexo suspeito e teste a versão revisada antes de enviá-la novamente.
• Listagem em lista de bloqueio: descubra primeiro por que a listagem ocorreu, corrija essa causa e depois siga o processo de remoção da lista específica. Nosso guia de remoção de listas de bloqueio cobre os passos.
• Limitação de taxa pelo provedor: reduza a concorrência e as mensagens por conexão para esse provedor e deixe a fila se esvaziar no ritmo que ele permitir.

Um plano de recuperação em etapas

1. Retome primeiro os assinantes mais engajados e mais recentes, com uma fração do volume normal.
2. Mantenha cada etapa por pelo menos um dia completo de feedback dos provedores, e por mais tempo nos provedores que informam dados com atraso.
3. Aumente o volume somente enquanto as taxas de bounce, deferral e reclamação ficarem iguais ou abaixo da sua linha de base anterior ao incidente.
4. Se algum sinal piorar, volte à etapa anterior em vez de manter a posição.
5. Traga os segmentos mais frios por último e considere uma rodada de reengajamento ou a remoção dos contatos que não interagem há muito tempo.
6. Declare a recuperação somente depois que os sinais permanecerem saudáveis em volume total por um período combinado no início.

A mesma rampa cuidadosa é descrita para novas infraestruturas em nosso artigo sobre warm-up, e ela vale aqui também. Pense na recuperação como uma versão menor do warm-up, usando primeiro o seu melhor tráfego.

Modelos de comunicação

Uma boa comunicação reduz o número de perguntas que interrompem as pessoas que estão resolvendo o problema. Mantenha as mensagens curtas, objetivas e regulares. Diga o que se sabe, o que não se sabe, o que estamos fazendo e quando virá a próxima atualização. Evite atribuir culpa e evite prometer um prazo de correção que você não controla. Adapte o texto fictício abaixo ao seu próprio tom.

Atualização interna para stakeholders

Subject: Email delivery incident - update 1 (14:30 UTC)

Status: Investigating, contained.
Impact: Promotional emails to one large mailbox provider are being
delayed or filtered. Order confirmations and password resets are
being delivered normally in our tests.
Actions taken: Promotional sends paused at 14:10 UTC. Evidence
collection in progress. No changes made to DNS yet.
Next steps: Review provider responses and authentication reports.
Needed from you: Please do not schedule new campaigns until we confirm.
Next update: 15:30 UTC or sooner if anything changes.
Incident lead: [name]

Mensagem para o suporte e equipes que atendem clientes

Subject: For support: delayed or missing marketing emails

What customers may report: Some people have not received recent
newsletters or promotions.
What we know: We are investigating a delivery problem affecting one
mailbox provider. Account and transactional emails are working.
What to say: We are aware that some emails are delayed and are working
on it. Please ask the customer to check their spam folder and to add
our sending address to their contacts.
What not to say: Do not name a cause or promise a time until the
incident lead confirms.
Escalate to the incident lead if: a customer reports missing password
reset or payment emails.
Next update: 16:00 UTC.

Um exemplo prático com números inventados

Uma equipe normalmente envia cerca de 200.000 e-mails promocionais e 15.000 e-mails transacionais por dia. A taxa normal de bounce é de cerca de 0,6 por cento e a taxa normal de reclamação é de cerca de 0,05 por cento. Em uma terça-feira, às 09:00 UTC, sai uma campanha para 80.000 contatos. Às 09:40, o painel mostra 2.400 hard bounces dessa campanha, ou seja, 3 por cento, e um grande provedor está adiando a maior parte das mensagens restantes.

Às 09:45, o investigador de plantão abre o runbook. Às 09:55, o stream promocional está pausado e os recibos de teste foram confirmados como entregues. A tabela de decisão aponta para um pico de bounces com erros de usuário desconhecido, concentrado em uma campanha. A verificação do histórico da lista mostra que 30.000 dos 80.000 endereços foram importados de uma planilha antiga de evento dois dias antes e nunca foram validados. Cerca de 2.000 dos 2.400 bounces vêm dessa importação.

A contenção é simples: suprimir os endereços que deram bounce, remover a importação não validada de todos os segmentos e passá-la por validação antes de qualquer novo uso. A equipe retoma o stream com 10 por cento do volume normal para os contatos mais engajados na manhã seguinte, eleva para 25, 50 e 100 por cento nos dias seguintes enquanto a taxa de bounce permanece abaixo de 1 por cento, e confirma a recuperação após três dias limpos em volume total. A revisão adiciona uma proteção: toda nova importação deve passar por validação e ficar fora das campanhas até que uma pessoa nomeada a aprove. O custo do incidente foi um dia de pausa e algumas campanhas atrasadas, em vez de um longo reparo de reputação.

Proteções e limites de alerta para ajustar

A maioria dos incidentes é descoberta pelos clientes porque ninguém estava observando o número certo. As proteções antecipam a descoberta. Os valores abaixo são exemplos escolhidos para mostrar o formato de um alerta sensato. Não são padrões universais, e os números certos dependem do seu público, dos seus provedores e do seu histórico. Meça sua própria linha de base por várias semanas e depois defina os limites em relação a ela. Consulte as diretrizes atuais para remetentes dos provedores de e-mail que importam para você, em busca de limites publicados, e leia nosso guia sobre as métricas a acompanhar para decidir o que monitorar.

Sinal	Alerta de exemplo (ajuste à sua linha de base)	Ação automática sugerida
Taxa de hard bounce por campanha	Aviso acima de 2 vezes a linha de base, parada acima de 4 vezes, ou quando o seu próprio limite absoluto for ultrapassado	Pausar a campanha e alertar o responsável
Taxa de reclamação por provedor	Aviso na metade do limite publicado por um provedor, acionamento em três quartos dele	Pausar o segmento e revisar a origem do cadastro
Participação de deferrals por provedor	Aviso quando os deferrals superam uma participação que você normalmente nunca vê, por exemplo 10 por cento por 15 minutos	Reduzir a taxa de envio para esse provedor
Idade da fila do e-mail transacional	Aviso quando a mensagem mais antiga espera mais do que alguns minutos	Acionar o investigador de plantão
Volume de envio	Aviso quando o volume por hora excede um múltiplo do habitual para aquele horário	Verificar credenciais comprometidas ou jobs descontrolados
Saúde de DNS e certificados	Verificação diária de que os registros de SPF, DKIM, DMARC e rastreamento resolvem; aviso semanas antes da expiração do certificado	Abrir um ticket para corrigir antes que falhe
Novas importações de listas	Bloquear o uso em campanhas até a validação e a aprovação	Exigir aprovação nominal no fluxo de trabalho

Além dos alertas, adicione proteções estruturais: streams separados, limites de envio por campanha, um período de retenção para novas fontes e um responsável permanente por cada domínio e IP. O comportamento de taxa e de novas tentativas também importa, e é explicado no guia sobre limites de taxa, novas tentativas e backoff em nossa central de ajuda.

Papéis de plantão

Um runbook funciona melhor quando os papéis são conhecidos antes de o alerta tocar. Em uma pequena empresa, uma pessoa pode ocupar vários papéis, mas cada um deve ter uma pessoa nomeada e um substituto.

Papel	Responsabilidade	O que não faz
Líder do incidente	Declara e encerra o incidente, toma decisões, define os horários de atualização	Conduzir pessoalmente todas as investigações
Investigador técnico	Lê logs, cabeçalhos e DNS, testa correções, propõe a contenção	Alterar configurações de produção sem avisar o líder
Responsável pelo envio ou pela campanha	Sabe o que foi enviado, para quem e por quê; pausa e retoma streams	Retomar o tráfego sem a concordância do líder
Comunicador	Envia as atualizações para stakeholders e suporte, mantém a linha do tempo	Especular sobre causas

Revisão pós-incidente

Faça a revisão em poucos dias, enquanto as lembranças e os logs ainda estão frescos. Mantenha-a sem atribuição de culpa: o objetivo é descobrir o que no sistema deixou o problema passar, e não quem clicou no botão. Um registro de uma página é suficiente para a maioria dos incidentes.

1. Resumo: o que aconteceu e qual foi o impacto, em duas ou três frases.
2. Linha do tempo: quando começou, quando foi detectado, quando foi contido, quando foi recuperado. Tudo em UTC.
3. Causa raiz e fatores contribuintes: a causa direta e as lacunas que permitiram que acontecesse ou atrasaram a detecção.
4. O que funcionou bem: passos que deram certo e devem ser mantidos.
5. Ações: cada uma com um responsável e uma data, como um novo alerta, uma etapa de validação, uma verificação de DNS ou um fluxo de aprovação alterado.
6. Acompanhamento: uma data para confirmar que as ações foram concluídas e que as métricas estão estáveis.

Checklist do incidente

1. Incidente declarado, líder nomeado, horário de início registrado em UTC.
2. E-mail transacional verificado com mensagens de teste e mantido em um stream próprio.
3. Streams em massa e promocionais não críticos pausados ou limitados.
4. Sintoma classificado com a tabela de decisão: bounce, deferral, reclamação ou queda de engajamento; um provedor ou todos.
5. Evidências salvas: logs de eventos, respostas brutas, cabeçalhos, relatórios DMARC, dados de postmaster, verificações de listas de bloqueio e de DNS.
6. Histórico de mudanças reunido com toda a equipe.
7. Causa corrigida e verificada com uma mensagem de teste antes de qualquer retomada.
8. Recuperação em etapas a partir de contatos engajados, em volume reduzido, com critérios de aprovação combinados.
9. Atualizações para stakeholders e suporte enviadas no prazo.
10. Revisão realizada, ações atribuídas, proteções e alertas atualizados.

O MigoSMTP oferece envio, logs e eventos que ajudam em vários destes passos. Consulte sua conta MigoSMTP ou a documentação da API para ver os detalhes exatos sobre os relatórios, webhooks e controles disponíveis para você.

Leituras complementares e fontes

• RFC 5321: Simple Mail Transfer Protocol (códigos de resposta e comportamento de novas tentativas)
• RFC 3463: Enhanced Mail System Status Codes
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 6591: Authentication Failure Reporting Using the Abuse Reporting Format
• Google: Email sender guidelines