Compatibilità con i Client di Email: Cosa Funziona Dove

Per la maggior parte dei team la scelta più sicura è MJML: scrivi componenti semantici e il framework compila tabelle annidate e stili inline pensati per i client di posta. Nei dati prezzi verificati MJML compare come modello self-hosted senza un piano a canone, quindi il costo reale è quello del server su cui fai la compilazione e del servizio di invio che usi dopo.

Il resto di questa guida spiega perché un messaggio che sembra perfetto nel browser si rompe in Outlook desktop, quali proprietà CSS sono davvero affidabili, come scegliere tra builder visuali e framework da sviluppatori e quanto costano gli strumenti per cui abbiamo dati di prezzo verificati.

Perché i client di posta si comportano in modo diverso

Un browser web segue da anni gli stessi standard di rendering. I client di posta no. Ognuno usa un motore diverso, con regole proprie su quali selettori accettare, quali tag rimuovere e quali proprietà ignorare. Questo significa che non esiste un unico "HTML email": esiste un sottoinsieme di HTML e CSS che sopravvive quasi ovunque, e il lavoro consiste nel restare dentro quel sottoinsieme.

Ci sono tre fattori da tenere a mente prima di toccare il codice:

• Il motore di rendering: Outlook desktop usa il motore di Microsoft Word per la composizione, mentre Apple Mail usa WebKit.
• La pulizia del markup: alcuni client riscrivono o rimuovono i blocchi <style> e gli attributi che non riconoscono.
• Il contesto di caricamento: le immagini possono essere bloccate per impostazione predefinita, e il messaggio deve reggere anche senza di esse.

Una regola pratica: se una proprietà non è supportata, il client la ignora in silenzio. Il messaggio non va in errore, cambia solo l'aspetto. Per questo il controllo va fatto con anteprime reali e non dando per scontato che "dovrebbe funzionare".

I principali client di email e cosa cambia per ciascuno

Outlook desktop (Windows)

È il client più impegnativo. Le versioni desktop più diffuse usano il motore di composizione di Word, che non segue le regole dei browser. In pratica:

• I float CSS non vengono rispettati.
• Le immagini di sfondo sui div non compaiono, mentre funzionano sulle celle di tabella con VML.
• Margin e padding si comportano in modo incoerente, soprattutto sui blocchi.
• Il posizionamento CSS non è affidabile.
• Il layout deve appoggiarsi alle tabelle.

Il nuovo Outlook e la variante web sono in genere più vicini al rendering dei browser, ma non vanno trattati come equivalenti al desktop. Un messaggio che passa nel nuovo Outlook può comunque rompersi nella versione classica.

Gmail (web e app)

Gmail ha un suo modo di trattare il CSS. Può rimuovere alcuni selettori, ignorare blocchi <style> in certi contesti e richiede spesso stili inline per essere sicuro. Le media query funzionano meglio nell'app mobile che nella versione web, dove il supporto è limitato. Le immagini esterne possono essere bloccate finché il destinatario non le autorizza, quindi il messaggio deve avere un senso anche senza di esse.

Apple Mail (macOS e iOS)

È il client con il supporto CSS più ampio. Usa WebKit e accetta media query, immagini di sfondo e molte proprietà moderne. Il rischio con Apple Mail è l'eccesso di fiducia: se il tuo pubblico usa soprattutto questo client, puoi permetterti un design più ricco, ma il messaggio dovrà comunque reggere negli altri client che la tua lista utilizza.

Yahoo Mail

Il supporto CSS è moderato. Alcuni stili vengono rimossi, ma in modo meno aggressivo di Gmail. Le immagini di sfondo funzionano con un fallback di colore pieno.

Outlook.com (Hotmail)

È diverso da Outlook desktop perché usa un renderer basato su browser. Il supporto CSS è migliore, ma restano alcune particolarità che conviene verificare prima dell'invio.

Proprietà CSS: cosa usare, cosa controllare, cosa evitare

Il modo più semplice di ragionare è dividere le proprietà in tre gruppi. La divisione non è una garanzia assoluta, ma serve come base per le decisioni di design.

Sicure in quasi tutti i client

/* Affidabili nei principali client */
color: #333333;
font-family: Arial, sans-serif;
font-size: 16px;
font-weight: bold;
line-height: 1.5;
text-align: center;
text-decoration: none;
background-color: #ffffff;
border: 1px solid #cccccc;
padding: 10px; /* meglio sulle celle di tabella */
width: 100%;
max-width: 600px;

Il colore di sfondo e i bordi semplici sono la scelta più robusta. Preferisci sempre il colore di sfondo pieno come fallback, anche quando usi un'immagine.

Supporto parziale: usare con un fallback

/* Funzionano nella maggior parte dei client, ma non in Outlook desktop */
border-radius: 4px;      /* Outlook desktop lo ignora: il bordo resta squadrato */
background-image: url(...); /* In Outlook serve VML */
box-shadow: ...;         /* Supporto limitato */
margin: 10px;            /* Incoerente in Outlook: preferisci lo spazio nelle celle */

Per queste proprietà la regola è semplice: il messaggio deve restare leggibile e ordinato anche se il client le ignora. Un pulsante con angoli squadrati in Outlook è accettabile. Un pulsante invisibile non lo è.

Da evitare o da usare con molta cautela

/* Causano problemi o non sono supportate */
display: flex;           /* Non affidabile nei client di posta */
display: grid;           /* Non affidabile nei client di posta */
position: absolute;      /* Molto limitato */
float: left;             /* Problemi in Outlook desktop */
transform: ...;          /* Supporto limitato */
animation: ...;          /* Supporto solo in alcuni client */

Flexbox e grid sono le trappole più comuni per chi arriva dallo sviluppo web. Se il tuo layout dipende da queste proprietà, è il segnale per tornare alle tabelle.

Tecniche di layout che reggono nel tempo

Tabelle per la struttura

Le tabelle restano il metodo di layout più affidabile. Ogni sezione del messaggio è una riga, ogni colonna è una cella, e la larghezza del contenitore è fissata con un attributo HTML e non solo con CSS:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center" style="padding: 20px;">
      <table width="600" cellpadding="0" cellspacing="0">
        <tr>
          <td>Contenuto qui</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

L'attributo role="presentation" dice agli screen reader che la tabella serve solo al layout. È una scelta che aiuta l'accessibilità senza costi di compatibilità.

Commenti condizionali per Outlook

Quando un blocco deve comportarsi diversamente solo in Outlook desktop, puoi usare un commento condizionale. Gli altri client lo leggono come commento e lo ignorano:

<!--[if mso]>
  <table width="600"><tr><td>
<![endif]-->

  <div style="max-width: 600px;">
    Contenuto per tutti i client
  </div>

<!--[if mso]>
  </td></tr></table>
<![endif]-->

Usa questi commenti con parsimonia. Ogni blocco condizionale è codice che qualcuno dovrà mantenere, e più ne metti, più il template diventa fragile.

VML per le immagini di sfondo in Outlook

Le immagini di sfondo su una sezione richiedono VML in Outlook desktop. Il codice seguente crea lo sfondo per Outlook e lascia il div con background-image per gli altri client:

<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
<v:fill type="tile" src="background.jpg" color="#ffffff" />
<v:textbox inset="0,0,0,0">
<![endif]-->

<div style="background-image: url(background.jpg); background-color: #ffffff;">
  Contenuto qui
</div>

<!--[if gte mso 9]>
</v:textbox>
</v:rect>
<![endif]-->

Il colore di sfondo nel div è il fallback: se l'immagine non carica, il contenuto resta leggibile.

Immagini: dimensioni, formati e comportamento senza immagini

Il tag immagine di base

<img
  src="https://example.com/image.jpg"
  alt="Descrizione"
  width="600"
  height="300"
  style="display: block; max-width: 100%; height: auto; border: 0;"
>

Gli attributi contano più degli stili:

• width e height: Outlook ha bisogno delle dimensioni esplicite per fare il layout prima del caricamento.
• display: block: elimina lo spazio extra che alcuni client lasciano sotto l'immagine.
• max-width: 100%: permette il ridimensionamento sui telefoni.
• border: 0: evita il bordo che alcuni client aggiungono alle immagini linkate.
• alt: descrive l'immagine. Con le immagini bloccate è spesso l'unico testo che il lettore vede.

Formati immagine

• JPG: fotografie e immagini complesse.
• PNG: trasparenza e grafiche semplici.
• GIF: animazioni, con attenzione al peso del file e al primo fotogramma, che è quello che alcuni client mostrano.
• SVG: supporto limitato. Evitalo nei messaggi.
• WebP: non supportato in Outlook. Se lo usi, fornisci un fallback.

Messaggi senza immagini

Molti destinatari non vedono le immagini finché non le autorizzano. Un messaggio ben costruito deve trasmettere l'informazione principale con testo, colori e pulsanti. Un banner che contiene da solo l'offerta o la data dell'evento è un rischio: se le immagini restano bloccate, il lettore non capisce il messaggio.

Font

Stack web-safe

font-family: Arial, Helvetica, sans-serif;
font-family: Georgia, Times, serif;
font-family: 'Courier New', Courier, monospace;

Lo stack web-safe è la scelta predefinita. Non dipende da file esterni e viene reso in modo prevedibile.

Font personalizzati

I web font funzionano in alcuni client, come Apple Mail e molte app mobili. Vanno sempre con un fallback:

<style>
  @import url('https://fonts.googleapis.com/css2?family=Open+Sans&display=swap');
</style>

<p style="font-family: 'Open Sans', Arial, sans-serif;">
  Testo con font personalizzato
</p>

Outlook e Gmail useranno il fallback, mentre Apple Mail mostrerà il font scelto. Il messaggio deve essere leggibile in entrambi i casi, quindi scegli un fallback con metriche simili.

Media query e responsive

Il supporto alle media query varia molto:

<style>
  @media screen and (max-width: 600px) {
    .mobile-full-width {
      width: 100% !important;
    }
    .mobile-hide {
      display: none !important;
    }
    .mobile-stack {
      display: block !important;
    }
  }
</style>

In pratica:

• Apple Mail e iOS Mail: supporto completo.
• Gmail app (iOS e Android): supporto.
• Gmail web: supporto limitato.
• Outlook desktop: nessun supporto. Il layout deve reggere anche senza le media query, con colonne che restano affiancate o che si adattano per larghezza.

Il responsive più robusto nasce dal fatto che il messaggio è già largo 600 pixel e si restringe con max-width o con colonne che si impilano. Lo smontaggio delle colonne con media query va considerato un miglioramento e non una condizione necessaria.

Strumenti: builder visuali, framework e sender a confronto

La compatibilità dipende dal codice che arriva al client, non dal servizio che lo invia. Un builder può produrre HTML pulito o disordinato, e un sender può consegnare entrambi con la stessa efficacia. Per questo la scelta dello strumento riguarda soprattutto chi scrive il template e come viene mantenuto nel tempo.

La tabella seguente riassume i principali strumenti citati in questa guida. I prezzi sono riportati solo quando nella documentazione verificata compare un valore; negli altri casi il prezzo è indicato come su richiesta e conviene consultare la pagina ufficiale del fornitore.

Due dettagli vanno letti con attenzione. Il piano gratuito di Kit copre fino a 10.000 iscritti, ma le automazioni visuali iniziano dal piano Creator, che è indicato a 33 $ al mese con fatturazione annuale. Il piano Developer di Courier include 10.000 invii al mese, ma gli strumenti per le journey e i broadcast sono descritti nello stesso piano, quindi conviene verificare quali funzioni servono davvero.

Costi per dimensione della lista

Il costo di un sender cambia in modo molto diverso a seconda che il prezzo dipenda dagli iscritti, dagli invii o dai destinatari di un database. La tabella seguente applica i prezzi verificati a tre dimensioni di lista. Dove il fornitore non indica un prezzo per quella dimensione, la cella dice "prezzo su richiesta".

Il calcolo di Courier è teorico: presuppone che ogni contatto riceva un solo invio al mese e che l'intero volume sia tariffato al prezzo a consumo del piano Business. Se il tuo flusso invia più messaggi per contatto, il costo cresce in proporzione. Il calcolo serve a confrontare le scale, non a fissare un preventivo.

Per Stripo, BEE, Unlayer, React Email e Maizzle non è indicato alcun prezzo nei dati verificati. Il costo reale dipende spesso dal tipo di licenza, dal numero di utenti o dall'integrazione, quindi la richiesta va fatta direttamente al fornitore.

Quale scegliere: tabella decisionale

La scelta dipende da chi scrive il template, da dove vive il messaggio e da quanto controllo serve sul markup. La tabella riassume le combinazioni più comuni.

Se stai ancora decidendo, parti dalla domanda più semplice: chi aggiornerà il template tra sei mesi? Se la risposta è uno sviluppatore, un framework come MJML o React Email ti dà controllo e versionamento. Se la risposta è il marketing, un editor visuale riduce gli errori dovuti al markup, ma il codice esportato va comunque controllato.

Setup e migrazione: checklist operativa

Se stai migrando template esistenti o avviando un nuovo flusso, questa checklist evita i problemi più frequenti.

Flusso di lavoro consigliato

Per i team che pubblicano messaggi con regolarità, conviene separare la costruzione del template dalla verifica. Il flusso più semplice è questo:

1. Definisci il template base una volta. Intestazione, corpo, pulsante e footer con il layout a tabelle. Tutti i messaggi partono da lì.
2. Crea le varianti come contenuti, non come nuovi template. Cambiare testo e immagine è sicuro; cambiare la struttura è dove nascono gli errori.
3. Controlla il codice esportato. Con un builder visuale, apri il sorgente e verifica che non compaiano flexbox, grid o proprietà fuori dall'elenco delle sicure.
4. Esegui l'anteprima su più client prima di ogni invio importante. Strumenti come Litmus o le anteprime integrate nel builder mostrano il rendering in client diversi.
5. Invia una prova a un gruppo interno che usa almeno Outlook desktop, Gmail web e un client mobile.

Strategia di test

Il test non va fatto una volta sola. Ogni modifica al template può rompere un dettaglio che prima funzionava, quindi serve un piccolo controllo ripetibile:

1. Inizia da Outlook desktop. Se il layout regge lì, di solito regge anche negli altri client.
2. Controlla Gmail web. È il client dove le regole CSS vengono più spesso riscritte.
3. Verifica il mobile. Controlla che le colonne si impilino correttamente e che i pulsanti restino cliccabili.
4. Disattiva le immagini. Il messaggio deve dire ciò che serve senza di esse.
5. Leggi il messaggio come se fossi il destinatario. Gli errori di copy e di gerarchia non si vedono nei test tecnici.

Il riassunto

La compatibilità con i client di posta non è un problema da risolvere una volta, ma una disciplina: layout a tabelle, stili inline, font web-safe con fallback, immagini con dimensioni esplicite e un messaggio che regge anche senza immagini. Gli strumenti aiutano, ma non sostituiscono il controllo finale.

Se il tuo team scrive template con regolarità, MJML è la scelta più sicura come punto di partenza, perché il markup finale è prevedibile e il costo dipende dal tuo server e non da un canone. Se invece il marketing deve lavorare da solo, uno strumento visuale come Stripo o BEE è più adatto, purché il codice esportato venga controllato. Per le newsletter sotto i 10.000 iscritti il piano Free di Kit copre l'invio, mentre per le email transazionali il piano Developer di Courier include 10.000 invii al mese.

Domande frequenti

Qual è la regola più importante per la compatibilità?

Costruire il layout con tabelle e usare stili inline per gli elementi critici. Tutto il resto, dalle media query ai font personalizzati, è un miglioramento che il messaggio deve poter fare a meno.

Serve davvero usare VML?

Solo se il messaggio usa immagini di sfondo su sezioni o pulsanti che devono apparire in Outlook desktop. Se il design può usare un colore pieno, puoi evitarlo.

Perché il mio messaggio funziona in Apple Mail e non in Outlook?

Apple Mail usa WebKit e accetta molte proprietà moderne. Outlook desktop usa il motore di Word, che ignora float, posizionamento e spesso margin. Il rimedio è costruire il layout con tabelle e non fare affidamento su proprietà che Outlook non applica.

I builder visuali producono HTML compatibile?

Molti sì, ma la qualità varia. Il codice esportato va controllato, soprattutto per flexbox, grid e stili non inline. Un controllo rapido del sorgente prima dell'invio evita la maggior parte dei problemi.

Posso usare un font personalizzato?

Sì, con un fallback web-safe. Apple Mail e molte app mobili mostrano il font scelto, mentre Outlook e Gmail useranno il fallback. Il messaggio deve restare leggibile in entrambi i casi.

Quanto costa un framework come MJML?

Nei dati prezzi verificati MJML compare come modello self-hosted senza un piano a canone. Il costo reale è quello dell'infrastruttura su cui compili il template e del servizio di invio che usi. Consulta la pagina ufficiale dei prezzi per eventuali aggiornamenti.

Il sender influisce sulla compatibilità?

No. La compatibilità dipende dall'HTML che arriva al client. Il sender incide su consegna, costi e gestione degli iscritti, quindi va scelto con criteri diversi dal template.

Quante prove servono prima di un invio importante?

Almeno un invio a un gruppo interno che usa Outlook desktop, Gmail web e un client mobile. Per campagne con molte immagini o layout complessi, aggiungi un'anteprima multi-client prima dell'invio.