Un record MX (Mail Exchange) indica quali server ricevono le email per un dominio. Ogni MX ha una priorità: il server con il numero più basso viene contattato per primo. Se quel server non è disponibile, il mittente prova il successivo.

Come funziona la priorità MX?

La priorità è un numero (tipicamente 10, 20, 30...). Il server con la priorità più bassa riceve la posta per primo. Se due MX hanno la stessa priorità, il traffico viene distribuito tra loro.

Perché il mio MX punta a un nome invece che a un IP?

Per design DNS, un MX deve puntare a un hostname, mai direttamente a un IP. Quell'hostname deve poi avere un record A o AAAA per risolvere a un IP.

Posso usare un CNAME come destinazione MX?

No, è proibito dalle RFC. Un MX deve puntare a un nome canonico (A/AAAA), non a un alias CNAME. Molti server rifiuteranno di consegnare se l'MX è un CNAME.

Come aggiungo un MX di backup?

Pubblica più record MX con priorità diverse. Per esempio: priorità 10 per il server principale, priorità 20 per il backup. Il backup riceve le email se il principale non è disponibile.

Le mie email finiscono in spam, è collegato al MX?

Il MX riguarda solo la ricezione delle email. Per problemi di invio e spam, verifica SPF, DKIM e DMARC. Tuttavia, il server MX dovrebbe avere un reverse DNS (PTR) corretto per la deliverability.

Quanti server MX devo avere?

Minimo uno, ma due sono raccomandati per la ridondanza. I grandi provider come Google Workspace o Microsoft 365 tipicamente ne configurano da 2 a 5.

Ricerca record MX

Identifica i server di posta del tuo dominio

Le tue email non vengono consegnate? Verifica che i tuoi record MX puntino ai server di posta corretti. Confronta le risposte di più resolver per rilevare problemi di configurazione.

Host

Tipo

Resolver

Traccia iterativa

In modalità traccia iterativa, il resolver viene ignorato.

Test di propagazione

Interroga più resolver pubblici per confrontare le risposte.

Server e priorità

Visualizza tutti i server MX con le loro priorità. Il server con la priorità più bassa riceve la posta per primo.

Validazione destinazioni

Verifica che ogni server MX risolva a un record A o AAAA valido. Un MX senza IP impedisce la consegna.

Confronto multi-resolver

Confronta le risposte di Google, Cloudflare, Quad9 per rilevare inconsistenze di propagazione.

Diagnosi completa

Identifica record MX orfani, priorità mal configurate o server irraggiungibili.

Gratuito e senza registrazione

Testa quanti domini vuoi. Nessun account richiesto.

Come utilizzare al meglio le opzioni del motore di lookup DNS

Cos'è la traccia iterativa?

La traccia esegue la risoluzione passo dopo passo. Il resolver interroga prima i server root, poi il TLD (.com, .fr, .eu) e infine i server autoritativi della zona di destinazione. A ogni fase la pagina mostra il server interrogato, la risposta, l'RCODE e la latenza.

1. Root
Scoperta dei server TLD per il nome richiesto.
2. TLD
Riferimento agli NS della zona (delegazione).
3. Authoritative
Risposta finale (o errore) con TTL e latenza.

A cosa serve?

Confrontare le risposte tra resolver e regioni
Individuare cache calde, TTL troppo lunghi o deleghe incomplete
Spiegare una differenza di latenza o un RCODE inatteso

Suggerimento: lascia la traccia disattivata per i controlli rapidi; attivala durante un'indagine o per preparare ticket e post-mortem.

Cos'è la traccia classica?

La traccia classica interroga solo il resolver selezionato (UDP o DoH) e mostra la risposta così come viene percepita da quel punto di rete. Ottieni l'RCODE, le sezioni di risposta e la latenza per il tratto client → resolver.

1. Resolver scelto
Utilizza il preset o la configurazione personalizzata per eseguire la query esattamente come farebbe il tuo servizio.
2. Protocollo preservato
Rispetta il trasporto selezionato (UDP, TCP o DoH) così da riprodurre il comportamento reale.
3. Risposta dettagliata
Mostra domanda, risposta e sezioni authority/additional quando presenti, insieme a TTL e metadati utili.

Perché usarla?

Verificare la vista di un resolver specifico prima di sospettare problemi di delega
Confermare valori in cache e l'impatto di TTL o flush
Documentare una risoluzione esattamente come la vede un client o un microservizio

Suggerimento: tieni disattivata la traccia iterativa quando esegui l'audit di un resolver; riattivala dopo per confrontarla con il percorso root → TLD → authoritative.

Come funziona il test di propagazione?

Il test interroga in parallelo un insieme di resolver pubblici (Google, Cloudflare, Quad9, OpenDNS, ISP…) e raggruppa le risposte per contenuto e RCODE. Vedi subito chi ha già recepito l'aggiornamento.

1. Resolver multi-punto
Abilita i preset di propagazione per interrogare diversi attori distribuiti nel mondo.
2. Confronto automatico
Raggruppa le risposte identiche e mette in evidenza divergenze o errori specifici di un resolver.
3. Riepilogo operativo
Fornisce un riepilogo chiaro, l'elenco dei resolver, le loro latenze e lo stato di ciascun gruppo.

Quando usarlo?

Monitorare la propagazione mondiale di una modifica DNS
Individuare cache obsolete e decidere un flush mirato
Condividere uno snapshot di propagazione in un ticket o post-mortem

Suggerimento: mentre il test di propagazione è attivo, il selettore del resolver resta bloccato. Disattiva la modalità per tornare alla diagnostica su singolo resolver.

Cos'è un record MX?

Un record MX (Mail Exchange) indica quali server ricevono le email per un dominio. Quando qualcuno invia un'email a user@captaindns.com, il server mittente interroga l'MX di captaindns.com per sapere dove consegnare il messaggio.

Struttura di un record MX:

Campo	Descrizione	Esempio
Nome	Il dominio (@ per l'apex)	`@`
Tipo	Sempre `MX`	`MX`
Priorità	Ordine di preferenza (minore = primo)	`10`
Destinazione	Nome del server di posta	`mail.captaindns.com.`
TTL	Durata cache in secondi	`3600`

Esempio concreto:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

Il server con priorità 10 riceve la posta per primo. Se non disponibile, il server con priorità 20 subentra.

Configurazione per provider comuni

Google Workspace

@  MX  1   ASPMX.L.GOOGLE.COM.
@  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
@  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365

@  MX  0  captaindns-com.mail.protection.outlook.com.

Il nome esatto dipende dal tuo tenant Microsoft.

Server dedicato

@  MX  10  mail.captaindns.com.

Assicurati che mail.captaindns.com abbia un record A valido.

Best practice

Ridondanza

Configura almeno 2 server MX con priorità diverse
Il server di backup deve poter archiviare le email temporaneamente (store-and-forward)
Testa regolarmente il failover fermando il server principale

Configurazione corretta

Regola	Spiegazione
MX → hostname	Un MX punta a un nome, mai a un IP
Hostname → A/AAAA	La destinazione MX deve avere un record A o AAAA
Niente CNAME	La destinazione non deve essere un CNAME
Reverse DNS	L'IP del server di posta dovrebbe avere un PTR corrispondente

Da evitare

❌ MX verso IP: MX 10 203.0.113.25 (non valido)
❌ MX verso CNAME: MX deve puntare a un A/AAAA diretto
❌ Priorità identiche senza intenzione: Può causare distribuzione non voluta
❌ MX orfano: Un MX la cui destinazione non risolve a nessun IP

Diagnosi dei problemi comuni

Email non consegnate (bounce)

Verifica che l'MX esista e punti a un nome valido
Conferma che la destinazione MX abbia un record A/AAAA
Testa l'accessibilità del server sulla porta 25
Verifica il reverse DNS (PTR) dell'IP del server

Email consegnate al server sbagliato

Verifica le priorità: la più bassa viene contattata per prima
Rimuovi i vecchi record MX dopo una migrazione
Attendi la scadenza del TTL dopo le modifiche

Ritardo nella consegna

Verifica che il server principale (priorità bassa) sia raggiungibile
Se il backup riceve le email, il principale ha un problema
Consulta i log SMTP per identificare i retry

Verifica da riga di comando

Windows (nslookup)

nslookup
set q=mx
captaindns.com

Linux/Mac (dig)

dig MX captaindns.com

Risultato tipico:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

Verificare che la destinazione risolva:

dig A mail.captaindns.com

Strumenti complementari

Strumento	Utilità
Tester email	Testare deliverability e autenticazione
Ispettore SPF	Verificare record SPF
Ispettore DKIM	Validare firma DKIM
Ricerca A	Verificare che la destinazione MX risolva
Ricerca PTR	Verificare il reverse DNS del server

Risorse utili

RFC 5321 - Simple Mail Transfer Protocol (specifica SMTP)
RFC 7505 - Null MX Record (come indicare che un dominio non riceve email)
Google Workspace - Configurare MX (guida ufficiale)
Microsoft 365 - Configurare MX (guida ufficiale)