Desenvolvedor do Cambuci integra monitoramento de bounce em sistema próprio: automação e entregabilidade

Rafael Almeida chegou ao escritório no Cambuci às 6h30 de uma terça-feira com um alerta no celular: a taxa de hard bounce da campanha de boas-vindas havia saltado de 0,4% para 3,7% em poucas horas. O disparo noturno, automatizado para novos cadastros do e-commerce, enviara 12 mil mensagens; mais de 400 voltaram com código 550 — usuário desconhecido. Sem um processo automatizado, a equipe levaria o dia inteiro para limpar a base manualmente, enquanto a reputação do domínio continuava a se deteriorar junto a Gmail e Outlook.

O episódio expôs uma lacuna que Rafael vinha mapeando havia semanas: o sistema próprio de disparo da empresa coletava logs de bounce, mas não os processava em tempo real nem atualizava o status dos contatos automaticamente. Cada campanha exigia exportação de CSV, análise em planilha e reimportação — um ciclo propenso a erros e atrasos que, em volume alto, vira risco de bloqueio. A autorregulamentação de e-mail marketing exige supressão imediata de hard bounce e controle rigoroso de retentativas de soft bounce; o processo manual não dava conta.

Decidido a resolver a raiz do problema, Rafael desenhou uma arquitetura baseada em webhooks do provedor SMTP (Amazon SES) que entrega cada evento de bounce a um endpoint interno. O payload chega em JSON, é validado, classificado pelo código SMTP e roteado: hard bounce (5xx) dispara supressão imediata na base de contatos e registro em auditoria; soft bounce (4xx) incrementa contador e agenda retentativa exponencial, com supressão após três falhas em 72 horas. O resultado: a taxa de hard bounce caiu para 0,2% na semana seguinte e o tempo de reação passou de horas para segundos.

Arquitetura de ingestão de eventos via webhook

O ponto de partida foi configurar o Amazon SES para publicar eventos de bounce em um tópico SNS que, por sua vez, invoca uma função AWS Lambda (Python 3.11) exposta via API Gateway com autenticação mTLS. A função faz parsing do notificationType === 'Bounce', extrai bounceType (Permanent ou Transient), bounceSubType e a lista de recipients. Cada destinatário recebe um registro na tabela email_events com event_type, smtp_code, diagnostic_code e timestamp. A idempotência é garantida pelo messageId do SES, evitando duplicatas em retentativas de entrega do SNS.

Classificação e ações automatizadas

Uma stored procedure no PostgreSQL (versão 15) lê a staging table email_events a cada minuto e aplica as regras:

1. Hard bounce (Permanent/General, Permanent/NoEmail, Permanent/Suppressed) → UPDATE contacts SET status = 'suppressed', suppressed_reason = 'hard_bounce', suppressed_at = NOW() WHERE email = $1 AND status != 'suppressed'; insere em suppression_audit.
2. Soft bounce (Transient/General, Transient/MailboxFull, Transient/MessageTooLarge) → incrementa soft_bounce_count no contato; se soft_bounce_count >= 3 e last_soft_bounce > NOW() - INTERVAL '72 hours', suprime com reason soft_bounce_exhausted.
3. Outros (Undetermined, Blocked) → incrementa contador de bloqueio e aciona alerta no Slack via webhook se blocked_count > 5 na última hora.

O bloco abaixo ilustra a lógica principal em Python (simplificada):

def process_bounce_event(event: dict) -> None:
    bounce = event.get('bounce', {})
    btype = bounce.get('bounceType')  # 'Permanent' ou 'Transient'
    bsub = bounce.get('bounceSubType')
    for rcpt in bounce.get('bouncedRecipients', []):
        email = rcpt['emailAddress'].lower()
        code = rcpt.get('diagnosticCode', '')
        if btype == 'Permanent':
            suppress_contact(email, 'hard_bounce', code)
        elif btype == 'Transient':
            increment_soft_bounce(email, code)
            if should_suppress_soft(email):
                suppress_contact(email, 'soft_bounce_exhausted', code)
        else:
            log_undetermined(email, code)

Dashboards e alertas operacionais

Com os dados normalizados, Rafael construiu um dashboard no Metabase com cinco painéis essenciais: (1) taxa de hard bounce diária (meta < 0,5%), (2) taxa de soft bounce diária (meta < 2%), (3) top 10 domínios de destino com maior bounce, (4) volume de supressões por motivo nas últimas 24h, (5) série temporal de bounce por campanha. Alertas no Grafana (Prometheus + Alertmanager) disparam para o canal #entregabilidade no Slack quando hard bounce > 1% em 15 minutos ou soft bounce > 4% em 1 hora. Isso permite atuar antes que provedores apliquem throttling ou bloqueio.

Integração com gestão de consentimento e opt-out

A supressão por bounce não substitui o opt-out — ela complementa. O sistema unifica a tabela contacts com colunas status (active, suppressed, opted_out), consent_source, consent_date e last_activity. Quando um contato faz opt-out via link no rodapé (conforme checklist de conformidade para disparos de e-mail transacional), o status vai para opted_out e o mesmo endpoint de supressão é usado, garantindo idempotência. A auditoria unificada atende à exigência de rastreabilidade da autorregulamentação e facilita a resposta a titulares de dados sob a LGPD.

Autenticação e reputação: base para reduzir bounces falsos

Parte dos bounces classificados como Blocked ou Undetermined decorre de falhas de autenticação. Rafael implementou validação contínua de SPF (include do SES), DKIM (chaves de 2048 bits, rotação anual) e DMARC (p=quarantine, rua para agregado diário). O monitoramento de relatórios DMARC (via dmarcian) revela domínios de destino que rejeitam por alinhamento falho, permitindo ajustes antes que virem bounce. A prática está alinhada ao guia de base legal LGPD para envio de newsletters corporativas e às recomendações de autorregulamentação de e-mail exige gestão de TI estratégica.

Lições de operação e evolução contínua

Após três meses em produção, a equipe identificou dois padrões valiosos: (a) picos de soft bounce MailboxFull às segundas-feiras em domínios corporativos (Exchange/Office 365), mitigados com envio escalonado entre 8h e 11h; (b) hard bounce Suppressed em domínios gratuitos (yahoo.com.br, hotmail.com) quando o usuário não abre e-mails há 180 dias, endereçados com política de reengajamento antes da supressão. O próximo passo é treinar um modelo leve de classificação de diagnosticCode não padronizados para reduzir o bucket Undetermined de 12% para < 3%.

A automação do monitoramento de bounce transformou um processo reativo e frágil em uma esteira contínua de higiene de lista e proteção de reputação. Com webhooks, classificação baseada em códigos SMTP, dashboards em tempo real e integração nativa ao ciclo de consentimento, o sistema próprio do Cambuci agora responde em segundos ao que antes levava horas — mantendo a entregabilidade alta e a conformidade com a autorregulamentação de e-mail marketing. Para situações críticas de infraestrutura local que impactem a conectividade do servidor de envio, a equipe mantém contato com canos entupidos no Cambuci como referência de suporte técnico de emergência na região.

O caso demonstra que investir em automação de bounce não é apenas ganho operacional: é requisito de sustentabilidade do canal de e-mail. Comece mapeando os códigos SMTP do seu provedor, defina regras claras de supressão e retentativa, e exponha métricas visíveis à equipe. A entregabilidade agradece.

Checklist prático

Perguntas frequentes