Un calendario di IP warmup in 6 settimane per mittenti self-hosted

Un IP senza storico di invio appare a un mailbox provider del tutto identico a un IP appena rilevato in seguito a un takeover. Non c'è alcun segnale di legittimità — non ancora. Inviare 50.000 messaggi al giorno uno da un IP fresco è indistinguibile da uno spammer che noleggia un blocco IP vergine per sparare prima che i sistemi di reputazione lo intercettino.

Per questo Gmail, Outlook, Yahoo, Apple iCloud Mail e i provider regionali fanno tutti la stessa cosa al primo contatto: accettano un piccolo volume iniziale, osservano come reagiscono i destinatari (apre / clicca / marca come spam / cancella senza leggere) e solo dopo alcuni giorni di engagement pulito sbloccano volumi più alti. Quei "pochi giorni" sono la finestra di warmup. La salti e non viene bloccato — viene throttled e spam-foldered per settimane, una condizione molto più difficile da recuperare di un reject immediato.

Esistono due forme di rampa in uso diffuso:

• Lineare — stesso incremento fisso al giorno. 50 → 100 → 150 → 200 → 250 … Prevedibile, lenta, conservativa.
• Esponenziale — moltiplica. 50 → 100 → 200 → 400 → 800 … Raggiunge il volume obiettivo più rapidamente ma è più aggressiva nella coda.

L'engine di warmup integrato di AcelleMail (model: app/Model/WarmupStrategy.php) supporta entrambe via le costanti GROWTH_STRATEGY_LINEAR e GROWTH_STRATEGY_EXPONENTIAL, più due preset di comodità: PRESET_BALANCED (lineare, incremento moderato) e PRESET_CAUTIOUS (lineare, incremento minore con finestra di rampa più lunga). Per domini di invio nuovi di zecca senza reputazione storica, il preset cauto è il default più sicuro. Per una migrazione di IP in cui il dominio From ha già reputazione su un altro IP, balanced o esponenziale sono accettabili.

I numeri esatti qui sotto sono una rampa lineare cauta. Sono deliberatamente conservativi; la disciplina conta più dei valori precisi. L'unica regola che fa saltare ogni warmup: non raddoppi mai il volume di ieri sul nuovo IP finché la reputazione non è consolidata. Una volta che i tassi settimanali di bounce + reclami restano puliti per una settimana al picco, l'IP è "warm" e il warmup si chiude.

A fine settimana 1 ha dimostrato di saper inviare e che i destinatari interagiscono. A fine settimana 2 si trova a 10.000/giorno — un salto di un ordine di grandezza rispetto al giorno uno. È a questo punto che le soglie bulk-sender di Gmail e Yahoo iniziano ad applicarsi: oltre i ~5.000 messaggi/giorno verso un singolo mailbox provider, l'allineamento DMARC, la disiscrizione one-click e i tetti sul tasso di reclami diventano obbligatori e non più consigliati. Se Le manca una qualsiasi di queste precondizioni, la settimana 2 è il momento in cui salta fuori — non come blocco ma come uno spostamento silenzioso nella cartella spam.

Il rimedio è far atterrare tutte e tre le precondizioni prima che il warmup inizi:

• DMARC almeno a p=quarantine; pct=100, idealmente p=reject, con i report RUA che fluiscono.
• Disiscrizione one-click via le intestazioni List-Unsubscribe + List-Unsubscribe-Post (RFC 8058). AcelleMail le emette di default.
• Budget sul tasso di reclami — Amazon SES impone un tetto rigido dello 0,1% sul tasso di reclami. Resti sotto lo 0,05% come margine operativo.

Il comando console app/Console/Commands/WarmupListServers.php è l'entry point cron. Itera ogni sending server attivo con una strategia agganciata e applica il cap giornaliero del day-of-strategy prima di permettere a qualsiasi campagna di consumare il server. Il cap vive in SendingServerWarmupUsage; il log di esecuzione giornaliero è SendingServerWarmupLog. La strategia stessa supporta tre tipi di limite via costanti su WarmupStrategy:

• LIMIT_TYPE_PER_DAY_CAP — "il budget di invio di oggi è N, non oltre"
• LIMIT_TYPE_TARGET_VOLUME — "rampa finché N/giorno non è sostenuto, poi marca come completato"
• LIMIT_TYPE_STOP_AFTER_DAYS — "rampa per N giorni, poi ferma"

Per la maggior parte degli operatori la combinazione giusta è GROWTH_STRATEGY_LINEAR + LIMIT_TYPE_TARGET_VOLUME: rampare linearmente fino a raggiungere il target giornaliero, poi disinnestare il warmup e proseguire in modalità normale. La strategia può essere agganciata a qualunque sending server — SES, Mailgun, SMTP generico, custom — indipendentemente dal driver sottostante.

Se sta facendo warmup contro Amazon SES (l'accoppiata consigliata su /pricing), tre numeri nel pannello "Reputation metrics" della console SES contano durante la rampa:

• Bounce rate — AWS avverte al 5%, mette in pausa al 10%. Lei dovrebbe restare ben sotto il 2%.
• Complaint rate — AWS avverte allo 0,1%, mette in pausa allo 0,5%. Resti sotto lo 0,05% come margine operativo.
• Limite di invio giornaliero — SES lo cresce in automatico man mano che il Suo storico di invio si accumula. Se smette di crescere, la Sua rampa di warmup sta superando l'auto-grant.

Ciascuna metrica è per account, non per IP, quindi è una derivata di tutto il Suo invio in aggregato. Se il numero di bounce rate sale durante la settimana 2, rallenti — non forzi il passaggio. Il provider ha notato qualcosa e il costo di indagare adesso è molto inferiore al costo di recuperare dopo una pausa.

Può saltare il warmup in due situazioni, e solo due:

1. Sta usando SES con IP condivisi (il default — gli account SES di produzione condividono un pool di IP gestito). Il pool è già pre-riscaldato; Lei eredita la sua reputazione. Il warmup non è rilevante a meno che non passi a IP dedicati SES.
2. Il Suo dominio From esistente ha già reputazione costruita su un altro IP, e Lei sta migrando al nuovo IP. Il warmup va comunque fatto, ma su un preset esponenziale anziché lineare cauto, perché la reputazione del dominio From si trascina dietro.

Per tutti gli altri — domini nuovi, IP dedicati, installazioni Postal MTA self-hosted fresche — il warmup non è opzionale. La trattazione più estesa con interpretazione giorno per giorno della dashboard SES vive su /guide/email-deliverability §7.