Come leggere un “fallimento” di deliverability

Prima di parlare di cause, serve una mappa mentale: un fallimento può avvenire in più punti e non tutti sono uguali. Puoi avere un invio accettato dal tuo sistema ma rifiutato dal server destinatario; oppure un messaggio consegnato tecnicamente, ma nascosto in spam o in una scheda secondaria; oppure ancora un recapito che funziona con un provider e fallisce con un altro. Ogni scenario produce sintomi differenti.

• Hard bounce: rifiuto definitivo (indirizzo inesistente, policy bloccante, dominio non valido).
• Soft bounce: problema temporaneo (mailbox piena, rate limit, server momentaneamente indisponibile).
• Delivered ma non visibile: inbox placement scarso (spam, “Promozioni”, quarantena, filtri interni).
• Consegna intermittente: un giorno va, il giorno dopo no (reputazione, throttling, variazioni contenuto).

Se nei test tratti tutto come “arriva/non arriva”, perdi il segnale più utile. La deliverability si diagnostica con indizi: codici di risposta, header, log dell’MTA/ESP, e coerenza delle autenticazioni.

Pattern 1: SPF passa “a volte” (allineamento e sender sbagliato)

Uno dei pattern più frustranti è l’SPF che sembra corretto, ma fallisce in modo intermittente. In molti casi non è un vero “a volte”: è una differenza tra chi invia davvero e chi dichiari come mittente. Se usi un provider esterno (ESP) o un relay, l’IP che consegna al destinatario potrebbe non essere incluso nel record SPF, oppure il dominio usato nel Return-Path (envelope-from) non coincide con quello che stai verificando.

Sintomi tipici:

• Con Gmail funziona, con Outlook/Hotmail fallisce o finisce in spam.
• I report mostrano “SPF fail” ma l’header From sembra corretto.
• Cambiando ambiente (staging/production) cambia anche l’esito.

Diagnosi rapida: controlla il dominio del Return-Path e verifica l’SPF su quello, non solo sul From. Se stai testando DMARC, ricorda che non basta passare SPF: serve anche l’allineamento con il dominio del From.

Pattern 2: DKIM “pass” ma la reputazione non migliora (selector, dominio e coerenza)

DKIM può risultare “pass” eppure non portare i benefici attesi. Il motivo spesso è la coerenza: se firmi con un dominio diverso da quello percepito dall’utente (From), o cambi selector frequentemente, la fiducia accumulata non si consolida. Inoltre, alcuni test si limitano a “DKIM=pass” senza controllare se il dominio DKIM è allineato a DMARC o se la firma è stabile.

Sintomi tipici:

• DKIM=pass, ma inbox placement resta scarso.
• Il dominio DKIM cambia tra invii apparentemente identici.
• In ambienti multipli, alcuni firmano e altri no (es. worker separati, template engine diverso).

Diagnosi rapida: verifica l’header DKIM-Signature (d=, s=) e assicurati che sia consistente tra campagne e ambienti. Se DMARC è attivo, verifica che l’allineamento (SPF o DKIM) sia soddisfatto dal dominio del From.

Pattern 3: DMARC “quasi ok” ma i provider trattano male (policy, allineamento e forwarding)

DMARC introduce un concetto chiave: non basta autenticare, serve allineare. Molti fallimenti nascono da configurazioni “parziali”: SPF passa ma non è allineato, DKIM passa ma firma un dominio diverso, oppure le email vengono inoltrate (forwarding) e l’SPF si rompe perché l’IP che consegna non è quello autorizzato.

Sintomi tipici:

• Consegna ok a indirizzi diretti, fallimento in caselle con forwarding.
• Report DMARC che mostrano pass SPF o pass DKIM, ma DMARC fail.
• Inasprimento improvviso dopo aver impostato p=quarantine o p=reject.

Diagnosi rapida: controlla DMARC alignment e valuta l’uso di DKIM come ancora principale nelle situazioni di forwarding. Se hai mailing list o inoltri via sistemi intermedi, considera che il contenuto può essere modificato e la firma DKIM può rompersi.

Pattern 4: “Accepted” dal server ma invisibile (spam, quarantena, schede)

Un fallimento non è sempre un rifiuto. A volte la consegna è tecnicamente riuscita, ma l’utente non vede l’email dove se l’aspetta. Questo pattern è comune quando si testano email transazionali e si presume che, essendo “utili”, finiscano sempre in inbox. In realtà, i filtri valutano reputazione, segnali di autenticazione, contenuto, e comportamenti storici.

Sintomi tipici:

• Nessun bounce, ma utenti che dicono “non mi è arrivata”.
• La stessa email arriva in inbox su un provider e in spam su un altro.
• In Gmail finisce in “Promozioni” o in una scheda secondaria.

Diagnosi rapida: chiedi sempre “dove è finita?” e verifica spam/quarantena/filtri. Nei test, usa caselle reali su più provider, non un solo indirizzo. Se puoi, controlla gli header “X-” legati a spam score, e confronta versioni della stessa email con minime variazioni (subject, link tracking, immagini, preheader).

Pattern 5: throttling e rate limit (sembra random, ma è volume-dipendente)

Molti test falliscono quando passano da “pochi invii” a un flusso reale: OTP in orari di punta, newsletter a cluster di utenti, oppure retry aggressivi. Alcuni provider applicano throttling (accettano lentamente) o rate limit (rifiutano temporaneamente) per proteggere le proprie infrastrutture e ridurre spam.

Sintomi tipici:

• Con pochi destinatari va sempre, con molti iniziano soft bounce.
• Picchi di latenza: l’email arriva dopo minuti, non secondi.
• Retry che peggiorano la situazione perché aumentano il traffico verso lo stesso dominio.

Diagnosi rapida: osserva la correlazione con volume e orario. Implementa backoff esponenziale e limiti per dominio destinatario. Se usi un ESP, verifica se ci sono code interne o policy di speed limit per specifici provider.

Pattern 6: contenuto “innocuo” che viene penalizzato (link, immagini, tracking)

Due email con lo stesso scopo possono avere esiti opposti solo per dettagli di contenuto: un dominio di tracking, un URL accorciato, un’immagine troppo “pesante”, un template con poco testo e molte call-to-action, oppure un oggetto che somiglia a pattern abusati. Nei test, spesso si prova con un template minimale e poi in produzione si aggiunge tracking, footer, pixel e link dinamici: e improvvisamente la deliverability cambia.

Sintomi tipici:

• Template di test ok, template reale finisce in spam.
• Le email con un certo tipo di link hanno performance peggiori.
• Problemi solo su alcune lingue o varianti (subject e copy cambiano i segnali).

Diagnosi rapida: isola le variabili. Esegui A/B controllati: stesso From e stessa infrastruttura, cambiando solo una cosa per volta (tracking, numero link, immagini, testo). Se possibile, usa domini di link coerenti con il tuo dominio principale e riduci gli “strati” tra utente e destinazione.

Pattern 7: problemi DNS “banali” ma devastanti (TTL, record multipli, propagation)

DNS è spesso il colpevole silenzioso: record duplicati, errori di sintassi, TXT troppo lunghi e spezzati male, TTL incoerente, o propagation non completata. Nei test, questo appare come “ieri funzionava, oggi no” oppure “funziona da me, non da un collega”. Non è magia: sono risoluzioni DNS diverse in base al resolver e al tempo.

Sintomi tipici:

• Autenticazioni che cambiano esito in base alla rete o al provider.
• Record SPF con più versioni o includi in conflitto.
• DKIM che fallisce perché il selector punta a un record non pubblicato correttamente.

Diagnosi rapida: verifica TXT/SRV/CNAME con più resolver e controlla duplicati. Mantieni i record puliti e documentati. Se fai cambi, attendi la propagazione reale e ripeti i test in momenti diversi.

Pattern 8: mismatch tra ambienti (staging vs produzione)

Un classico: i test passano in staging, ma in produzione arrivano spam o bounce. Oppure viceversa. Le differenze non sono solo “contenuto”: cambiano IP, domini, subdomini, certificati, routing, provider, e persino header. Se la tua pipeline invia da più componenti (API, worker, cron), è facile che una parte firmi DKIM e un’altra no, o che una usi un Return-Path diverso.

Sintomi tipici:

• Solo alcune tipologie di email falliscono (password reset ok, welcome no).
• Solo alcune istanze/regioni falliscono.
• Header diversi tra invii che sembrano uguali.

Diagnosi rapida: confronta gli header completi tra staging e produzione. Verifica con precisione: From, Return-Path, Message-ID, DKIM domain/selector, e IP di invio. Spesso la risposta è in una singola riga.

Pattern 9: reputazione dominio/IP e “cold start”

Anche con DNS perfetto, un dominio o IP nuovi partono senza reputazione. Alcuni provider trattano i nuovi mittenti con cautela, soprattutto se il volume sale rapidamente. Nei test piccoli sembra tutto ok; al primo invio serio emergono soft bounce, inbox placement mediocre o limiti più severi.

Sintomi tipici:

• Nei primi giorni ok, poi peggiora al crescere del volume.
• Problemi concentrati su provider specifici con policy più rigide.
• Fluttuazioni: oggi inbox, domani spam, senza cambiare nulla.

Diagnosi rapida: approccio graduale (“warm-up”) e coerenza. Mantieni costante il profilo di invio: stesso dominio, stessa struttura, stessi segnali di autenticazione. Evita picchi improvvisi e assicurati che gli utenti interagiscano in modo positivo (aperture reali, pochi reclami).

Pattern 10: bounce per policy (provider, parole chiave, categorie)

Non tutti i rifiuti sono tecnici. Ci sono rifiuti per policy: contenuti considerati rischiosi, categorie soggette a controlli, o pattern tipici dello spam. A volte basta un dettaglio: un dominio nel body associato a pratiche abusive, un URL accorciato, o un template che assomiglia a phishing. Nei test “interni” magari passa, ma su provider pubblici scatta il blocco.

Sintomi tipici:

• Hard bounce con motivazioni legate a policy o sicurezza.
• Blocchi solo su alcuni provider, con messaggi di rifiuto simili.
• Problemi che si manifestano dopo aver cambiato link o CTA.

Diagnosi rapida: esamina i log di rifiuto e identifica l’elemento scatenante. Riduci gli URL, evita redirect eccessivi, rendi i link trasparenti e coerenti con il dominio del mittente. Se l’email è transazionale, mantienila sobria e orientata all’azione essenziale.

Come impostare test affidabili (per non ingannarti da solo)

Un test di deliverability utile non è un singolo invio, ma una piccola batteria di prove. Ecco un’impostazione pragmatica:

• Più provider: almeno Gmail, Outlook/Hotmail, Yahoo/altro. Le differenze emergono subito.
• Header completi: conserva l’email originale e confronta header tra invii.
• Stesse condizioni: evita di cambiare contenuto e infrastruttura insieme.
• Volumi realistici: simula picchi e retry, non solo invii sporadici.
• Tempi e latenza: misura quanto impiega ad arrivare, non solo se arriva.
• Tracciamento controllato: attivalo gradualmente e verifica l’impatto.

L’idea è trasformare “non arriva” in un responso: “rifiuto per policy”, “soft bounce per rate limit”, “deliver ma in spam”, “DMARC fail per allineamento”, e così via. Quando dai un nome al fallimento, la soluzione non è più un tiro a caso.

Checklist finale: diagnosi in pochi minuti

1. Hai un bounce? Se sì, è hard o soft? Cosa dice la risposta?
2. Se non c’è bounce, controlla spam/quarantena/schede e filtri lato utente.
3. Verifica SPF sul dominio del Return-Path, non solo sul From.
4. Verifica DKIM: dominio (d=) e selector (s=) sono coerenti e presenti nel DNS?
5. Verifica DMARC: almeno SPF o DKIM passano con allineamento rispetto al From?
6. Contenuto: link, tracking, immagini, subject. Cosa è cambiato rispetto ai test “puliti”?
7. Volume: il problema appare con picchi? Hai throttling o retry aggressivi?
8. Ambienti: staging e produzione inviano identico per header e routing?

Se segui questa scaletta, nella maggior parte dei casi arrivi alla causa reale rapidamente, senza inseguire fantasmi. La deliverability è una disciplina di dettagli, ma non è una lotteria: i fallimenti si ripetono perché le regole dei provider sono pensate per riconoscere schemi. Il tuo vantaggio è imparare a leggerli.