Um cronograma de 6 semanas de IP warmup para remetentes auto-hospedados

Um IP sem histórico de envio parece igual a um provedor de mailbox a um IP que acabou de ser tomado. Não há sinal de legitimidade — ainda. Enviar 50.000 mensagens no dia um a partir de um IP fresco fica indistinguível de um spammer alugando um bloco de IP virgem para enviar antes que os sistemas de reputação acordem.

Então Gmail, Outlook, Yahoo, Apple iCloud Mail e os provedores regionais fazem todos a mesma coisa no primeiro contato: aceitam um volume inicial pequeno, observam como os destinatários reagem (abrir / clicar / marcar como spam / deletar sem ler), e somente após alguns dias de engajamento limpo desbloqueiam volumes maiores. Os "alguns dias" são a janela de warmup. Pule e você não fica bloqueado — fica throttled e spam-folderized por semanas, o que é mais difícil de recuperar do que uma rejeição imediata.

Há dois shapes de rampa em uso amplo:

• Linear — mesmo incremento fixo por dia. 50 → 100 → 150 → 200 → 250 … Previsível, lento, conservador.
• Exponencial — multiplica. 50 → 100 → 200 → 400 → 800 … Atinge o volume-alvo mais rápido mas é mais agressivo no final.

A engine de warmup integrada do AcelleMail (model: app/Model/WarmupStrategy.php) suporta ambas via as constantes GROWTH_STRATEGY_LINEAR e GROWTH_STRATEGY_EXPONENTIAL, mais dois presets de conveniência: PRESET_BALANCED (linear, incremento moderado) e PRESET_CAUTIOUS (linear, incremento menor com janela de rampa mais longa). Para domínios totalmente novos sem reputação histórica, cautious é o default mais seguro. Para uma migração de IP onde o domínio From já tem reputação em outro IP, balanced ou exponencial são aceitáveis.

Os números exatos abaixo são uma rampa linear cautious. São deliberadamente conservadores; a disciplina importa mais que os valores precisos. A única regra que quebra todo warmup: nunca dobre o volume de ontem no IP novo antes que a reputação esteja estabelecida. Uma vez que taxas semanais de bounce + complaint estejam limpas por uma semana no pico, o IP está "warm" e o warmup termina.

Ao fim da semana 1 você provou que pode enviar e que destinatários estão engajando. Ao fim da semana 2 você está em 10.000/dia — um pulo de uma ordem de grandeza desde o dia um. É aí que os thresholds de bulk sender no Gmail e Yahoo começam a se aplicar: acima de ~5.000 mensagens/dia para um único provedor de mailbox, o alinhamento DMARC, o unsubscribe de um clique e os tetos de complaint rate viram exigidos em vez de aconselháveis. Se você está faltando qualquer dessas precondições, a semana 2 é quando isso aparece — não como um bloqueio mas como uma mudança silenciosa para a pasta de spam.

A correção é pousar todas as três precondições antes que o warmup comece:

• DMARC em p=quarantine; pct=100 no mínimo, idealmente p=reject, com relatórios RUA fluindo.
• Unsubscribe de um clique via os headers List-Unsubscribe + List-Unsubscribe-Post (RFC 8058). O AcelleMail emite esses por padrão.
• Budget de complaint rate — Amazon SES força um teto rígido de 0,1% de complaint rate. Fique abaixo de 0,05% como margem de trabalho.

O comando de console app/Console/Commands/WarmupListServers.php é o entry point cron. Ele itera cada sending server ativo com uma estratégia anexada e aplica o cap diário do day-of-strategy antes de permitir que qualquer campanha consuma o servidor. O cap vive em SendingServerWarmupUsage; o log de execução por-dia é SendingServerWarmupLog. A própria estratégia suporta três tipos de limite via constantes em WarmupStrategy:

• LIMIT_TYPE_PER_DAY_CAP — "o budget de envio de hoje é N, não mais"
• LIMIT_TYPE_TARGET_VOLUME — "rampa até N/dia ficar sustentado, então marca como completo"
• LIMIT_TYPE_STOP_AFTER_DAYS — "rampa por N dias, então para"

Para a maioria dos operadores a combinação certa é GROWTH_STRATEGY_LINEAR + LIMIT_TYPE_TARGET_VOLUME: rampar linearmente até atingir o alvo diário, então desengajar warmup e rodar normalmente. A estratégia pode ser anexada a qualquer sending server — SES, Mailgun, SMTP genérico, custom — independentemente do driver subjacente.

Se você está fazendo warmup contra Amazon SES (o pairing recomendado em /pricing), três números no painel "Reputation metrics" do console SES importam durante a rampa:

• Bounce rate — AWS avisa em 5%, pausa em 10%. Você deve ficar bem abaixo de 2%.
• Complaint rate — AWS avisa em 0,1%, pausa em 0,5%. Fique abaixo de 0,05% como margem de trabalho.
• Sending limit diário — SES cresce isso automaticamente conforme seu histórico de envio acumula. Se parou de crescer, sua rampa de warmup está superando o auto-grant.

Cada um é por-conta, não por-IP, então a métrica é uma derivada de todos seus envios em agregado. Se o número de bounce rate sobe durante a semana 2, desacelere — não force passagem. O provedor notou alguma coisa e o custo de investigar agora é muito menor do que o custo de recuperar depois de uma pausa.

Você pode pular o warmup em duas situações e só duas:

1. Você está usando SES com IPs compartilhados (o default — contas SES de produção compartilham um pool de IPs gerenciado). O pool é pré-aquecido; você herda sua reputação. Warmup não é relevante a menos que você passe para IPs dedicados do SES.
2. Seu domínio From existente já tem reputação construída em outro IP, e você está migrando para o IP novo. Você ainda faz warmup, mas em um preset exponencial em vez de linear cautious, porque a reputação do domínio From carrega adiante.

Para todos os outros — domínios novos, IPs dedicados, installs de Postal MTA auto-hospedados frescos — warmup não é opcional. O tratamento mais longo com interpretação do dashboard SES dia-a-dia está em /guide/email-deliverability §7.