Progettazione Email Responsive: Guida Tecnica con Strumenti e Costi

Per la maggior parte dei team tecnici che devono produrre email responsive senza scrivere ogni media query a mano, la scelta più sensata è MJML. Il sorgente usa tag leggibili come mj-section e mj-column, e il compilatore produce HTML in cui le colonne si impilano su schermi stretti. La pagina prezzi di MJML descrive un modello self-hosted e non elenca piani a canone, quindi il costo reale è quello dell’infrastruttura di build e del tempo di sviluppo.

Questa guida è rivolta a chi deve scegliere uno strumento per costruire template responsive: sviluppatori che lavorano con codice, marketer che usano editor visivi e responsabili che devono capire quanto costa passare da un test a una produzione stabile. Spiega le tecniche che reggono tra i client, mostra dove ciascun builder è più adatto e raccoglie i prezzi che risultano dalle pagine ufficiali dei fornitori.

Perché l’email responsive è diversa dal web

Un browser web applica le media query in modo uniforme. Un client email no. Ogni programma interpreta l’HTML e il CSS con regole proprie, e il risultato cambia a seconda che il messaggio sia aperto in un’app mobile, in un webmail o in un client desktop. Per questo il lavoro responsive nell’email consiste soprattutto nel capire dove le regole si rompono.

• Apple Mail su iOS: applica le media query e si comporta in modo vicino a un browser moderno, quindi è il client più prevedibile.
• Gmail: supporta le media query nell’app e nel web, ma alcuni selettori e alcune proprietà vengono ignorati o riscritti. Conviene testare ogni regola nuova.
• Outlook per desktop: usa il motore di rendering di Word. Ignora gran parte di flexbox e grid, quindi il layout deve reggersi su tabelle e su commenti condizionali.
• Client Android e webmail minori: comportamento variabile. Il controllo migliore è un test reale, non la documentazione.

La regola pratica è costruire un layout che funzioni senza media query e poi aggiungere le media query come miglioramento. Se il messaggio su Outlook resta leggibile in una colonna, il resto è una questione di rifinitura.

Confronto rapido tra gli strumenti

La tabella riassume come si posizionano gli strumenti più citati per la progettazione responsive. Per i builder senza prezzo pubblico il campo è indicato come prezzo su richiesta; per gli strumenti senza piani a canone il campo spiega il modello di costo.

Ogni strumento nel dettaglio

MJML

MJML è un linguaggio di markup che si compila in HTML per email. Per un team tecnico è il punto di partenza più solido, perché le colonne, i margini e il comportamento su mobile sono gestiti dal compilatore e non dal singolo sviluppatore. Il sorgente resta leggibile anche per chi arriva dopo.

Dove eccelle: template che devono restare coerenti nel tempo, componenti riutilizzabili, output prevedibile su più client. Dove manca: un marketer senza competenze di sviluppo non lo usa in autonomia, e la personalizzazione di casi particolari richiede di leggere l’HTML generato. Prezzo: la pagina prezzi di MJML descrive un modello self-hosted e non elenca piani a canone. Il costo si riduce quindi all’infrastruttura di build e al lavoro del team. Fonte: pagina prezzi di MJML.

React Email

React Email permette di costruire email come componenti React. È adatto ai team che già usano React per il prodotto e vogliono riutilizzare componenti, props e test. Il vantaggio è la coerenza con il resto del codice; lo svantaggio è che la responsabilità del risultato resta allo sviluppatore, che deve controllare l’output sui client di destinazione. Prezzo: su richiesta.

Maizzle

Maizzle è un framework basato su Node che usa utility CSS, in stile Tailwind, per costruire template HTML. Chi conosce già le utility CSS trova il flusso familiare, e la build produce HTML pronto per l’invio, con inlining dei stili. Limite: non è pensato per chi non scrive codice, e richiede una pipeline di build da mantenere. Prezzo: su richiesta.

Stripo

Stripo è un editor visivo pensato per i team marketing che devono produrre molte email senza passare dallo sviluppo. È il più vicino all’esperienza di un builder tradizionale. Dove eccelle: autonomia del marketing, riuso di blocchi e rapidità di produzione. Dove manca: l’HTML esportato va sempre controllato su Outlook e su client con dark mode, perché un editor visivo tende a generare markup più pesante di un template scritto a mano. Prezzo: su richiesta.

BEE

BEE lavora per blocchi trascinabili. È adatto a creatori di contenuti che devono cambiare struttura e immagini senza toccare il codice. Limite: il risultato dipende da come il sender che userai interpreta l’HTML esportato, quindi il test di invio reale è obbligatorio prima di adottarlo. Prezzo: su richiesta.

Unlayer

Unlayer è un editor di email che può essere incorporato in un’applicazione. Ha senso quando il builder fa parte del prodotto che gestisci, per esempio quando i tuoi utenti devono creare le proprie email dentro il tuo software. Limite: se il tuo bisogno è solo produrre newsletter internamente, un editor autonomo è più semplice da adottare. Prezzo: su richiesta.

Email on Acid

Email on Acid non costruisce template: serve a verificarli. Il piano Basic costa 99 US$ al mese e include 1.000 anteprime, più di 100 client e dispositivi e accesso API. Il piano Premium costa 199 US$ al mese, con 2.000 anteprime, test di accessibilità e analisi dell’HTML. Non risulta un piano gratuito nella pagina prezzi. Fonte: pagina prezzi di Email on Acid.

Quando conviene: quando il template è stabile e vuoi controllare le regressioni prima di ogni campagna importante. Quando non serve: per una newsletter semplice con poche varianti, un test manuale su qualche client è sufficiente.

Vero

Vero è una piattaforma per email di lifecycle che invia messaggi a partire da profili, eventi e segmenti. Non è un builder, ma molti team la usano come sender e quindi devono sapere come si comporta il codice che produce. Il piano Starter costa 54 US$ al mese e include 5.000 profili, 10.000 email al mese, 20.000 messaggi push e 160.000 eventi tracciati. Il piano Professional è su preventivo, perché il prezzo dipende dai volumi di profili, email, push, eventi e SMS. Fonte: pagina prezzi di Vero.

Limite: il modello a consumo fa crescere il costo in fretta quando la base di profili aumenta, quindi conviene stimare i profili attivi prima di scegliere.

Tecniche che funzionano tra i client

Layout fluido come base

Parti da un contenitore a larghezza piena con un massimo di 600 pixel. In questo modo il messaggio occupa tutto lo spazio disponibile su mobile e non si rompe su desktop:

<table role="presentation" width="100%" style="max-width: 600px;">
  <tr>
    <td style="padding: 20px;">
      Il contenuto occupa lo spazio disponibile
    </td>
  </tr>
</table>

Questo schema funziona nei client più diffusi senza bisogno di media query. È la base su cui costruire tutto il resto.

Media query come miglioramento

Le media query servono a rifinire l’esperienza mobile nei client che le supportano. Non devono essere l’unico modo in cui il layout si adatta, perché Outlook per desktop le ignora:

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

Quattro interventi coprono la maggior parte dei casi:

• Impilare le colonne: trasforma le colonne affiancate in blocchi uno sotto l’altro.
• Ridurre il padding: lascia più spazio al contenuto sugli schermi piccoli.
• Nascondere elementi secondari: rimuovi solo ciò che può mancare senza perdere il senso del messaggio.
• Rendere le immagini a larghezza piena: evita che una colonna stretta costringa l’utente a scorrere lateralmente.

Il ricorso a !important serve perché molti stili vengono applicati inline, che hanno una specificità alta. Usalo solo nelle regole della media query, non nel resto del foglio di stile.

Il metodo ibrido per Outlook

Per le colonne affiancate in Outlook si usano commenti condizionali che Outlook legge e gli altri client ignorano. Le colonne vengono realizzate con tabelle in Outlook e con elementi div con display: inline-block negli altri client:

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

<div style="display: inline-block; width: 100%; max-width: 300px;">
  Contenuto della colonna 1
</div>

<!--[if mso]>
</td>
<td width="300">
<![endif]-->

<div style="display: inline-block; width: 100%; max-width: 300px;">
  Contenuto della colonna 2
</div>

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

Il risultato è un layout a due colonne in Outlook e due blocchi impilati negli altri client che non applicano il display. Non servono media query per la struttura di base.

Immagini che scalano con il contenitore

Un’immagine dovrebbe avere un attributo width che indica la dimensione prevista e uno stile che la riduce quando il contenitore è più stretto:

<img src="immagine.jpg"
     width="600"
     style="display: block; max-width: 100%; height: auto;"
     alt="Descrizione dell’immagine">

L’attributo width dà la dimensione intesa, max-width: 100% evita l’overflow e height: auto mantiene il rapporto d’aspetto. Il testo alternativo va scritto come descrizione del contenuto, non come elenco di parole chiave.

Pulsanti pensati per il tocco

Su mobile l’utente tocca. Un pulsante troppo piccolo o con poco spazio intorno è il primo punto debole di molte campagne. Le linee guida di interfaccia di Apple indicano un’area di tocco di circa 44 punti per lato, quindi conviene costruire il pulsante con padding generoso e con l’intera cella cliccabile:

<table role="presentation">
  <tr>
    <td style="background-color: #007bff; border-radius: 4px; padding: 12px 24px;">
      <a href="https://example.com"
         style="color: #ffffff; text-decoration: none; font-weight: bold; display: block;">
        Scopri di più
      </a>
    </td>
  </tr>
</table>

Il link è un blocco, quindi tutta la superficie della cella è toccabile. Il colore di sfondo sta sulla cella e non sul link, così il pulsante resta visibile anche quando il client blocca i link stilizzati.

Costi per volume: quanto pagherai davvero

Il prezzo cambia molto a seconda di cosa misuri. Alcuni strumenti addebitano per anteprima, altri per profili e volume di email, altri ancora non pubblicano un prezzo. La tabella mette a confronto solo i prezzi indicati nelle pagine ufficiali. Per gli strumenti senza prezzo pubblico il campo indica prezzo su richiesta.

Il confronto per anteprima è utile se devi scegliere tra i due piani di Email on Acid. Il piano Basic costa 99 ÷ 1.000 = 0,099 US$ per anteprima. Il piano Premium costa 199 ÷ 2.000 = 0,0995 US$ per anteprima. Il costo per anteprima è quasi identico, quindi il piano giusto dipende dal numero di test che fai davvero, non dal prezzo unitario.

Per Vero il punto critico è il numero di profili. Lo Starter copre 5.000 profili e 10.000 email al mese. Se la base cresce oltre questa soglia, il costo passa al piano su preventivo, e conviene chiederlo prima di costruire il flusso, non dopo.

Come scegliere

La scelta dipende da chi costruisce il template e da cosa deve dimostrare. Le regole sotto valgono per la maggior parte dei casi, ma non sostituiscono un test sul tuo pubblico.

Se il team è misto, con sviluppatori e marketer, la combinazione più frequente è un builder visivo per le campagne ricorrenti e un flusso in codice per i template strutturali. Evita di tenere due sistemi per lo stesso tipo di email: il costo di manutenzione cresce più in fretta del costo di licenza.

Checklist di setup e migrazione

Se stai spostando template esistenti verso un nuovo strumento, procedi per fasi. Ogni fase ha un controllo chiaro, così non passi alla successiva con un difetto ancora aperto.

Flusso di lavoro consigliato

Il responsive non si chiude alla consegna del template. Un flusso ordinato separa la costruzione, la verifica e l’invio, così ogni modifica passa dagli stessi controlli.

• Costruisci per primo il layout a colonna singola. È la versione che regge meglio tutti i client, e le colonne affiancate sono un miglioramento.
• Usa account di prova reali su Apple Mail, Gmail e Outlook. Un’anteprima non riproduce tutto il comportamento dell’app.
• Controlla con le immagini disattivate. Il messaggio deve restare comprensibile solo con testo, pulsanti e testo alternativo.
• Controlla la modalità scura. Colori di testo e sfondi possono cambiare, e un logo con sfondo trasparente può sparire.
• Verifica l’orientamento. Il messaggio va provato sia in verticale sia in orizzontale su telefono.

Pattern responsive comuni

Colonna singola come punto di partenza

Un layout a colonna singola funziona ovunque e richiede pochissimi interventi responsive. È il formato più sicuro per le newsletter di testo e per i messaggi transazionali, dove la leggibilità conta più della composizione.

Due colonne che si impilano

Due colonne affiancate su desktop e impilate su mobile sono il pattern più diffuso. Richiedono il metodo ibrido per Outlook oppure la media query per impilare le colonne. Se usi un builder, verifica che l’HTML esportato contenga entrambe le soluzioni.

Immagine hero con invito all’azione

Un’immagine a larghezza piena seguita da un testo centrato e da un pulsante è semplice e regge bene a ogni dimensione. L’immagine scala con il contenitore e il testo resta leggibile perché ha un margine laterale che si riduce su mobile.

Errori frequenti

• Progettare su desktop e poi adattare. Il risultato su mobile è quasi sempre una correzione forzata. Parti dalla colonna stretta.
• Affidarsi a flexbox o grid. Outlook per desktop non li applica, quindi il layout si rompe proprio nel client più usato in ambito aziendale.
• Usare immagini di testo. Se l’immagine non carica, il messaggio perde il contenuto principale. Mantieni il testo come testo.
• Pulsanti piccoli. Un’area di tocco ridotta costringe l’utente a cercare il link. Aumenta il padding prima di ridurre il testo.
• Dipendere solo dall’anteprima. Le anteprime sono un controllo utile, ma non sostituiscono l’invio di prova su account reali.

In conclusione

Un’email responsive si costruisce partendo da un layout che funziona senza media query, poi si migliora con le media query dove sono supportate e con il metodo ibrido in Outlook. Gli strumenti aiutano a ridurre il lavoro manuale, ma non cancellano la necessità di test reali.

Per un team di sviluppo, MJML resta la scelta più sensata quando serve HTML responsive prodotto in modo prevedibile. Per un team marketing, un editor visivo come Stripo o BEE accelera la produzione, a patto di controllare l’output. Per la verifica, Email on Acid è utile quando il template è stabile. Per l’invio legato a profili ed eventi, Vero ha un piano iniziale a prezzo fisso, ma il costo cresce con la base di contatti.

Domande frequenti

Qual è il modo più semplice per ottenere un’email responsive?

Scegli un builder che generi HTML con colonne che si impilano da solo, come MJML, oppure un editor visivo che esporti tabelle compatibili con Outlook. In entrambi i casi, invia sempre una prova su Apple Mail, Gmail e Outlook prima dell’invio reale.

Le media query funzionano in Outlook?

In Outlook per desktop le media query non sono applicate in modo affidabile. Per questo il layout deve reggersi da solo su tabelle e commenti condizionali, e le media query servono solo come miglioramento per i client mobile.

Serve davvero il metodo ibrido se uso un builder?

Dipende dal builder. Alcuni generano già il markup per Outlook, altri no. Esporta l’HTML e controlla la presenza dei commenti condizionali. Se mancano, il layout a due colonne rischia di impilarsi anche in Outlook.

Quanto costa Email on Acid per un team piccolo?

Il piano Basic costa 99 US$ al mese con 1.000 anteprime, mentre il piano Premium costa 199 US$ al mese con 2.000 anteprime. Non risulta un piano gratuito nella pagina prezzi. Se fai poche campagne, valuta se un invio di prova su account reali basta.

MJML ha un costo?

La pagina prezzi di MJML descrive un modello self-hosted e non elenca piani a canone. Il costo reale è quindi quello dell’infrastruttura su cui gira la build e del tempo del team per mantenerla.

Posso usare Vero per le email di lifecycle e un builder per il design?

Sì. Vero gestisce invii, profili ed eventi, mentre il design può arrivare da un builder che esporta HTML. Verifica che il codice esportato venga inviato senza modifiche e che i blocchi dinamici funzionino con i dati del tuo profilo.

Come capisco se il mio template è pronto per l’invio?

Il template è pronto quando colonne, pulsanti e immagini reggono nei client principali, con le immagini disattivate e in modalità scura, e quando l’invio pilota non segnala errori di rendering. Se uno di questi controlli fallisce, correggi prima di inviare al pubblico completo.