Ricezione: i server che ricevono la posta del tuo dominio

I record MX indicano dove va consegnata la posta del tuo dominio. Come si leggono, gli errori che fanno rimbalzare i messaggi e come si mette in sicurezza un dominio senza caselle.

Fin qui abbiamo parlato di posta in uscita. Questa pagina riguarda il verso opposto: come fa il resto del mondo a sapere dove consegnare i messaggi indirizzati al tuo dominio. La risposta sta nei record MX, l'equivalente dell'indirizzo sulla cassetta delle lettere.

Quando qualcuno scrive a info@esempio.it, il suo server cerca i record MX di esempio.it, trova uno o più nomi di server, li prova in ordine di priorità e consegna al primo che risponde. Se non trova nessun MX, in molti casi ripiega sull'indirizzo IP del sito — che quasi mai è un server di posta — e il messaggio rimbalza.

C'è poi un caso che riguarda quasi tutte le aziende e che quasi nessuno considera: i domini che non ricevono posta. Vecchi marchi, varianti scritte male comprate per difesa, domini di campagne finite. Non avendo caselle, nessuno li guarda — ed è esattamente per questo che sono comodi da falsificare.

Come sono fatti i record

esempio.it.  MX  10 mail1.esempio.it.
esempio.it.  MX  20 mail2.esempio.it.

Due o più MX con priorità diverse sono la norma: se il primo non risponde, il mittente prova il secondo. Non è una vera ridondanza — se sono la stessa macchina non serve a nulla — ma nella maggior parte dei casi i due nomi puntano a sistemi diversi del provider.

Per un dominio che non deve ricevere posta esiste una forma prevista, il cosiddetto MX nullo:

esempio.it.  MX  0 .

Un punto e basta. Significa: questo dominio non riceve posta, non provarci nemmeno. Chi spedisce riceve subito un errore chiaro invece di aspettare giorni.

Il dominio senza caselle, messo in sicurezza

Se un dominio non riceve e non spedisce, tre righe lo chiudono del tutto:

esempio.it.        MX   0 .
esempio.it.        TXT  "v=spf1 -all"
_dmarc.esempio.it. TXT  "v=DMARC1; p=reject;"

L'MX nullo dice che non ci sono caselle. L'SPF con -all e senza nessun meccanismo dice che nessun server al mondo è autorizzato a spedire a nome di questo dominio. Il DMARC su p=reject dice ai destinatari di rifiutare qualsiasi cosa arrivi lo stesso. Tre righe, cinque minuti, e un bersaglio in meno.

Attenzione a una cosa sola: assicurati che il dominio non sia usato da qualche sistema interno per mandare notifiche. Capita che un vecchio dominio sia rimasto configurato come mittente in un gestionale.

Come si imposta

I record MX li fornisce il provider di posta e vanno pubblicati dove è gestita la zona DNS. Su Aruba:

1. Accedi all'area clienti e apri Gestione DNS e Domini.
2. Scegli il dominio e apri la gestione dei record DNS.
3. Nella sezione dei record MX inserisci i nomi indicati dal tuo servizio di posta, ognuno con la sua priorità.
4. Se il dominio non deve ricevere posta, cancella gli MX esistenti e inserisci un MX con priorità 0 e valore . — alcuni pannelli chiamano questa opzione «nessun server di posta».
5. Salva e ricontrolla dopo un'ora dall'esterno.

Chi usa Microsoft 365 o Google Workspace trova i record da inserire nella procedura guidata di aggiunta del dominio; per Register.it, Netsons, Serverplan e IONOS stanno nella pagina del servizio di posta. In tutti i casi vanno copiati come sono: un nome MX inventato o abbreviato non funziona.

I rilievi nel dettaglio

Nessun server di posta configurato

Il dominio non ha record MX. Chi prova a scriverti non sa dove consegnare: nella maggior parte dei casi il messaggio rimbalza, in altri il mittente ripiega sull'indirizzo del sito web, che non accetta posta, e rimbalza lo stesso.

Che cosa fare. Se il dominio deve ricevere posta, pubblica i record MX del tuo provider — li trovi nella documentazione del servizio o nella procedura di aggiunta del dominio. Se non deve riceverne, pubblica un MX nullo (0 .) e aggiungi anche v=spf1 -all e p=reject.

Un solo server di posta

C'è un unico record MX. Se quel server non risponde, la posta resta in attesa presso i mittenti. Non è un guasto: quasi tutti i server mittenti riprovano per giorni prima di rinunciare, quindi di rado si perde qualcosa. È però un punto singolo di rottura, e durante un guasto prolungato i tuoi messaggi arrivano con ore di ritardo.

Che cosa fare. Se il tuo provider offre un secondo nome, aggiungilo con una priorità più alta. Se non lo offre — molti servizi hanno già la ridondanza dietro a un nome solo — puoi lasciare così: è una scelta del provider, non una tua dimenticanza.

L'MX punta a un indirizzo IP

Nel record MX c'è un indirizzo IP invece di un nome di server. Lo standard non lo prevede: un MX deve indicare un nome, che poi si risolve in un indirizzo. I mittenti più rigorosi rifiutano la consegna, altri la accettano, e il risultato è che la posta arriva da alcuni e non da altri — il tipo di guasto più difficile da diagnosticare.

Che cosa fare. Crea un record A (o AAAA) con un nome — per esempio mail.esempio.it — che punti a quell'indirizzo, e metti quel nome nel record MX.

L'MX punta a un alias

Il nome indicato nel record MX è a sua volta un alias (CNAME) verso un altro nome. Lo standard lo vieta esplicitamente. Parte dei server mittenti rifiuta la consegna, parte la accetta: di nuovo, posta che arriva a intermittenza.

Che cosa fare. Metti nel record MX direttamente il nome di destinazione, quello a cui punta il CNAME. Se il provider cambia spesso quel nome, chiedi a lui il nome da usare nell'MX: tutti i servizi seri ne forniscono uno stabile.

Il server di posta non si risolve

Il nome indicato nell'MX non ha né un indirizzo IPv4 né uno IPv6. Nessuno può consegnare lì, perché il nome non porta da nessuna parte. Le cause tipiche: un refuso, un record A cancellato durante una pulizia del DNS, o un server dismesso e mai tolto dall'MX.

Che cosa fare. Controlla la grafia del nome nel record MX. Se è giusto, manca il record A/AAAA del server: pubblicalo, o correggi l'MX con il nome attuale fornito dal provider.

Server di posta senza risoluzione inversa

L'indirizzo del server di posta non ha un record PTR, cioè non ha un nome quando lo si interroga al contrario. Per la ricezione non conta nulla. Conta molto per l'invio: se lo stesso server spedisce anche, molti destinatari rifiutano le connessioni da indirizzi senza risoluzione inversa, o le penalizzano pesantemente.

Che cosa fare. Il PTR non si imposta nel DNS del dominio: lo pubblica chi possiede l'indirizzo IP, quindi il tuo provider di hosting o di server. Chiediglielo, indicando il nome a cui deve puntare — che dovrebbe essere lo stesso nome con cui il server si presenta quando spedisce.

Dominio senza caselle, ancora falsificabile

Questo dominio non riceve posta, e da come è configurato sembra una scelta deliberata. Manca però un SPF rigoroso: senza, chiunque può spedire messaggi a nome di questo dominio, e nessuno in azienda se ne accorgerà, perché non ci sono caselle da cui vedere le risposte.

Che cosa fare. Pubblica un record TXT con esattamente v=spf1 -all. Nessun include:, nessun indirizzo: il dominio non spedisce, quindi non c'è niente da autorizzare. Prima di farlo, verifica che nessun sistema interno stia usando questo dominio come mittente.

Dominio senza caselle e senza rifiuto DMARC

Come sopra, ma dal lato del DMARC: il dominio non riceve posta e non porta l'istruzione più rigorosa. Un dominio che non spedisce non ha alcun motivo per chiedere clemenza ai destinatari.

Che cosa fare. Pubblica _dmarc.<dominio> con valore v=DMARC1; p=reject;. Puoi aggiungere un rua= verso una casella che leggi davvero: su un dominio che non spedisce, ogni voce nei rapporti è per definizione qualcuno che non dovrebbe esserci.

Nessun server e nessuna dichiarazione chiara

Il dominio non ha record MX, ma non dichiara nemmeno di non voler ricevere posta. È lo stato ambiguo: i mittenti che non trovano MX ripiegano sull'indirizzo del sito e provano a consegnare lì. Il risultato sono messaggi che restano in coda per giorni prima di rimbalzare, e mittenti convinti di averti scritto.

Che cosa fare. Decidi. Se il dominio deve ricevere posta, pubblica i record MX del provider. Se non deve, pubblica un MX nullo (0 .) e completa con v=spf1 -all e p=reject.

Domande frequenti

Posso spedire posta da un dominio che non ha MX?

Sì. Invio e ricezione sono indipendenti, e non è raro: i domini usati solo per le newsletter spesso non ricevono nulla. Vale però la pena di pensare a dove finiscono le risposte e i messaggi di errore — un indirizzo che rimbalza sempre danneggia la reputazione del mittente.

Quanti record MX servono?

Uno funziona. Due sono meglio, se il provider li offre e puntano a sistemi diversi. Aggiungerne cinque tutti verso la stessa macchina non serve a niente: la ridondanza sta nell'infrastruttura, non nel numero di righe nel DNS.

Il record MX ha effetto sul recapito di quello che spedisco?

Indirettamente. Alcuni destinatari guardano se il dominio del mittente è in grado di ricevere una risposta: un dominio che spedisce e non riceve nulla è un segnale debolmente negativo. Il peso è piccolo rispetto a SPF, DKIM e DMARC.

Quanti domini «parcheggiati» ha un'azienda tipo?

Più di quanti pensi. Tra varianti di scrittura, vecchi nomi di prodotto e domini comprati per campagne, un'azienda di medie dimensioni ne ha spesso dieci o venti. Metterli in sicurezza è un lavoro di un pomeriggio e toglie di mezzo l'intera categoria.