Come configurare un record PTR per un server di posta

Gmail, Yahooe Microsoft controllano tutti i record PTR sulla posta in arrivo e rifiutano o spostano nella cartella spam i messaggi provenienti da server senza DNS inverso valido. A differenza SPF, DKIM o DMARCUn record PTR non è qualcosa che puoi aggiungere alla tua zona DNS. Deve essere configurato da chiunque possieda l'indirizzo IP utilizzato dal tuo server di posta per l'invio.

Spesso, dopo aver configurato completamente il resto dello stack di autenticazione, mancano i record PTR. La maggior parte dei mittenti configura tutto ciò che controlla direttamente, ma continua a riscontrare problemi di recapito perché l'indirizzo IP di invio non punta a un hostname attendibile.

Configurare un record PTR significa individuare l'indirizzo IP di invio, confermare chi lo controlla, scegliere il nome host corretto, inviare la richiesta al proprietario dell'indirizzo IP e verificare che il DNS inverso funzioni correttamente dopo la modifica.

Come configurare un record PTR per un server di posta: 5 passaggi

La configurazione del PTR segue gli stessi cinque passaggi fondamentali con qualsiasi provider di hosting. L'unica parte che cambia è la modalità di invio della richiesta PTR.

L'intero processo richiede in genere da 1 a 5 giorni lavorativi. I primi tre passaggi richiedono solo pochi minuti. Il provider si occupa dell'aggiornamento del PTR, e il passaggio finale consiste nel verificare che il DNS inverso funzioni correttamente.

Passaggio 1: Trova l'indirizzo IP pubblico del tuo server di posta

Identifica l'indirizzo IP pubblico che il tuo server di posta utilizza per le connessioni SMTP in uscita. Questo è l'indirizzo IP effettivamente visualizzato dai server di posta riceventi, non un eventuale indirizzo IP interno o privato utilizzato dal tuo server.

Esegui il comando `curl ifconfig.me` dalla riga di comando del server di posta oppure controlla il pannello delle impostazioni di rete della tua piattaforma cloud. Per i servizi SMTP dedicati, l'indirizzo IP di invio di solito compare direttamente nella dashboard del provider.

Verifica che l'indirizzo IP sia statico. I record PTR richiedono indirizzi IP statici; sono inutili se l'indirizzo IP sottostante cambia periodicamente. Le piattaforme cloud in genere assegnano indirizzi IP statici per impostazione predefinita ai server di posta, ma verifica questa impostazione prima di procedere al passaggio successivo.

Passaggio 2: Identifica il proprietario del tuo blocco IP

Cerca l'IP usando Strumento di DNS inverso di MXToolbox oppure eseguendo una query WHOIS su ARIN, RIPE o APNIC, a seconda della regione. Il risultato identifica l'organizzazione che controlla il blocco IP, solitamente il provider di servizi cloud, la società di hosting o l'ISP.

Non è possibile bypassare il proprietario dell'indirizzo IP. Quest'ultimo controlla la zona DNS inversa in cui risiede il record PTR. Anche se gestisci il DNS per il tuo dominio, non controlli il DNS inverso per gli indirizzi IP di cui non sei proprietario.

Passaggio 3: Scegliere un nome host e aggiungere un record A corrispondente

Scegli un nome host che identifichi chiaramente il ruolo e il dominio del server di posta, ad esempio mail.yourcompany.com o smtp.yourcompany.com funzionano bene. Evita i nomi host generici forniti dal provider di servizi Internet, come host-203-0-113-25.example-isp.com, che risultano sospetti ai server di posta riceventi anche se tecnicamente funzionanti.

Nel DNS del tuo dominio, crea un record A che punti questo hostname all'indirizzo IP pubblico del tuo server di posta. Questo record A deve esistere prima di inviare la richiesta PTR; il DNS inverso con conferma diretta (FCrDNS) richiede che le ricerche dirette e inverse corrispondano.

Attendi fino a 24 ore affinché il record A si propaghi prima di inviare la richiesta PTR. La maggior parte dei resolver DNS si aggiorna entro poche ore, ma attendere l'intero intervallo di tempo evita discrepanze durante il processo di verifica del proprietario IP.

Passaggio 4: Configura il PTR tramite il proprietario IP

Il percorso esatto dipende interamente dal provider. Le piattaforme cloud, come AWS, Azure e GCP, e i provider di VPS dedicati in genere offrono la configurazione self-service del PTR direttamente nelle loro console. L'hosting condiviso tradizionale e gli ISP, invece, di solito richiedono l'apertura di un ticket di supporto.

Quando invii una richiesta, includi tre informazioni: l'indirizzo IP, il nome host desiderato e la prova che tu controlli il dominio (il record A corrispondente del passaggio 3 funge da prova). La maggior parte dei provider risponde entro 1-3 giorni lavorativi. Consulta la sezione specifica del provider qui sotto per i percorsi di navigazione esatti.

Passaggio 5: Verifica con FCrDNS

Una volta che il proprietario dell'IP conferma che il PTR è impostato, verificalo con due comandi. Innanzitutto, esegui `dig -x 203.0.113.25 @8.8.8.8` (sostituendo il tuo IP effettivo) per confermare che la ricerca inversa restituisca il nome host scelto. Quindi esegui `dig mail.yourcompany.com @8.8.8.8` (sostituendo il tuo nome host) per confermare che la ricerca A diretta restituisca lo stesso IP.

Entrambe le query devono restituire risultati corrispondenti. Questa corrispondenza diretta e inversa è FCrDNS, il controllo standard eseguito dai server di posta in ricezione. Un record PTR che restituisce un nome host il cui record A non punta all'indirizzo IP originale non supera il controllo FCrDNS e viene considerato non valido, anche se tecnicamente esiste un record PTR.

Attendere fino a 24 ore per la completa propagazione del DNS prima di presumere che il nuovo PTR sia visibile in modo affidabile da tutte le reti.

Configurazione del record PTR da parte del provider di hosting

La procedura di configurazione esatta varia significativamente a seconda della piattaforma di hosting. Le piattaforme cloud generalmente offrono la configurazione PTR self-service tramite le loro console o API, mentre l'hosting condiviso tradizionale richiede l'apertura di un ticket di supporto. Le informazioni necessarie sono identiche in entrambi i casi: indirizzo IP, nome host e prova di proprietà del dominio.

AWS EC2 e SES

AWS richiede una richiesta di supporto anziché la configurazione self-service. Apri il Centro assistenza nella console AWS, scegli "Servizio: SES" o "Servizio: EC2" a seconda dell'origine del traffico in invio e invia una richiesta DNS inversa. Includi l'indirizzo IP elastico e il nome host desiderato. L'elaborazione richiede in genere 24-48 ore. Documentazione relativa al DNS inverso SES di AWS descrive in dettaglio l'intero flusso di lavoro della richiesta.

Microsoft Azure

Azure supporta la configurazione del PTR sia tramite il portale che tramite PowerShell. Nel portale, accedere alla risorsa IP pubblico e individuare direttamente il campo DNS inverso. Tramite PowerShell, utilizzare il comando Set-AzPublicIpAddress con il parametro ReverseFqdn. La documentazione di Microsoft sul DNS inverso di Azure illustra la sintassi esatta per entrambi i metodi.

Google Cloud Platform (GCP)

Nella console GCP, vai su Rete VPC → Indirizzi IP esterni. Fai clic sul menu con i tre puntini accanto all'indirizzo IP pertinente e scegli DNS inverso. Inserisci il nome host e salva. GCP verifica che il record A del nome host punti all'indirizzo IP prima di attivare il PTR, il che significa che il passaggio 3 sopra descritto deve essere completato affinché questo passaggio abbia esito positivo.

Hetzner, Linode e DigitalOcean

Tutti e tre i provider di VPS dedicati offrono la configurazione self-service del PTR direttamente tramite i loro pannelli di controllo. In Hetzner Robot o Cloud, trova l'indirizzo IP nella sezione Server, fai clic sull'icona della matita accanto a rDNS e inserisci il nome host. In Linode Cloud Manager, apri la scheda Rete di Linode. In DigitalOcean, configura il PTR nella sezione Rete delle impostazioni del Droplet.

Hosting condiviso e cPanel

I tradizionali provider di hosting condiviso, come Bluehost, HostGator, GoDaddy e la maggior parte dei provider basati su cPanel, in genere non offrono la configurazione self-service del record PTR. Apri un ticket di supporto richiedendo un record PTR per il tuo indirizzo IP, che punti al nome host del tuo server di posta, e fornisci la prova di proprietà del dominio tramite il record A corrispondente.

Alcuni provider di hosting condiviso non consentono la personalizzazione del PTR, indipendentemente da come viene formulata la richiesta. Se il tuo provider non lo permette, l'unica soluzione è migrare a un provider che lo offra. Questo di solito significa optare per un VPS dedicato, una piattaforma cloud o un servizio di posta elettronica transazionale con supporto PTR incluso.

Servizi di posta elettronica ospitati (Google Workspace, Microsoft 365)

I servizi di posta elettronica ospitati gestiscono i record PTR sulla propria infrastruttura condivisa. I mittenti che utilizzano Google Workspace o Microsoft 365 non devono configurare autonomamente i record PTR, poiché il fornitore del servizio se ne occupa per gli indirizzi IP di sua proprietà e sotto il suo controllo.

Questo vale solo quando si invia tramite i server in uscita del servizio stesso. Se si instrada la posta tramite un server SMTP di terze parti mentre si utilizza Google Workspace o Microsoft 365 per altri scopi, i requisiti PTR si applicano all'indirizzo IP di tale server di terze parti, non all'infrastruttura di Google o Microsoft.

Come verificare che il tuo record PTR funzioni

La verifica conferma due cose distinte: che il PTR sia configurato correttamente e che FCrDNS si risolva senza problemi. Saltare questo passaggio è la ragione più comune per cui i team credono che un PTR sia impostato quando in realtà non funziona correttamente.

• Verifica da riga di comando: Esegui il comando `dig -x [il tuo IP] @8.8.8.8` per verificare che la ricerca inversa restituisca il nome host scelto. Esegui nuovamente il comando `dig [il tuo nome host] @8.8.8.8` per verificare che la ricerca diretta restituisca il tuo IP. Entrambi i risultati devono corrispondere; questo è il controllo FCrDNS effettivamente eseguito dai server di posta riceventi.
• Strumenti di verifica online: La ricerca DNS inversa di MXToolbox accetta un indirizzo IP e restituisce il nome host PTR insieme a un indicatore di successo/fallimento. Questo è utile per una conferma non tecnica e per includerlo nei ticket di supporto quando si collabora con il proprietario dell'indirizzo IP per risolvere un problema.
• Verifica lato server: Eseguire il comando `hostname -f` direttamente sul server di posta per verificare che il nome host configurato sul server corrisponda a quello restituito dal PTR. Se differiscono, il comando HELO/EHLO del server di posta invia un nome diverso da quello a cui si risolve il PTR e la maggior parte dei server riceventi considera tale discrepanza come un errore temporaneo, anche quando il PTR stesso è tecnicamente valido.

Problemi comuni relativi ai record PTR e come risolverli

Questi quattro problemi sono la causa principale dei problemi di recapito relativi ai PTR. Nella maggior parte dei casi, risolverli significa contattare il proprietario dell'IP.

Record PTR completamente mancante

Diagnosticare: L'esecuzione del comando dig -x [il tuo IP] @8.8.8.8 non restituisce alcun risultato PTR oppure restituisce NXDOMAIN.

Fix: Contatta il proprietario dell'indirizzo IP e richiedi un record PTR che punti al nome host del server di posta che hai scelto. Fornisci la prova di proprietà del dominio e il record A corrispondente del DNS del tuo dominio come documentazione a supporto.

Il nome host PTR non corrisponde al record A (errore FCrDNS)

Diagnosticare: La ricerca inversa restituisce un nome host, ma la ricerca diretta di tale nome host restituisce un indirizzo IP diverso, oppure nessun indirizzo IP. Questo è il classico schema di errore di FCrDNS.

Fix: È necessario aggiornare il record A in modo che punti all'indirizzo IP di invio effettivo, oppure richiedere al proprietario dell'indirizzo IP di aggiornare il record PTR in modo che corrisponda a un record A esistente. Entrambi i record devono essere risolvibili l'uno nell'altro affinché FCrDNS funzioni correttamente.

Nome host generico del provider di servizi Internet (ISP) anziché nome host personalizzato.

Diagnosticare: Il PTR restituisce un nome host come host-203-0-113-25.example-isp.com anziché un nome host personalizzato sotto il tuo dominio.

Fix: Richiedi al proprietario dell'indirizzo IP di aggiornare il PTR in modo che punti a un nome host sotto il tuo dominio (mail.yourcompany.com o smtp.yourcompany.com). I nomi host generici degli ISP non violano tecnicamente il test FCrDNS, ma appaiono sospetti ai server di ricezione e riducono i segnali di fiducia complessivi.

Record PTR IPv6 mancante

Diagnosticare: PTR funziona correttamente per il traffico IPv4, ma Gmail rifiuta la posta recapitata tramite IPv6 con errori del tipo "reverse DNS failed" o "sender identity mismatch".

Fix: Richiedi un record PTR separato specificamente per l'indirizzo IPv6. I record PTR IPv6 risiedono nella zona ip6.arpa con notazione nibble-reversed, il che significa che sono configurati in modo completamente separato dai record IPv4, anche quando entrambi servono lo stesso server di posta.

PTR Records gestito correttamente

La configurazione del PTR segue un processo universale in 5 fasi, ma il percorso di configurazione effettivo varia a seconda del provider. Le piattaforme cloud e gli host VPS dedicati offrono la configurazione self-service; l'hosting condiviso richiede l'apertura di un ticket di supporto; i servizi di posta elettronica gestiti gestiscono l'intero processo per conto dell'utente.

La verifica FCrDNS è il controllo più importante dopo il completamento della configurazione. La maggior parte dei problemi di recapito relativi al PTR deriva da una mancata corrispondenza tra il PTR e il record A corrispondente. Risolvendo tale mancata corrispondenza, i problemi di recapito correlati si risolvono in genere da soli.

Una solida reputazione di dominio e IP dipende dai record PTR che operano in sinergia con SPF, DKIM e DMARC. I record PTR confermano l'identità a livello di rete, ma non sostituiscono una corretta gestione delle liste di distribuzione. Per una deliverability affidabile, è necessario che siano presenti sia l'autenticazione che la qualità delle liste.

Se stai configurando un nuovo server di posta o riscaldamento di un nuovo dominio di invio, associare la configurazione PTR con Convalida dell'elenco e-mail prima del primo invio in produzione. L'autenticazione forte e una lista pulita, insieme, offrono a ogni messaggio le migliori possibilità di raggiungere la casella di posta in arrivo, e ciascuna risolve un problema che l'altra non può affrontare.