SPF, DKIM e DMARC: la guida completa all'autenticazione email

Ogni giorno gli attaccanti inviano miliardi di email spacciandosi per brand che non sono. Fatture contraffatte, falsi reset della password, richieste fasulle dell'amministratore delegato: funzionano tutte perché, per impostazione predefinita, chiunque può inserire qualsiasi indirizzo nel campo From di un'email. SPF, DKIM e DMARC esistono per chiudere questa falla. Insieme permettono ai provider di posta di verificare che un messaggio provenga davvero dal dominio dichiarato, e sono diventati silenziosamente il prezzo d'ingresso per la inbox: da febbraio 2024 Gmail e Yahoo richiedono l'autenticazione a ogni mittente e SPF, DKIM e DMARC completi ai bulk sender. Questa guida spiega come funziona ciascun protocollo, i record DNS esatti di cui hai bisogno, gli errori che li compromettono senza dare segnali e un piano di implementazione che puoi seguire già questa settimana.

Perché l'autenticazione email è importante

Il problema di fondo è che SMTP, il protocollo che trasporta le email su internet, è stato progettato in un'epoca basata sulla fiducia. Non esegue alcun controllo di identità sull'indirizzo From visibile. Questa singola lacuna di progettazione alimenta phishing e business email compromise (BEC) su scala industriale: l'Internet Crime Complaint Center dell'FBI ha attribuito al BEC circa 2,9 miliardi di dollari di perdite denunciate nel solo 2023. Quando i criminali falsificano il tuo dominio, i tuoi clienti vengono truffati e la tua deliverability ne risente: i provider di posta non riescono a distinguere le tue campagne reali dai falsi.

L'autenticazione risolve il problema con tre protocolli complementari basati sul DNS:

• SPF dichiara quali server sono autorizzati a inviare posta per il tuo dominio
• DKIM firma crittograficamente ogni messaggio, rendendo rilevabili manomissioni e falsificazioni
• DMARC collega entrambi all'indirizzo From visibile e indica ai server riceventi cosa fare quando i controlli falliscono

L'obbligo di Gmail e Yahoo

A febbraio 2024 Google e Yahoo hanno trasformato best practice consolidate in requisiti obbligatori. Tutti i mittenti devono autenticarsi con almeno SPF o DKIM. I mittenti che superano circa 5.000 messaggi al giorno verso un provider devono avere sia SPF sia DKIM, più una policy DMARC (come minimo p=none), un dominio From allineato con l'autenticazione, una disiscrizione con un clic gestita entro due giorni e un tasso di segnalazioni di spam inferiore allo 0,3%. La posta non conforme viene prima rallentata con errori temporanei e poi rifiutata del tutto. Nel 2025 Microsoft ha annunciato requisiti equivalenti per i mittenti ad alto volume verso Outlook.com, quindi la direzione del settore è inequivocabile.

L'adozione cresce ma è tutt'altro che universale: l'analisi di EasyDMARC sui primi 1,8 milioni di domini al mondo ha rilevato che il 47,7% aveva un record DMARC nel 2025, e gli studi di settore mostrano costantemente che una quota elevata dei record pubblicati è ancora ferma alla policy di solo monitoraggio p=none, che non offre alcuna protezione reale dallo spoofing. Fare le cose per bene è ancora un vantaggio competitivo.

SPF: Sender Policy Framework

Come funziona SPF

SPF è un record DNS TXT che elenca tutti i server autorizzati a inviare posta per conto del tuo dominio. Quando un server ricevente accetta una connessione, esamina il dominio del Return-Path (detto anche envelope from o indirizzo MAIL FROM, non l'intestazione From che vedono i destinatari), recupera il record SPF di quel dominio e verifica se l'IP che si connette è nell'elenco. Se c'è, SPF passa; altrimenti SPF fallisce o restituisce un soft fail, a seconda della tua policy.

La sintassi del record, passo dopo passo

Un record SPF tipico per un'azienda che usa Google Workspace, una piattaforma di marketing e un IP di invio dedicato è fatto così:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 ~all"

Leggendolo da sinistra a destra:

• v=spf1 — il tag di versione; ogni record SPF inizia così
• include:_spf.google.com — autorizza i server di invio di Google Workspace facendo riferimento al record SPF di Google
• include:servers.mcsv.net — autorizza una piattaforma di marketing (Mailchimp, in questo esempio)
• ip4:203.0.113.10 — autorizza uno specifico indirizzo IPv4, ad esempio il tuo server SMTP
• ~all — la regola finale: qualsiasi server non elencato riceve un soft fail. Il qualificatore conta: -all è un hard fail (consigliato quando il record è completo), ~all è un soft fail e +all autorizza l'intera internet: non usarlo mai

Il limite di 10 lookup DNS

L'RFC 7208 limita la valutazione SPF a 10 lookup DNS. Ogni meccanismo include, a, mx, ptr ed exists conta, e gli include vengono conteggiati in modo ricorsivo, quindi l'include di una sola piattaforma di marketing può consumare da solo tre o quattro lookup. Se superi il limite, i server riceventi restituiscono permerror, che molti provider trattano come un fallimento SPF. I meccanismi ip4 e ip6 semplici non costano nulla: preferiscili quando possibile, rimuovi i servizi che non usi più e valuta lo SPF flattening se hai legittimamente bisogno di molti provider.

Errori comuni con SPF

• Pubblicare più record SPF. Un dominio deve avere esattamente un record che inizia con v=spf1. Due record producono un errore permanente e la validazione fallisce. Unisci tutti i meccanismi in un unico record.
• Usare +all. Comunica al mondo che qualsiasi server può inviare a tuo nome: di fatto disattiva SPF e segnala il tuo dominio come configurato male.
• Dimenticare un servizio di invio. Helpdesk, sistema di fatturazione e CRM inviano tutti posta. Se non sono nel record, i loro messaggi ricevono un soft fail.
• Lasciare invecchiare il record. I servizi dismessi lasciano include orfani che sprecano lookup e possono creare esposizioni di sicurezza.
• Dare per scontato che SPF copra il From visibile. Controlla solo il Return-Path. L'allineamento con l'intestazione From è compito di DMARC, ed è per questo che SPF da solo ferma ben poco spoofing.

DKIM: DomainKeys Identified Mail

Come funziona la firma DKIM

DKIM aggiunge una firma crittografica a ogni messaggio in uscita. Il tuo server di invio custodisce una chiave privata e firma un hash del corpo del messaggio più alcune intestazioni selezionate (From, Subject, Date e altre). La chiave pubblica corrispondente è pubblicata nel tuo DNS e il server ricevente la usa per verificare la firma. Una firma valida dimostra due cose: il messaggio è stato autorizzato dal dominio che lo ha firmato e il contenuto firmato non è stato modificato durante il transito. A differenza di SPF, una firma DKIM sopravvive all'inoltro, il che la rende il più robusto dei due meccanismi.

I selettori e il record DNS

La chiave pubblica risiede in un nome DNS costruito a partire da un selettore: selector._domainkey.yourdomain.com. I selettori permettono la coesistenza di più chiavi: una per ogni servizio di invio, oppure la vecchia e la nuova durante la rotazione. Un record di chiave pubblicato ha questo aspetto:

s1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Zx8...IDAQAB"

E ogni messaggio firmato contiene un'intestazione che vi fa riferimento:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s1;
  h=from:subject:date:to:mime-version; bh=Kx9c1...; b=HqTf3...

Il tag d= indica il dominio firmatario e il tag s= il selettore: insieme dicono al server ricevente esattamente dove recuperare la chiave pubblica.

Lunghezza e rotazione delle chiavi

• Usa chiavi RSA a 2048 bit. Le chiavi a 1024 bit sono considerate deboli e alcuni provider le penalizzano; 2048 bit è lo standard attuale ed è ciò che raccomanda Google.
• Ruota le chiavi regolarmente. La best practice M3AAWG prevede di ruotare le chiavi DKIM almeno ogni sei mesi. Pubblica la nuova chiave con un nuovo selettore, cambia la firma e poi ritira il vecchio record dopo qualche giorno.
• Firma con il tuo dominio. Molte piattaforme firmano per impostazione predefinita con il proprio dominio (il che autentica la posta ma non la allinea con il tuo indirizzo From). Completa la configurazione DKIM con dominio personalizzato della piattaforma, in modo che d= corrisponda al tuo dominio.

DMARC: policy, report e allineamento

SPF e DKIM verificano ciascuno qualcosa, ma nessuno dei due controlla l'indirizzo che i destinatari vedono davvero. DMARC chiude il cerchio: un messaggio supera DMARC solo se SPF o DKIM passano e il dominio che ha superato il controllo è allineato con il dominio From visibile. DMARC permette inoltre di pubblicare una policy che dice ai server riceventi cosa fare con i fallimenti e fornisce report per vedere chi sta inviando a nome del tuo dominio, in modo legittimo o no.

Il record DMARC e la progressione delle policy

DMARC è un record TXT in _dmarc.yourdomain.com. Un record iniziale sensato:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"

Il tag p= è il cuore del record ed è pensato per essere reso più restrittivo per gradi:

• p=none — solo monitoraggio. La posta che fallisce viene recapitata normalmente, ma ricevi i report. Ogni implementazione parte da qui.
• p=quarantine — la posta che fallisce finisce nello spam. Usa pct= per procedere gradualmente: ad esempio p=quarantine; pct=25 applica la policy a un quarto dei messaggi che falliscono.
• p=reject — la posta che fallisce viene rifiutata del tutto. È il traguardo: protezione completa dallo spoofing e prerequisito per BIMI.

Un record in enforcement avrà alla fine questo aspetto:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"

I report rua e ruf

Il tag rua= richiede i report aggregati: riepiloghi XML giornalieri di ciascun provider ricevente che mostrano quali IP hanno inviato a nome del tuo dominio, cosa ha superato i controlli e cosa no. Non contengono il contenuto dei messaggi e sono lo strumento principale per scoprire servizi di invio dimenticati. Il tag ruf= richiede i report di errore (forensi): campioni dei singoli messaggi che hanno fallito. Pochi provider li inviano e possono contenere dati personali, quindi la maggior parte dei team si affida solo ai rua, elaborati tramite uno strumento di reportistica DMARC invece di leggerli grezzi.

Allineamento: relaxed o strict

L'allineamento è il punto in cui si verificano la maggior parte dei fallimenti DMARC nel mondo reale. I tag aspf= e adkim= controllano quanto il dominio autenticato debba corrispondere al dominio From. In modalità relaxed (r, quella predefinita) basta una corrispondenza a livello di sottodominio: la posta da news.yourdomain.com è allineata con yourdomain.com. In modalità strict (s) i domini devono coincidere esattamente. Parti con relaxed e passa a strict solo quando i report mostrano che non bloccherai posta legittima. Ricorda: l'allineamento SPF confronta il dominio del Return-Path, l'allineamento DKIM confronta il dominio d=, e basta che uno dei due passi con allineamento perché DMARC venga superato.

I tre protocolli a colpo d'occhio

Piano di implementazione passo dopo passo

1. Censisci tutti i servizi di invio (settimana 1). Fai l'inventario di tutto ciò che invia a nome del tuo dominio: suite di posta, piattaforma di marketing, CRM, helpdesk, fatturazione, avvisi di monitoraggio. Se ne dimentichi uno, in seguito ne bloccherai la posta.
2. Pubblica o correggi SPF (settimana 1). Un solo record, tutte le fonti legittime, meno di 10 lookup, terminato con ~all (da rendere più restrittivo con -all in seguito).
3. Attiva DKIM ovunque (settimane 1-2). Abilita la firma DKIM con dominio personalizzato e chiavi a 2048 bit su ogni piattaforma emersa dal censimento, e verifica ciascuna con un messaggio di prova.
4. Pubblica DMARC con p=none e report rua (settimana 2). Nessun impatto sul recapito: stai solo raccogliendo dati.
5. Monitora per 4-6 settimane. Esamina i report aggregati ogni settimana. Correggi ogni fonte legittima che non supera l'allineamento; ciò che continua a fallire è spoofing.
6. Stringi gradualmente. Passa a p=quarantine; pct=25, sali fino a pct=100, mantieni per un paio di settimane e poi passa a p=reject. Continua a monitorare: nuovi strumenti e fornitori continueranno a comparire.

Oltre DMARC: due parole su BIMI

Una volta raggiunto l'enforcement, BIMI (Brand Indicators for Message Identification) permette ai provider di posta aderenti di mostrare il tuo logo verificato accanto ai messaggi. Richiede DMARC con p=quarantine o p=reject e pct=100, un logo in formato SVG e, per la spunta blu di verifica di Gmail, un Verified Mark Certificate legato a un marchio registrato (Google accetta anche i Common Mark Certificate per la visualizzazione del logo). BIMI non modifica direttamente il filtraggio, ma il segno di fiducia visibile aiuta in modo misurabile riconoscibilità ed engagement, ed è una bella ricompensa per aver completato il percorso DMARC.

Autenticazione + validazione delle liste: lo stack completo

Ecco la parte che molte guide saltano: l'autenticazione dimostra chi sei, non che la tua posta sia desiderata. I provider di posta combinano entrambi i segnali. Un mittente perfettamente autenticato che invia in massa a una lista obsoleta genera comunque bounce e segnalazioni di spam, e la soglia dello 0,3% di segnalazioni di Gmail si applica a prescindere dalla tua policy DMARC. Tassi di bounce elevati danneggiano proprio quella reputazione del mittente che l'autenticazione dovrebbe proteggere.

Ecco perché autenticazione e igiene delle liste sono due metà della stessa strategia di deliverability. AT Valid esegue oltre 20 controlli di verifica, tra cui sintassi, MX, SMTP, rilevamento di indirizzi usa e getta e catch-all, con un'accuratezza del 99,5%, così ogni messaggio che firmi con DKIM ha davvero una inbox reale ad attenderlo. Valida al momento della raccolta tramite l'API, oppure ripulisci in blocco le liste esistenti con le integrazioni native per Salesforce, HubSpot, Mailchimp, RD Station, Pipedrive, Zapier e webhook. La nostra guida completa alla deliverability email spiega come le due discipline si rafforzano a vicenda.

Conclusione

SPF, DKIM e DMARC formano un sistema di identità a più livelli: SPF autorizza i server, DKIM firma il contenuto, DMARC allinea entrambi con l'indirizzo che vedono i destinatari e applica il risultato. Dopo l'obbligo di Gmail e Yahoo, sono requisiti di base, non opzioni avanzate, e il percorso è ben tracciato: censisci i mittenti, pubblica SPF, attiva DKIM a 2048 bit, monitora con p=none e poi stringi fino a p=reject.

Fallo insieme a una validazione continua delle liste e risponderai a entrambe le domande che si pone un provider di posta: questo mittente è autentico, e questa posta è desiderata? Pronto a completare il tuo stack di deliverability? Inizia con 200 crediti di validazione gratuiti e scopri la differenza che fa un'email autenticata e validata.