Chi invia posta tramite una piattaforma esterna raramente deve preoccuparsi dell'identità del server: se ne occupa il fornitore. Chi invece gestisce un proprio server di posta, per un'azienda, un'applicazione o un progetto personale, deve curare alcuni dettagli che i destinatari controllano prima ancora di guardare SPF, DKIM o il contenuto. Sono controlli vecchi, semplici, e proprio per questo applicati da quasi tutti.
Il record PTR e il DNS inverso
Il DNS normale traduce un nome in un indirizzo: mail.example.com diventa 198.51.100.20. Il DNS inverso fa il contrario: dato l'indirizzo, restituisce un nome. Questa associazione è un record PTR, e la sua particolarità è che non lo gestisce il proprietario del dominio, ma chi possiede il blocco di indirizzi IP: il fornitore di connettività, l'hosting o il cloud.
Si verifica così:
dig +short -x 198.51.100.20
mail.example.com.
Un server che invia posta senza PTR, o con un PTR generico come quelli assegnati automaticamente dai fornitori, che contengono l'IP stesso e parole come «dynamic» o «pool», viene trattato con sospetto. Molti destinatari rifiutano direttamente la connessione, e alcuni grandi provider indicano il PTR valido tra i requisiti per tutti i mittenti.
Corrispondenza diretta e inversa
Non basta che il PTR esista. Il nome restituito deve a sua volta risolvere nello stesso indirizzo:
| Controllo | Esempio | Esito |
|---|---|---|
| IP → nome (PTR) | 198.51.100.20 → mail.example.com |
presente |
| nome → IP (A) | mail.example.com → 198.51.100.20 |
coincide |
Quando entrambe le direzioni coincidono si parla di DNS inverso confermato, spesso indicato con la sigla FCrDNS. È il controllo che i filtri applicano davvero. Per IPv6 vale lo stesso principio: ogni indirizzo IPv6 da cui il server invia deve avere un PTR e un record AAAA corrispondenti. Un server che invia via IPv6 senza averlo configurato è una causa frequente di rifiuti improvvisi, perché i provider tendono a essere più severi proprio su IPv6.
Il nome HELO o EHLO
All'inizio di ogni sessione SMTP il server mittente si presenta con il comando EHLO, seguito da un nome. Questo nome dovrebbe:
- essere un nome di dominio completo, non un nome interno come
localhostoserver01; - risolvere nell'IP da cui parte la connessione;
- idealmente coincidere con il PTR dell'IP.
La configurazione più pulita è quella in cui PTR, nome HELO e record A raccontano la stessa storia: un IP, un nome, in entrambe le direzioni. Il nome scelto non deve coincidere con il dominio del From. Un server può inviare per molti domini diversi; conta che la sua identità tecnica sia coerente.
Altri controlli di base
TLS in uscita
I destinatari registrano se la connessione è cifrata, e alcuni pannelli per i mittenti mostrano la quota di traffico ricevuto tramite TLS. Il server deve offrire STARTTLS anche in uscita, con un certificato valido per il nome del server. È una configurazione ormai attesa da tutti.
Il tipo di IP
Gli indirizzi delle connessioni domestiche e di molti servizi a consumo non sono adatti all'invio diretto. Spesso sono inclusi in liste che segnalano gli IP residenziali, e molti fornitori bloccano in uscita la porta 25. In questi casi la soluzione corretta è inviare tramite un relay autenticato, cioè un servizio che riceve la posta dal tuo server e la consegna da IP con reputazione propria.
Anche nei cloud pubblici la porta 25 in uscita è spesso bloccata per impostazione predefinita e va richiesta esplicitamente; alcuni fornitori non la concedono affatto.
Postmaster e abuse
È buona pratica che il dominio del server abbia caselle postmaster e abuse funzionanti e lette. Sono gli indirizzi a cui altri amministratori scrivono quando qualcosa non va, e vengono usati anche da alcuni strumenti per verificare chi è responsabile di un IP.
Una lista di verifica
Prima di mettere in produzione un server di posta proprio conviene controllare:
- PTR impostato dal fornitore su un nome significativo, per IPv4 e IPv6;
- record A e AAAA del nome che puntano agli stessi indirizzi;
- nome HELO uguale al PTR;
- STARTTLS attivo con certificato valido;
- porta 25 in uscita disponibile, oppure relay configurato;
- IP non presenti nelle principali blacklist;
- SPF, DKIM e DMARC configurati per ogni dominio servito;
- caselle
postmastereabuseattive.
Nel mio lavoro trovo spesso server configurati con cura sul lato software ma con il PTR lasciato al valore predefinito del fornitore. È la correzione più rapida e una delle più efficaci.
In sintesi
- Il PTR è gestito da chi possiede l'IP e deve puntare a un nome significativo.
- Il nome del PTR deve risolvere nello stesso IP: è il DNS inverso confermato.
- Il nome HELO deve essere un nome completo coerente con PTR e record A.
- IPv6 richiede la stessa configurazione, spesso dimenticata.
- Dagli IP residenziali o senza porta 25 si invia tramite un relay autenticato.
