L'uso esteso di web font nelle pagine web è oramai assodato: dopo i primi timidi approcci della fine degli anni '90 (una volta tanto il primo a supportare la direttiva @font-face è stato il vituperato Internet Explorer), dal 2008, e soprattutto con l'avvento della libreria gratuita di Google Font nel 2010, il web ha cambiato faccia, lasciando campo libero alla web-typography, come vero fondamento del web-design.

Chiaramente il passaggio dal web all'email non è stato automatico, e non è ancora lontano dal potersi considerare completato. Vediamo quali sono le opportunità che un email designer ha a disposizione quando si tratta di scegliere font per titoli e testi di una missiva.

Uso di caratteri web safe

I caratteri web-safe sono una serie di font presenti in tutti i computer e quindi visualizzati sicuramente con effetto simile, se non identico.

I font sono: Arial, Comic Sans, Courier New, Georgia, Impact, Palatino, Tahoma, Times New Roman, Trebuchet MS, Verdana.

Nel 2012 Microsoft ha abbandonato i brand Hotmail e Live, lanciando la nuova piattaforma email Outlook.com.

Questa riunificazione, che ha portato il brand delle email desktop Microsoft su web, era mirata a intaccare il crescente predominio di Gmail nel settore delle webmail.
Per riuscirci Microsoft ha rivisto nel profondo l'interfaccia delle vecchie webmail, rinnovandola e adeguandola al nuovo stile Metro di Windows 8, che proprio in quegli anni stava lanciando.

Nel farlo ha però calcato la mano in maniera significativa: il preprocessing css era piuttosto "violento", fino a rendere il rendering delle email html impreciso e in larga parte imprevedibile.

I professionisti dell'email design si sono da subito scervellati per trovare trucchi adatti a compensare questo tipo di limitazioni: di base infatti Outlook.com settava un line-height maggiorato a tutte le email, nel tentativo di uniformare lo stile del contenuto dell'email a quello dell'interfaccia, oppure imponeva di base una colorazione ai vari H1, H2 etc, o ancora non accettava margin (a meno che non li si indicasse con la M maiuscola), oltre a imporre un doctype che in determinate condizioni introduceva spaziature non volute sotto le immagini.

La disponibilità di device in grado di filmare qualsiasi momento della nostra vita - e del nostro business - e la contemporanea disponibilità (ok, più o meno) di banda hanno decretato negli ultimi anni il successo dei video come forma di comunicazione online.

Youtube ha tracciato la strada, ma presto Facebook, Instagram e anche Twitter si sono adeguati: ormai non esiste sito o webmedia che non offra tonnellate di video. Gli esperti insistono sul valore di questo tipo di comunicazione, in termini di engagement, empatia, branding, è dunque ovvio che anche nell'ambito email marketing si valuti la possibilità di invio newsletter che includano video.

Sappiamo però che, per quel che riguarda le innovazioni tecnologiche, l'email è molto tradizionalista; ancora oggi è decisamente difficile far convivere email e css, o addirittura email e tableless design e la stessa cosa non può non valere per le inclusioni video.

Per la sua app Mobile, sia IOS che Android, Libero ha fatto una scelta piuttosto furba: di fatto l'applicazione in questione non è nient'altro che una ribrandizzazione della nota app multiprovider myMail.

L'applicazione in questione è sicuramente una delle alternative più utilizzate, ha una interfaccia comoda e moderna e consente di configurare più caselle di posta, anche di provider diversi. La ribrandizzazione fatta da Libero ha mantenuto questa caratteristica (proponendo chiaramente Libero come prima scelta), oltre alle altre che hanno reso questa applicazione così famosa.

Dai dati in nostro possesso, le aperture provenienti dall'applicazione Mobile di Libero corrispondono all'incirca al 3% del totale delle aperture di newsletter in Italia, per cui un numero sicuramente ragguardevole. Quasi un terzo delle aperture fatte da utenti di @libero.it (e domini correlati come @iol.it, @virgilio.it, @inwind.it) oggigiorno avviene proprio tramite questa applicazione piuttosto che con la classica "webmail". Alcuni utenti, chiaramente, utilizzano entrambe le piattaforme in vari momenti della giornata.

Dal 12 dicembre 2014 i server mail degli indirizzi email forniti da Apple (@icloud.com, @mac.com, @me.com) hanno cominciato a rifiutare svariate email.

Dopo qualche test ho verificato che l'errore era il seguente:

550 5.7.1 Success delivery receipts not accepted: emailaddress@domain

Fatte un po' di ricerche su Google non ho trovato informazioni e quindi mi sono messo a fare prove per scoprire che i mail server di Apple forniscono quell'errore in risposta al comando RCPT TO nel caso venga passato l'attributo NOTIFY con un valore che contenga il valore SUCCESS.

Ottima notizia per chi invia newsletter a Gmail, un po' meno per chi utilizza sistemi di tracciamento per individuare la geolocalizzazione dell'apertura, tipo di dispositivo utilizzato e tipo di programma di posta in uso.

Già con il passaggio ad https (connessione protetta alla webmail) per la sua webmail Gmail aveva reso più complicato riuscire a distinguere le aperture avenute sulla webmail ma con quest'ultima modifica di fatto Google fa un passo avanti nella difesa della privacy dei suoi lettori.

La stranezza è che con il nuovo sistema rende più semplice il tracciamento dell'apertura che ora non ha più bisogno che l'utente scelga di visualizzare le immagini, quindi in questo senso potrebbe essere visto come un passo indietro nella difesa della privacy.

Da pochi giorni (lunedì scorso per la precisione) Gmail ha modificato il DOCTYPE utilizzato per mostrare le email ai propri utenti, passando da "nessun doctype" al doctype di HTML5.

Il risultato più evidente di questo cambiamento è che potrebbero comparire strane linee bianche inaspettate nelle vostre newsletter. In realtà se le vostre email sono testate bene questa cosa non accadrà poichè il problema che vedrete da ora in poi su Gmail c'è da sempre nel caso di visualizzazione di Hotmail usando Firefox. Gmail, usando il doctype di HTML5, rende la cosa più evidente poichè tutti i browser di ultima generazione si comporterano in questo modo (e non solo Firefox come nel caso di Hotmail).

Ecco quindi come importanti newsletter, come quella di iTunes non si veda più bene su Gmail:

Scrivevo ieri di come l'adozione di DKIM sia molto meno diffusa rispetto al "cugino" SPF, complice, probabilmente, il maggiore impatto tecnico che ha la sua implementazione da parte dei mittenti.

Oltre a questo vorrei aggiungere alcune anomalie nelle quali mi sono imbattuto:

DKIM, acronimo di DomainKeys Identified Mail, identifica un meccanismo di autenticazione della posta. Al contrario di SPF (Sender Policy Framework), che si preoccupa di "certificare" se il postino (mail server mittente) di una determinata email è autorizzato a consegnare quella determinata email, DKIM si concentra sulla "certificazione" del contenuto. DKIM permette infatti di stabilire che i gestori di un determinato dominio "firmatario" (parametro d= nell'header DKIM) hanno applicato una firma certificando il contenuto e le intestazioni del messaggio. Se la firma risulta valida si può quindi stabilire che la mail ricevuta sia "certificata" dal dominio che ha messo la firma.

Da notare che, al contrario di quello che alcuni pensano, la specifica DKIM non impone alcuna relazione tra il dominio del firmatario e il dominio mittente e che il fatto che una mail sia firmata non significa che non sia spam.

Innanzitutto, ecco un esempio della lista messaggi di posta in arrivo di Gmail:

Oltre alla classica coppia mittente e subject mostrata da tutti i client di posta Gmail visualizza, a seguito del subject, un testo chiamato "Snippet". Lo "Snippet" contiene le prime parole del contenuto del messaggio e fornisce all'utente qualche indicazione in più per aiutarlo a decidere se aprire o meno il messaggio.