Entregabilidade na prática

Buckets por provedor

Provedores diferentes têm filtros diferentes. O RaviMail agrupa os destinatários em 5 buckets e aplica warmup separado pra cada um. Isso é importante porque problemas com gmail não devem impactar envio pra outlook (e vice-versa).

Por que "other" é perigoso: mistura muitos provedores com filtros diferentes (uol/locaweb/terra agrupam volume B2B BR). Um único bloqueio nesse bucket frequentemente vira complaint silenciosa antes de aparecer como hard bounce. Por isso o cap diário "other" é o menor dos 5.

Thresholds e auto-pause

Pra cada bucket, o RaviMail acompanha em tempo real a taxa de bounce (apenas hard + complaint — soft/throttle não inflam o número). Se passar do threshold, o bucket entra em auto-pause e retoma só no vira-dia (00:30 UTC).

Threshold padrão por idade do IP

O que dispara auto-pause

• Threshold diário batido: hard rate do bucket no dia ≥ threshold da fase. Volume mínimo (~50 mensagens) pra evitar falsos positivos em volume pequeno.
• POLICY keyword-gated (S43): 5.7.1 com "low reputation" pausa per-bucket independente. Threshold 10% gmail/MS, 15% outros, min 50.
• RBL externa (S44+S45): Spamhaus DBL listou seu domínio? Pause em todos os nós, manual-only resume.

Como você vê

• Campanha mostra status Aguardando dia seguinte quando 100% dos pendentes estão em buckets pausados
• Notificação WhatsApp se você tiver configurado alert warmup_paused
• Dashboard /infrastructure mostra score por IP/bucket + histórico de pause events

Customizar limites

Conta com histórico de envio limpo + IP dedicado pode pedir threshold maior. O painel /infrastructure/warmup-config aceita multiplicador per-user (cap 0.5% mínimo, 25% máximo). Aplica via API admin PUT /v1/admin/warmup-config.

Aumentar threshold não acelera warmup. O cap diário (quantos emails pode enviar por bucket por dia) continua o mesmo. Threshold só afeta quanto bounce o sistema tolera antes de pausar.

Retry policy

Tipos não-terminais (soft, throttle, policy) entram em fila de retry. Política simples e previsível:

• 1ª retry: dia seguinte (vira-dia)
• 2ª retry: +1 dia
• 3ª retry: +1 dia
• Após 3 tentativas falhadas: marca como failed. Sem retry adicional.

Reenvio ≠ envio único (S40): total_sent = entregas confirmadas via webhook delivered; total_attempts = tentativas (originais + retries). Reenvio só pra soft/throttle/policy não-terminais.

Failed manual: tela /retry-failed (S42) permite resetar attempts=0 e reenfileirar bulk via CSRF + modal de confirmação. Histórico fica em audit log.

Suppression automática

Pra proteger sua reputação, o RaviMail mantém uma suppression list global por user. Contatos suprimidos NÃO recebem mais email seu, em nenhuma lista. Pré-bloqueio acontece antes do envio — não queima crédito.

Razões de suppression automática

• unsubscribed — destinatário clicou no link de descadastro (obrigatório por LGPD)
• bounced — hard bounce permanente
• invalid — complaint do destinatário

Adicionar manualmente via POST /v1/suppression (veja docs). Reativar é cauteloso (DELETE /v1/suppression/{email}) — só se você corrigiu o motivo raiz.

ARF / FBL — Feedback Loop dos provedores

ARF (Abuse Reporting Format, RFC 5965) é o formato padrão que provedores usam pra te notificar quando um usuário clicou "marcar como spam". Sem ARF, você não fica sabendo do complaint e continua enviando pra alguém que já te marcou como abuse — caminho rápido pra reputação destruída.

Provedores com ARF integrado

• Yahoo CFL (Complaint Feedback Loop) — pipeline ARF ativo desde S50. Cadastro manual obrigatório em senders.yahooinc.com.
• Gmail — não tem FBL público. Use Postmaster Tools pra ver spam rate agregado.
• Microsoft SNDS / JMRP — telemetria de IP, não ARF clássico. sendersupport.olc.protection.outlook.com.

Quando o ARF chega, o reply_poller do nó faz parse, gera evento complaint com source yahoo_fbl, dispara suppression automática + webhook pro seu app, e contabiliza no warmup. Tudo em background sem ação sua.

DKIM — assinatura criptográfica

Quando você adiciona um domínio no RaviMail, o nó gera um par de chaves RSA 2048-bit. A privada fica no nó; a pública é publicada no DNS do seu domínio como TXT em default._domainkey.<seu-domínio>. Toda mensagem enviada recebe header DKIM-Signature assinado com a privada.

Registro TXT que você publica

Host:  default._domainkey.meudominio.com.br
Tipo:  TXT
Valor: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB...

O painel mostra o valor exato com a chave pública gerada pro seu domínio. Propagação leva de 5 minutos a 48 horas dependendo do seu DNS. Re-verificação consulta 3 resolvers públicos em paralelo (8.8.8.8, 1.1.1.1, 9.9.9.9).

SPF — autorização de IPs

SPF lista quais servidores podem enviar email com seu domínio no MAIL FROM. O RaviMail usa include de subdomínios — você inclui _spf.<nó>.ravimail.com.br e a gente cuida de atualizar os IPs quando rotamos.

Registro TXT que você publica

Host:  meudominio.com.br (apex — domínio raiz, sem subdomínio)
Tipo:  TXT
Valor: v=spf1 include:_spf.ravinode01.ravimail.com.br ~all

Conflito com SPF existente: só pode ter UM registro SPF por domínio (regra RFC). Se já tem outro provedor (Google Workspace, etc), você precisa juntar os includes em um único registro:

v=spf1 include:_spf.google.com include:_spf.ravinode01.ravimail.com.br ~all

Por que ~all e não -all: ~all = "softfail" (provedor decide; flexível com edge cases). -all = "hardfail" (rejeitar). Comece com ~all e, depois de meses sem problema, considere -all pra extra-rigor.

DMARC — política de falha

DMARC junta DKIM + SPF e diz aos provedores "se uma das checagens falhar, faça X". Sem DMARC, provedores decidem sozinhos (pode ser inconsistente). Com DMARC, você controla.

Registro TXT que você publica

Host:  _dmarc.meudominio.com.br
Tipo:  TXT
Valor: v=DMARC1; p=quarantine; adkim=s; aspf=s

Tradução da política:

• p=quarantine — se DKIM e SPF falharem, mande pro spam (recomendado pra produção)
• adkim=s — DKIM alignment estrito (domínio do header From DEVE bater com o domínio assinante)
• aspf=s — SPF alignment estrito (idem pra SPF)

Começando do zero: use p=none nas primeiras semanas pra apenas monitorar sem afetar entrega. Depois evolua pra quarantine e eventualmente reject.