Mi serve un IP dedicato per far girare un mail server?

Di fatto sì. La deliverability dipende da un record reverse DNS (PTR) che corrisponde al tuo hostname di posta, e puoi impostare un PTR solo su un IP che è esclusivamente tuo. Su un indirizzo condiviso o NAT non controlli il PTR, quindi i server riceventi vedono un hostname generico o non corrispondente e ti trattano con sospetto. Un IP dedicato è la base per la posta in uscita.

Cos'è un record PTR e perché la posta ne ha bisogno?

Un record PTR è il reverse DNS — mappa il tuo IP di ritorno a un hostname, l'opposto di un normale record A. Quando il tuo server si connette a Gmail o Outlook, il lato ricevente cerca chi possiede il tuo IP. Se il PTR è mancante o generico (come static.203-0-113-19.rev.example-isp.net), è un colpo immediato contro di te. I mail server si aspettano che il PTR corrisponda al nome che il tuo server annuncia nell'HELO.

Perché la porta 25 in uscita è bloccata di default sulla maggior parte degli host VPS?

La porta 25 è il singolo maggiore vettore di spam, quindi gli host la tengono chiusa finché non la chiedi e spieghi cosa invii. Non è un bug — è prevenzione degli abusi. Uno script compromesso che spara spam può bruciare la reputazione di un IP, e su una subnet condivisa quel danno si riversa sugli altri clienti. Gli host seri, EQVPS incluso, la aprono su richiesta anziché di default.

Posso far girare un mail server su un IP NAT o condiviso?

Puoi ricevere posta tramite port forwarding, ma inviare in modo affidabile è un'altra storia. Senza il tuo IP non puoi impostare un PTR corrispondente, ed erediti qualsiasi reputazione l'indirizzo condiviso già porti — buona o cattiva. Per qualsiasi cosa tu abbia bisogno di recapitare, usa un IP dedicato con una storia pulita e un PTR che controlli.

Vale davvero la pena fare self-hosting della posta nel 2026?

Dipende dal perché. Se vuoi il controllo sui tuoi dati e sul tuo dominio senza una terza parte nel giro, è molto fattibile su un piccolo VPS. Ma la deliverability è lavoro continuo — sorvegli le blocklist, ruoti le chiavi DKIM e mantieni pulito l'IP. Per un progetto collaterale a basse poste, inoltrare tramite un provider esistente è meno doloroso. Fai self-hosting quando il controllo conta più della comodità.

Far girare un mail server su un VPS: cosa ti tiene davvero fuori dallo spam

Il tuo mail server funziona. Postfix si avvia, i log sembrano puliti, invii un messaggio di test alla tua Gmail — e finisce nello spam. O semplicemente scompare. Niente nella tua config è rotto. Il software ha fatto esattamente ciò che gli hai detto.

Il problema è che il server dall'altra parte non si fida ancora del tuo IP, e la posta nasconde un'intera pila di piccoli controlli di fiducia che devono tutti allinearsi prima che la casella di uno sconosciuto ti faccia entrare. Impostali bene e il recapito per lo più si prende cura di sé. Manca uno e stai gridando in una cartella spam.

Tre cose portano gran parte del peso: reverse DNS, autenticazione del mittente e se il tuo host ti lascia persino parlare sulla porta 25. Nessuna di esse è difficile. Sono solo facili da dimenticare, e ciascuna è un veto silenzioso.

Quello che tutti dimenticano: il reverse DNS

Il DNS forward è la parte che conosci — un nome punta a un IP. Il reverse DNS è lo specchio: un IP punta di nuovo a un nome. Quel record si chiama PTR, e vive con chi controlla l'IP, non nella zona del tuo dominio.

Ecco perché conta. Quando il tuo server apre una connessione all'SMTP di Gmail, una delle prime cose che fa il lato ricevente è un lookup inverso sul tuo IP — chi è? Eseguilo tu stesso:

dig -x 203.0.113.19 +short

Se torna qualcosa come static.203-0-113-19.rev.example-isp.net, o torna vuoto, hai già perso punti. Quel nome generico dice "un VPS a caso", e peggio, non corrisponde all'hostname con cui il tuo server si presenta nel saluto HELO. I server riceventi segnalano quella discrepanza pesantemente. Alcuni rifiutano del tutto.

Ciò che vogliono vedere è un PTR che corrisponde al tuo hostname di posta. Se il tuo server dice HELO mail.example.com, il lookup inverso sul suo IP dovrebbe restituire mail.example.com. Forward e reverse concordano, la storia è coerente, e sembri un vero mail server invece di una macchina dirottata.

Impostare un PTR ha tradizionalmente significato aprire un ticket di supporto con chi possiede il blocco di IP e aspettare. Sui piani con IP dedicato di EQVPS è un campo nella tua dashboard — digita l'hostname, scrive direttamente nel registro tramite l'API del provider, ed è live in pochi secondi. È tutto il punto del farlo self-serve: il reverse DNS è il passo che la gente salta perché era fastidioso.

Autenticazione: SPF, DKIM, DMARC

Questi tre record DNS dicono ai server riceventi che la posta che dichiara di venire dal tuo dominio viene davvero da lì. Saltali e sei uno sconosciuto non verificato.

SPF è un record TXT che elenca quali server sono autorizzati a inviare per il tuo dominio. Gmail lo controlla e chiede: questo messaggio è venuto da un IP che hai autorizzato?
DKIM firma crittograficamente ogni messaggio in uscita. Il ricevente prende la tua chiave pubblica dal DNS e verifica che la firma non sia stata falsificata in transito.
DMARC lega i due insieme e dice ai riceventi cosa fare quando un controllo fallisce — niente, mettere in quarantena o rifiutare — e dove inviare i report.

Li vuoi tutti e tre. SPF e DKIM provano che la posta è legittimamente tua; DMARC trasforma quella prova in una policy. Sono forse venti minuti di modifiche DNS, ed è la differenza tra "mittente verificato" e "chi?"

La porta 25, e perché è chiusa

Ecco quella che sorprende la gente. La porta 25 in uscita — la porta che i mail server usano per parlarsi — è bloccata di default su essenzialmente ogni host VPS. Anche noi.

È deliberato. La porta 25 è il classico cannone dello spam, quindi resta chiusa finché non la chiedi e dici cosa stai effettivamente inviando. La apriamo su richiesta anziché lasciarla aperta a chiunque avvii un server.

E c'è un'avvertenza onesta qui che vale la pena dire chiaramente: con una porta 25 aperta arriva la responsabilità. Uno script compromesso o un relay mal configurato che pompa spam, e la reputazione del tuo IP è andata — a volte per settimane. Su una subnet condivisa quel pasticcio schizza sui tuoi vicini, che è esattamente perché gli host sono cauti al riguardo. Se ci chiedi di aprire la 25, tieni pulito il tuo server, perché la reputazione che stai proteggendo è in parte anche nostra.

Perché l'IP dedicato non è opzionale

Tutto questo torna a un requisito: l'IP deve essere tuo. Su un setup NAT o un indirizzo condiviso non puoi impostare il tuo PTR, perché l'indirizzo non è esclusivamente tuo da puntare. Erediti anche qualsiasi reputazione l'IP condiviso già porti — e non hai idea di cosa abbia fatto l'inquilino precedente con esso.

Un IP dedicato ti dà un PTR che controlli, una reputazione che è tua da costruire e un punto di partenza pulito. Per la posta in uscita non è un optional; è il pavimento.

La conclusione onesta

Fare self-hosting della posta nel 2026 è vero lavoro continuo. Non è set-and-forget — sorveglierai le blocklist, ruoterai le chiavi DKIM, e occasionalmente capirai perché uno specifico provider ha iniziato a fare greylisting con te. Se questo è un progetto collaterale a basse poste, onestamente, inoltrare tramite un provider di posta esistente ti risparmierà mal di testa.

Ma se vuoi il controllo vero — i tuoi dati, il tuo dominio, nessun altro che legge le intestazioni — è molto fattibile su un piccolo VPS. L'impianto di fiducia sopra è circa il 90% della battaglia, e niente di esso è esotico. Prendi un IP dedicato, imposta il PTR perché corrisponda al tuo hostname, pubblica SPF/DKIM/DMARC, chiedici di aprire la porta 25, poi invia un test tramite uno strumento come mail-tester.com e sistema ciò che segnala. Fallo e non stai più gridando in una cartella spam — sei un mail server di cui le caselle della gente si fidano davvero.