Il playbook dell'infrastruttura cold email
Se le email non atterrano nella primary inbox, nient'altro nell'outbound conta. La copy non La salva. L'AI non La salva. Lo fa solo un'infrastruttura autenticata, diversificata, rotata.
Ecco il pattern che vediamo settimanalmente. Un team compra 120 inbox su 40 domain da un reseller. Le warm-uppa per due o tre settimane. Lancia le campagne. Zero reply, nemmeno un out-of-office. Panico. Cambia la copy. Ancora niente. Sei settimane dopo, la deliverability crolla del tutto. L'infrastruttura viene rottamata e si ricomincia.
Nove volte su dieci, il problema è l'infrastruttura, non la copy. Una copy «cattiva» spedita su un'infrastruttura ben autenticata viene consegnata. Una copy «buona» spedita su un'infrastruttura rotta no. Framing e autenticazione contano 10x più delle spam word.
Il triangolo di autenticazione: SPF, DKIM, DMARC
Ogni sending domain in cold ha bisogno di tre record DNS, configurati in allineamento. Quando uno solo manca o è mal configurato, la deliverability crolla.
SPF (Sender Policy Framework)
SPF dice ai mail server in ricezione quali IP sono autorizzati a spedire dal Suo domain. Un record SPF Google Workspace standard è così: v=spf1 include:_spf.google.com ~all. La regola critica: la return address (envelope-from) deve corrispondere alla sender address perché SPF passi — si chiama SPF alignment. Il forwarding rompe l'alignment, ed è per questo che un «reply-to» diverso su una cold campaign spesso uccide la deliverability.
DKIM (DomainKeys Identified Mail)
DKIM è una firma crittografica — il francobollo che prova che il messaggio viene davvero dal domain che dichiara di averlo spedito. Google Workspace genera la chiave DKIM nella console admin; la copia come record TXT nel DNS. Microsoft 365 funziona allo stesso modo. Verifichi che passi mandandosi un'email su Gmail e aprendo «Mostra originale» — SPF, DKIM e DMARC devono mostrare tutti PASS.
DMARC (Domain-based Message Authentication)
DMARC è la policy che dice ai receiver cosa fare quando SPF o DKIM falliscono. Le tre policy sono none, quarantine e reject. La best practice per il cold sending è:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; sp=none
p=reject è il gold standard una volta che SPF e DKIM passano. Forza un'infrastruttura pulita — nulla di non autenticato passa. Aggiungere rua= (aggregate report URI) significa ricevere report giornalieri su chi prova a spedire spacciandosi per Lei. Saltare rua= è un classico errore da principianti; senza, vola alla cieca.
Trappola comune: p=reject prima che SPF e DKIM siano verificati in pass. Se l'auth fallisce, la Sua stessa mail non raggiunge la Sua primary inbox. Mandi un test su mail-tester.com, confermi 10/10 e controlli via «Mostra originale» di Gmail che SPF/DKIM/DMARC mostrino tutti PASS prima di stringere DMARC.
Warmup di domain: 28 giorni, non due settimane
I domain freschi hanno bisogno di un minimo di 28 giorni di warmup prima di lanciare campagne vere. Due settimane non bastano. Tre settimane sono il pavimento per risultati marginali. Quattro settimane sono il punto in cui i reply rate si stabilizzano.
I tool di warmup — Warmup Inbox, Warmbox, Warmforge, Mailwarm, Folderly, Mailreach, Warmy — simulano conversazioni per costruire reputation del domain. Ne usi uno integrato con il Suo sequencer. Durante il warmup, gli inbox health score devono salire da zero verso 80-100. Se gli score restano sotto 20 dopo tre settimane su domain freschi, qualcosa è rotto a monte — di solito il blocco IP del reseller o una misconfigurazione DNS.
Cosa fa davvero il warmup: stabilisce che il Suo domain ha traffico email legittimo, dall'aspetto umano. Cosa non fa: compensare copy cattiva, liste non verificate o un registrar di domain in una blocklist spam.
Placement testing, per provider
Ogni provider email ha seed di deliverability diversi. Il filtro spam di Google non è quello di Microsoft 365. Mimecast, Barracuda e Proofpoint (anti-spam enterprise) classificano ognuno in modo diverso. Lanciare un placement test Le dice quali provider inboxano e quali quarantenano prima di sprecare una campagna su un'audience silenziosa.
Tool che usiamo:
- mail-tester.com — health score base, check delle spam word, verifica auth
- Folderly — placement testing completo più monitoraggio continuo della deliverability
- GlockApps — inbox placement dettagliato sui provider
- Emailguard / Mailreach / Warmy — monitoraggio continuo del placement
- Inbox Placement (Smartlead) — il quick check più economico
Lanci placement test su infrastruttura fresca prima di andare live, poi ri-testi ogni due settimane. La deliverability deriva — un domain che inboxa in settimana 4 può finire in quarantena in settimana 8. Lo intercetti presto e ruoti prima che le reply muoiano.
Lo stack multi-ESP, multi-registrar
Gold standard 2026: due registrar di domain, due ESP (Google Workspace + Microsoft 365), come minimo. Tre di ciascuno a regime vero. Il ragionamento è semplice: un single point of failure uccide tutta la pipeline. Quando Google deprecata un reseller grey-hat o Microsoft stringe le quote, ruota sul Suo secondo stack mentre sistema il primo.
Come appare in pratica per un team che spedisce 100K+ email al mese:
- Batch 1: 30 domain su registrar A, Google Workspace, sequencer 1 — spedire per due settimane, poi cool down
- Batch 2: 30 domain su registrar B, Microsoft 365, sequencer 2 — spedire mentre il batch 1 riposa
- Batch 3: riserva hot-swap — pre-warmata, pronta a essere deployata quando uno dei batch brucia
Per questo le agenzie che girano 100+ inbox senza rotazione vedono una scogliera di deliverability ogni sei settimane. Bruciano uno stack alla volta. La rotazione distribuisce il burn e allunga la vita dell'infrastruttura.
Naming dei domain: lettere, .com o .co, nessuna eccezione
Gli amministratori di sistema nei target enterprise bloccano attivamente TLD insoliti e domain dall'aria sospetta. Il Suo sending domain deve sembrare esattamente un normale domain aziendale di cui un sysadmin si fida a colpo d'occhio.
- Usare: .com, .co e TLD geo-specifici (.de, .nl, .fr, .uk) per campagne locali
- Evitare: .xyz, .online, .site, .tech, .info, .biz — tutti flaggati dai filtri enterprise
- Evitare: numeri (company1.com), trattini (get-company.com) — pattern di phishing
- Preferire: varianti con sole lettere (trycompany.com, hqcompany.com, getcompany.com, usecompany.com, joincompany.com)
Il Suo domain principale non andrebbe mai usato per cold sending — il rischio reputazionale è troppo alto. Usi domain look-alike acquistati su infrastruttura separata e tenga il domain principale pulito per la comunicazione customer-facing.
Due inbox per domain, non tre
Dati di deliverability da migliaia di setup di cold sending: due inbox per domain su Google Workspace performano meglio di tre. Più inbox per domain non è più throughput — è più rischio per burn di domain. Quindici domain con due inbox ciascuno (30 mailbox) battono dieci domain con tre inbox ciascuno (30 mailbox) sulla deliverability.
Spam word e igiene della copy
Le liste di spam word sono sopravvalutate. Framing e infrastruttura contano 10x di più. Detto questo, non riempia di proposito un messaggio con «free», «guarantee», «urgent», «act now» o tipico linguaggio sales. Usi lo spam checker di Mailmeteor o il word checker di Folderly per un sanity check veloce.
Più importante delle singole parole:
- Tenere le cold email sotto le 50-60 parole (i dati di copy Leadbird mostrano costantemente: più corto consegna meglio)
- Niente HTML, CSS o tracking pixel al first touch — il plain text vince
- Niente link nella prima email se non per un motivo eccezionale
- Una CTA, non tre
- Spintax o varianti AI-generate su ogni riga per evitare il pattern fingerprinting
Cosa costruiamo per i clienti
Un engagement di deliverability tipico:
- Audit della flotta di domain esistente, dei record di auth, dei warmup pool e del placement
- Setup di un'architettura multi-ESP, multi-registrar dimensionata sul volume
- Configurazione di SPF, DKIM, DMARC p=reject con reporting rua=
- Costruzione del calendario di rotazione (batch 1/2/3) e di una riserva hot-swap
- Integrazione di una cadenza di placement testing (ogni 2 settimane, alert automatici)
- Ingestione delle metriche di deliverability in HubSpot accanto ai dati di sequence e reply
- Formazione del Suo team per gestire il sistema e diagnosticare il drift
Timeline: quattro-sei settimane dal contratto al primo invio pulito, in base alla dimensione della flotta di domain e allo stato del warmup. Lanciamo campagne LinkedIn e cold calling durante il warmup, così non aspetta un mese per la pipeline.
Sistemi la deliverability prima di toccare la copy
Auditiamo, ricostruiamo e rotiamo l'infrastruttura affinché i Suoi reply rate riflettano la Sua offer, non i Suoi record di auth.
Parliamone