Da quando Gmail, Yahoo e Microsoft applicano con rigore le loro regole di autenticazione, i messaggi di un dominio configurato male non finiscono più soltanto nello spam: possono essere rifiutati del tutto. La buona notizia è che cPanel riunisce ora SPF, DKIM e DMARC in un'unica pagina. Questa guida la accompagna dalla prima verifica fino a una policy DMARC in p=reject, con i report a supporto.
Cosa chiedono Gmail, Yahoo e Microsoft nel 2026
I tre grandi provider di posta distinguono tra regole valide per tutti i mittenti e regole riservate agli invii massivi. Ecco la sintesi, basata sulla loro documentazione ufficiale in vigore a ottobre 2026.
| Requisito | Gmail | Yahoo | Outlook.com / Hotmail |
|---|---|---|---|
| Tutti i mittenti | SPF o DKIM, DNS diretto e inverso (PTR) validi, TLS, tasso di spam < 0,3% | SPF o DKIM, DNS diretto e inverso validi, tasso di spam < 0,3% | Buone pratiche consigliate |
| Soglia per gli invii massivi | Circa 5.000 messaggi al giorno verso account Gmail | Nessuna cifra pubblicata («volume significativo») | 5.000 messaggi o più verso i servizi consumer di Microsoft |
| Invii massivi: autenticazione | SPF e DKIM, DMARC almeno p=none, allineamento del dominio From | SPF e DKIM, DMARC almeno p=none, allineamento rilassato accettato | SPF e DKIM superati, DMARC pubblicato e superato |
| Disiscrizione | Con un clic (intestazioni List-Unsubscribe) più link visibile | Con un clic, applicata entro 2 giorni | Consigliata |
| Conseguenza | Rifiuti temporanei o permanenti, oppure cartella spam | Filtraggio o rifiuto | Rifiuto con errore 550 5.7.515 |
Google precisa nelle sue FAQ che da novembre 2025 Gmail ha intensificato l'applicazione di queste regole: i messaggi non conformi subiscono ora rifiuti temporanei e permanenti. Gmail raccomanda inoltre una chiave DKIM di almeno 1024 bit, idealmente 2048, e un tasso di spam idealmente inferiore allo 0,1%.
Perché riguarda anche i siti piccoli
Non invia 5.000 messaggi al giorno? Le regole per tutti i mittenti valgono comunque, e un dominio senza DMARC è un bersaglio facile per lo spoofing: chiunque può inviare un'email falsa a suo nome. I moduli di contatto WordPress, le conferme d'ordine PrestaShop e le newsletter passano dagli stessi filtri della sua posta personale. Configurare i tre record richiede meno di un'ora e la protegge nel tempo.
SPF, DKIM e DMARC: il ruolo di ciascuno
- SPF elenca i server autorizzati a inviare per il suo dominio. Viene verificato sull'indirizzo di busta (Return-Path), non su quello visualizzato.
- DKIM aggiunge una firma crittografica a ogni messaggio. Il destinatario la verifica con la chiave pubblica pubblicata nel suo DNS.
- DMARC collega entrambi all'indirizzo visibile (il dominio del campo From). Un messaggio supera DMARC se SPF o DKIM vengono superati e il dominio verificato corrisponde a quello mostrato: è l'allineamento. DMARC indica anche cosa fare in caso di errore e dove inviare i report.
La trappola più comune: un SPF valido non basta se il Return-Path appartiene a un altro dominio, ad esempio quello del servizio di newsletter. Senza una firma DKIM con il suo dominio, DMARC fallisce.
Passo 1: fare il punto della situazione in cPanel
- Acceda a cPanel, apra la sezione Email e poi Email Deliverability (Recapito delle email).
- La tabella elenca i suoi domini con una colonna di stato del recapito. Un dominio segnalato ha un problema su DKIM, SPF, DMARC o DNS inverso.
- Faccia clic su Manage (Gestisci) per vedere i dettagli: ogni record viene confrontato con quello suggerito da cPanel.
Il pulsante Repair (Ripara) corregge automaticamente i record non validi dopo la sua conferma. È disponibile solo se il server gestisce la zona DNS del dominio. Se i suoi nameserver sono altrove (presso il registrar o un servizio CDN), copi i record suggeriti e li aggiunga presso quel fornitore.
La sezione DMARC di questa pagina è presente nelle versioni recenti di cPanel (versione 130 e successive). Nelle versioni più vecchie, aggiunga il record DMARC a mano nello Zone Editor.
Passo 2: configurare SPF
Nella sezione SPF della pagina Manage, cPanel propone un record adatto al suo server. Per un dominio che invia solo dal suo hosting, è simile a questo:
tuodominio.it. 14400 IN TXT "v=spf1 +a +mx +ip4:203.0.113.10 ~all"
Se usa anche un servizio esterno (strumento di newsletter, suite collaborativa), clicchi su Customize per aggiungere l'include fornito da quel servizio, poi su Install a Customized SPF Record:
tuodominio.it. 14400 IN TXT "v=spf1 +a +mx +ip4:203.0.113.10 include:_spf.servizio-esempio.com ~all"
Tre regole da rispettare:
- Un solo record SPF per dominio. Due record
v=spf1rendono SPF non valido. - Massimo dieci query DNS. Ogni
include,aomxne consuma una; oltre, SPF restituisce un errore. ~allo-all? cPanel propone~all(soft fail) come impostazione predefinita. Con DMARC attivo, è DMARC a decidere la sorte dei messaggi:~allresta la scelta prudente finché non è certo di aver elencato tutte le fonti.
Passo 3: attivare e pubblicare DKIM
Nella sezione DKIM, clicchi su Generate Local DKIM Key se non esiste ancora una chiave. cPanel firmerà così la posta in uscita dal suo hosting con il selettore default. Il record pubblico ha questa forma:
default._domainkey.tuodominio.it. 14400 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"
Se il suo DNS è gestito altrove, usi Copy e incolli il valore presso il suo provider DNS (il formato «Split» divide una chiave lunga in più stringhe se l'interfaccia lo richiede). Non pubblichi mai la chiave privata: cPanel permette di visualizzarla, ma deve restare sul server.
Ogni servizio esterno che invia a suo nome deve firmare anch'esso con il suo dominio, tramite un proprio selettore (ad esempio s1._domainkey). A differenza di SPF, più selettori DKIM convivono senza problemi.
Passo 4: pubblicare DMARC in modalità osservazione
Per prima cosa, crei in cPanel un indirizzo email riservato alla ricezione dei report, ad esempio [email protected]: ne riceverà diversi al giorno. Poi, nella sezione DMARC, installi il record suggerito o lo adatti nello Zone Editor:
_dmarc.tuodominio.it. 14400 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"
p=none: nessuna azione sui messaggi che falliscono, si limita a osservare.rua: l'indirizzo che riceve i report aggregati giornalieri.adkim=reaspf=r: allineamento rilassato, che accetta i sottodomini (un Return-Path subounce.tuodominio.itresta allineato).
cPanel ricorda che DMARC è pienamente attivo solo se SPF e DKIM sono già validi: completi i passi 2 e 3 prima di questo.
Passo 5: leggere i report DMARC
I report aggregati arrivano come allegato compresso (.zip o .gz) contenente un file XML. Ogni provider (Google, Yahoo, Microsoft…) invia il proprio, di solito una volta al giorno. Ecco la parte che conta:
<record>
<row>
<source_ip>198.51.100.25</source_ip>
<count>137</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>tuodominio.it</header_from>
</identifiers>
</record>
Si legge così: 137 messaggi con il suo dominio sono partiti dall'indirizzo IP 198.51.100.25. SPF è allineato, DKIM no, quindi DMARC viene superato grazie a SPF. Per ogni IP di origine, si ponga tre domande:
- Riconosco questa fonte? Il suo server cPanel, lo strumento di newsletter, il software di fatturazione… Se sì, è un invio legittimo da correggere.
- Se legittima, cosa fallisce? Manca DKIM: attivi la firma con il suo dominio in quel servizio. SPF non allineato: aggiunga il suo
includeo configuri un Return-Path sul suo dominio. - Se sconosciuta, è spoofing? Volumi da IP sconosciuti che falliscono sia SPF sia DKIM sono esattamente ciò che
p=rejectbloccherà.
Leggere XML a mano diventa presto faticoso: molti analizzatori di report DMARC, gratuiti o a pagamento, trasformano questi file in tabelle per fonte. L'importante è consultarli ogni settimana durante la transizione.
Passo 6: passare da p=none a p=reject senza danni
Irrigidire la policy troppo presto fa sparire le sue stesse email legittime. Proceda per gradi:
| Fase | Record | Durata consigliata | Condizione per passare oltre |
|---|---|---|---|
| 1. Osservazione | p=none | Da 2 a 4 settimane | Tutte le fonti legittime individuate e allineate |
| 2. Quarantena | p=quarantine | Da 2 a 4 settimane | Nessuna segnalazione di email legittime nello spam, report stabili |
| 3. Rifiuto | p=reject | Permanente | Controllo mensile dei report |
; Fase 2
_dmarc.tuodominio.it. 14400 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"
; Fase 3
_dmarc.tuodominio.it. 14400 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=r; aspf=r"
Il parametro sp=reject applica la stessa regola ai sottodomini, che chi fa spoofing sfrutta volentieri quando restano senza protezione. Il parametro pct, un tempo usato per un'introduzione graduale, non fa più parte della nuova versione dello standard DMARC (RFC 9989, pubblicata nel 2026): preferisca fasi complete e periodi di osservazione sufficienti.
Verificare con un messaggio reale
Invii un'email dalla sua casella cPanel a un indirizzo Gmail, la apra e scelga Mostra originale. Gmail mostra SPF, DKIM e DMARC con PASS o FAIL. Nelle intestazioni complete, cerchi la riga Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=default;
spf=pass smtp.mailfrom=tuodominio.it;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tuodominio.it
Ripeta il test dal suo sito: modulo di contatto, reimpostazione della password, ordine di prova. Le email inviate da PHP senza autenticazione partono a volte con un indirizzo di busta legato all'account di hosting anziché al suo dominio. Configuri il suo CMS per inviare tramite SMTP autenticato con un indirizzo reale del suo dominio: SPF e DKIM saranno allineati.
Gli errori di rifiuto più comuni
5.7.26su Gmail: il messaggio non è autenticato (né SPF né DKIM validi e allineati). Torni alla verifica del passo 1.550 5.7.515su Microsoft: il dominio mittente non raggiunge il livello di autenticazione richiesto agli invii massivi. SPF e DKIM devono essere entrambi superati, e DMARC deve essere pubblicato e superato.- DMARC fallisce anche se SPF passa: il Return-Path appartiene al dominio di un fornitore. Attivi DKIM con il suo dominio presso quel fornitore.
- DKIM fallisce dopo una migrazione: la chiave è stata rigenerata sul nuovo server, ma il vecchio valore è ancora pubblicato nel DNS esterno.
- PTR mancante o incoerente: lo segnala la sezione Reverse DNS della pagina Manage. Questo record dipende dal proprietario dell'indirizzo IP, quindi dal suo provider di hosting.
Domande frequenti
DMARC in p=none basta per Gmail e Outlook?
In senso stretto sì: Gmail, Yahoo e Microsoft accettano p=none come minimo. Ma questa policy non protegge il suo dominio dallo spoofing. Punti a p=reject una volta allineati i suoi invii legittimi.
Quanto tempo serve perché le modifiche siano attive?
La pagina Email Deliverability ricontrolla i record in pochi minuti dopo una riparazione. Lato destinatari, consideri la scadenza del TTL dei suoi record DNS, di solito qualche ora.
Cosa fare se il pulsante Repair non compare?
La sua zona DNS non è gestita dal server cPanel. Copi i record suggeriti e li aggiunga presso il fornitore che gestisce i suoi nameserver.
Serve un record DMARC per ogni sottodominio?
No. Il record del dominio principale si applica ai sottodomini, e il parametro sp consente di assegnare loro una policy propria.
I report DMARC contengono il testo delle mie email?
No. I report aggregati (rua) contengono solo statistiche: indirizzi IP, volumi e risultati di SPF, DKIM e DMARC.