Configurare SPF, DKIM e DMARC: guida passo passo per le cold email

Se invia cold email dal Suo dominio, tre record DNS decidono se i server riceventi credono che il messaggio sia davvero Suo: SPF, DKIM e DMARC. Senza di essi, anche una prima email ben scritta può essere filtrata prima che qualcuno la legga.

Questa guida è pensata per fondatori e team commerciali che inviano messaggi di prospezione da un indirizzo come you@yourcompany.com, di solito tramite Google Workspace. Noi (Outreach) esaminiamo ogni record nell'ordine in cui va configurato, mostriamo i formati dei record esattamente come li pubblicano le pagine di assistenza di Google e le RFC, e segnaliamo gli errori che fanno sembrare corretto un record mentre in realtà non funziona senza darlo a vedere.

Non serve essere esperti di DNS. Servono l'accesso alle impostazioni DNS del Suo dominio (presso il registrar o il provider DNS) e, per DKIM, l'accesso come amministratore a Google Workspace.

Che cosa sono SPF, DKIM e DMARC, in una frase ciascuno?

SPF elenca i server autorizzati a inviare posta per il Suo dominio, DKIM aggiunge una firma crittografica che dimostra che un messaggio non è stato contraffatto né modificato, e DMARC indica ai destinatari che cosa fare quando un messaggio non supera questi controlli. Tutti e tre vengono pubblicati come record TXT nel DNS del Suo dominio.

Record	Dove si trova	A che cosa risponde
SPF	`yourcompany.com` (host `@`)	“Questo server è autorizzato a inviare per questo dominio?”
DKIM	`google._domainkey.yourcompany.com`	“Il messaggio è stato firmato dal dominio e non è stato modificato?”
DMARC	`_dmarc.yourcompany.com`	“Se un controllo non viene superato, che cosa chiede di fare il titolare del dominio?”

Funzionano insieme. SPF e DKIM dimostrano ciascuno qualcosa di limitato; DMARC collega queste prove all'indirizzo che le persone vedono effettivamente nel campo Da.

Questi record sono davvero obbligatori per le cold email?

Sì — almeno SPF o DKIM è obbligatorio per ogni mittente verso Gmail e Yahoo, e i mittenti di email collettive hanno bisogno di tutti e tre. Non è un semplice consiglio di buone pratiche: è scritto nelle regole per i mittenti pubblicate da entrambi i fornitori.

Le linee guida di Google per i mittenti indicano che tutti i mittenti devono “configurare l'autenticazione email SPF o DKIM per i domini di invio.” I mittenti di “più di 5.000 messaggi al giorno verso account Gmail” devono inoltre “configurare SPF e DKIM” oltre all'“autenticazione email DMARC per il dominio di invio”, e il dominio del campo Da deve essere allineato al dominio SPF o DKIM. Queste regole sono entrate in vigore il 1° febbraio 2024.

Le procedure consigliate di Yahoo Sender Hub coincidono: ogni mittente deve “implementare almeno SPF o DKIM”, e i mittenti di email collettive devono “implementare sia SPF sia DKIM” e “pubblicare un criterio DMARC valido con almeno p=none.”

Un piccolo programma di cold email potrebbe non raggiungere mai i 5.000 messaggi al giorno. Configuri comunque tutti e tre: non costa nulla, richiede un pomeriggio e fa sì che non debba mai scoprire dove si trovi il limite.

Come si configura SPF?

Aggiunga un record TXT al Suo dominio principale che inizi con v=spf1, elenchi ogni servizio che invia posta per Lei e termini con ~all. Per un dominio che invia solo tramite Google Workspace, la pagina di Google sulla configurazione di SPF fornisce questo record esatto:

v=spf1 include:_spf.google.com ~all

Passaggi:

Acceda alle impostazioni DNS del provider del Suo dominio.
Crei un record TXT. Nel campo host o nome, Google indica di inserire @ se lo aggiunge al dominio principale anziché a un sottodominio.
Incolli il record come valore e salvi.
Attenda. Google precisa che “possono essere necessarie fino a 48 ore prima che l'autenticazione SPF inizi a funzionare.”

Se anche altri servizi inviano posta dal Suo dominio — uno strumento per newsletter, un CRM, un servizio di posta transazionale — ciascuno richiede il proprio include: nello stesso record. La pagina di Google fornisce questi esempi combinati:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Usi il valore include che ogni servizio di invio indica nella propria documentazione; non lo indovini.

Il record SPF dovrebbe terminare con ~all o con -all?

La guida di Google alla configurazione usa ~all, ed è l'impostazione predefinita più sicura finché sta ancora scoprendo tutti i servizi che inviano posta per Lei. I due finali hanno significati diversi nella RFC 7208, lo standard SPF:

~all (softfail) è “una dichiarazione debole da parte dell'ADMD che pubblica il record, secondo cui l'host probabilmente non è autorizzato.”
-all (fail) è “una dichiarazione esplicita secondo cui il client non è autorizzato a usare il dominio nell'identità indicata.”

Con -all, un servizio di invio che ha dimenticato di includere riceve un esito negativo definitivo. Quando DMARC è attivo e i suoi report mostrano che ogni fonte legittima supera il controllo, il finale del record SPF conta meno, perché il criterio DMARC diventa l'istruzione che i destinatari seguono.

Perché SPF smette di funzionare con troppi include?

Perché un controllo SPF può attivare al massimo 10 ricerche DNS; oltre questo limite, l'intero risultato diventa un errore. La RFC 7208, sezione 4.6.4 stabilisce che le implementazioni “DEVONO limitare a 10 il numero totale di tali termini durante la valutazione SPF” e che “se questo limite viene superato, l'implementazione DEVE restituire ‘permerror’.”

I termini che contano sono include, a, mx, ptr, exists e il modificatore redirect. Aspetto fondamentale: il conteggio riguarda l'intera valutazione — quindi un include: che a sua volta contiene altri include ne consuma diversi dei Suoi 10. La pagina di Google la formula così: “Un record SPF può avere fino a 10 tag include:”; la RFC offre la lettura più rigorosa perché contano anche le ricerche nidificate.

Se nel corso degli anni ha aggiunto diversi strumenti di vendita e marketing, rimuova quelli che non usa più prima di aggiungere nuovi include.

Che cosa succede se un dominio ha due record SPF?

SPF non riesce e restituisce un errore — due record vengono trattati come una configurazione errata, non come due elenchi da combinare. La RFC 7208 stabilisce che, quando per un dominio esiste più di un record v=spf1, il controllo “produce il risultato ‘permerror’.”

Un caso frequente: qualcuno aggiunge un secondo record TXT per un nuovo strumento invece di modificare quello esistente. La soluzione è unirli in un unico record con più termini include:, come negli esempi precedenti.

Come si attiva DKIM in Google Workspace?

Generi una chiave nella Console di amministrazione, la pubblichi come record TXT in google._domainkey, quindi faccia clic su “Avvia autenticazione.” La pagina di Google sulla configurazione di DKIM descrive il percorso:

Nella Console di amministrazione Google, vada su App > Google Workspace > Gmail > Autentica email. (Servono i privilegi amministrativi per le Impostazioni di Gmail.)
Scelga il dominio e faccia clic su “Genera nuovo record”.
Scelga la lunghezza della chiave. Google indica di scegliere 2048 “se il provider del Suo dominio supporta le chiavi a 2048 bit” perché “le chiavi più lunghe sono più sicure delle chiavi più corte”, e 1024 solo “se l'host del Suo dominio non supporta le chiavi a 2048 bit.”
Mantenga il selettore di prefisso predefinito, google — Google lo definisce “l'opzione consigliata” per Workspace.
Google mostra un nome host DNS, google._domainkey, e un valore TXT che inizia con v=DKIM1. Copi entrambi in un nuovo record TXT presso il Suo provider DNS.
Torni nella Console di amministrazione e faccia clic su Avvia autenticazione.

Il valore TXT generato da Google ha questa forma (la chiave è una lunga stringa unica per il Suo dominio):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Tempistiche: Google precisa che “possono essere necessarie fino a 48 ore prima che l'autenticazione DKIM inizi a funzionare” dopo l'aggiunta della chiave. Se ha appena configurato Gmail per un nuovo dominio, Google segnala che “è necessario attendere 24–72 ore” prima che la chiave DKIM sia disponibile nella Console di amministrazione.

Se un altro servizio invia posta per Lei, Le fornirà un proprio record DKIM con un proprio selettore. Pubblichi anche quello — più chiavi DKIM con selettori diversi possono coesistere, a differenza di SPF.

Come si configura DMARC senza bloccare la propria posta?

Pubblichi un record TXT in _dmarc.yourcompany.com con p=none all'inizio, legga i report e solo dopo renda più rigido il criterio. La pagina di Google sulla configurazione di DMARC indica: “Quando si inizia a usare DMARC, si consiglia di impostare l'opzione del criterio (p) su none.” Consiglia inoltre di “attendere 48 ore dopo aver configurato SPF e/o DKIM prima di configurare DMARC.”

La pagina di Google fornisce questo record di esempio completo:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Questo esempio mostra lo stato finale, il più rigoroso. Per un primo record basta lo stesso formato con un criterio di monitoraggio e un solo indirizzo per i report — ad esempio v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. Il tag rua invia i report aggregati a quella casella; Google consiglia una casella o un gruppo dedicato, perché i report possono arrivare in grande quantità.

I tre valori del criterio, come definiti nella specifica DMARC:

Criterio	Che cosa chiede ai destinatari di fare
`p=none`	Nessuna azione specifica — solo segnalare
`p=quarantine`	Trattare gli esiti negativi come sospetti (ad esempio, la cartella dello spam)
`p=reject`	Rifiutare la posta che non supera il controllo DMARC

Un dominio ha un solo record DMARC. Secondo la RFC 9989, se vengono restituiti più record DMARC, “vengono tutti scartati” — il che significa che non si applica alcun criterio.

Che cosa significa “allineamento” e perché DMARC fallisce quando SPF supera il controllo?

DMARC viene superato solo quando SPF o DKIM superano il controllo per un dominio che corrisponde all'indirizzo del campo Da che le persone vedono. SPF può essere superato per il dominio del Suo servizio di invio mentre il campo Da mostra il Suo — e in tal caso DMARC fallisce comunque, perché il dominio che ha superato il controllo non è allineato.

La specifica DMARC stabilisce che un messaggio supera il controllo quando almeno un metodo di autenticazione dà esito positivo “sulla base di un identificatore allineato” (RFC 7489, ora proseguita nella RFC 9989). Per impostazione predefinita, l'allineamento è rilassato (adkim e aspf hanno come valore predefinito r): mail.yourcompany.com e yourcompany.com risultano corrispondenti perché condividono lo stesso dominio organizzativo. La modalità rigorosa (s), come nell'esempio di Google, richiede una corrispondenza esatta.

In pratica, per questo DKIM è così importante per le cold email: quando il Suo servizio di invio firma con il Suo dominio, l'allineamento DKIM viene superato anche se quello SPF non lo è.

Lo standard DMARC è cambiato nel 2026?

Sì. La RFC 9989, pubblicata a maggio 2026 come documento Standards Track, sostituisce la RFC 7489 originale — ed elimina il tag pct. I record v=DMARC1 esistenti continuano a funzionare.

La modifica principale che la maggior parte dei mittenti noterà: pct (applicare il criterio solo a una percentuale dei messaggi non conformi) è scomparso. La RFC spiega che “l'esperienza operativa ha mostrato che il tag ‘pct’ di solito non veniva applicato con precisione, a meno che il valore specificato fosse 0 o 100.” Al suo posto c'è un indicatore di test, t=y, che chiede ai destinatari di non applicare il criterio dichiarato mentre lo si sta provando.

La pagina di assistenza di Google mostra ancora pct=100 nel suo esempio. Questo non rompe nulla: la RFC 9989 stabilisce che “i tag sconosciuti DEVONO essere ignorati”, quindi un pct rimasto viene semplicemente saltato. La prossima volta che modificherà il record, potrà eliminarlo.

Come si verifica che tutto funzioni?

Controlli i record pubblicati, poi invii un messaggio reale a un indirizzo Gmail e legga i risultati dell'autenticazione. Due controlli rapidi:

Consulti i record DNS. Il nostro verificatore gratuito cerca i record SPF, DKIM e DMARC per il dominio dell'indirizzo che inserisce — senza bisogno di registrarsi. Controlla il selettore DKIM predefinito di Google (google._domainkey); se il Suo servizio di invio usa un selettore diverso, il verificatore segnalerà DKIM come non confermato anche quando è configurato. Lo strumento è disponibile in inglese e in coreano; inserisca l'indirizzo email da cui invia.
Controlli un messaggio reale. Invii un'email a un account Gmail che gestisce, la apra, scelga “Mostra originale” e cerchi SPF: PASS, DKIM: PASS e DMARC: PASS.

Poi lasci passare una o due settimane ai report DMARC. Quando ogni fonte legittima che utilizza risulta superare i controlli, passi da p=none a p=quarantine e, in seguito, a p=reject se desidera la massima protezione contro la falsificazione dell'indirizzo del mittente.

Quali errori compromettono più spesso l'autenticazione?

Due record SPF, troppe ricerche SPF, DKIM generato ma mai avviato e DMARC pubblicato prima che SPF e DKIM abbiano avuto il tempo di funzionare. Una lista di controllo:

Un solo record SPF, con ogni mittente come include: al suo interno e non più di 10 termini di ricerca.
Faccia clic su “Avvia autenticazione” dopo aver pubblicato la chiave DKIM — il solo record DNS non basta.
Attenda circa 48 ore dopo SPF e DKIM prima di aggiungere DMARC e lo pubblichi in _dmarc, non nel dominio principale.
Invii da un dominio che controlla. Non è possibile pubblicare DMARC per un indirizzo @gmail.com.

L'autenticazione fa sì che la Sua posta venga presa in considerazione; non fa sì che i destinatari la desiderino. I reclami per spam contano comunque — Google e Yahoo indicano entrambi di mantenere il tasso di spam sotto lo 0,3%, come spieghiamo in perché le cold email finiscono nello spam. E l'invio a indirizzi inesistenti genera rimbalzi, ed è per questo che consigliamo di verificare gli indirizzi prima dell'invio.

In breve

Google e Yahoo richiedono SPF o DKIM a ogni mittente e tutti e tre più l'allineamento ai mittenti di email collettive (più di 5.000 messaggi al giorno verso Gmail).
SPF: un record TXT in @, ad esempio v=spf1 include:_spf.google.com ~all; rimanga entro 10 termini con ricerca DNS.
DKIM: chiave a 2048 bit, selettore google, record TXT in google._domainkey, poi Avvia autenticazione.
DMARC: un record TXT in _dmarc, inizi con p=none e un indirizzo per i report, renda il criterio più rigido in seguito. La RFC 9989 (maggio 2026) ha sostituito pct con t=y.
Controlli i Suoi record con il nostro verificatore gratuito dell'autenticazione email, poi confermi con un messaggio reale.