SPF, DKIM e DMARC sul server di posta: guida contro lo spam
Se le email del tuo server finiscono nello spam, quasi sempre manca uno di questi cinque elementi: un PTR (DNS inverso) coerente con il nome del server, un record SPF che autorizza il suo indirizzo, la firma DKIM, un record DMARC e la porta 25 in uscita aperta. Gmail, Yahoo e Outlook oggi li verificano tutti e rifiutano o spostano nello spam i messaggi che non li superano. In questa guida trovi i record DNS d'esempio, i comandi per controllarli e gli errori più comuni.
Negli esempi usiamo il dominio esempio.it, il server di posta mail.esempio.it con indirizzo IPv4 203.0.113.10 e IPv6 2001:db8::10. Sostituiscili con i tuoi.
Prima dei record: le basi del server
Porta 25 in uscita
Molti provider cloud bloccano la porta 25 in uscita sui nuovi VPS per limitare lo spam. Senza porta 25 il server riceve la posta ma non riesce a consegnarla. Verifica così:
nc -vz -w 5 gmail-smtp-in.l.google.com 25
Se la connessione va in timeout, chiedi lo sblocco al provider oppure usa un relay SMTP (smarthost) come Amazon SES, Brevo o Mailgun: in quel caso l'SPF dovrà includere il servizio di invio, non solo il tuo server.
Nome del server e record A
Il nome con cui il server si presenta (HELO/EHLO) deve risolvere al suo indirizzo:
mail.esempio.it. 3600 IN A 203.0.113.10
mail.esempio.it. 3600 IN AAAA 2001:db8::10
PTR (DNS inverso)
Il PTR è il record che, partendo dall'indirizzo IP, restituisce un nome. Deve restituire mail.esempio.it, e quel nome deve tornare allo stesso IP (si chiama forward-confirmed reverse DNS). Il PTR non si imposta nel DNS del dominio ma nel pannello del provider del server, perché la zona inversa appartiene a chi possiede l'indirizzo IP.
dig +short -x 203.0.113.10
# atteso: mail.esempio.it.
dig +short mail.esempio.it A
# atteso: 203.0.113.10
Se il server ha IPv6, serve anche il PTR per l'indirizzo IPv6: Gmail rifiuta spesso i messaggi che arrivano da un IPv6 senza DNS inverso. Se non puoi impostarlo, fai uscire la posta solo in IPv4 (in Postfix: smtp_address_preference = ipv4 oppure inet_protocols = ipv4).
MX
esempio.it. 3600 IN MX 10 mail.esempio.it.
L'MX deve puntare a un nome con record A/AAAA, mai a un indirizzo IP e mai a un CNAME.
SPF: chi può spedire per il tuo dominio
SPF è un record TXT sul dominio che elenca i server autorizzati a spedire con quell'indirizzo nel mittente di busta (Return-Path).
esempio.it. 3600 IN TXT "v=spf1 mx a ip4:203.0.113.10 ip6:2001:db8::10 ~all"
mxeaautorizzano i server indicati dall'MX e dal record A del dominio;ip4:eip6:autorizzano indirizzi precisi;include:aggiunge i server di un servizio esterno (per esempioinclude:amazonses.comse usi Amazon SES);~all(softfail) segna come sospetti gli altri;-all(fail) li rifiuta.
Con DMARC attivo, ~all è sufficiente e più tollerante durante i cambi di infrastruttura; passa a -all quando sei sicuro di aver elencato tutti i mittenti (newsletter, CRM, gestionale, sito che invia email).
Regole da ricordare: un solo record SPF per dominio (due record v=spf1 fanno fallire la verifica); al massimo 10 ricerche DNS tra include, a, mx, redirect ed exists (RFC 7208); i sottodomini non ereditano l'SPF del dominio padre.
DKIM: la firma dei messaggi
DKIM firma ogni messaggio con una chiave privata che resta sul server; la chiave pubblica sta nel DNS sotto un selettore. Chi riceve verifica che il messaggio non sia stato alterato e che venga davvero dal dominio.
Il record ha questa forma (chiave accorciata):
selettore._domainkey.esempio.it. 3600 IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx..."
"...IDAQAB" )
- Usa chiavi RSA da 2048 bit: Google accetta dal 1024 in su, ma consiglia 2048.
- Un record TXT più lungo di 255 caratteri va diviso in più stringhe tra virgolette nello stesso record; molti pannelli DNS lo fanno da soli, altri no.
- Il selettore permette di avere più chiavi (per esempio una per il server, una per il servizio di newsletter) e di ruotarle senza interruzioni.
Se configuri tutto a mano con OpenDKIM, la coppia di chiavi si genera così (il pacchetto opendkim-tools è nei repository di Ubuntu 24.04):
sudo apt install opendkim opendkim-tools
opendkim-genkey -b 2048 -d esempio.it -s mail
# crea mail.private (chiave privata) e mail.txt (record da pubblicare)
DMARC: la politica e i rapporti
DMARC dice ai destinatari cosa fare quando un messaggio non supera i controlli, e ti manda rapporti su chi spedisce a nome del tuo dominio. Soprattutto introduce l'allineamento: il dominio nel campo From: visibile deve coincidere con quello verificato da SPF o da DKIM.
_dmarc.esempio.it. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@esempio.it; adkim=r; aspf=r"
p=none: solo osservazione, nessun effetto sulla consegna;p=quarantine: i messaggi non conformi vanno nello spam;p=reject: vengono rifiutati;rua=: indirizzo che riceve i rapporti aggregati (file XML giornalieri dai grandi provider);adkimeaspf: allineamentor(rilassato, accetta i sottodomini) os(stretto).
Percorso consigliato: parti da p=none, leggi i rapporti per qualche settimana, correggi i mittenti che falliscono, poi passa a quarantine e infine a reject. Se i rapporti vanno a un indirizzo di un altro dominio, quel dominio deve autorizzarlo con un record esempio.it._report._dmarc.altrodominio.it.
MTA-STS e TLS-RPT, in breve
Tra server la cifratura STARTTLS è facoltativa e può essere tolta da chi si mette in mezzo. MTA-STS (RFC 8461) permette di dichiarare che il tuo dominio accetta posta solo su TLS con un certificato valido. Serve:
- un record TXT
_mta-sts.esempio.itconv=STSv1; id=20260926; - un file di policy servito in HTTPS su
https://mta-sts.esempio.it/.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: mail.esempio.it
max_age: 604800
TLS-RPT (RFC 8460) aggiunge i rapporti sugli errori TLS: _smtp._tls.esempio.it TXT "v=TLSRPTv1; rua=mailto:tls@esempio.it". Parti con mode: testing e passa a enforce solo quando il certificato del server di posta si rinnova in modo affidabile. MTA-STS protegge la posta in arrivo; non è richiesto da Gmail o Yahoo per consegnare.
I requisiti di Gmail, Yahoo e Outlook
Dal febbraio 2024 Google richiede a tutti i mittenti verso Gmail SPF o DKIM, DNS diretto e inverso validi (PTR), connessione TLS, tasso di spam segnalato sotto lo 0,3% e messaggi conformi alla RFC 5322. Chi invia più di 5.000 messaggi al giorno a Gmail deve avere SPF e DKIM, un record DMARC (anche p=none), l'allineamento del From: e la disiscrizione con un clic per i messaggi promozionali (requisiti di Google). Da novembre 2025 Google applica le regole con rifiuti temporanei e permanenti per il traffico non conforme (FAQ di Google).
Yahoo chiede le stesse cose: SPF o DKIM per tutti, SPF e DKIM più DMARC valido per i mittenti di massa, spam sotto lo 0,3%, DNS inverso valido e disiscrizione rispettata entro due giorni (Yahoo Sender Hub). Da maggio 2025 anche Outlook.com applica SPF, DKIM e DMARC a chi invia più di 5.000 messaggi al giorno (annuncio Microsoft).
In pratica: anche se spedisci poco, configura tutti e tre i record. È l'unico modo per non dipendere dalla soglia.
Come verificare che tutto funzioni
Con dig
dig +short MX esempio.it
dig +short TXT esempio.it | grep spf1
dig +short TXT selettore._domainkey.esempio.it
dig +short TXT _dmarc.esempio.it
dig +short -x 203.0.113.10
Interroga anche un DNS pubblico specifico (dig @1.1.1.1 ... o dig @8.8.8.8 ...) per vedere cosa vede il resto di Internet dopo una modifica: il TTL può ritardare l'aggiornamento.
Il certificato TLS del server di posta
openssl s_client -starttls smtp -connect mail.esempio.it:25 -servername mail.esempio.it </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
Un messaggio vero
Il test più affidabile è mandare una email a una casella Gmail o Outlook tua e aprire l'originale (in Gmail: menu ⋮ › Mostra originale). Devi leggere SPF: PASS, DKIM: PASS e DMARC: PASS, con il tuo dominio in tutti e tre. Esistono anche servizi web che ti danno un indirizzo a cui scrivere e restituiscono un punteggio: sono utili per un controllo rapido, ma il verdetto che conta è quello del provider del destinatario. Per i volumi alti, registra il dominio su Google Postmaster Tools per vedere reputazione e tasso di spam.
Errori comuni
- Due record SPF sullo stesso dominio, per esempio uno vecchio del provider precedente: fondili in uno solo.
- Troppi
includenell'SPF: oltre 10 ricerche DNS il risultato èpermerror. - PTR generico del provider (tipo
vps-203-0-113-10.provider.net) o assente, soprattutto su IPv6. - Record DKIM spezzato male: virgolette mancanti, spazi dentro la chiave o selettore diverso da quello usato nella firma.
From:non allineato: il sito spedisce comeinfo@esempio.itpassando da un servizio che firma con il proprio dominio.- Inoltri verso indirizzi esterni senza riscrittura del mittente (SRS): l'SPF del mittente originale fallisce sul server di destinazione.
- Passare subito a
p=rejectsenza leggere i rapporti: rischi di bloccare newsletter e gestionali legittimi. - Indirizzo IP in lista nera (Spamhaus, Barracuda, SpamCop), magari ereditato da un cliente precedente del provider.
Come lo fa Koapanel
Se usi Koapanel, il servizio di posta facoltativo (Postfix, Dovecot, Rspamd) fa gran parte del lavoro. Prima dell'attivazione controlla porta 25 in uscita, PTR, record A del nome del server di posta e liste nere, e spiega cosa correggere. In Server › Posta › Invio della posta scegli tra invio diretto e relay (Brevo, Mailgun, Amazon SES, SMTP2GO, Postmark, SendGrid o altri); Esegui la diagnosi prova la porta 25 verso Gmail e Outlook e controlla il PTR anche in IPv6, e l'opzione Invia solo in IPv4 evita i rifiuti quando l'IPv6 non ha un PTR. Su Vultr e Hetzner Cloud il PTR si può impostare direttamente dal pannello con la chiave API del provider.
Quando attivi la posta su un dominio, il pannello crea la chiave DKIM a 2048 bit e la scheda DNS posta mostra i record da pubblicare, controllando cosa vedono i DNS pubblici: MX, SPF (v=spf1 mx a ip4:… ~all, con l'include del servizio se usi un relay), DKIM con selettore panel._domainkey, DMARC che parte da p=none e, facoltativi, autoconfig e autodiscover. I dettagli sono nel manuale della posta.
Se il DNS è su Cloudflare collegato, Configura DNS posta mostra le modifiche e poi le pubblica, senza toccare una policy DMARC già presente. Se invece il server fa da DNS dei tuoi domini (DNS di questo server, con PowerDNS e DNSSEC), MX, SPF, DKIM e DMARC vengono scritti da soli nella zona. MTA-STS e TLS-RPT non sono citati nel manuale: vanno pubblicati a mano.
Domande frequenti
Mi servono tutti e tre, SPF, DKIM e DMARC?
Sì. Per chi spedisce poco Gmail chiede SPF o DKIM, ma senza DMARC e senza allineamento la reputazione del dominio resta fragile. Con tutti e tre, più il PTR, parti nel modo giusto.
Meglio ~all o -all nell'SPF?
Con DMARC attivo ~all basta ed è più sicuro durante i cambi. -all va bene quando sei certo di aver elencato ogni servizio che spedisce per il dominio.
Dove si imposta il PTR?
Nel pannello del provider che ti ha assegnato l'indirizzo IP (Vultr, Hetzner, OVHcloud…), non nel DNS del dominio.
Quanto tempo serve perché i record funzionino?
Dipende dal TTL: da pochi minuti a qualche ora. Controlla con dig @8.8.8.8 e dig @1.1.1.1 prima di fare test di invio.
Uso un relay SMTP: cambia qualcosa?
L'SPF deve includere il servizio (include: indicato dal fornitore) e spesso il servizio chiede di autenticare il dominio con un suo record DKIM. Il PTR del tuo server conta meno, perché i messaggi escono dai server del relay.
Prova Koapanel
Vuoi un server di posta con DKIM, SPF e DMARC già pronti e i controlli in chiaro? Installa Koapanel gratis su un Ubuntu 24.04 nuovo, oppure guarda la demo pubblica. Stai spostando caselle da un altro server? Leggi anche la guida per migrare le caselle email via IMAP.