Cosa sono i record MX

Il record MX (Mail Exchange Record) è un record DNS che specifica quale server di posta è re­spon­sa­bi­le della ricezione delle e-mail di un dominio. Ga­ran­ti­sce che le e-mail in arrivo vengano inoltrate cor­ret­ta­men­te al server giusto.

Il record MX spiegato con un esempio

I record DNS si trovano in file di zona, che non sono altro che semplici file di testo in cui vengono rag­grup­pa­ti tutti i record di una zona di cui è re­spon­sa­bi­le il server cor­ri­spon­den­te. Se un client fa una richiesta, il server che risponde riceve le sue in­for­ma­zio­ni da questo file. I diversi tipi di record hanno funzioni diverse. L’ab­bre­via­zio­ne MX sta per Mail Exchange e dà quindi già un’in­di­ca­zio­ne sulla funzione di questo record: il record MX indica, tramite DNS, a un client su quale dominio può rag­giun­ge­re un de­ter­mi­na­to server di posta.

Un dominio di solito è co­sti­tui­to da diversi server. Oltre al server web, che fornisce il sito web, ad esempio, dispone spesso anche di un server FTP e di uno o più server di posta. Tutti possono essere raggiunti tramite diversi sot­to­do­mi­ni. Il nome di questo sot­to­do­mi­nio può essere ottenuto dal record MX. Il server di posta da cui viene inviata l’e-mail esegue di solito au­to­ma­ti­ca­men­te questa funzione.

Campi e sintassi dei record

I record DNS sono co­sti­tui­ti es­sen­zial­men­te da diverse in­for­ma­zio­ni me­mo­riz­za­te in campi. Oltre alle in­for­ma­zio­ni sul nome del server di posta di un de­ter­mi­na­to dominio, è possibile tra­smet­te­re dettagli ag­giun­ti­vi:

• <name>: il primo campo contiene il nome del dominio.
• <ttl>: il Time to live indica la durata di validità dell’in­for­ma­zio­ne.
• <class>: il campo classe specifica il tipo di rete.
• <type>: il tipo di record DNS in questo caso è MX.
• <priority>: più piccolo è il valore, più alta è la priorità del server di posta.
• <rdata>: Resource Data definisce il nome del server di posta.

I nomi di dominio sono sempre indicati, in tutti i tipi di record, nella forma di Fully Qualified Domain Name (FQDN). Ciò significa che il contenuto di ogni campo termina con un punto. Infatti, gli FQDN rap­pre­sen­ta­no il percorso completo, dall’unità più piccola all’estrema sinistra a quella più grande all’estrema destra, ovvero il root server. Il livello più alto rimane comunque vuoto, motivo per cui non c’è più nulla dopo il punto pre­ce­den­te.

Il Time to live indica per quanto tempo il ri­chie­den­te può me­mo­riz­za­re e uti­liz­za­re le in­for­ma­zio­ni nella sua cache. In questo modo viene garantito che non vengano uti­liz­za­ti record obsoleti. Se il tempo è scaduto, il client deve ri­chie­de­re nuo­va­men­te il record dal name server. Il TTL viene spe­ci­fi­ca­to in secondi. Spesso questo campo non compare nel record vero e proprio perché viene spe­ci­fi­ca­to all’inizio del file di zona e definito per l’intera zona.

Il campo classe è opzionale, dato che internet è l’unica opzione di­spo­ni­bi­le. Al momento dell’in­tro­du­zio­ne dei record di risorse esi­ste­va­no ancora le due classi Hesiod (HS) e Chaos (CH). Oggi, tuttavia, entrambe le reti non sono più in uso. Pertanto, il campo rimane vuoto o contiene l’ab­bre­via­zio­ne IN senza eccezioni.

Il campo priorità è una ca­rat­te­ri­sti­ca speciale dei record MX. Molti am­mi­ni­stra­to­ri e molte am­mi­ni­stra­tri­ci, spe­cial­men­te in caso di progetti più grandi, ge­sti­sco­no più server di posta in parallelo. Questo consente di com­pen­sa­re i guasti e i picchi di carico ed evitare che la co­mu­ni­ca­zio­ne via e-mail si in­ter­rom­pa im­prov­vi­sa­men­te. La di­stri­bu­zio­ne non deve comunque essere ne­ces­sa­ria­men­te uniforme. Per questo motivo si assegnano le priorità. Il server con il valore più basso ha la massima priorità ed è quindi il primo a essere in­di­riz­za­to. Se non è di­spo­ni­bi­le, viene se­le­zio­na­to il server con il prossimo valore superiore.

Infine, il campo data contiene il nome del server di posta, anch’esso spe­ci­fi­ca­to nella forma FQDN. Nel record, tutti i campi si sus­se­guo­no all’interno di una riga e il record termina con un’in­ter­ru­zio­ne di riga.

Esempio di record MX

Come esempio uti­liz­zia­mo il server di posta fittizio di example.com. Un indirizzo e-mail adatto sarebbe ad esempio user@example.com. Il server web del mittente in­vie­reb­be quindi la sua richiesta DNS al dominio example.com. I record cor­ri­spon­den­ti nel file di zona del name server si pre­sen­te­ran­no nel modo seguente:

$TTL 1200
example.com.	IN	A		93.184.216.34
example.com.	IN	MX	10	mail1.example.com.
example.com.	IN	MX	10	mail2.example.com.
example.com.	IN	MX	50	mail3.example.com.

Come si può vedere qui, la durata delle in­for­ma­zio­ni si applica a tutta la zona. Il campo non deve quindi essere integrato nei singoli record. In questo esempio abbiamo prima di tutto un record A che collega il dominio a un indirizzo IP. Poi seguono tre record MX. Si nota che questi dif­fe­ri­sco­no solo nei sot­to­do­mi­ni.

In questo esempio, i primi due server di posta hanno gli stessi livelli di priorità (10), i compiti sono quindi di­stri­bui­ti equamente tra i due. Il server di posta 3 viene in­di­riz­za­to solo quando gli altri due non riescono più a gestire il carico, ad esempio a causa di un guasto.

Aspetti di sicurezza nella con­fi­gu­ra­zio­ne dei record MX

Quando crei record MX, dovresti dare im­por­tan­za alla sicurezza e all’evi­ta­men­to degli errori. I record MX non devono mai puntare di­ret­ta­men­te agli indirizzi IP, ma sempre ai nomi di dominio com­ple­ta­men­te qua­li­fi­ca­ti, che a loro volta vengono risolti tramite record A o AAAA. Inoltre, non è con­sen­ti­to uti­liz­za­re un record CNAME come de­sti­na­zio­ne di un record MX, poiché questa pratica viola gli standard DNS e può quindi portare a problemi di consegna. I server di posta di de­sti­na­zio­ne devono essere ri­sol­vi­bi­li e rag­giun­gi­bi­li cor­ret­ta­men­te tramite DNS, al­tri­men­ti si ve­ri­fi­che­ran­no messaggi di errore o le e-mail andranno perse.

Per prevenire lo spam e lo spoofing, do­vreb­be­ro essere impostati i record SPF, DKIM e DMARC per garantire l’au­ten­ti­ci­tà del dominio del mittente. Questi sono mec­ca­ni­smi di sicurezza delle e-mail:

• SPF ga­ran­ti­sce che solo i server au­to­riz­za­ti possano inviare e-mail a nome di un dominio.
• DKIM ga­ran­ti­sce che le e-mail siano firmate di­gi­tal­men­te e protette da ma­ni­po­la­zio­ni.
• DMARC fornisce regole ai de­sti­na­ta­ri e alle de­sti­na­ta­rie su come gestire le e-mail non au­ten­ti­ca­te.

Con­fi­gu­ra­re i record MX

Se desideri gestire la tua co­mu­ni­ca­zio­ne e-mail aziendale tramite Google Workspace o Microsoft 365, è ob­bli­ga­to­rio con­fi­gu­ra­re cor­ret­ta­men­te un record MX nella zona DNS del tuo dominio. Solo così si assicura che le e-mail in arrivo vengano re­ca­pi­ta­te in modo af­fi­da­bi­le ai server di posta del ri­spet­ti­vo fornitore.

Con­fi­gu­ra­zio­ne di un record MX su Google Workspace

Se desideri ricevere e-mail tramite lo strumento di col­la­bo­ra­zio­ne e per il project ma­na­ge­ment Google Workspace, devi inserire il server ufficiale di Google Mail come record MX nella zona DNS del tuo dominio. Si può fare fa­cil­men­te con i seguenti passaggi:

1. Rimuovi tutte le voci MX esistenti.

2. Aggiungi il seguente record MX per il server di posta di Google:

@	IN	MX	1	smtp.google.com.

3. Accedi alla console di am­mi­ni­stra­zio­ne Google con il tuo account am­mi­ni­stra­to­re e naviga nelle im­po­sta­zio­ni dell’account fino ai tuoi domini. Attiva Gmail per il dominio di cui desideri ag­gior­na­re il record MX.

Ci possono volere fino a 72 ore affinché la voce MX diventi effettiva.

Con­fi­gu­ra­zio­ne di un record MX su Microsoft 365

Anche con Microsoft 365 puoi con­fi­gu­ra­re fa­cil­men­te un record MX, che ga­ran­ti­sce che le e-mail destinate a persone che uti­liz­za­no il dominio vengano inviate a Microsoft 365. Le istru­zio­ni sono simili a quelle già descritte:

1. Rimuovi tutti gli attuali record MX.

2. Accedi al centro am­mi­ni­stra­ti­vo di Microsoft 365. Clicca su “Mostra tutto” -> “Im­po­sta­zio­ni” -> “Domini”. Qui troverai il record MX da uti­liz­za­re.

3. Copia il record MX, crealo presso il tuo provider di hosting e salva le modifiche.

Come ve­ri­fi­ca­re il record MX

Per eseguire un lookup di record MX è possibile uti­liz­za­re diversi servizi web. Molto comodo e facile da usare è il Public DNS di Google. Nella pagina iniziale, inserisci il dominio di cui vorresti con­trol­la­re i record MX. Nella pagina seguente devi cambiare il tipo di record da A a MX. Le due opzioni EDNS Client Subnet e DNSSEC non devono essere mo­di­fi­ca­te. La prima accelera l’ero­ga­zio­ne di in­for­ma­zio­ni DNS. L’altra invece ga­ran­ti­sce che le in­for­ma­zio­ni non siano state ma­ni­po­la­te da terzi.

Close

Nell’esempio di ricerca puoi vedere i diversi server di posta alla voce “Answer”. Il FQDN sotto il quale è possibile rag­giun­ger­li si trova alla voce “Data”. Anche la priorità è spe­ci­fi­ca­ta qui: il record di questa sezione ha una priorità di 10. Per il tipo troviamo il numero 15, che cor­ri­spon­de al record MX. L’Internet Assigned Numbers Authority (IANA) ha assegnato un valore, e quindi un numero, a ciascun tipo di record DNS.