Record PTR e Reverse DNS: perché una configurazione errata può bloccare l’invio delle email
Può capitare che un server SMTP funzioni correttamente, riesca ad avviare la connessione verso l’MX destinatario, ma alcune email vengano comunque respinte.
In questi casi una delle verifiche da effettuare riguarda il Reverse DNS dell’indirizzo IP del server SMTP e, in particolare, la presenza e la corretta configurazione del record PTR.
Non si tratta di un controllo secondario. Gmail richiede che gli indirizzi IP utilizzati per l’invio abbiamo reverse validi e coerenti (ovvero che il record A del nome del server coincida con il record PRT), mentre Yahoo raccomanda esplicitamente record PTR validi, specifici e non generici (mail.example.com e non ip-192-0-2-10.dynamic.net) per gli IP dei server di posta. Anche altri sistemi antispam utilizzano il Reverse DNS tra i fattori analizzati durante la connessione SMTP.
Questo non significa che un’email rifiutata abbia necessariamente un problema di PTR, ma sicuramente non averlo confiturato correttamente (rDNS → hostname → IP rDNS) è un problema da risolvere.
Cos’è il Reverse DNS e a cosa serve il record PTR
Nella normale risoluzione DNS, un hostname viene associato al relativo indirizzo IP, ad esempio:
mail.example.com → 192.0.2.10
Il Reverse DNS, detto anche rDNS, permette di effettuare il controllo inverso, partendo dall’indirizzo IP per risalire all’hostname associato. Questa associazione viene definita attraverso un record PTR.
Nel contesto della posta elettronica, il server destinatario può quindi utilizzare il Reverse DNS per verificare quale hostname è associato all’indirizzo IP del server che sta tentando di consegnare il messaggio.
Qboxmail aveva già affrontato questo aspetto nella propria guida dedicata alla configurazione del Reverse DNS, evidenziando che il nome associato all’rDNS dovrebbe identificare correttamente l’hostname del mail server.
rDNS e hostname devono essere coerenti nel DNS
La presenza del record PTR, da sola, non garantisce che la configurazione sia corretta.
Se, ad esempio, il server invia dall’indirizzo:
192.0.2.10
e il Reverse DNS restituisce:
192.0.2.10 → mail.example.com
anche la risoluzione DNS dell’hostname dovrebbe riportare allo stesso indirizzo IP:
mail.example.com → 192.0.2.10
Se invece mail.example.com risolvesse verso un indirizzo IP differente, si avrebbe un’incongruenza tra Reverse DNS e risoluzione DNS diretta.
La configurazione può quindi essere letta come una catena:
IP di invio → PTR → hostname → A/AAAA → IP di invio
In una configurazione coerente, il percorso forma una sorta di circuito chiuso: partendo dall’indirizzo IP si risale all’hostname tramite il record PTR e, risolvendo nuovamente quell’hostname, si ritorna allo stesso indirizzo IP.
Perché il Reverse DNS è importante per l’invio delle email
Quando riceve una connessione SMTP, un mail server può analizzare diversi segnali prima di decidere se accettare il messaggio.
Il Reverse DNS è uno di questi.
Un IP privo di PTR, un hostname che non risolve correttamente oppure una configurazione incoerente possono indicare che l’infrastruttura di invio non è stata configurata correttamente.
Questo aspetto non deve però essere confuso con l’autenticazione del dominio.
rDNS, SPF, DKIM e DMARC svolgono funzioni differenti
SPF permette di dichiarare quali indirizzi IP sono autorizzati a inviare per conto di un dominio; DKIM applica una firma crittografica al messaggio; DMARC mette in relazione questi meccanismi con il dominio presente nel campo From e consente di definire una politica per i messaggi che non rispettano i controlli.
Puoi approfondire il funzionamento combinato di questi protocolli nella nostra pagina dedicata a SPF, DKIM e DMARC.
Un dominio può quindi superare SPF e DKIM e utilizzare comunque un server con Reverse DNS configurato male. Allo stesso modo, un PTR corretto non sostituisce SPF, DKIM o DMARC.
L’assenza del Reverse DNS è sempre sufficiente per bloccare un’email?
L’assenza di un Reverse DNS corretto può rappresentare un elemento negativo, ma non dovrebbe essere valutata da sola. Nella gestione del proprio sistema antispam, Qboxmail ha osservato casi in cui email legittime venivano penalizzate proprio per l’assenza del Reverse DNS, pur non risultando presenti nelle principali DNSBL. Ad esempio molte stampanti, impianti di allarme, ascensori, sistemi di telemetria, inviano email da indirizzi IP collegati a connettività aziendali con IP statici o dinamici ma hostname generici.
Questa esperienza ci portato a rivedere il peso attribuito a questo singolo controllo, proprio per ridurre il rischio di falsi positivi. Un caso approfondito nell’articolo dedicato a come ridurre i falsi positivi nei sistemi antispam.
L’esperienza mostra quindi perché il Reverse DNS debba essere valutato insieme agli altri segnali utilizzati durante la consegna.
I sistemi di posta possono prendere in considerazione configurazione dell’infrastruttura, autenticazione, reputazione dell’IP, reputazione del dominio, comportamento del mittente e altri segnali.
Come capire se il problema riguarda davvero PTR e Reverse DNS
Quando un’email non viene consegnata, il primo controllo dovrebbe riguardare il log della transazione SMTP.
La risposta del server destinatario può contenere informazioni determinanti per capire perché il messaggio non è stato accettato:
codice SMTP → enhanced status code → descrizione dell'errore
Leggere l’intera risposta permette di distinguere un problema di Reverse DNS da un errore di autenticazione, una limitazione temporanea oppure un problema di reputazione.
Per i clienti Qboxmail, la funzionalità Tracemail permette di analizzare i log dei messaggi e, nel caso di Email Delivery, verificare se un messaggio è stato consegnato oppure individuare le motivazioni della mancata consegna. I bounce vengono inoltre classificati per facilitare l’identificazione dei problemi di deliverability.
Un esempio concreto: l’errore Gmail 451 4.7.23
Un caso particolarmente utile per capire come leggere un log è quello di Gmail.
Google documenta il codice:
451 4.7.23
per situazioni nelle quali l’indirizzo IP utilizzato per inviare presenta problemi con il record PTR o con la corrispondenza tra Reverse DNS e Forward DNS.
La parte importante, però, non è soltanto il numero 451.
Il codice SMTP 451 indica infatti una condizione temporanea, ma può essere associato a problemi differenti.
Per identificare la causa è necessario leggere anche:
- l’enhanced status code
- il testo completo restituito dal server
- eventuali riferimenti all’IP, al DNS o alla reputazione
Come controllare se PTR e Reverse DNS sono configurati correttamente
Se il messaggio restituito dal destinatario indica effettivamente un problema di Reverse DNS, puoi procedere con una verifica strutturata.
- Individua l’IP che sta realmente inviando l’email
Il primo passaggio consiste nell’identificare l’indirizzo IP pubblico dal quale viene effettuata la connessione SMTP.
Non bisogna dare per scontato che coincida con l’IP del sito web o del dominio: un’applicazione può utilizzare un server SMTP o un servizio di Email Delivery completamente separato dall’hosting del sito. - Verifica il record PTR dell’IP
Effettua una Reverse DNS lookup sull’indirizzo IP.
Il risultato dovrebbe restituire un hostname valido, ad esempio:192.0.2.10 → mail.example.com
Se non viene restituito alcun hostname, il record PTR potrebbe non essere configurato. - Controlla il Forward DNS dell’hostname
Ora esegui il controllo inverso sull’hostname ottenuto:mail.example.com → 192.0.2.10
La configurazione risulta coerente quando l’hostname indicato dal PTR riconduce all’indirizzo IP utilizzato dal server per l’invio. - Verifica HELO/EHLO
Durante una sessione SMTP, il server mittente si identifica attraverso il comando HELO o EHLO.
Anche il nome utilizzato in questa fase deve essere coerente con la configurazione del mail server.
Approfondisci il rapporto fra HELO e configurazione DNS/SPF. - Controlla nuovamente i log
Dopo aver corretto l’eventuale incongruenza, controlla le successive risposte SMTP per verificare se il problema è stato effettivamente risolto.
È proprio questa sequenza a evitare uno degli errori più frequenti nel troubleshooting della posta: modificare più parametri contemporaneamente senza sapere quale stava realmente causando il rifiuto.
Il PTR è corretto ma le email vengono ancora rifiutate?
Un Reverse DNS corretto è un requisito tecnico importante, ma non garantisce da solo che un messaggio venga accettato o raggiunga la posta in arrivo.
Se PTR, Forward DNS e HELO/EHLO sono coerenti, bisogna tornare alla risposta SMTP e verificare le altre possibili cause.
A seconda dell’errore, può essere necessario controllare:
- SPF, DKIM e DMARC
- reputazione dell’IP
- reputazione del dominio
- volumi e pattern di invio
- bounce e segnalazioni di spam
- policy specifiche del provider destinatario
- eventuale presenza dell’IP in una DNSBL
In particolare, è importante distinguere la reputazione dell’indirizzo IP dalla configurazione del Reverse DNS. Un IP può avere un PTR perfettamente configurato e presentare comunque problemi reputazionali.
Per le verifiche relative ai record del dominio, Qboxmail mette inoltre a disposizione una Toolbox dedicata ai controlli DNS, con strumenti per verificare MX, SPF, DMARC e blocklist dell’IP.
Reverse DNS o reputazione IP? La risposta SMTP indica dove cercare
Il Reverse DNS è quindi uno dei controlli da effettuare quando un server destinatario rifiuta o limita un messaggio, ma deve essere interpretato insieme alla risposta SMTP.
Se l’errore riguarda PTR o rDNS, verifica la catena:
IP → PTR → hostname → Forward DNS → HELO/EHLO
Se invece la risposta fa riferimento alla reputazione dell’IP o alla sua presenza in una lista di blocco, il troubleshooting deve spostarsi sulle blocklist e sulla reputazione dell’indirizzo IP.