DMARC DKIM SPF: come autenticare le email aziendali
SPF, DKIM e DMARC sono tre record DNS che decidono se le email del tuo dominio aziendale arrivano nella inbox dei destinatari o finiscono dritte nello spam, e nel 2026 non sono più opzionali.
Sono sigle che spaventano, lette così. In realtà ognuna risponde a una domanda semplice e specifica, e configurate insieme rendono il tuo dominio email autenticato, riconosciuto come legittimo dai grandi provider di posta, e molto più difficile da impersonare per chi vuole inviare phishing a nome tuo. Negli ultimi anni Google, Yahoo e Microsoft hanno iniziato a richiedere queste configurazioni come requisito minimo per consegnare email di mittenti che inviano regolarmente verso i loro utenti. Senza, le tue email partono già con il freno tirato.
In questo articolo vediamo cosa fa ciascuno dei tre record, perché ne servono tutti e tre, cosa va impostato a livello di DNS, quali errori incontriamo più spesso quando arriviamo su un dominio nuovo da configurare, e come verificare alla fine che tutto funzioni davvero. Lo facciamo dal punto di vista pratico di chi questi record li configura tutti i giorni sui domini dei clienti, non da quello teorico di chi ha letto l'RFC.
Cosa sono SPF, DKIM e DMARC (e perché esistono tutti e tre)
Il problema che SPF, DKIM e DMARC risolvono insieme è semplice da raccontare: chiunque, nel mondo, può inviare una email mettendo come mittente un indirizzo del tuo dominio. È un limite del protocollo SMTP, nato negli anni ottanta in un contesto dove non si pensava al phishing, dove tutti si fidavano di tutti, e dove non esistevano impersonificatori industriali. Una persona malintenzionata oggi può inviare una email firmata "
I tre record DNS sono nati nel tempo per rispondere a tre domande diverse, complementari. SPF risponde a "quali server sono autorizzati a inviare email per il mio dominio?". DKIM risponde a "questa email è stata effettivamente firmata dal mittente, o è stata alterata in transito?". DMARC risponde a "cosa deve fare il destinatario quando un controllo SPF o DKIM fallisce, e dove può segnalarmi il problema?". Solo i tre messi insieme danno una risposta completa, e questo è il motivo per cui non basta configurarne uno o due: servono tutti e tre, e devono parlarsi correttamente.
Da febbraio 2024 Google e Yahoo hanno iniziato a richiedere queste configurazioni come requisito per chi invia volumi significativi verso i loro utenti, e Microsoft ha seguito a ruota. Per qualunque dominio aziendale che mandi anche solo cento email al giorno, oggi non è più una buona pratica: è un requisito infrastrutturale.
SPF: dichiarare chi può inviare email per il tuo dominio
SPF, acronimo di Sender Policy Framework, è il più vecchio dei tre. È un record TXT che si pubblica nel DNS del proprio dominio e che contiene la lista degli indirizzi IP e dei server autorizzati a inviare email per quel dominio. Un esempio semplice: se la tua azienda usa Google Workspace per le email aziendali e Brevo per le newsletter, il record SPF dichiarerà che entrambi sono mittenti autorizzati. Qualunque altro server che provi a inviare email a nome del tuo dominio fallirà il controllo SPF.
Un record SPF tipico per un dominio che usa Google Workspace ha questa forma: v=spf1 include:_spf.google.com ~all. La parte "v=spf1" identifica il record come SPF, "include" autorizza il blocco di IP di Google, "~all" indica come trattare tutti gli altri mittenti, in questo caso con un soft fail. Se serve aggiungere un altro provider, lo si concatena con un secondo "include": ad esempio v=spf1 include:_spf.google.com include:spf.brevo.com ~all.
Il punto su cui chi configura SPF da solo inciampa più spesso è la regola del massimo di dieci lookup DNS: se il record SPF, espandendo gli "include", supera dieci interrogazioni DNS, tutto il record viene considerato non valido. Aggiungere troppi servizi senza ottimizzare significa rompere l'autenticazione invece di rafforzarla, e questo è uno dei motivi per cui l'audit periodico del record SPF è una buona pratica.
DKIM: firmare le email per dimostrare che sono autentiche
SPF dice chi può inviare. DKIM, acronimo di DomainKeys Identified Mail, dice qualcosa di diverso: che la specifica email che hai ricevuto è stata firmata da chi dice di averla mandata, e che il contenuto non è stato modificato durante il viaggio. Funziona con una coppia di chiavi crittografiche, una privata che resta sul server di invio e firma ogni email in uscita, e una pubblica pubblicata nel DNS che il destinatario usa per verificare la firma.
Il vantaggio di DKIM rispetto a SPF è che resiste meglio agli inoltri. Quando una email viene inoltrata, l'IP del mittente cambia, e SPF da solo fallisce. La firma DKIM invece viaggia con il messaggio: anche dopo un inoltro, la firma resta valida e il destinatario finale può verificare che il contenuto originale è autentico.
Il record DKIM si pubblica come record TXT nel DNS, sotto un nome convenzionale che dipende dal "selettore" usato dal servizio di invio. Ogni servizio, Google Workspace, Microsoft 365, Brevo, MailUp, ha un proprio selettore e una propria chiave da pubblicare. La parte tecnica viene gestita dal provider che fornisce le istruzioni precise: il compito di chi gestisce il dominio è incollare i record corretti nel DNS senza errori di battitura, e verificare che la chiave pubblicata sia effettivamente quella attesa dal provider.
DMARC: dire ai destinatari cosa fare quando qualcosa non torna
DMARC è il livello sopra. SPF e DKIM dicono ai destinatari come verificare l'autenticità delle email. DMARC, acronimo di Domain-based Message Authentication, Reporting and Conformance, dice ai destinatari cosa fare quando i controlli SPF o DKIM falliscono, e come segnalare al mittente cosa sta succedendo.
Senza DMARC, ogni provider di posta decide autonomamente come trattare le email che falliscono i controlli: alcuni le mettono in spam, altri le rifiutano, altri ancora le consegnano lo stesso. Con DMARC sei tu, proprietario del dominio, a dire come vanno gestite. Le tre policy possibili sono: none, ovvero "consegna comunque ma mandami un report", quarantine, "metti in spam", e reject, "rifiuta proprio".
L'altra parte importante di DMARC è la reportistica. Configurando un indirizzo email nei parametri "rua" e "ruf" del record, ricevi report periodici dai provider di posta che ti dicono quante email a nome del tuo dominio sono passate, quante hanno fallito SPF, quante hanno fallito DKIM, e da quali IP. È il modo più chiaro per scoprire che qualcuno sta tentando di inviare email a nome tuo, o che un servizio legittimo che usi ha problemi di configurazione.
Un record DMARC tipico per iniziare ha questa forma: v=DMARC1; p=none; rua=mailto:
Configurare i record DNS: cosa devi sapere prima di toccare nulla
Prima di mettere mano al DNS del dominio, ci sono tre cose da chiarire. La prima è dove è gestito il DNS: spesso non è dove pensi. Su molti domini italiani il DNS è gestito dal registrar (Aruba, OVH, Register) ma può essere anche su Cloudflare, su Google Cloud DNS, su un servizio dedicato dell'hosting. Ogni pannello ha la sua interfaccia, ma la logica dei record TXT è la stessa: nome, tipo, valore.
La seconda è la lista completa dei mittenti che inviano a nome del tuo dominio. È quasi sempre più lunga di quanto pensi: il server di posta principale, la piattaforma di newsletter, il CRM, il software di assistenza clienti, l'eventuale servizio di SMS che invia anche email transazionali, il gestionale che spedisce le fatture in PDF. Ognuno di questi va censito e, se autorizzato, va incluso in SPF e configurato per firmare con DKIM.
La terza è la propagazione DNS. Le modifiche ai record DNS non sono istantanee: a seconda del TTL impostato e della rete del destinatario, possono volerci da pochi minuti a qualche ora prima che siano effettive ovunque. Significa che dopo aver pubblicato un record nuovo, i test vanno ripetuti dopo un po' di tempo, non subito. Significa anche che durante una migrazione o un cambio di provider, va lasciato il vecchio record SPF in vigore finché il nuovo non è stato propagato e verificato, altrimenti per qualche ora il dominio resta scoperto.
Errori comuni che vediamo sui clienti
Negli interventi di configurazione SPF/DKIM/DMARC sui domini dei clienti, alcuni errori si ripetono con regolarità. Vale la pena sapere quali sono per evitare di farli.
Il primo è avere più record SPF sullo stesso dominio. Quando arriva un nuovo provider e qualcuno aggiunge un secondo record TXT che inizia con "v=spf1" invece di estendere il primo, l'autenticazione si rompe: per le specifiche, un dominio deve avere un solo record SPF. Si controlla con MXToolbox e si corregge unificando i due in uno solo.
Il secondo è configurare DMARC senza prima aver verificato SPF e DKIM. Mettere subito una policy "reject" su un dominio dove SPF è incompleto o DKIM non è ben firmato significa fare finire in spam tutte le email legittime. La regola d'oro è andare per gradi: prima si sistemano SPF e DKIM, poi si pubblica DMARC con policy "none", poi si raccolgono report per qualche settimana, e solo a quel punto si alza la policy.
Il terzo è non includere tutti i mittenti reali in SPF. Capita frequentemente che un cliente ci dica "le mie newsletter da Brevo arrivano in spam" e scopriamo che SPF è configurato solo per Google Workspace, dimenticando completamente Brevo. È un errore semplice da identificare con i report DMARC, ma se DMARC non è ancora stato attivato, il problema può durare mesi senza che nessuno se ne accorga.
Il quarto è copiare e incollare record di esempio trovati online senza adattarli. Non esiste un record SPF universale: dipende dai mittenti che usi. Non esiste una chiave DKIM da copiare: ogni provider te ne fornisce una specifica. Le guide generiche sono utili per capire la logica, ma il record da pubblicare va sempre costruito sul tuo caso specifico.
Cosa cambia se sei su Google Workspace, Microsoft 365 o hosting tradizionale
Le tre situazioni più comuni sono queste. Se usi Google Workspace, Google ti fornisce sia un blocco SPF già pronto da includere, sia il pannello per generare le chiavi DKIM. La parte sotto il tuo controllo è pubblicare correttamente il record SPF, generare la chiave DKIM dal pannello Workspace, pubblicarla nel DNS e poi tornare nel pannello per attivare la firma. La parte DMARC è separata: non c'è nel pannello di Workspace, va aggiunta a mano nel DNS.
Se usi Microsoft 365, la logica è la stessa ma i pannelli e i parametri sono diversi. Microsoft ha CNAME predefiniti per DKIM che vanno pubblicati e poi attivati nel pannello Exchange Admin. Anche qui DMARC è separato e va gestito nel DNS.
Se usi un hosting tradizionale con caselle email del provider tipo Aruba, Register, OVH, la situazione è meno standardizzata. Alcuni hosting offrono SPF e DKIM già configurati di default, altri richiedono l'attivazione esplicita, altri ancora non offrono DKIM senza upgrade del piano. Va verificato caso per caso, leggendo la documentazione del provider e, se necessario, contattando l'assistenza.
Per qualunque caso, se il dominio invia anche newsletter o DEM da una piattaforma esterna, vanno aggiunti i record specifici di quella piattaforma sopra a quelli dell'email principale. Approfondiremo il discorso del recapito nel dettaglio nell'articolo dedicato a come capire perché le email finiscono in spam.
Verifica finale: come capire se hai configurato bene tutto
Una volta pubblicati i tre record, la verifica si fa in tre passaggi. Il primo è andare su MXToolbox, inserire il proprio dominio e usare i tool dedicati: SPF Lookup, DKIM Lookup con il selettore corretto, DMARC Lookup. Tutti e tre dovrebbero restituire i record con stato verde, senza warning.
Il secondo è inviare una email di test verso un account Gmail e, una volta ricevuta, aprirla e guardare i dettagli del messaggio attraverso la voce "Mostra originale". In testa al messaggio originale Gmail riporta lo stato di SPF, DKIM e DMARC: tutti e tre devono risultare "PASS". Se uno dei tre dice "fail" o "neutral", c'è qualcosa da rivedere.
Il terzo è attendere qualche giorno e iniziare a ricevere i report DMARC aggregati all'indirizzo configurato in "rua". Sono file XML un po' criptici da leggere a mano, ma esistono servizi gratuiti che li convertono in dashboard leggibili. Vedere i report con tutti i flussi di posta in regola, da tutti i mittenti legittimi, è la conferma definitiva che la configurazione regge.
Il lavoro vero, una volta che tutto è in piedi, non è quello iniziale: è il monitoraggio nel tempo. Ogni nuovo strumento che inizia a inviare email a nome del tuo dominio va censito e aggiunto a SPF e DKIM. Ogni alert nei report DMARC va investigato, perché può essere il segnale di un servizio che si è rotto, oppure di qualcuno che sta tentando di impersonare il tuo dominio. La sicurezza email non è un check una tantum, è una manutenzione che vive con l'azienda.
Verifichiamo la configurazione email del tuo dominio
Articolo di Marco Galassi
