Por que meu aplicativo parou de enviar e-mails?

Olhe primeiro o log do provedor, não o seu

O que confunde nessa falha é que nada parece quebrado. Seu código rodou, a função de envio retornou, nenhuma exceção foi lançada, e os seus próprios logs mostram mensagens saindo. Isso acontece porque o log do seu aplicativo registra o que o seu código decidiu fazer, e o log do provedor registra o que aconteceu com a mensagem. Quando os dois discordam, o provedor está certo. Abra a visão de atividade dele e filtre pela janela em que os envios pararam: normalmente você vai ver ou silêncio a partir de um horário, o que significa que o seu código parou de chamar, ou uma sequência de recusas com um motivo anexado, o que significa que ele chamou e foi recusado.

Faça isso antes de mudar código, rotacionar uma chave de API ou reenviar qualquer coisa. Cada uma dessas ações dificulta o diagnóstico, e uma delas piora o problema: uma rajada de reenvios contra uma conta já marcada por volume é a maneira clássica de transformar uma pausa temporária em permanente.

As quatro coisas que de fato interrompem o envio

Em ordem aproximada de quantas vezes cada uma acaba sendo a resposta:

• Um limite do plano no qual você entrou crescendo Tetos de envio diários e mensais são a causa mais comum e a que mais parece injusta, porque nada no seu sistema mudou: os seus cadastros mudaram. O limite é cruzado numa terça-feira igual a todas as outras, e o que é descartado é o que estava na fila por último, normalmente o e-mail de notificação e de ciclo de vida, e não os e-mails de acesso enviados de manhã.
• Uma pausa do provedor Provedores param contas diante de mudanças bruscas de volume, de uma taxa de retorno definitivo acima de um limite e de reclamações de spam. Essa costuma vir com um e-mail de aviso, enviado para o endereço que estava na conta quando ela foi criada, que num time pequeno muitas vezes já não é a caixa de entrada de ninguém.
• Autenticação de domínio quebrada Os registros SPF, DKIM e DMARC ficam no DNS, então quebram quando o DNS muda: uma migração de registrador, um registro que substituiu em vez de acrescentar, uma verificação vencida, uma chave de assinatura rotacionada. Essa degrada antes de parar: primeiro a entrega falha num provedor de caixa postal, depois a taxa de retorno sobe, depois vem a pausa.
• O seu próprio código parou de chamar Uma variável de ambiente faltando em um ambiente, um worker de fila que morreu calado, uma feature flag que ficou desligada depois de um deploy, uma atualização de SDK que mudou um campo obrigatório. Se o log do provedor mostra silêncio em vez de recusas, esse é o seu ramo, e a resposta está no seu histórico de deploys, não no painel do provedor.

Leia o corpo, não o código de status

É isso que transforma um incidente de dez minutos num de três dias, e nós já cometemos o erro mais de uma vez no nosso próprio sistema. Uma chamada recusada não chega de forma confiável como erro. Ela chega como um HTTP 200 com a falha dentro do corpo da resposta, e o código que só confere o código de status registra um sucesso. Batemos exatamente nesse formato com fornecedores diferentes: um responde 200 com um indicador de sucesso falso no corpo quando falta uma permissão no token; outro aceitou uma publicação em rede social, relatou uma falha de validação no corpo, e o nosso sistema — que lia só o envelope — registrou a publicação como publicada e disse isso ao cliente. Nada havia sido publicado.

A regra que saiu disso é curta, e vale para e-mail como vale para tudo: considere um envio bem-sucedido apenas quando o corpo da resposta disser que o provedor aceitou, registre o motivo literal do provedor quando ele não aceitar, e alerte sobre essa string em vez de sobre o seu próprio resumo dela. A linha de status descreve a conversa com a API. O corpo descreve o e-mail.

A mesma disciplina cobre a limitação de taxa. Um provedor respondendo 429 está te dizendo algo útil e temporário, e código sem recuo progressivo converte isso em perda permanente, porque a mensagem é descartada e nunca reenviada. Ficamos sem esse recuo por mais tempo do que deveríamos, e o que acabou revelando o problema não foi um alerta. Foi alguém ir olhar.

Faça o próximo fazer barulho

A correção que importa não é aumentar o limite, é perceber antes de chegar nele — e o alerta tem que ser sobre a proporção, não sobre a contagem. «Usamos 80% da cota de hoje até as 14h» é acionável; «enviamos 100 mensagens» deixa de significar qualquer coisa no instante em que o plano muda. Nosso próprio volume passou de cem mensagens por dia conforme os cadastros cresceram, contra um teto de plano gratuito de exatamente cem: cerca de 107 no dia em que finalmente olhamos, depois de termos ficado em 99 de 100 no começo daquela semana. Nenhuma parte do sistema falou nada. O upgrade de plano foi a metade fácil. O alerta que ainda devíamos a nós mesmos era a metade que importava, e o motivo de ele não existir é que o teto nunca tinha chegado perto, então ninguém tinha pensado nele como um número que se mexe.

Mais duas coisas que valem a pena já que você está aqui. Mantenha uma segunda porta de entrada na conta para quando um e-mail que carrega um acesso não chegar, pelos motivos da nossa página sobre por que os logins por link mágico falham. E separe o e-mail que carrega um acesso ou um recibo do e-mail que carrega uma campanha — por domínio de envio no mínimo, de preferência por provedor — para que uma campanha que dispara um limite de reclamações não consiga derrubar as suas redefinições de senha junto. Nossa página sobre como montar e-mails de ciclo de vida cobre o que pertence a cada fluxo. Construir a AgentCeres — a AI Growth Officer em agentceres.com — nos ensinou a prioridade pelo caminho caro: as mensagens que o cliente realmente pediu são as que você protege primeiro.