Quando si fa clic su un pulsante per inviare un’e-mail, il client di posta elettronica si connette al server di posta. I server sono computer che gestiscono servizi specifici. Un server di posta elettronica è pensato per gestire le e-mail. 

Allo stesso tempo, possiamo suddividere i server di posta elettronica in due categorie: in uscita e in entrata. Oggi stiamo parlando di un concetto relativo a un server di posta in uscita, noto come server SMTP.

Che cos’ è un server SMTP? 

Un server SMTP è un computer o un’app responsabile dell’invio di e-mail. Funziona secondo il Simple Mail Transfer Protocol (SMTP). Un server SMTP riceve e-mail dal client di posta elettronica. Quindi li passa a un altro server di posta elettronica SMTP e li inoltra al server di posta in arrivo.

Come funziona un server SMTP? 

Dai un’occhiata ai passaggi di base del percorso di invio delle e-mail e al ruolo svolto dal server SMTP.

• Un mail user agent (MUA), che può essere il tuo client di posta elettronica o un’app, si connette al server SMTP del tuo dominio (ad esempio, live.mailtrap.io) per avviare la connessione SMTP. Questo è chiamato handshake SMTP. La connessione viene effettuata tramite una porta SMTP, che normalmente è 25. Tuttavia, altre porte, come 465, 587, 2525 potrebbero anche essere utilizzate in casi diversi. Puoi saperne di più su di loro nel nostro post sul blog sulle porte SMTP. Una volta connesso, inizia la sessione SMTP.
• Il client invia gli indirizzi e-mail del mittente e del destinatario, nonché il corpo e gli allegati dell’e-mail, al server. 
• Il server SMTP, o più precisamente l’ agente di trasferimento della posta (MTA), controlla se il nome di dominio del destinatario e del mittente è lo stesso. Se lo è, l’e-mail va direttamente al server POP3 o IMAP del destinatario. Se i domini sono diversi, il server SMTP deve comunicare con il DNS (Domain Name Server).
• Il DNS fornisce l’indirizzo IP del destinatario. 
• Il server SMTP del mittente si connette al server SMTP del destinatario e inoltra l’e-mail. Se il server del destinatario non è disponibile (inattivo o occupato), l’e-mail verrà inserita in una coda SMTP. Questo è un buffer in cui le e-mail vengono archiviate prima di raggiungere l’endpoint. Per ulteriori informazioni su questo, leggi il nostro post sul blog sull’ accodamento delle e-mail. In alternativa, l’e-mail può essere inviata a un server di backup.
• Il server SMTP del destinatario verifica l’e-mail in arrivo. Se il dominio e il nome utente sono stati riconosciuti, il server inoltra l’e-mail ai server di ricezione, server POP3 o IMAP.

Il server SMTP è sicuro? 

Sorprendentemente, il server SMTP non è intrinsecamente sicuro. Non ha alcun meccanismo di crittografia o di sicurezza incorporato. Ciò lo rende vulnerabile a spoofing, spamming o perdita di dati. Per evitare tutti questi sfortunati eventi, i provider di posta elettronica hanno aggiunto livelli di sicurezza all’infrastruttura. 

Il primo meccanismo che hanno incorporato è stato il Secure Sockets Layer (SSL), ma aveva notevoli difetti di sicurezza. Di conseguenza, Internet Engineering Task Force (IETF) ha deprecato la sua versione finale, SSL 3.0 nel 2015 applicando RFC 7568.

4 anni dopo la creazione di SSL, un altro standard di sicurezza, Transport Security Layer (TLS) è stato introdotto al pubblico. Inizialmente, non era nemmeno perfetto, ma è stato migliorato nel corso degli anni. A partire dal 2022, la versione TLS 1.3 è considerata il protocollo più sicuro per la crittografia delle e-mail.Tutto ciò è fantastico, ma a che punto della connessione SMTP entra in gioco TLS? Per impostazione predefinita, la maggior parte dei client di posta elettronica avvia una connessione TLS durante l’handshake. Lo fanno utilizzando il comando SMTP STARTTLS, che avvia il passaggio a una connessione crittografata. Per saperne di più, dai un’occhiata al nostro post sul blog sulla sicurezza SMTP.

Cos’ è l’autenticazione SMTP? 

L’autenticazione SMTP o SMTP AUTH è il meccanismo utilizzato per proteggere il server di posta elettronica in uscita. È il servizio fornito dall’Extended Simple Mail Transfer Protocol (ESMTP) che aggiunge nuove funzionalità al protocollo SMTP, inclusa l’autenticazione. 

SMTP AUTH ‘‘richiede che il mittente sia autorizzato a utilizzare il server per inviare e-mail. Rende più difficile impersonare utenti reali, proteggendoli da spoofer e spammer. SMTP AUTH sfrutta il meccanismo SASL per l’autenticazione, che specifica il livello di sicurezza e i metodi di login. Meccanismi come PLAIN, LOGIN e CRAM-MD5 sono comunemente usati in questo processo. Per approfondire l’autenticazione SMTP, consulta la nostra guida dedicata.

Dovresti usare server SMTP locale o basato su cloud? 

Il tuo proprio server SMTP 

Impostare il proprio server SMTP potrebbe essere un’opzione se si desidera inviare e-mail di massa. Non impone alcun limite al numero di e-mail inviate all’ora/giorno e garantisce il controllo di tutta la posta in uscita. 

Tuttavia, questo comporta uno svantaggio in quanto la frequenza di rimbalzo può aumentare del 20-30%, che è una considerazione importante per la deliverability delle campagne di marketing transazionale o di posta elettronica. Se vuoi conoscere tutti i dettagli della configurazione del tuo server SMTP, leggi questo post sul blog.

API di invio e-mail di terze parti 

Nella nostra guida sui migliori server SMTP gratuiti, abbiamo introdotto un elenco di API e-mail di terze parti basate su cloud che la maggior parte delle startup e dei progetti opta per. Si tratta di servizi di inoltro SMTP che includono Gmail, Amazon SES, Elastic Email, Mailtrap e altri. 

Il vantaggio principale dell’utilizzo di provider di servizi SMTP al posto dell’SMTP locale è che non è necessario creare e mantenere l’intera infrastruttura di posta elettronica da soli. Ciò significa che risparmi le tue risorse. 

Tuttavia, è importante scegliere un provider di posta elettronica affidabile come Mailtrap Email Sending. Si tratta di una soluzione end-to-end in grado di consegnare in modo sicuro i messaggi di posta elettronica alle caselle di posta dei destinatari.

Include un gran numero di utili funzioni, come analitiche attuabili, SDK per una serie di linguaggi di programmazione, consegna puntuale delle e-mail, configurazione fluida e sicura e altro ancora. Le analisi citate possono essere utilizzate per monitorare e controllare la deliverability di tutte le vostre e-mail in uscita.

L’aspetto più importante è che Mailtrap Email Sending semplifica enormemente l’utilizzo del servizio SMTP o dell’API di posta elettronica. Una volta verificato il vostro dominio con i protocolli di autenticazione SPF, DKIM e DMARC, vedrete immediatamente le credenziali SMTP e API per l’invio transazionale e massivo di e-mail.

Il server SMTP di Mailtrap Email Sending sfrutta i meccanismi di autenticazione PLAIN e LOGIN e richiede la crittografia STARTTLS.

Ora che sai cos’ è un server SMTP e come funziona, approfondiamo e rispondiamo alle altre domande che potresti avere.

Server di SMTP relay o API HTTP: qual è il migliore e quando? 

Un agente utente di posta (il client) invia e-mail al server tramite SMTP. È un protocollo indipendente dalla piattaforma ampiamente utilizzato per l’invio di e-mail. Allo stesso tempo, puoi inviare e-mail dalla tua app utilizzando un protocollo specifico per il web: HTTP. In questo caso, non ci sono client-server o server-server avanti e indietro. La tua app invia richieste HTTP a un servizio di terze parti che esegue l’invio di e-mail. Questo modo di recapito della posta è noto come API HTTP o API Web.

Non possiamo affermare che le API Web superino il servizio dei server di  SMTP relay. Ogni opzione ha i suoi pro e contro.

Scegliere un server SMTP se:

• preferisci la semplicità per le attività di base 
• hai bisogno di integrabilità con il tuo sistema CRM o client di posta
• stai cercando una soluzione affidabile e sostenibile

Seleziona API Web se:

• ti occupi di email di massa
• hai bisogno di maggiori funzionalità
• non ti dispiace armeggiare con il codice

Per ulteriori informazioni sulle differenze tra server di SMTP relay e API HTTP, leggi il nostro post sul blog.

Che cos’ è un indirizzo di server SMTP? 

Un server SMTP ha un indirizzo web per comunicare con altri server e client su Internet. Di solito, é smtp. o mail. più il nome di dominio. Alcuni esempi?

Se hai configurato il tuo server SMTP, puoi utilizzare il suo indirizzo IP, ad esempio 192.0.2.0, invece dell’indirizzo web. 

Gli utenti dei servizi di posta elettronica condivisi possono trovare informazioni sul nome e sull’indirizzo del server SMTP cercando i record MX del dominio.

Un server SMTP e un SMTP relay sono la stessa cosa? 

SMTP relay è il processo di trasferimento di e-mail tra server SMTP (o MTA, se si vuole). Un relay si verifica se il mittente e il destinatario provengono da domini diversi. In pratica, tuttavia, il termine SMTP relay si riferisce spesso ai server SMTP che consentono la trasmissione. I provider di posta elettronica come Mailtrap Email Sending offrono tali server di inoltro per l’invio di posta elettronica di massa e transazionale. In questo contesto, possiamo dire che un server SMTP e un relay SMTP sono la stessa cosa.

Che cosa è un falso server SMTP? 

• Un vero server SMTP accetta le e-mail dal client e le invia al server di posta in arrivo. 
• Un server SMTP falso accetta e-mail dal client ed emula l’invio senza consegna effettiva. 

Perché dovrei averne uno falso? – Per testare l’invio di e-mail, ovviamente!

Ad un certo punto del tuo progetto, dovrai inviare un paio di e-mail di prova dalla tua app o dal tuo sito web. Puoi farlo utilizzando un vero server SMTP. In questo caso, dovresti armeggiare con account di posta elettronica fittizi, ovvero creare centinaia di indirizzi e-mail che scompariranno in poche ore. 

Se siamo completamente onesti, le e-mail fittizie non sono la migliore soluzione per i test. Richiedono troppe risorse, hanno capacità di test di progettazione limitate e contengono il rischio di spamming di utenti reali. È qui che entra in gioco un falso server SMTP!

Oltre all’invio di e-mail, la piattaforma Mailtrap Email Delivery comprende Email Testing, una soluzione di test basata su cloud che cattura il traffico SMTP in uscita.

Con Mailtrap Email Testing, le e-mail di prova inviate dalla tua app verranno intrappolate utilizzando un server SMTP falso e inserite in una casella di posta virtuale. Puoi essere sicuro che nessuna delle email arriverà ai tuoi utenti. A differenza delle e-mail fittizie, la Email Testing consente l’automazione QA ed elimina la maggior parte del lavoro manuale. 

Inoltre, è possibile visualizzare l’anteprima delle e-mail, verificare la presenza di spam e del dominio/IP del mittente nella blacklist, ispezionare l’HTML/CSS e molto altro ancora.

Potresti anche considerare di configurare un server SMTP falso locale come MailHog o MailCatcher o persino un’app desktop, ad esempio FakeSMTP o DevNull SMTP. Abbiamo descritto i motivi per scegliere tra opzioni SMTP false cloud o locali nel post del blog dedicato.

Qual è la differenza tra un server SMTP e un server IMAP/POP3? 

SMTP è un protocollo di invio di e-mail, mentre IMAP4 e POP3 sono protocolli per la ricezione di e-mail. Pertanto, un server di posta in arrivo può utilizzare uno di questi protocolli per la consegna di posta elettronica. Ecco come funzionano:

La differenza principale tra questi protocolli è che i server IMAP memorizzano sempre le copie delle e-mail, mentre i server POP3 le eliminano una volta recuperate. Per ulteriori informazioni sulle differenze tra server in entrata e in uscita, consulta il nostro post sul blog IMAP vs POP3 vs SMTP.

In che modo un MTA differisce da un server SMTP? 

È pratica comune utilizzare il termine “mail transfer agent ” invece di “SMTP server”. Ma queste nozioni non sono diverse? Un MTA è un software installato sul server SMTP. Generalmente, un MTA riceve e-mail da un MUA e le inoltra a:

• un mail delivery agent (MDA), se il mittente e il destinatario hanno lo stesso dominio, o
• un altro MTA (server SMTP) 

In alcuni casi, ci potrebbe essere anche un mail submission agent (MSA) tra il MUA e MTA. Tuttavia, molti MTA svolgono la funzione MSA, ecco perché la menzione degli agenti di invio della posta viene spesso omessa. Gli MTA più utilizzati sono Postfix, Sendmail ed Exim.

Quindi, se chiami il server SMTP un MTA o anche un MSA, questo non sarà un errore. La differenza sta nella nomenclatura che si usa.

Elenco di controllo per la risoluzione dei problemi del server SMTP 

Diciamo che hai controllato l’invio di posta elettronica della tua app e va bene. Speriamo che la Mailtrap Email Delivery Platform ti abbia aiutato in questo :). Ma quando hai iniziato a utilizzare un vero server SMTP per l’invio di e-mail, non sono state consegnate. La seguente lista di controllo ti aiuterà a rilevare ciò che potrebbe essere sbagliato:

• controlla la connessione Internet
• controlla la configurazione del server SMTP (nome server, porta, nome utente, password)
• prova diverse porte SMTP

verifica la connessione al server SMTP. Per questo, è possibile utilizzare un servizio online come MXToolbox o eseguire una sessione telnet manuale. Leggi il nostro post sul blog su come testare il server SMTP per imparare come farlo. Potrebbe anche essere necessario conoscere i comandi SMTP e i codici di risposta per la risoluzione dei problemi.

In conclusione

Questo è tutto ciò che volevamo trattare in questa guida sui server SMTP. Abbiamo coperto tutte le domande più frequenti, incluso cos’ è un server SMTP, come funziona, come si confronta con altri server SMTP e come risolvere gli errori. Abbiamo anche discusso su SMTP relay di terze parti e server SMTP falsi per il test. 

Per sfruttare i falsi server SMTP e quindi inviare e-mail tramite un SMTP basato su cloud, si consiglia di utilizzare la piattaforma di consegna e-mail Mailtrap. È una soluzione unica per tutte le tue esigenze SMTP. 

Per uno sguardo approfondito sui diversi aspetti del server SMTP, dai un’occhiata ai post del blog che abbiamo consigliato sopra. Se ci sono altri argomenti che vorresti che trattassimo, faccelo sapere su Twitter.

Cosa sono i record MX?

I record di Mail Exchange sono parte integrante del Domain Name System (DNS) e svolgono un ruolo fondamentale nell’instradamento dei messaggi di posta elettronica. Situati nei file di zona DNS, che sono semplici file di testo che raggruppano tutti i record di un particolare dominio, i record MX forniscono ai client di posta elettronica informazioni sul dominio sotto il quale è possibile accedere a un server di posta. Utilizzando il Simple Mail Transfer Protocol (SMTP), sono responsabili dell’indirizzamento delle e-mail al server di posta corretto.

All’interno di un dominio sono solitamente presenti più server, tra cui web, File Transfer Protocol (FTP) e uno o più server di posta, ciascuno accessibile tramite diversi sottodomini gestiti da record DNS. Essendo un tipo di record DNS, un record MX consente ai clienti di richiedere il nome del sottodominio associato al server di posta, che gestisce l’invio e la ricezione delle e-mail. È qui che i pannelli di controllo, come cPanel, si rivelano utili, fornendo agli utenti un’interfaccia per gestire questi record DNS.

Perché sono necessari i record MX?

I record MX svolgono un ruolo fondamentale nel garantire il recapito regolare delle e-mail, fornendo un meccanismo affidabile ed efficiente per l’instradamento dei messaggi. Anche i provider di posta elettronica svolgono un ruolo cruciale nella consegna efficiente delle e-mail, ma con i record MX correttamente configurati è possibile indirizzare le e-mail al server di posta del provider corretto.

I record MX forniscono una soluzione di instradamento delle e-mail più avanzata rispetto al sistema di base basato sul file HOSTS.TXT, consentendo la distribuzione del carico su più server di posta. Questo approccio migliora l’efficienza distribuendo uniformemente il carico e offrendo opzioni alternative ove necessario.

Come funzionano i record MX del DNS?

Per capire come funzionano i record MX, è essenziale conoscere il ruolo dei Message Transfer Agent (MTA) e dei server DNS nel processo di consegna delle e-mail. Gli MTA interrogano i record MX quando un utente invia una e-mail, mentre i server DNS memorizzano e forniscono i record MX necessari per l’instradamento dei messaggi e-mail.

Quando viene inviato un messaggio di posta elettronica, l’MTA del mittente avvia una query DNS per identificare i server di posta del destinatario, cercando i record MX appropriati. Questa interrogazione è diretta al server DNS del destinatario, che risponde con i record MX necessari, compresi i valori di priorità. L’MTA del mittente stabilisce una connessione SMTP con i server di posta del destinatario, iniziando da quello con la priorità più alta e scendendo nell’elenco delle priorità, se necessario, finché l’e-mail non viene consegnata con successo.

Ecco un esempio di configurazione di un record MX:

In questa tabella che rappresenta i record MX per “dummyserver.com”, vediamo due record con valori di priorità e host di posta diversi. I numeri di “priorità” in questi record MX indicano la preferenza, con valori più bassi che sono preferiti.

Il server proverà prima “mailhost1.dummyserver.com” grazie al suo valore di priorità più basso, pari a 10, prima di passare a “mailhost2.dummyserver.com” con un valore di priorità pari a 20 in caso di mancato invio di un messaggio.

Inoltre, il simbolo “@” sotto la colonna “Tipo di record” indica che il record MX è associato al dominio principale (dummyserver.com).

Infine, il valore TTL (Time To Live) di 45000 secondi specifica la durata della cache del record MX da parte dei resolver DNS prima che venga effettuata una nuova richiesta di aggiornamento delle informazioni al server DNS autoritario. Ciò contribuisce a ridurre il carico dell’infrastruttura DNS e a migliorare le prestazioni.

Esempi di record DNS MX

Per comprendere meglio i record MX, esaminiamo altri esempi di come appaiono nei file di zona DNS e i vari parametri e valori che possono essere impostati.

Esempio 1:

Supponiamo di avere un record A per un dominio, mailtrap.io, con le seguenti informazioni:

Domain: mailtrap.io
Mail exchanger: mail.mailtrap.io
Priority: 10

Il server di posta di questo dominio si chiama ora mail.mailtrap.io. Possiamo usare queste informazioni per creare un record MX:

Domain: mailtrap.io
Mail exchanger: mail.mailtrap.io
Priority: 10

Con questa configurazione, tutte le e-mail inviate a recipient@mailtrap.io saranno dirette al server di posta mail.mailtrap.io con l’indirizzo IP 11.22.00.333.

Esempio 2:

In questo esempio, abbiamo un server SMTP primario (mail1.mailtrap.io) e un server SMTP di backup (mail2.mailtrap.io) per il dominio mailtrap.io:

MX record: mailtrap.io IN MX 5 mail1.mailtrap.io
A record: mail1.mailtrap.io.com IN A 192.166.12.14

MX record: mailtrap.io IN MX 10 mail2.mailtrap.io
A record: mail2.mailtrap.io IN A 192.166.12.15

I messaggi indirizzati a recipient@mailtrap.io vengono instradati prima a mail1.mailtrap.io a causa di un valore di preferenza inferiore (5). Se mail1.mailtrap.io non è disponibile, la posta viene indirizzata a mail2.mailtrap.io.

Esempio 3:

In questo scenario, abbiamo due server di posta con valori di preferenza uguali per il dominio mailtrap.io, che consentono il bilanciamento del carico:

MX record: mailtrap.io IN MX 5 mail1.mailtrap.io
A record: mail1.mailtrap.io IN A 192.167.10.15

MX record: mailtrap.io IN MX 5 mail2.mailtrap.io
A record: mail2.mailtrap.io IN A 192.167.10.16

Con valori di preferenza uguali (entrambi 5), il DNS seleziona casualmente un server per bilanciare il carico della posta in arrivo.

Vale la pena notare che oltre ai record A, negli esempi precedenti, esistono altri tipi di record DNS chiamati record AAAA. I record AAAA sono utilizzati per mappare un nome di dominio a un indirizzo IPv6, mentre i record A sono utilizzati per mappare un nome di dominio a un indirizzo IPv4. Poiché l’IPv6 sta gradualmente sostituendo l’IPv4 come protocollo primario, diventa sempre più importante configurare correttamente i record AAAA.

In sintesi, configurando i valori dei record MX nei file di zona DNS, come il dominio, lo scambiatore di posta, i valori di priorità e l’MX di backup, è possibile configurare più server di posta elettronica, creare server SMTP di backup e bilanciare il carico tra di essi per garantire una consegna efficiente e affidabile delle e-mail. Con i record MX e DNS correttamente configurati, il traffico e-mail in arrivo può essere distribuito in modo efficiente tra più server, garantendo un’esperienza e-mail senza interruzioni per tutte le parti coinvolte.

Come controllare il record MX?

Alcuni dei metodi più comuni per controllare i record MX del vostro dominio sono gli strumenti online. Alcuni di questi sono MXToolbox.com o G Suite Toolbox di Google, che consentono di consultare altri tipi di record DNS (TXT, PTR, TLSA, CNAME, ecc.).

Questi strumenti consentono di inserire il nome di dominio e di eseguire una ricerca MX per visualizzare gli attuali record MX associati al dominio. Esaminando i risultati, è possibile verificare che i server di posta siano configurati e prioritari in modo corretto per garantire la consegna delle e-mail.

  Tenete presente che questi strumenti si basano sull’uso di server di nomi autorevoli per eseguire ricerche DNS e recuperare le informazioni sui record MX. Supponiamo che il vostro dominio utilizzi server dei nomi personalizzati o privati. In questo caso, potrebbe essere necessario fornire informazioni aggiuntive o configurare le impostazioni DNS per consentire a questi strumenti di accedere alle informazioni dei record MX.

Controllare regolarmente i record MX del proprio dominio e risolvere i potenziali problemi che influiscono sulla consegna delle e-mail aiuta a mantenere un sistema di posta elettronica efficiente e affidabile per il proprio dominio. Alcuni problemi comuni includono:

• Record MX mancanti: Se il vostro dominio non ha alcun record MX, la consegna delle e-mail sarà probabilmente interrotta, poiché gli MTA dei mittenti dovranno sapere dove indirizzare i messaggi.
• Informazioni errate sul server di posta: Se i record MX puntano al server di posta sbagliato, la consegna delle e-mail può fallire o essere ritardata.
• Valori di priorità errati: Se i vostri record MX hanno valori di priorità contrastanti o confusi, la consegna delle e-mail potrebbe essere meno efficiente o meno affidabile a causa di messaggi errati o di un bilanciamento del carico inefficace.

Conclusione

In sintesi, i record MX del DNS sono essenziali per garantire un instradamento e una consegna delle e-mail fluidi ed efficienti. Configurando accuratamente i record MX, è possibile ottimizzare le prestazioni del server e-mail, creare backup e distribuire il traffico e-mail in entrata. Controllare e aggiornare regolarmente i record MX del proprio dominio non solo aiuta a mantenere un sistema di posta elettronica affidabile, ma contribuisce anche a migliorare l’esperienza di comunicazione complessiva.

Speriamo che questo articolo vi sia stato utile Se volete saperne di più sui record DNS e sul ruolo che svolgono nella deliverability delle e-mail, date un’occhiata a:

• How to Set Up DMARC Records | Mailtrap Blog 
• DKIM Signature: Why You Need It and How to Set Up | Mailtrap Blog 
• What is SPF and How to Setup SPF Record | Mailtrap Blog 
• BIMI Records: Yes, You Should Set This One Too | Mailtrap Blog 
• Verify Email Address Without Sending an Email | Mailtrap Blog

Che cos’è il DKIM?

DomainKeys Identified Mail (DKIM) è una firma digitale aggiunta a ogni e-mail inviata da un determinato indirizzo e-mail. Non è la tipica firma che ci si aspetta di vedere in calce a un’e-mail aziendale. In effetti, normalmente non si vede nemmeno il DKIM. Si tratta di un insieme apparentemente casuale di caratteri nascosti nel codice sorgente di un’e-mail, un luogo in cui le persone non guardano di solito, ma i server che accettano le e-mail in arrivo sicuramente sì.

Dopo tutto, DKIM è uno standard di settore per l’autenticazione delle e-mail. Naturalmente, l’aggiunta di una firma DKIM non garantisce la consegna, ma aumenta significativamente le probabilità di un esito positivo.

Perché usare il DKIM?

Immaginate il seguente scenario. State inviando un rapido messaggio di follow-up a un potenziale investitore dopo un incontro: “Yvonne, fammi sapere se vuoi procedere con quello che abbiamo discusso prima“. Passa un po’ di tempo e non avete mai ricevuto una risposta da Yvonne, ma la incontrate durante un’altra riunione e le accennate con discrezione a quell’e-mail. Perplessa, Yvonne dice: “Mark, non ti ho più sentito“.

Ci sono molte ragioni potenziali per una scarsa deliverability, ma, come si è scoperto, Mark ha dimenticato di impostare l’autenticazione DKIM per il suo account di posta elettronica. Di conseguenza, il server di Yvonne non era sicuro che fosse davvero Mark a inviarle l’e-mail e ha scartato il messaggio.

Lo scopo principale del DKIM è quello di prevenire lo spoofing. Lo spoofing delle e-mail consiste nel modificare il contenuto del messaggio originale e inviarlo da un mittente alternativo che sembra una fonte affidabile. Questo tipo di attacco informatico è ampiamente utilizzato per le frodi, ad esempio l’invio di messaggi di richiesta di pagamento da un indirizzo e-mail simile al vostro (mark@whatevercompany.io vs. mark@whatever-company.io).

Che aspetto ha un’intestazione DKIM?

Ecco un esempio di record di posta identificata DomainKeys:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=newyork;
     c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

DKIM è composto da diversi elementi, descritti con vari tag e valori corrispondenti a ciascuno. Analizziamo il significato di ciascun elemento utilizzato sopra:

Come si può notare, la firma vera e propria è solo una piccola parte del DKIM. Tutto ciò che si trova al di sopra di essa sono metadati, che descrivono come sono stati calcolati i valori hash.

Si noti che due dei tag sono stati contrassegnati come opzionali: non sono necessari perché il DKIM sia verificato correttamente, ma aggiungono un ulteriore livello di sicurezza. Ci sono diversi altri tag opzionali che si possono usare: “i” – identità di un utente o di un agente (si consiglia di impostarlo); “l” – lunghezza del corpo del messaggio e “z” – elenco delle intestazioni originali del messaggio (entrambi non si consiglia di impostarli).

Come funziona il DKIM?

La firma e la ricezione di DKIM avvengono in tre fasi:

1. Il mittente decide cosa includere in un record DKIM

Come mittente, è possibile limitarsi solo ad alcune parti dei campi dell’intestazione (“Da”, “A”, “Cc”, “Oggetto”, ecc.), ma anche includere l’intera intestazione e il corpo nel DKIM. Si può anche scegliere di aggiungere alcuni o tutti i campi opzionali menzionati sopra. 

Tecnicamente, più dettagli specifici sono inclusi, più affidabile sarà l’autenticazione. Tuttavia, è necessario fare attenzione anche a questo aspetto, poiché anche i più piccoli dettagli modificati dal server SMTP porteranno a un fallimento dell’autenticazione DKIM da parte del destinatario. Si pensi, ad esempio, ai messaggi “inoltrati da…” che vengono aggiunti alle e-mail quando le si inoltra dai client di posta elettronica. Se si include l’intero corpo in DKIM, l’autenticazione fallirà inevitabilmente perché il corpo è stato appena modificato.

Non preoccupatevi, però. Non è necessario decidere la forma del DKIM ogni volta che si invia un’e-mail. Se ne occupa automaticamente un server da configurare una sola volta. 

2. Il DKIM viene creato e viene inviato un messaggio che lo include

Una volta che il server sa cosa includere nel DKIM e l’invio dell’e-mail è iniziato, inizia l’hashing del contenuto. Si è già visto come appaiono i tag “b” e “bh” nel nostro esempio. Per fornire un ulteriore esempio, ecco come apparirebbe il passaggio precedente se l’hashing fosse effettuato con il metodo SHA256:

568291DDA7ECE2594254BC8E7D70DA150968D022021081BB6E3FC40DC9C260D6
CE328291830AB02CFB1D8CDEC3C2B35C73F92ADF335BCCF38C6784AC9922A8C1

Anche se può sembrare complesso, questi hash sono estremamente facili da decifrare con vari strumenti online (provate voi stessi!). Per questo motivo, prima di inviare un’e-mail, ogni hash viene crittografato con una cosiddetta chiave privata. È possibile avere una chiave privata separata per ogni selettore utilizzato, anche se si inviano tutte le e-mail dallo stesso dominio. Questo può significare una chiave per le e-mail di marketing, un’altra per le e-mail transazionali e una terza per le e-mail inviate ai venditori. L’uso di chiavi private diverse è importante per ragioni di sicurezza.

Una volta impostato tutto, l’e-mail viene inviata!

3. Viene ricevuto un messaggio e il server convalida le firme DKIM

Nel giro di pochi secondi, il server di posta ricevente riceve un messaggio e deve prendere una decisione importante: accettare o meno l’e-mail. Quando vede che un DKIM è incluso nel messaggio, inizia immediatamente il processo di convalida.

Con i campi dominio (“d”) e selettore (“s”) visibili in DKIM, il server può recuperare la chiave pubblica che corrisponde a questa combinazione eseguendo un’apposita interrogazione DNS (tali dati sono pubblicamente disponibili). Quindi, con la chiave pubblica appena acquisita e i campi cifrati “b” e “h”, il server ricevente costruisce i propri hash e li confronta con quelli ricevuti nel messaggio. Se c’è corrispondenza, l’autenticazione ha successo. In caso contrario, l’autorizzazione DKIM fallisce. Questo non significa che il messaggio verrà scartato, ma riduce le sue possibilità di essere consegnato.

Come si aggiunge la firma DKIM alle e-mail?

L’aggiunta del DKIM richiede la modifica di alcuni dettagli dei record DNS. Molti client di posta elettronica descrivono il processo in dettaglio, quindi non ci concentreremo su di esso in questa sede. Consultate i seguenti link per i dettagli specifici dei provider più diffusi:

• Mailtrap Email API
• MailChimp
• SendGrid
• Sendinblue
• Mailjet
• AWeber
• Gmail
• Outlook e Office365

Se il vostro client di posta elettronica non offre alcuna assistenza per l’implementazione del DKIM o se state configurando la vostra infrastruttura, consultate la documentazione ufficiale del DKIM. Con Mailtrap Email API, si ottengono i record DKIM con una rotazione automatica trimestrale che aiuta a mantenere sicura l’infrastruttura di posta elettronica.

Come si può verificare se il DKIM è stato configurato correttamente?

Una volta aggiunto il DKIM, assicuratevi di convalidarlo con un analizzatore DKIM online. Utilizzate, ad esempio, MXToolbox o Mail-tester.com – quest’ultimo può essere utilizzato per controllare contemporaneamente i record SPF.

Potete anche inviare un’e-mail di prova al vostro account Gmail o Yahoo e verificare voi stessi se un messaggio è arrivato con la vostra firma DKIM.

Una volta arrivato il messaggio, espandere l’intestazione dell’e-mail con l’icona del triangolo sotto il nome del mittente. Se il dominio del mittente appare sia per “mailed-by” che per “signed-by”, il messaggio è stato verificato con successo con DKIM.

È anche possibile fare clic sui tre punti nell’angolo in alto a destra e su “Mostra originale”. Qui vedrete il risultato dell’autenticazione DKIM. Se c’è scritto “PASS” e il vostro indirizzo di dominio, tutto funziona bene.

Per verificare il record DKIM su Yahoo, cliccate su “Visualizza intestazione completa” e cercate la traccia di DKIM. Se trovate dkim=pass (ok), avete superato il test!

Che cos’è Gappssmtp?

Gappssmtp è una chiave di dominio predefinita per le e-mail inviate attraverso il server SMTP di gmail. Il record di autenticazione DKIM a volte mostrerà gappssmtp. Ad esempio, se si riceve un’e-mail da name@railsware.com, il record DKIM mostrerà railsware-com.20150623.gappssmtp.com.

Per controllare il record di autenticazione DKIM, in caso di sospetto di phishing o altro, individuare il menu a tendina “mostra dettagli” sotto il nome del mittente. La sezione “firmato da” è quella che si cerca per determinare se l’e-mail è stata inviata da un server sicuro. Se c’è scritto “gmail”, il record DKIM includerà gappssmtp, quindi l’e-mail è stata inviata da un server sicuro con una chiave di autenticazione predefinita.

Le e-mail inviate tramite un servizio, come un calendario, un drive, una casella o altro, non hanno un DKIM. Al contrario, sarà possibile individuare solo una firma fornita dal servizio. Queste firme, compresa quella di gappssmtp, vengono assegnate automaticamente e verificano semplicemente la sicurezza dell’e-mail ricevuta. Si tratta di una procedura standard e automatizzata eseguita a scopo di verifica.

Tre principali idee sbagliate sul DKIM

DKIM cripta la posta elettronica

Non è così. L’obiettivo principale di DKIM è verificare e confermare che il messaggio sia intatto. Gli hash sotto i tag “bh” e “b” offrono protezione dalla modifica e dalla riproduzione dei messaggi, compresa una protezione parziale dal furto di identità e dalla contraffazione. Un test di verifica DKIM superato significa sostanzialmente che l’e-mail inviata ha il permesso di essere inviata da questo dominio e che il contenuto del messaggio non è stato alterato durante il transito.

Una firma DKIM può essere falsificata poiché i suoi dettagli sono disponibili nei record DNS.

No, non può essere falsificato. DKIM si basa sulla PKI (Public key infrastructure), il che significa che è coinvolta una coppia di chiavi. Una pubblica e una privata. Mentre è vero che la chiave pubblica è pubblicata nei record DNS (ed è disponibile per tutti), la chiave privata è conservata solo sul server del provider di servizi e-mail. La chiave privata rimane segreta e viene utilizzata per firmare i messaggi. La chiave pubblica non può firmare i messaggi e viene utilizzata solo per la verifica. 

DKIM vi salva dallo spam una volta per tutte

Magari. Poiché la firma digitale DKIM consente di dimostrare che il mittente è autorizzato a inviare messaggi dal dominio e che il messaggio non è stato manipolato durante il percorso, DKIM riduce solo le possibilità che gli spammer utilizzino indirizzi e-mail contraffatti o rubati. 

Tuttavia, nulla impedisce loro di acquistare un dominio, creare un record DKIM e continuare le loro attività di spamming. Anzi, in un certo senso questo potrebbe addirittura legittimare lo spam. 

Tuttavia, l’utilizzo di un nome di dominio reale invece di uno contraffatto può molto probabilmente ridurre al minimo gli attacchi di phishing, come quando si riceve un’e-mail contraffatta dalla propria “banca” che chiede di confermare i dati della carta di credito.

Rotazione delle chiavi DKIM: mantenere aggiornata la sicurezza DKIM

Sebbene le chiavi pubbliche DKIM a 1024 bit siano difficili da decifrare e quelle a 2048 bit quasi impossibili, vengono comunque pubblicate nei record DNS e potrebbero quindi diventare un bersaglio di attacchi. Anche le chiavi private (chiave di firma) potrebbero essere rubate se il sistema in cui sono memorizzate venisse violato.

Per ridurre i rischi di compromissione delle chiavi DKIM, è necessario ridurre al minimo il tempo in cui vengono utilizzate attivamente. Il processo di sostituzione sistematica della vecchia coppia di chiavi DKIM con la nuova è chiamato rotazione delle chiavi DKIM.

In generale, il periodo di rotazione delle chiavi consigliato va dalla sostituzione trimestrale a quella semestrale. La frequenza di rotazione delle chiavi deve essere stabilita individualmente dall’organizzazione, ma sicuramente è un must del flusso di lavoro. 

Il processo di rotazione delle chiavi può diventare piuttosto complicato nelle aziende che hanno più flussi di e-mail, sottodomini delegati o flussi inviati per conto di terzi. Pertanto, per mantenere sicuro il flusso di e-mail, il processo di rotazione delle chiavi DKIM deve essere pianificato in anticipo.

Come ruotare le chiavi DKIM?

Il processo di rotazione delle chiavi DKIM si divide in due fasi principali: la preparazione e la rotazione vera e propria. 

In primo luogo, nella fase di preparazione, si identificano tutti i flussi di posta inviati dall’organizzazione: dai messaggi transazionali e di conversazione all’interno dell’azienda alle e-mail inviate da fornitori terzi. La preparazione comprende anche l’informazione del processo di rotazione delle chiavi agli stakeholder interni, agli amministratori di posta elettronica, agli amministratori DNS e al personale di supporto tecnico interno responsabile dei flussi di posta elettronica. Dovrebbero anche sapere come comportarsi in caso di rotazione di emergenza delle chiavi, se le chiavi DKIM sono inaspettatamente compromesse.

In secondo luogo, nella fase di implementazione, si definisce lo schema di rotazione dei selettori, si ruotano le chiavi e si esegue la verifica a posteriori.  

Il Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG) ha creato una guida passo passo per le migliori pratiche di rotazione delle chiavi DKIM. Ricordate che la sicurezza delle e-mail deve essere sempre al primo posto. 

Altre considerazioni

La guida al DKIM si conclude qui, ma non dovrebbe essere la fine dei vostri sforzi per migliorare la deliverability delle e-mail. Consultate la nostra guida sulla deliverability, dove elenchiamo molte altre idee. Assicuratevi anche di autenticarvi con SPF (Sender Policy Framework) e DMARC (Domain-based Message Authentication, Reporting, and Conformance) per rendere il vostro dominio ancora più credibile. Ci vuole solo un po’ di tempo e di impegno, ma i vantaggi possono essere enormi.

Qual è lo scopo del DMARC, come si presenta e come funziona, e molte altre domande relative al famoso protocollo di autenticazione trovano risposta nel testo che segue. Continuate a leggere!

Che cos’è il DMARC?

Inizieremo questo articolo con la domanda presente nella mente della maggior parte dei lettori: “Che cosa significa DMARC?”. La risposta è: Domain-based Message Authentication, Reporting & Conformance.

Il DMARC non solo ha il nome più complicato dei tre principali protocolli di autenticazione delle e-mail, ma è anche il più efficace. È facile capire perché. 

Il DMARC sfrutta i controlli DKIM (DomainKeys Identified Mail) e/o SPF (Sender Policy Framework) per eseguire una convalida più avanzata su ogni messaggio e-mail ricevuto.

L’autenticazione DKIM utilizza le firme DKIM per verificare l’integrità del contenuto di un’e-mail e la sua origine. L’SPF, invece, consente al proprietario di un dominio di autorizzare gli indirizzi IP a inviare e-mail con il nome del dominio ed è utilizzato da provider di servizi Internet come Gmail, Yahoo, ecc.

Con l’autenticazione DMARC, il proprietario di un dominio può specificare la propria procedura di autenticazione, nota anche come criterio DMARC. Utilizzando tale criterio, si istruisce un server in entrata su cosa fare se un’e-mail non supera il test DMARC. 

Infine, il criterio può anche fornire rapporti con i dettagli di ogni controllo per migliorare i processi e fornire un avviso immediato se qualcuno fa spoofing del dominio.

Come funziona il DMARC?

La chiave per comprendere il DMARC e il suo funzionamento è sapere che è necessario impostare un record SPF o un record DKIM o, meglio, entrambi. 

Quando si riceve un’e-mail, il server ricevente esegue una ricerca DNS (Domain Name System) e controlla se esiste un record DMARC. 

DKIM/SPF viene eseguito come di consueto. 

Il server ricevente esegue quindi un cosiddetto “test di allineamento DMARC” per verificare se:

• Nel caso di SPF, l’indirizzo e-mail “envelope from” all’interno dell’intestazione tecnica nascosta dell’e-mail corrisponde all’indirizzo “return-path”. In altre parole, si verifica se l’indirizzo e-mail da cui è stato inviato il messaggio corrisponde all’indirizzo a cui verrebbe inviata una potenziale risposta.
• Nel caso di DKIM, il valore dietro il tag “d” (dominio del mittente dell’e-mail) corrisponde al dominio da cui è stata inviata l’e-mail.

Naturalmente, se sono impostate entrambe le autenticazioni, vengono eseguiti entrambi i test di allineamento. 

I requisiti di allineamento possono essere “rigidi” (i domini devono corrispondere esattamente) o “rilassati” (i domini di base devono corrispondere, ma sono ammessi sottodomini diversi). 

Il DMARC avrà successo nei seguenti scenari:

• Se è stata impostata solo una delle autenticazioni, la sua verifica deve avere esito positivo, insieme al relativo test di allineamento.
• Se sono impostate entrambe le autenticazioni, una di esse deve avere successo con il rispettivo test di allineamento, ma non sono necessarie entrambe.

Si noti che il DMARC avrà comunque successo anche se, ad esempio, DKIM e l’allineamento DKIM falliscono, ma SPF e il suo allineamento hanno successo (o viceversa).

Supponiamo che un’e-mail non abbia superato la verifica DMARC per qualsiasi motivo. 

Il DMARC consente di indicare al server in entrata cosa deve accadere alle e-mail che non riescono ad essere autenticate. 

Sono disponibili tre opzioni (denominate “politiche”):

• “Nessuno”: l’e-mail deve essere trattata come se non fosse stato impostato il DMARC (il messaggio può ancora essere consegnato, messo nello spam o scartato in base agli altri fattori). In genere si usa per controllare l’ambiente e analizzare i report senza influenzare la deliverability.
• “quarantena”: consente di ricevere l’e-mail, ma non di inviarla alla casella di posta. Di solito, questi messaggi finiscono nella cartella dello spam.
• “rifiuta”: scarta subito le e-mail che non hanno superato il controllo.

Questi criteri possono anche essere personalizzati. Ad esempio, con un criterio di “quarantena”, si può dire al server di posta elettronica di inviare alla cartella spam solo il 10% delle e-mail con un controllo non riuscito e di ignorare (“nessuno”) il restante 90%. 

Si noti che il fatto che si dia al server un’istruzione su cosa fare non significa che seguirà completamente il consiglio. Tuttavia, in questo modo si ha un controllo maggiore rispetto alle autenticazioni DKIM e SPF.

Infine, un server ricevente invierà rapporti per ogni verifica DMARC fallita con dati aggregati sulle verifiche non andate a buon fine. Questi dati sono preziosi per analizzare le prestazioni dei messaggi e per tenervi informati in caso di truffe di phishing.

Perché utilizzare il DMARC?

Lo abbiamo detto più volte, ma vale la pena ripeterlo: DMARC è il modo più efficace per proteggersi dallo spoofing. Punto. 

Secondo le stime dell’ HMRC, il numero di e-mail di phishing inviate dal loro dominio è diminuito di 500 milioni in appena 1,5 anni dopo l’implementazione del DMARC. 

Senza elencare altri vantaggi del DMARC, questo dovrebbe essere un motivo sufficiente per aggiungere l’implementazione del DMARC al vostro prossimo sprint. 

Ma se avete bisogno di qualcosa di più, ci sono due vantaggi principali del DMARC da considerare:

• È molto più probabile che i criminali informatici rinuncino a tentare lo spoofing di un dominio se vedono i record DMARC (correttamente configurati) nel DNS del dominio. L’implementazione del DMARC non è ancora diffusa, quindi non sarà difficile trovare qualcosa che valga la pena.
• I server di ricezione sanno anche che le e-mail provenienti da domini protetti da DMARC hanno molte più probabilità di essere legittime rispetto a quelle protette con uno solo degli altri metodi di autenticazione (per non parlare di quelle senza alcuna sicurezza).

In cosa consiste un record DMARC?

Avete le basi? Perfetto! Ora analizziamo un record DMARC. 

Invece di affidarci a dati fittizi, useremo il record di Square, un unicorno fornitore di servizi finanziari per le piccole imprese. Molti criminali informatici probabilmente sognano di fare lo spoofing delle loro e-mail, quindi non sorprende che abbiano scelto di proteggersi con il DMARC.

È possibile accedere al record di Square a questo link, che conduce a un sito che mostra i record DMARC per qualsiasi dominio, a condizione, ovviamente, che sia stato configurato.

v=DMARC1; p=reject; rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com; ruf=mailto:dmarc-ruf@squareup.com

Esaminiamo uno per uno i parametri DMARC del record di cui sopra.

v=DMARC1

Questo è l’identificatore (una versione DMARC) che deve essere sempre incluso nel record DNS, poiché il server di posta ricevente lo cerca sempre. Se v=DMARC1 manca o è modificato in qualche modo, l’intera verifica verrà saltata.

p=reject

Questo è il criterio scelto da Square, che rifiuta tutte le e-mail che non superano il controllo DMARC. Naturalmente, potrebbero essere consegnate, ma verrà inviato un segnale forte al server ricevente per non consentire tali messaggi.

rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com

Questi tre indirizzi riceveranno quotidianamente rapporti aggregati sulle e-mail che non hanno superato la verifica. I rapporti conterranno dati di alto livello sui motivi dei fallimenti, senza fornire alcun dettaglio per ciascuno di essi. Tutti gli indirizzi aggiunti qui devono essere preceduti da “mailto:” come nell’esempio precedente.

ruf=mailto:dmarc-ruf@squareup.com

Si tratta di un indirizzo e-mail al quale verranno inviati in tempo reale i singoli rapporti (ovvero i rapporti sui guasti), compresi i dettagli di ciascun guasto.

Altri record DMARC di esempio

Nell’esempio del record Square DMARC, abbiamo mostrato un record con un criterio di “rifiuto”. Per coprire le altre due varianti di criterio, utilizzeremo ora alcuni dati fittizi a scopo puramente dimostrativo.

Record DMARC con criterio “nessuno”:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;

Spiegazione:

• “p=none” specifica un criterio di “nessuno”, il che significa che non deve essere intrapresa alcuna azione sulle e-mail che non superano l’autenticazione DMARC.

Record DMARC con criterio “quarantena”:

v=DMARC1; p=quarantine; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;

Spiegazione:

• “p=quarantine” specifica un criterio di “quarantena”, il che significa che le e-mail che non superano l’autenticazione DMARC devono essere messe in quarantena o segnalate come sospette dal sistema di posta elettronica del destinatario, ma consegnate comunque alla casella di posta del destinatario.

Alcuni tag DMARC opzionali per la personalizzazione

Come di solito accade, ci sono anche diversi campi opzionali che possono essere aggiunti a un record DMARC per personalizzarlo un po’.

Come implementare i record DMARC

L’intero processo di implementazione del DMARC si riduce alle seguenti fasi:

• Convalida della configurazione di SPF/DKIM e dell’allineamento dei domini.
• Generare un record DMARC e specificare le impostazioni DMARC.
• Aggiungerlo al DNS del vostro dominio.

Verificare che DKIM e/o SPF siano impostati correttamente.

Come già detto, la presenza di DKIM o SPF è obbligatoria per il funzionamento del DMARC. Ma anche se uno dei due restituisce risultati negativi per le e-mail legittime non serve a nulla. Il test DMARC fallisce automaticamente se SPF o DKIM falliscono.

Se è stato impostato solo l’SPF, verificare se i due seguenti elementi corrispondono:

• Indirizzo ” envelope from “: l’indirizzo da cui vengono inviate le e-mail.
• Indirizzo “Return-path”: l’indirizzo a cui verranno indirizzate le e-mail se un destinatario risponde a un’e-mail.

Se ci si affida solo a DKIM, verificare se i due seguenti elementi corrispondono:

• Indirizzo ” envelope from “: l’indirizzo da cui vengono inviate le e-mail.
• “d” del vostro record DKIM.

Se utilizzate entrambi i metodi (e giustamente!), eseguite ovviamente entrambi i controlli. 

Scegliere un account e-mail per la ricezione dei record DKIM

L’aspetto positivo del DMARC è che, una volta impostato, il server inizia a inviare rapporti giornalieri sull’andamento delle e-mail (rapporti aggregati e forensi separati). In questo modo, è possibile individuare rapidamente eventuali anomalie e migliorare le prestazioni utilizzando i dati. 

Tenete presente che i rapporti vengono inviati in un formato grezzo e di difficile lettura, per cui si consiglia di utilizzare strumenti come Dmarcian o MXToolbox per ottenere il massimo dai dati. 

Generare il record DMARC

E ora, generiamo finalmente un record DMARC.

Dmarc.org raccomanda una serie di risorse per questo compito. Inoltre, ci sono diversi tag già menzionati che è necessario utilizzare nel record e alcuni opzionali. 

Si noti che il tag “p” (“policy”) rappresenterà direttamente il passo precedente.

Aggiungere il record DMARC al DNS del vostro dominio

Una volta ottenuto il record, si può procedere ad aggiungerlo come record DNS. Potreste essere in grado di farlo da soli o, in alcuni casi, potrebbe essere necessario l’aiuto del vostro provider di hosting. 

Nel registrar del dominio, è necessario aggiungere il DMARC appena creato come record TXT. Non ci addentreremo nei dettagli in questa sede, poiché il processo varia a seconda del provider di hosting, ma è essenziale scegliere provider di web hosting affidabili per un’assistenza eccellente.

Se avete fatto tutto correttamente, dovreste ricevere i primi rapporti entro le prossime 24 ore.

Tre grandi miti DMARC sfatati

Il DMARC è impostato solo per motivi di sicurezza

Parzialmente vero. Il DMARC mira effettivamente a prevenire gli attacchi di spoofing e phishing via e-mail. Tuttavia, il DMARC non si limita a questo. 

I criteri di applicazione del DMARC e le funzionalità avanzate di reporting migliorano significativamente la consegna della posta legittima. Contribuiscono a creare e migliorare la fiducia nel marchio e l’analisi. Pertanto, il DMARC può dare un notevole impulso a qualsiasi campagna di marketing.

Il DMARC è solo per i domini che inviano posta.

Non è vero. Il fatto che il vostro dominio non invii e-mail non significa che non possa essere impersonato. Anzi, più il vostro marchio, la vostra azienda, la vostra organizzazione o la vostra personalità sono famosi, più alte sono le possibilità che qualche spammer voglia impersonare il vostro dominio e utilizzarlo per attività dannose come l’invio di e-mail fraudolente, siano esse di marketing o transazionali. 

I destinatari di e-mail dannose inviate dal “vostro” marchio molto probabilmente non saranno in grado di identificare che il vostro dominio non è configurato per l’invio di posta. Di conseguenza, dovrete affrontare molte conseguenze spiacevoli per la vostra reputazione e credibilità.

L’impostazione del criterio DMARC su “nessuno” è sufficiente per la sicurezza delle email

Sbagliato. Impostare il criterio DMARC su “nessuno” è di solito il primo passo per assicurarsi che la segnalazione e la consegna DMARC siano impostate correttamente, ma non migliora la sicurezza né aiuta a proteggere il dominio dall’impersonificazione. Alla fine, per sfruttare al meglio la sicurezza del DMARC e il miglioramento del marketing, dovrete utilizzare la politica di (almeno) p=quarantine o (meglio di tutti) p=reject a un tasso di pct=100. 

Inoltre, nel caso in cui decidiate di stare al passo con i tempi e di adottare il BIMI come ultima strategia di autenticazione del marchio, il vostro record DMARC dovrà essere impostato sulla politica “reject” per essere qualificato per la certificazione BIMI.

Riflessioni finali

La sicurezza delle e-mail non deve mai essere sottovalutata. Più grande è la vostra azienda, più avete da perdere se qualcuno fa uno spoofing del vostro dominio e inganna i vostri clienti con qualcosa che probabilmente non approvereste. 

Data la facilità con cui è possibile aggiungere ogni metodo di autenticazione e i vantaggi che si ottengono impostandoli correttamente, non c’è motivo di non provare.

L’aspetto assolutamente interessante del DMARC è che si può iniziare con un criterio “nessuno” e osservare cosa succede. In pratica, questo significa che le vostre e-mail saranno sottoposte ai controlli del caso sul lato ricevente, ma che se dovessero fallire, non influiranno sulla vostra deliverability. 

Inoltre, riceverete tonnellate di dati attraverso i rapporti DMARC che riguardano i problemi di autenticazione. In questo modo, potrete identificare rapidamente se qualcuno sta cercando di falsificare il vostro dominio e potenzialmente chiedere ai destinatari di fornire informazioni sensibili o se il problema risiede nella vostra azienda, in modo da poter effettuare una corretta risoluzione dei problemi.