VERIFICATOREEMAIL.COM / GUIDE E RISORSE
Diagnosi DNS dei record MX: preferenza, MX implicito e limiti sulla casella
Generato con assistenza IA · Fonti tecniche primarie indicate sotto. I controlli automatici non garantiscono l’assenza di errori.
Prima del DNS: separare sintassi, dominio, casella e recapito
Una diagnosi DNS della posta risponde a una domanda circoscritta: quali host sono indicati per gestire i messaggi destinati a un dominio? Non stabilisce se una specifica casella esista. Per Anna@example.com occorre separare quattro livelli: la sintassi dell’indirizzo, la risoluzione del dominio, il riconoscimento della parte locale Anna e il recapito di un messaggio. Un esito positivo a un livello non dimostra quello successivo: trovare un indirizzo IP non dimostra nemmeno che il servizio SMTP sia disponibile.
Il primo passo consiste nell’identificare correttamente il dominio dell’indirizzo, senza dedurlo da nomi incompleti o sostituirlo con il nome di un server ritenuto plausibile. La parte locale va conservata: secondo rfc5321, sezioni 2.3.11 e 2.4, soltanto il sistema indicato dal dominio può attribuirle significato e le maiuscole devono essere preservate. Il dominio, invece, non distingue maiuscole e minuscole. Tutti gli esempi seguenti su example.com e example.net sono ipotetici: illustrano risposte DNS, non risultati di interrogazioni effettuate.
Riferimenti: RFC5321
Interrogare gli MX distinguendo assenza ed errore
Il secondo passo è cercare i record MX del dominio completo. Prima di leggere eventuali destinazioni, bisogna classificare l’esito: record presenti, lista MX vuota, dominio inesistente oppure errore temporaneo. Sono condizioni diverse. La sezione 5.1 di rfc5321 prescrive di segnalare come errore il dominio inesistente; in presenza di un errore temporaneo, un mittente SMTP deve invece accodare il messaggio e riprovare. In una diagnosi senza invio, la conseguenza è registrare un esito non conclusivo, senza trasformarlo in «indirizzo inesistente».
Se la ricerca iniziale incontra un CNAME, il nome risultante viene elaborato come quello iniziale. Conviene quindi annotare sia il dominio richiesto sia quello verso cui la risoluzione prosegue. Una risposta priva di MX è utilizzabile per valutare l’MX implicito soltanto quando rappresenta effettivamente una lista vuota, non quando la ricerca è fallita. Questo controllo evita un errore pratico: cercare subito l’indirizzo del dominio dopo qualsiasi mancata risposta MX e considerarlo una destinazione alternativa valida.
Riferimenti: RFC5321
Leggere la preferenza senza confonderla con affidabilità
Quando gli MX sono presenti, il terzo passo è raccogliere tutte le coppie formate da preferenza e nome dell’exchanger. Supponiamo che example.com indichi mx-a.example.net con preferenza 10, mx-b.example.net con preferenza 10 e mx-c.example.net con preferenza 30. I valori più bassi sono preferiti: i primi due appartengono allo stesso gruppo, mentre il terzo viene dopo. Il numero non esprime una percentuale di traffico, una misura di qualità o la probabilità che una casella esista.
A parità di preferenza, in assenza di un motivo chiaro per favorire una destinazione, rfc5321, sezione 5.1, richiede al mittente di randomizzare le destinazioni per distribuire il carico. L’ordine mostrato da una risposta DNS non identifica quindi necessariamente un server principale. Inoltre un exchanger può avere più indirizzi IP: l’ordinamento degli MX e la lista degli indirizzi del singolo host sono due livelli distinti. Una diagnosi deve conservarli entrambi, anziché ridurre tutto al primo nome o al primo indirizzo trovato.
Riferimenti: RFC5321
Risolvere le destinazioni MX e riconoscere gli alias problematici
Il quarto passo consiste nel cercare i record A e AAAA dei nomi indicati dagli MX, non soltanto quelli del dominio dell’indirizzo. Per l’esempio precedente si esaminano separatamente mx-a.example.net, mx-b.example.net e mx-c.example.net. Il valore della destinazione MX deve essere un nome di dominio che restituisce almeno un record di indirizzo. Se un exchanger non fornisce indirizzi e la ricerca si conclude senza errori temporanei, manca per quell’host il collegamento DNS necessario a individuare il server.
Qui il trattamento dei CNAME cambia rispetto alla ricerca iniziale: un dominio destinatario che rinvia tramite CNAME viene seguito, ma il nome indicato come destinazione di un MX deve restituire record di indirizzo. Una destinazione MX che risolve a CNAME è esplicitamente fuori dall’ambito previsto da rfc5321, sezione 5.1. Va segnalata come irregolarità della configurazione, anche se un risolutore riesce infine a ottenere un IP: il completamento della risoluzione non elimina il problema.
Non è necessario trovare contemporaneamente A e AAAA. La sezione 5.2 ammette exchanger con IPv4, IPv6 o entrambe le famiglie. Un host con soli AAAA non è per questo privo di indirizzi; la possibilità di raggiungerlo dipende anche dalla connettività del mittente. Nel rapporto vanno quindi distinti «indirizzi pubblicati» e «compatibilità con l’ambiente di invio», lasciando non verificata la raggiungibilità effettiva quando l’analisi si ferma al DNS.
Riferimenti: RFC5321
Applicare l’MX implicito soltanto quando gli MX mancano
Se la ricerca termina con una lista MX vuota, il quinto passo è considerare il dominio come associato a un MX implicito con preferenza 0 e destinazione il dominio stesso. Se example.com non ha MX ma restituisce un record A o AAAA, esiste dunque un candidato individuabile attraverso questa regola. Non è un record aggiunto alla zona DNS: è il comportamento di risoluzione prescritto da rfc5321, sezione 5.1. Rimane ignoto se quell’indirizzo ospiti effettivamente un servizio SMTP.
Il caso opposto è decisivo: example.com pubblica un MX verso mx-a.example.net, ma quella destinazione non ha indirizzi utilizzabili. Anche se example.com possiede un record A, non è consentito usarlo come ripiego estraneo agli MX. L’MX implicito vale esclusivamente in assenza di MX. Se tutti gli exchanger risultano inutilizzabili, la diagnosi deve segnalare il problema del percorso MX; se manca anche un indirizzo utilizzabile per l’MX implicito, deve segnalare il problema di quel percorso. Un errore temporaneo di risoluzione resta invece da riesaminare.
Riferimenti: RFC5321
Chiudere la diagnosi senza certificare la casella
Il rapporto finale dovrebbe riportare dominio esaminato, eventuale alias iniziale, esito della ricerca MX, gruppi di preferenza e indirizzi delle destinazioni. Una conclusione precisa può essere: «MX espliciti presenti; una destinazione priva di indirizzi, una destinazione con AAAA; disponibilità SMTP e casella non verificate». Oppure: «Nessun MX; indirizzo A disponibile per il percorso implicito; servizio SMTP non verificato». Queste formulazioni individuano ciò che occorre controllare senza assegnare impropriamente all’intero indirizzo un’etichetta binaria.
La procedura termina prima di aprire connessioni SMTP: non comprende VRFY, RCPT o invio di contenuti. Il limite non è soltanto prudenziale. Secondo rfc5321, sezioni 3.3 e 6.1, alcuni sistemi rimandano la verifica dei destinatari e possono incontrare problemi dopo l’accettazione del messaggio. Se persino una risposta SMTP richiede contesto, la presenza di MX non può certificare la casella né promettere recapito. L’esito utile della diagnosi DNS è un percorso individuato, un’anomalia localizzata oppure un’incertezza esplicitamente conservata.
Riferimenti: RFC5321