Smart. Concentrazione. Email.
Posta elettronica veloce e multipiattaforma progettata per filtrare i fastidi.
💡 Reverse DNS lookup: il processo di risoluzione di un indirizzo IP fino a un nome di dominio, l'opposto di come funziona normalmente il DNS. Per l'email, è il modo in cui i server riceventi verificano se un indirizzo IP di invio appartiene davvero al dominio che afferma di rappresentare. Il DNS normale va dal dominio all'IP. Il reverse DNS va dall'IP al dominio. Entrambe le direzioni devono corrispondere.
Probabilmente non direttamente, ma vale la pena sapere perché.
Se invii email tramite Gmail, Google Workspace, Outlook o Microsoft 365, il reverse DNS viene gestito automaticamente da Google e Microsoft sui loro IP di invio. Non devi toccarlo. Lo stesso vale per gli IP condivisi su piattaforme come Mailchimp o Klaviyo. Questi ESP gestiscono i record PTR per gli indirizzi IP da cui inviano i loro server.
Il reverse DNS diventa un tuo problema se invii da un indirizzo IP dedicato (tramite un servizio come SendGrid o Mailgun) o se gestisci un tuo server di posta su un VPS o un'istanza cloud. In queste situazioni, il record PTR per il tuo IP non viene impostato automaticamente. Devi configurarlo tu. E se manca o è configurato male, la deliverability delle tue email ne risente.
Il test pratico: se le tue email finiscono nello spam e i tuoi DKIM, SPF e record DMARC passano tutti, un record PTR mancante o rotto è la prossima cosa logica da controllare.
Il processo si chiama Forward-Confirmed reverse DNS (FCrDNS). Ecco cosa succede quando la tua email arriva a un server ricevente.
Il server ricevente prende il tuo indirizzo IP di invio e interroga il DNS per il record PTR (Pointer) a esso associato. Questa ricerca avviene in una zona DNS speciale chiamata in-addr.arpa. Se un record PTR è configurato, la ricerca restituisce un hostname, qualcosa come mail.yourbusiness.com.
Il server ricevente esegue poi una normale ricerca DNS diretta su quell'hostname per confermare che si risolva di nuovo all'IP originale. Se l'IP corrisponde, il controllo passa. Se l'hostname si risolve a un IP diverso, o se non c'è alcun record PTR, il mittente sembra poco affidabile.
Il punto è proprio questa verifica bidirezionale. Chiunque può affermare di inviare da yourbusiness.com. Molte meno persone possono manipolare sia il record PTR sia il DNS diretto per farli corrispondere. Da quando Google e Yahoo hanno inasprito i requisiti per i mittenti massivi nel 2024, Gmail ora restituisce un errore specifico (421 4.7.23) per gli IP senza un record PTR valido. Non è più opzionale per chiunque invii volumi significativi.
Un reverse DNS mancante o non corrispondente è uno dei problemi di deliverability più subdoli. Non produce sempre un bounce chiaro. Le tue email potrebbero semplicemente finire nello spam in silenzio, senza spiegazioni.
Prima di provare a sistemare qualcosa, controlla se esiste un record PTR e se è corretto.
MXToolbox: vai su mxtoolbox.com/ReverseLookup.aspx e inserisci l'indirizzo IP del tuo server di posta. Restituirà il record PTR o segnalerà se non ne esiste nessuno.
Riga di comando (Mac/Linux/Windows):
nslookup [your IP address]
Oppure su Mac/Linux:
dig -x [your IP address]
L'output dovrebbe mostrare un record PTR che punta all'hostname del tuo server di posta. Se non mostra nulla, o punta a qualcosa di generico come l'hostname predefinito di un provider cloud (ec2-203-0-113-25.compute-1.amazonaws.com), è un problema che vale la pena risolvere.
Ecco il dettaglio critico che la maggior parte delle persone sbaglia: i record PTR sono controllati da chi possiede l'indirizzo IP (il tuo provider di hosting o VPS, non il tuo registrar di dominio).
Non puoi impostare un record PTR su Cloudflare o GoDaddy. Lo imposti tramite DigitalOcean, Vultr, Hetzner, AWS, Linode, o ovunque risieda l'IP del tuo server di posta.
Processo generale (server di posta self-hosted):
Perché la tua configurazione superi l'FCrDNS, devi anche confermare che l'hostname del tuo server di posta abbia un record A che si risolve di nuovo allo stesso IP. Entrambe le direzioni devono funzionare.
Se sei su un IP dedicato tramite un ESP: SendGrid, Mailgun e servizi simili hanno i propri flussi di configurazione del reverse DNS all'interno delle loro dashboard. Per SendGrid, si trova in Settings > Sender Authentication > Reverse DNS. Consulta la guida al reverse DNS di SendGrid per la procedura completa. Generano i record e ti guidano nella loro pubblicazione.
Se sei su un IP condiviso tramite un ESP: il provider gestisce i record PTR per gli IP condivisi. Non devi configurare nulla.
Evita gli hostname cloud generici. Un PTR predefinito di un provider cloud segnala "istanza VPS generica" anziché "server di posta gestito". I server riceventi lo trattano come un campanello d'allarme. Sostituiscilo con un hostname personalizzato che corrisponde al tuo dominio.
Il PTR è un livello, non l'intero stack. Un PTR pulito aiuta a stabilire una legittimità di invio di base, ma funziona insieme a DKIM, SPF e DMARC, non al loro posto. Un PTR perfetto senza DKIM continua a fare fatica. Metti prima in atto tutti e tre i livelli di autenticazione; poi verifica il tuo PTR.
Ricontrolla dopo qualsiasi modifica all'infrastruttura. Se migri a un nuovo server, ottieni un nuovo IP o cambi provider di hosting, il tuo record PTR non ti segue automaticamente. Deve essere riconfigurato per il nuovo IP. Facile da dimenticare. Vale la pena controllarlo.
Un record PTR per IP, che punta al tuo hostname di invio. Il tuo record PTR dovrebbe risolversi allo stesso hostname che il tuo server SMTP annuncia nelle conversazioni SMTP (il comando HELO/EHLO). Le mancate corrispondenze appaiono incoerenti ai filtri antispam.