Defaults.Exposed › Correzioni › DNS inverso (PTR)

Come correggere DNS inverso (PTR)

Il DNS inverso è il tesserino di riconoscimento del server che invia le email della tua azienda. Quando un provider ricevente come Gmail o Microsoft 365 cerca chi c'è dietro l'indirizzo mittente e ottiene un nome che torna, la tua posta sembra legittima. Quando non c'è tesserino — o il nome e il numero non concordano — le tue fatture e i tuoi preventivi perfettamente reali vengono trattati con sospetto e cestinati o rifiutati in silenzio.

In sintesi per la tua attività: Le tue fatture, i tuoi preventivi e le tue risposte ai clienti finiscono in silenzio nello spam o non arrivano affatto — così le trattative si bloccano, i pagamenti arrivano in ritardo, e i clienti pensano che li abbia ignorati, nulla di tutto ciò comparendo come un errore che noteresti.

Cosa può costarti

• Invii un preventivo a un cliente caldo, finisce nel suo spam, e lui sceglie il concorrente che «ha davvero risposto» — e non hai mai nemmeno saputo che l'email non era arrivata.
• Le fatture ai clienti svaniscono nello spam, i pagamenti arrivano con settimane di ritardo, e il tuo flusso di cassa ci rimette perché nessuno ha mai visto l'email.
• Un cliente si lamenta che non gli hai mai risposto — ma l'hai fatto; il suo provider di posta ha cestinato in silenzio la tua risposta perché il tuo server mittente non riusciva a dimostrare chi fosse.
• Il tuo dominio supera senza problemi la revisione di sicurezza di un nuovo cliente su tutto il resto, poi viene segnalato perché il tuo server di posta non ha un'identità adeguata — una piccola cosa che ti fa sembrare sbadato.
• Sei passato a un VPS economico o a una nuova app per inviare newsletter e fatture, e da un giorno all'altro il tuo tasso di recapito crolla — perché quel nuovo server mittente non ha un tesserino di DNS inverso e i grandi provider non si fidano più di lui.

Perché è importante. Ogni grande provider di posta controlla l'identità del server che invia la tua posta, e la controlla su ogni messaggio. Se quel server non riesce a dimostrare chi è — o se il suo nome e il suo numero si contraddicono — le tue email aziendali autentiche vengono trattate come potenziale spam. Perdi risposte, pagamenti e fiducia, e poiché nulla rimbalza, di solito non scopri mai il perché.

In breve

Quando la tua azienda invia un’email, questa parte da un server di posta, e ogni server su internet ha un indirizzo numerico — il suo IP. Il DNS inverso (un record «PTR») è il tesserino di riconoscimento di quel server: permette a chiunque veda il numero di risalire al nome proprio che c’è dietro, come mail.tuaazienda.com.

I grandi provider riceventi — Gmail, Microsoft 365, Yahoo — controllano quel tesserino su ogni messaggio che invii. Un server che sa dichiarare il proprio nome, e dove nome e numero concordano tra loro, sembra un server di posta legittimo. Un server senza tesserino, o con un tesserino che non corrisponde, sembra esattamente le macchine anonime e usa-e-getta che usano gli spammer. Così le tue fatture e i tuoi preventivi autentici iniziano ogni conversazione sotto sospetto — e molti di loro perdono.

La parte frustrante è che nulla ti avverte che sta succedendo. Nessun rimbalzo, nessun errore. La tua email semplicemente rende meno del dovuto, in silenzio.

Quanto può costarti

Questi sono i modi quotidiani in cui un record di DNS inverso mancante o discordante si traduce in soldi e fiducia che escono dalla porta. Non nominiamo mai un’azienda reale — sono schemi che vediamo nei dati.

• Il preventivo che non è mai arrivato. Invii via email un preventivo dettagliato a un potenziale cliente che lo aveva chiesto quella mattina. Il suo provider non riesce a verificare il tuo server mittente, quindi lascia cadere il messaggio nello spam. Lui non scava nel cestino. Nel pomeriggio ha preso il preventivo del concorrente — quello che «si è davvero presentato». Lo metti giù come un contatto lento; in realtà la tua email non è mai stata vista.
• La fattura nel vuoto. Fatturi a un buon cliente. Finisce nella sua cartella indesiderata. Trenta giorni dopo stai sollecitando un pagamento scaduto senza alcuna sua colpa — e ora c’è una conversazione imbarazzante, un rapporto teso, e un buco di cassa del tutto evitabile.
• «Non hai mai risposto». Un cliente è seccato perché hai ignorato la sua domanda. Non l’hai fatto — hai risposto lo stesso giorno. Il suo provider di posta ha cestinato in silenzio la tua risposta perché il tuo server mittente sembrava inaffidabile. Sembri poco professionale per qualcosa che in realtà hai fatto bene.
• Il server di invio fai-da-te che ha avvelenato tutto in silenzio. Per risparmiare, la tua posta (o solo le tue newsletter e le fatture automatiche) ha iniziato a uscire tramite un VPS economico o una nuova app di invio. Quel server non ha mai avuto un tesserino di DNS inverso. Da un giorno all’altro, il tuo tasso di recapito è calato su tutta la linea — e poiché non c’è alcun messaggio di errore, ci sono voluti mesi anche solo per sospettarne la causa.
• La segnalazione nella revisione di sicurezza. L’ufficio IT di un cliente più grande fa un controllo di routine sul tuo dominio durante l’onboarding. Tutto il resto va bene, ma il tuo server di posta non ha un’identità adeguata. È un punto tecnico minore, ma sembra sbadataggine — e ora lo stai sistemando sotto pressione di scadenza, o lo stai giustificando, mentre il dominio di un concorrente è appena passato senza intoppi.

Il filo conduttore di tutto questo: il costo ricade su di te, è invisibile mentre accade, e la correzione è gratuita.

Cos’è davvero

Il normale DNS trasforma un nome in un numero: digiti tuaazienda.com, e il DNS restituisce l’indirizzo IP a cui connettersi. Il DNS inverso fa l’opposto — trasforma un numero di nuovo in un nome. Dato l’IP 203.0.113.10, una ricerca inversa (un «record PTR») risponde mail.tuaazienda.com.

Perché ai riceventi importa: quando il tuo server di posta si connette a Gmail per recapitare un messaggio, Gmail vede l’IP che si connette. La prima cosa che fa un filtro di posta serio è chiedersi «chi è questa macchina?» — facendo una ricerca inversa su quell’IP. Un vero server di posta aziendale ha una risposta (mail.tuaazienda.com). Una macchina spam usa-e-getta di solito no, o ha un nome generico assegnato dal provider come host-203-0-113-10.qualcheisp.net. Quindi la presenza e la qualità del tesserino sono uno dei primissimi segnali di fiducia applicati alla tua posta — prima ancora che SPF, DKIM o il contenuto del messaggio vengano nemmeno guardati.

Controlla il server di posta, non il tuo sito. È un punto che inganna le persone. L’indirizzo del tuo sito è spesso dietro una CDN o un proxy (come Cloudflare) e non avrà mai un tesserino corrispondente — e va bene così, perché il DNS inverso per le email riguarda l’IP del server di posta MX, una macchina del tutto separata. Questo controllo cerca correttamente il server di posta principale del tuo dominio (il record MX con priorità più bassa), lo risolve al suo IP, e controlla il tesserino su *quell’*IP.

La metà che la maggior parte delle configurazioni sbaglia: deve corrispondere in entrambe le direzioni. Avere un nome non basta di per sé. Gmail e gli altri grandi filtri fanno qualcosa di più rigoroso, chiamato DNS inverso confermato in avanti (FCrDNS):

1. Cerca l’IP → ottieni un nome (es. mail.tuaazienda.com).
2. Ora cerca all’indietro quel nome → deve risolversi allo stesso IP da cui sei partito.

Se le due direzioni concordano, il server è confermato e pienamente affidabile. Se c’è un nome ma punta altrove (o nel vuoto), il server è affidabile solo a metà — un tesserino che non regge a un secondo sguardo viene trattato come più debole di quanto vorresti. Un PTR che punta a un hostname controllato da un attaccante, e che non si risolve all’indietro, è per certi versi peggio di nessun PTR.

È esattamente così che questo controllo lo valuta:

• Confermato in avanti (FCrDNS): l’IP nomina un host, e quell’host punta di nuovo allo stesso IP. Punteggio pieno — questa è la configurazione corretta, ed è ciò di cui i riceventi si fidano.
• Il tesserino esiste ma non conferma: c’è un record PTR, ma il nome non si risolve di nuovo all’IP del server di posta. Solo credito parziale — sembra configurato ma i grandi filtri non si fideranno del tutto.
• Nessun tesserino: nessun record PTR sull’IP del server di posta. Nessun credito, e il costo in recapitabilità è reale.

Una nota sul peso: nella metodologia questo è un controllo di sicurezza email a punteggio (del valore di 25 punti, un elemento di priorità P2). Non è il singolo controllo email più pesante — quelli sono SPF e DMARC, che fermano l’impersonificazione diretta — ma è una parte autentica e valutata della tua reputazione email, e una delle poche che dipende dal fatto che il tuo provider faccia qualcosa di giusto invece che tu. Se invii solo tramite Google Workspace o Microsoft 365, quasi certamente lo superi già; le aziende che falliscono sono quelle che inviano tramite il proprio server o un server di terze parti.

Com’è fatto un «buono»: l’IP del tuo server di posta principale ha un record PTR che punta a un hostname reale di tua proprietà, e quell’hostname si risolve dritto di nuovo allo stesso IP — le due direzioni concordano (FCrDNS confermato).

Come sistemarlo (gratis, ~10 minuti del tempo di qualcuno)

Passa questa sezione a chi possiede l’indirizzo IP del tuo server di posta — di solito il tuo provider di posta o di hosting, o il tuo data center per una macchina auto-ospitata — e nota che la correzione è gratuita. Questa è l’unica impostazione email che quasi certamente non puoi cambiare da solo nel tuo normale pannello DNS, perché il DNS inverso è controllato da chi possiede l’IP, non da chi possiede il dominio. Facciamo pagare solo il monitoraggio nel tempo, perché resti corretto, mai la modifica.

Passo 1 — Trova l’IP del server di posta mittente. Identifica l’host MX principale del dominio (il server di posta con il numero di priorità più basso) e risolvilo al suo indirizzo IP:

dig MX tuaazienda.com        # trova l'host MX principale (priorità più bassa)
dig A mail.tuaazienda.com    # risolvi quell'host al suo IP

Quell’IP è quello che ha bisogno del tesserino. Non usare l’IP del sito — è una macchina diversa, spesso dietro una CDN che non corrisponderà mai.

Passo 2 — Chiedi al proprietario dell’IP di impostare il record PTR. Il DNS inverso risiede presso chi controlla il blocco di IP, quindi la richiesta va a:

• Google Workspace / Gmail: gestito automaticamente per i server di posta di Google — se un dominio che invia solo tramite Google risultasse in qualche modo fallito, segnalalo al supporto Google. (In pratica questi superano il controllo.)
• Microsoft 365: analogamente gestito automaticamente per i server di Microsoft.
• Un server di posta auto-ospitato o su VPS: apri un ticket con il tuo provider di hosting o data center chiedendo di impostare il PTR (DNS inverso) per il tuo IP sull’hostname del tuo server di posta. La maggior parte dei provider lo espone nel pannello di controllo sotto «Reverse DNS», «rDNS» o «PTR». Sui grandi cloud è un’impostazione di un solo campo (es. AWS richiede un breve modulo di richiesta per abilitare l’rDNS su un Elastic IP; la maggior parte degli host VPS permette di impostarlo all’istante).
• Un’app di invio di terze parti (strumento di newsletter / fatturazione / CRM): se invia dai propri server condivisi, il provider gestisce il DNS inverso — non c’è nulla da impostare per te, e puoi ignorare questo per quel traffico. Se invia da un IP dedicato che hai acquistato da loro, chiedi loro di impostarci il PTR.

Indica loro il record che vuoi, per esempio: 203.0.113.10 → mail.tuaazienda.com.

Passo 3 — Fai sì che confermi in avanti (è il passo che la maggior parte delle persone si lascia sfuggire). L’hostname nel PTR deve anche risolversi di nuovo allo stesso IP tramite un normale record A che controlli nel tuo DNS. Quindi:

• Il PTR dice 203.0.113.10 → mail.tuaazienda.com (lo imposta il tuo provider).
• Il record A dice mail.tuaazienda.com → 203.0.113.10 (lo imposti tu nel tuo DNS, es. Cloudflare → DNS → aggiungi un record A, Nome mail, contenuto 203.0.113.10).

Entrambe le direzioni devono puntare l’una all’altra. Solo allora è confermato in avanti e pienamente affidabile.

Passo 4 — Ricontrolla il tuo dominio. Conferma che il server di posta mostri ora un DNS inverso confermato in avanti e che il controllo venga superato. Le modifiche DNS si propagano entro pochi minuti o qualche ora.

Errori comuni

• Impostare il tesserino sull’IP del sito invece che del server di posta. Il DNS inverso per le email riguarda il server MX. Mettere un PTR sull’indirizzo del tuo sito web/CDN non fa nulla per la recapitabilità — il tesserino va alla macchina sbagliata.
• Fermarsi a «il PTR esiste». Un nome di per sé vale solo fiducia parziale. Se non si risolve di nuovo allo stesso IP, i filtri rigorosi (Gmail, M365, Yahoo) non si fideranno del tutto. Completa sempre la conferma in avanti (Passo 3).
• Dimenticare il record A dopo che il provider imposta il PTR. Il provider imposta la metà inversa; tu devi impostare la metà in avanti nel tuo DNS. Le persone ne fanno una e danno per scontato di aver finito.
• Chiedere alla parte sbagliata. Inviare la richiesta al tuo registrar o host DNS invece che al proprietario dell’IP ti fa ottenere un «non possiamo farlo» — perché davvero non possono. Deve andare a chi possiede l’IP.
• Hostname generici del provider. Un PTR come host-203-0-113-10.qualcheisp.net tecnicamente esiste ma non fa nulla per il tuo marchio o la tua fiducia. Usa un hostname reale sul tuo dominio che confermi in avanti.

Dove si colloca

Il DNS inverso è l’identità del server; SPF, DKIM e DMARC sono lo strato di autorizzazione e anti-impersonificazione del dominio. Rispondono a domande diverse, e i grandi provider li controllano tutti. L’SPF elenca quali servizi possono inviare a tuo nome; il DKIM firma crittograficamente i tuoi messaggi così non possono essere manomessi; il DMARC lega i due insieme e dice ai riceventi cosa fare con la posta che fallisce — e protegge il nome del mittente visibile che i tuoi clienti vedono davvero. Il DNS inverso sta sotto tutto questo, garantendo che la macchina che sta inviando sia, prima di tutto, un server di posta reale e con un nome. Sistema bene SPF, DKIM e DMARC per la difesa più forte dall’impersonificazione; sistema bene il DNS inverso così un server mittente nuovo o auto-ospitato non venga messo in dubbio in silenzio prima ancora che il resto abbia una chance. Ognuna di queste correzioni è gratuita.

FAQ