Email deliverability nel 2026 — gli standard, il warmup, il feedback loop.

§1 · Definizione

Cos'è davvero l'email deliverability.

La deliverability è il tasso con cui i messaggi inviati raggiungono l'inbox principale del destinatario — distinta dalla delivery (il messaggio è stato accettato dal mail server del destinatario) e dal send (lo hai consegnato alla pipeline di invio). Un messaggio può essere inviato con successo, consegnato al mail server del destinatario, e finire nella cartella spam — è un successo di delivery e un fallimento di deliverability. I numeri che contano davvero — open rate, click rate, conversioni — dipendono dalla deliverability, non dalla delivery.

I mailbox provider — Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton, i grandi provider regionali — eseguono ciascuno una pipeline di scoring multi-stage su ogni messaggio in arrivo. Gli stage sono più o meno gli stessi tra provider, con differenze di peso:

1. Controlli al momento della connessione. Reverse DNS, sanity check su HELO/EHLO, supporto TLS, presenza dell'IP su RBL (Spamhaus, SpamCop, ecc.).
2. Controlli di autenticazione. SPF pass/fail (RFC 7208), validazione della firma DKIM (RFC 6376), DMARC alignment (RFC 7489). Tutti e tre devono passare puliti per ottenere lo scoring downstream più indulgente.
3. Scoring dei contenuti. Densità di parole-spam, reputazione dei link, rapporto immagine-testo, coerenza tra From-name e From-address.
4. Lookup della reputazione. Il registro interno del provider per il tuo IP di invio e il dominio From — bounce rate storico, complaint rate, engagement sugli invii precedenti.
5. Segnale di engagement. Il destinatario (o i destinatari della sua coorte) ha aperto o cliccato in passato messaggi simili da te? L'engagement recente è il singolo segnale positivo più forte.
6. Disposition. Inbox, scheda Promozioni (Gmail), cartella spam, o reject. La disposition rientra a sua volta nella reputazione.

Le cinque sezioni qui sotto affrontano gli stage 2 (autenticazione) e 4 (reputazione). Lo stage 1 è per lo più compito del relay di invio; gli stage 3 e 5 sono decisioni su contenuti e audience fuori dallo scope di una guida di deliverability. Lo stage 6 è l'output. Per un sender commerciale tipico, fare bene gli stage 2 e 4 ti porta dal 60–80% di inboxing al 95%+.

Questa guida è scritta per chi gestisce un'installazione self-hosted perché sei tu a regolare i parametri. Su SaaS la piattaforma astrae quasi tutto questo; in self-hosted possiedi tu il record SPF, la coppia di chiavi DKIM, la policy DMARC, la pianificazione di IP warmup. La buona notizia: gli standard sono pubblici e stabili. La cattiva: non esistono scorciatoie.

§2 · SPF

SPF — Sender Policy Framework.

SPF (RFC 7208) è una lista pubblica di indirizzi IP autorizzati a inviare email per conto del tuo dominio. La pubblichi come un singolo record TXT sul tuo dominio di invio. Quando un mailbox provider riceve un messaggio che dichiara di provenire da @yourcompany.com, consulta il record SPF su yourcompany.com e chiede: questo messaggio arriva da uno degli IP elencati? Se sì, SPF passa. Se no, SPF fallisce.

La sintassi

v=spf1 include:amazonses.com ~all

Si legge: "SPF versione 1, autorizza tutto ciò che Amazon SES autorizza, soft-fail su tutto il resto." Il ~all finale è la clausola catch-all. ~all = soft-fail (segna come sospetto ma accetta), -all = hard-fail (rifiuta), ?all = neutral (nessun parere). Usa ~all finché DMARC non è in salute, poi stringi a -all.

Con più sender (es. Google Workspace per la posta outbound + SES per il marketing + Mailgun per le transazionali) si concatenano più meccanismi include::

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

Il limite di 10 lookup DNS. RFC 7208 §4.6.4 limita la risoluzione SPF a un totale di 10 lookup DNS. Ogni include: ne conta uno. Un errore comune: concatenare 5+ vendor e sfondare il limite, dopo di che SPF risolve in permerror e viene trattato come fail. Verifica con dig TXT yourcompany.com + uno SPF flattener se sei vicino al limite.

SPF in AcelleMail

Il modello SendingDomain di AcelleMail espone getSpf() in app/Model/SendingDomain.php:154, che legge il setting globale spf_record e renderizza il valore del record TXT. Il metodo verifySpf(string $ipOrHostname) alla riga 363 incapsula la libreria Mika56\SPFCheck — interroga il DNS live a runtime e verifica RESULT_PASS. La superficie di verifica nell'UI admin mostra verde quando il record è presente e autorizza l'IP di invio, rosso altrimenti.

Suggerimento pratico: SPF autentica solo l'envelope sender (il MAIL FROM a livello SMTP), non l'header From visibile. È proprio questa distinzione che il DMARC alignment risolve — vedi §4.

§3 · DKIM

DKIM — DomainKeys Identified Mail.

DKIM (RFC 6376) applica una firma crittografica a ogni messaggio in uscita. Il server destinatario recupera la tua chiave pubblica da un record TXT in DNS, verifica la firma su header e body specifici, e accetta il messaggio come autentico se il calcolo torna. SPF dice "questo IP è autorizzato a inviare per noi"; DKIM dice "questo esatto body e header From non sono stati manomessi dopo che li abbiamo firmati".

Il meccanismo

1. Generi una coppia di chiavi RSA (minimo 1024-bit, 2048-bit raccomandato per nuovi setup).
2. La chiave pubblica va in DNS come record TXT su {selector}._domainkey.{yourdomain}. Il selector è una stringa arbitraria (es. k1, mail, 20251208) che scegli per poter ruotare le chiavi senza spezzare i messaggi in volo.
3. La chiave privata resta sul tuo server di invio. L'MTA (o il relay di invio) firma ogni messaggio in uscita con essa, aggiungendo un header DKIM-Signature.
4. Il mail server destinatario legge i valori d= (dominio) e s= (selector) dall'header di firma, fa il lookup di {s}._domainkey.{d}, recupera la chiave pubblica e verifica.

DKIM in AcelleMail

SendingDomain::generateDkimKeys() in app/Model/SendingDomain.php:221 genera una coppia di chiavi RSA 1024-bit tramite i binding OpenSSL di PHP, salva la parte privata in dkim_private e la parte pubblica in dkim_public. Il selector viene letto da dkim_selector sul modello, con fallback al setting globale dkim_selector. Il valore del record DNS viene renderizzato da $this->getDomain()->getDkimDnsRecord() (riga 270) e mostrato all'operatore con un pulsante di copia accanto a "il valore da pubblicare".

Il pattern di generazione delle chiavi (da generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Verifica: $this->getDomain()->verifyDkim() interroga il DNS su {selector}._domainkey.{domain} e confronta la chiave pubblica pubblicata con il valore memorizzato localmente. Il metodo completo verify() sul modello orchestra in un'unica chiamata i controlli di identità + DKIM + SPF + DMARC (riga 300).

DKIM gestito dal vendor

Se invii tramite Amazon SES, SendGrid, Mailgun o un altro vendor che firma lato suo, pubblichi il selector + chiave pubblica del vendor invece di generare le tue. La capability driver-level SignsDkimOnServer di AcelleMail (vedi app/SendingServers/Capabilities/SignsDkimOnServer.php) segnala i driver che gestiscono DKIM in remoto; l'UI mostra quindi i record CNAME del vendor da pubblicare invece di generare una coppia di chiavi locale. SES usa tre CNAME che delegano _domainkey a amazonses.com — li imposti una volta e SES ruota la chiave sottostante al posto tuo.

§4 · DMARC

DMARC — alignment, policy e reporting.

DMARC (RFC 7489) si appoggia sopra a SPF e DKIM. Fa tre cose che SPF e DKIM, presi singolarmente, non fanno:

1. Alignment. Richiede che il dominio envelope validato da SPF oppure il dominio che firma DKIM corrispondano al dominio dell'header From visibile. Senza alignment, SPF e DKIM possono passare per un dominio diverso da quello che vede il destinatario — la falla che il phishing sfrutta.
2. Policy. Dice ai server riceventi cosa fare quando l'alignment fallisce: none (non fare nulla, solo report), quarantine (consegna in spam), reject (rifiuta il messaggio in SMTP).
3. Reporting. Aggregate report (RUA — report XML giornalieri di tutti gli invii dal tuo dominio) e forensic report (RUF — report individuali per ogni failure) inviati agli indirizzi che specifichi. I report ti danno visibilità su chi sta inviando posta dichiarandosi te.

La sintassi

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Si legge: "DMARC versione 1, metti in quarantena i messaggi che falliscono l'alignment, invia gli aggregate report a dmarc@yourcompany.com, applica la policy al 100% dei messaggi falliti, richiedi strict alignment sia per SPF sia per DKIM."

Il rollout standard

1. Giorno 0: pubblica p=none con rua= che punta a una mailbox monitorata. Raccogli report per 7–14 giorni. È solo osservazione — nessun messaggio viene rifiutato.
2. Giorno 14: esamina i report. Identifica i sender legittimi (il tuo SES, gli IP di invio del tuo CRM, i provider transazionali) e portali tutti in alignment SPF + DKIM.
3. Giorno 30: stringi a p=quarantine; pct=10. La posta non allineata finisce in spam per il 10% dei destinatari. Tieni d'occhio i report per due settimane.
4. Giorno 45: sali a pct=50, poi a pct=100 nell'arco di 2–4 settimane.
5. Giorno 60–90: stringi a p=reject. Ora la posta non allineata fa bounce in SMTP — i phisher che usano il tuo dominio vedono hard reject.

Non saltare il rollout. Passare diretto da nessun DMARC a p=reject è la causa più comune di disastri di deliverability autoinflitti: un sender transazionale dimenticato (il tuo CRM, il tool di supporto, il sistema di fatturazione) inizia a fare hard bounce nel momento in cui p=reject si propaga.

Mandati dei mailbox provider

Da febbraio 2024, Gmail e Yahoo richiedono DMARC per ogni sender che invia > 5.000 messaggi al giorno verso i loro domini, più SPF o DKIM allineato, più List-Unsubscribe one-click (RFC 8058). Microsoft 365 si è allineato allo stesso standard al momento della stesura. L'asticella del "sending commerciale" si è alzata in modo permanente — DMARC non è più opzionale per nessuna lista sopra i ~1.000 contatti. Configuralo presto, anche se la tua lista è ancora piccola.

§5 · BIMI

BIMI — il bonus del logo brand.

BIMI (Brand Indicators for Message Identification) mostra il logo del tuo brand accanto ai tuoi messaggi nell'inbox del destinatario. Gmail, Yahoo, Apple Mail e Fastmail lo supportano dal 2025. È una funzionalità adiacente alla deliverability — non è autenticazione di per sé — ma richiede DMARC a p=quarantine o p=reject come prerequisito, motivo per cui vive in questa guida.

Step di setup (dopo che DMARC è almeno a quarantine o più stringente):

1. Crea una versione SVG del tuo logo seguendo la specifica BIMI SVG Tiny PS — quadrato, niente testo fuori dal mark, path semplici.
2. Ospita l'SVG su un URL HTTPS pubblicamente accessibile.
3. Opzionalmente ottieni un Verified Mark Certificate (VMC) da una CA — richiesto da Gmail per mostrare il badge con il check blu, ~1.500 $/anno. I Common Mark Certificates (CMC) sono un'alternativa più economica per brand non registrati.
4. Pubblica il record BIMI: default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

L'impatto sulla deliverability di BIMI è indiretto ma misurabile: i loghi brand in inbox alzano gli open rate del 5–20% nei case study pubblicati (dati pilota di Yahoo Mail, report BIMI di Mailchimp). È anche una forte leva di forcing — non puoi abilitare BIMI senza prima irrobustire DMARC, quindi i team lo usano come carota per una bonifica dell'autenticazione.

§6 · Reputazione

Reputazione — cosa scorano davvero i mailbox provider.

L'autenticazione è binaria — un record risolve e si allinea, oppure no. La reputazione è continua: un punteggio da 0 a 100 mantenuto da ogni mailbox provider, sul tuo IP di invio e sul tuo dominio From in modo indipendente. I due punteggi si combinano nella decisione di routing (inbox vs Promozioni vs spam vs reject).

I segnali

Dove leggere il tuo punteggio di reputazione

• Google Postmaster Tools (postmaster.google.com) — reputazione di IP e dominio dal punto di vista di Gmail, più compliance di autenticazione, encryption rate, spam rate. Gratuito.
• Microsoft SNDS (postmaster.live.com/snds/) — dati IP-level di Outlook.com, classificazioni di sender reputation. Gratuito, richiede registrazione.
• Yahoo Sender Hub — più recente, iscrizioni dalla pagina Yahoo Postmaster. Statistiche aggregate per dominio.
• Dashboard del provider — la Amazon SES Reputation Dashboard espone bounce + complaint rate con soglie. SparkPost, Mailgun, SendGrid hanno tutti qualcosa di simile.

Controllane almeno una a settimana. Gli indicatori anticipatori (trend del spam rate, calo della IP reputation) appaiono giorni prima degli effetti downstream (calo dell'open rate) — quando ti accorgi che una campagna performa male, il problema di reputazione è già vecchio di due settimane.

§7 · IP warmup

IP warmup — la pianificazione su 6 settimane.

Un IP di invio fresco parte da reputazione zero. I mailbox provider, per design, fanno throttling sui volumi alti da IP nuovi — è la difesa principale contro gli snowshoe spammer che spinnano istanze cloud e fanno blast. Il warmup è la pratica di aumentare gradualmente il volume di invio nell'arco di 4–6 settimane restando dentro i limiti di throttle per ora e per giorno, costruendo reputazione in modo organico.

Lo fai una sola volta per IP. La maggior parte dei team non lo fa mai perché gli IP condivisi di Amazon SES, SendGrid e Mailgun arrivano già pre-warmed. I casi in cui il warmup conta: IP dedicato su SES (di solito > 1M di invii/mese ne giustifica uno), Postal MTA self-hosted su un'istanza cloud fresca, migrazione da un ESP all'altro con cambio di dominio.

La pianificazione

Pianificazione basata sulle raccomandazioni di warmup pubblicate da SparkPost / Postmark / SES, consolidate in un'unica tabella settimana per settimana. Procedi più lentamente se vedi il complaint rate in trend al rialzo; accelera solo se hai conferma di reputation verde dal provider a ogni step.

Tracking del warmup in AcelleMail

Il modello SendingServer di AcelleMail ha lo stato del warmup come first-class. warmup_enabled, warmup_strategy_id e warmup_started_at stanno nella tabella sending_servers; isWarmupEnabled() in app/Model/SendingServer.php:333 fa da gate alle decisioni in fase di invio. La tabella complementare SendingServerWarmupLog registra ogni invio durante la finestra di warmup con data, status e un payload meta serializzato — vedi app/Model/SendingServerWarmupLog.php.

Il pattern: assegna una WarmupStrategy (una riga che definisce la curva di volume per giorno) a un sending server, imposta warmup_enabled = true, warmup_started_at = now(). SendingServerWarmupUsage nella pipeline di invio traccia il conteggio odierno e rifiuta di dispatchare oltre il tetto giornaliero della strategia. Quando il tetto del giorno N della strategia supera il tuo volume giornaliero pieno, il server "si diploma" e la modalità warmup si auto-disabilita.

Le classi DynamicRateTracker e InMemoryRateTracker (app/Library/) gestiscono il rate limiting per minuto / per ora a livello SMTP — anche fuori dal warmup, AcelleMail rispetta i rate cap pubblicati dal relay in modo che un picco di coda non faccia scattare il throttling lato provider.

§8 · Bounce + complaint

Bounce, complaint e il feedback loop.

Hard bounce vs soft bounce

Un hard bounce è un fallimento permanente — tipicamente un codice SMTP 5xx: l'indirizzo non esiste, il dominio non risolve, la mailbox del destinatario è disabilitata in modo permanente. Il modello BounceLog di AcelleMail definisce le costanti HARD e SOFT in app/Model/BounceLog.php:33; un hard bounce sopprime immediatamente l'indirizzo. Un soft bounce è transitorio — codice 4xx: mailbox piena, server temporaneamente non disponibile, messaggio troppo grande. I soft bounce vengono ritentati con uno schema di backoff; gli indirizzi che fanno soft bounce ripetutamente attraverso più invii vengono alla fine retrocessi a hard.

La mappa di classificazione per le notifiche di bounce di AWS SES (la fonte citata dalla documentazione di AcelleMail in BounceLog.php:32): i tipi di bounce includono Permanent (hard) con sotto-tipi General / NoEmail / Suppressed / OnAccountSuppressionList; Transient (soft) con sotto-tipi General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected; più Undetermined (trattato come soft, ritenta).

Complaint

Una complaint è un destinatario che preme "segnala come spam" nel suo client email. Le complaint arrivano via Feedback Loop (FBL) — un canale di notifica per-provider dove gli ISP ti inoltrano i messaggi segnalati come abuse. Il FeedbackLoopHandler di AcelleMail in app/Model/FeedbackLoopHandler.php processa i messaggi FBL in ingresso via IMAP/POP e fa il parsing degli header dell'Abuse Reporting Format (ARF, RFC 5965) per estrarre il message ID originale e il tipo di feedback.

Tipi di feedback ARF che AcelleMail gestisce (da FeedbackLoopHandler::FEEDBACK_TYPES alla riga 35):

• abuse — il destinatario ha marcato esplicitamente come spam. Sopprimi subito.
• fraud — il destinatario ha segnalato come phishing. Sopprimi + log per security review.
• virus — l'antivirus del destinatario ha segnalato un payload. Sopprimi + audit del contenuto.
• other — complaint generica. Sopprimi.
• not-spam — segnalazione esplicita "questo non è spam" (raro). Escluso dalla suppression — vedi EXCLUDED_FEEDBACK_TYPES.

Mailbox provider principali che partecipano ai FBL: AOL, Yahoo, Microsoft (via JMRP), Comcast, BlueTie. Gmail non gestisce un FBL pubblico — consegna il feedback "marked as spam" tramite la dashboard di Postmaster Tools e tramite gli aggregate report DMARC.

Regole di suppression

1. Hard bounce → sopprimi in modo permanente. Non riprovare mai; l'indirizzo è morto.
2. Complaint → sopprimi in modo permanente. Il destinatario ha attivamente chiesto di smettere. Rinviare è illegale in quasi tutte le giurisdizioni e brucia la reputazione.
3. Soft bounce ×3 in 30 giorni → retrocedi a hard, sopprimi. Soft bounce persistenti sono mailbox piene o problemi di connettività persistenti — trattali come morti.
4. Unsubscribe → sopprimi per il marketing, non per il transazionale. Ricevute d'ordine e password reset continuano; le campagne si fermano.
5. Spam-trap hit → escalation a indagine. Estrai l'intera fonte di acquisizione di quel subscriber. La lista è stata probabilmente contaminata con indirizzi comprati o scrapeati.

§9 · List hygiene

List hygiene — la disciplina che tiene alta la reputazione.

L'autenticazione è un setup una tantum. La reputazione è disciplina operativa. Le sette abitudini che spostano l'ago:

1. Double opt-in per tutte le iscrizioni marketing. Un click di conferma prima che l'indirizzo entri nella lista attiva. Elimina refusi, role address (info@, sales@) e indirizzi raccolti. Aggiunge 10–20% di attrito all'iscrizione; sottrae il 50–80% del rischio bounce/complaint.
2. Unsubscribe one-click (RFC 8058). Header List-Unsubscribe che punta a un URL one-click. Richiesto da Gmail e Yahoo per i sender > 5K/giorno verso i loro domini da febbraio 2024. Rendi l'unsub più facile della complaint — i destinatari che premerebbero "spam" premono "unsubscribe" invece.
3. Re-engagement prima della suppression. I subscriber che non aprono da 90 giorni ricevono una campagna "vogliamo restare rilevanti". Apertura → tienili. Nessuna apertura → spostali in una sunset queue. Nessuna apertura dopo 180 giorni → sopprimi.
4. Suppression automatica dei bounce. Processa il webhook di bounce in pochi minuti; rimuovi dalla lista di invio attiva prima della campagna successiva. BounceLog::record() di AcelleMail e gli handler webhook stile vbrandsync lo fanno in automatico.
5. Non importare liste comprate. Mai. Le liste comprate sono seminate di spam trap. Un trap hit e il tuo dominio è su Spamhaus per 30+ giorni. La matematica non torna mai — le liste comprate sono un buco nero permanente per la reputazione.
6. Segmenta per engagement. Invia campagne al 50% engaged due volte più spesso, al 50% freddo la metà delle volte. Alza l'open rate complessivo, abbassa il complaint rate e dà ai mailbox provider un forte segnale "questo sender è rilevante".
7. Limita la cadenza delle automation. Una welcome series + abandoned-cart + post-purchase + compleanno + re-engagement possono produrre 8 messaggi in una sola settimana. Limita il totale dei messaggi automation a uno ogni 48 ore per destinatario, con eccezioni rigide per le transazionali (ricevute, password reset).

§10 · Strumenti AcelleMail

Gli strumenti di deliverability di AcelleMail — cosa porta in dote il sorgente.

Estratti direttamente dal source tree sotto app/Model/ e app/Library/. Ogni voce è un model reale, una capability interface o una classe di libreria — non marketing.

§11 · Troubleshooting

Problemi comuni di deliverability e soluzioni.

§12 · FAQ

FAQ sull'email deliverability.

Capostipite del cluster

Dove andare ora.

Domini autenticati. Bounce tracciati. Reputazione da inbox.

AcelleMail include verifica SPF/DKIM/DMARC, elaborazione ARF dei feedback loop, state machine di IP warmup e rate limiting per server, già nella scatola. Ogni affermazione di questa guida mappa a una classe in app/Model/ o app/Library/ nel source tree di AcelleMail.