SPF, DKIM e DMARC sono tre record DNS che dicono ai server di posta del mondo una cosa sola: questa email arriva davvero dalla tua azienda. SPF elenca i server autorizzati a spedire per il tuo dominio, DKIM firma ogni messaggio con una chiave crittografica, DMARC verifica che i due controlli siano coerenti con il mittente visibile e decide cosa fare se non lo sono. Senza questi tre record le tue offerte, fatture e conferme d’ordine rischiano lo spam, e chiunque può spedire email false a nome tuo. In questa guida trovi come funzionano, come si configurano passo dopo passo e quali errori bloccano più spesso le PMI.
In breve
- SPF autorizza i server che possono inviare email per il tuo dominio; DKIM firma i messaggi; DMARC controlla l’allineamento con l’indirizzo “Da:” e stabilisce la policy.
- Dal 1° febbraio 2024 Gmail richiede l’autenticazione a tutti i mittenti; chi supera i 5.000 messaggi al giorno deve avere tutti e tre i record.
- DMARC si attiva per gradi: si parte da
p=none, si leggono i report, solo dopo si passa aquarantineereject. - L’errore più comune è dimenticare un servizio che spedisce a nome tuo: CRM, gestionale, fatturazione, newsletter.
- La PEC ha valore legale, ma non protegge il dominio della posta ordinaria: servono comunque SPF, DKIM e DMARC.
Indice
- Perché oggi l’autenticazione email non è più facoltativa
- SPF: chi può spedire per il tuo dominio
- DKIM: la firma che garantisce l’integrità
- DMARC: la regola che tiene insieme tutto
- SPF, DKIM e DMARC a confronto
- Come configurarli: il percorso in sei passi
- Gli errori che vediamo più spesso nelle PMI
- Inoltri e mailing list: il caso che manda in crisi DMARC
- PEC e DMARC: due strumenti diversi
- Il nostro punto di vista
- Come possiamo aiutarti
- Domande frequenti
- Fonti
Perché oggi l’autenticazione email non è più facoltativa
Per anni SPF, DKIM e DMARC sono stati una “buona pratica” che molte aziende rimandavano. Oggi sono un requisito tecnico. Secondo le linee guida di Gmail per i mittenti, dal 1° febbraio 2024 chiunque invii email ad account Gmail deve configurare almeno SPF o DKIM. Chi invia più di 5.000 messaggi al giorno deve avere SPF, DKIM e DMARC (con policy minima p=none), l’allineamento tra dominio del mittente e dominio autenticato, la disiscrizione con un clic per i messaggi commerciali e un tasso di spam segnalato sotto lo 0,3%.
Le conseguenze del mancato rispetto sono concrete. Le FAQ di Gmail sulle linee guida indicano che i messaggi non autenticati o con intestazione “Da:” non allineata possono ricevere codici di errore temporanei o permanenti, oppure finire nello spam.
C’è poi il tema sicurezza. Lo spoofing, cioè l’invio di email che sembrano provenire dal tuo dominio, è la base di molte truffe: il finto ordine al fornitore, la richiesta di cambio IBAN, il link a un falso portale. Un dominio senza DMARC non dice ai server riceventi come trattare questi falsi. Per una PMI manifatturiera, uno studio dentistico o un hotel, significa esporre clienti e partner a messaggi che portano il proprio nome.

SPF: chi può spedire per il tuo dominio
SPF (Sender Policy Framework) è definito dalla RFC 7208. È un record TXT pubblicato nel DNS del dominio che elenca gli indirizzi IP e i servizi autorizzati a inviare posta. Quando un server riceve un messaggio, controlla se l’IP di provenienza compare nell’elenco.
Un record SPF tipico per un’azienda che usa Google Workspace e un servizio esterno ha questa forma:
esempio.it. TXT "v=spf1 include:_spf.google.com include:spf.servizio-crm.example ~all"
Gli elementi da conoscere:
- v=spf1: identifica il record come SPF. Ne deve esistere uno solo per dominio.
- include:: delega l’autorizzazione ai server di un fornitore. Google indica
include:_spf.google.comnella sua guida alla configurazione di SPF. - ip4: / ip6:: autorizzano indirizzi specifici, ad esempio il server di posta interno o il gestionale che spedisce in proprio.
- ~all (softfail) o -all (fail): dicono come trattare tutto ciò che non è in elenco.
Il limite delle 10 ricerche DNS
Ogni include, a, mx e redirect costa una ricerca DNS, e la RFC 7208 fissa il tetto a 10 per singola valutazione. Superarlo produce un errore permanente: il record diventa di fatto inutile. È un problema frequente nelle aziende che, negli anni, hanno aggiunto un fornitore dopo l’altro senza mai fare pulizia. La soluzione è eliminare i servizi dismessi, sostituire gli include ridondanti con IP diretti dove possibile e verificare il conteggio dopo ogni modifica.
Il limite di SPF
SPF controlla il dominio della busta tecnica (il “MAIL FROM”, o Return-Path), non l’indirizzo che il destinatario vede nel campo “Da:”. Da solo, quindi, non impedisce a un truffatore di mostrare il tuo nome. Serve DMARC per collegare le due cose.
DKIM: la firma che garantisce l’integrità
DKIM (DomainKeys Identified Mail) aggiunge a ogni email una firma crittografica nell’intestazione. Il server che spedisce firma il messaggio con una chiave privata; la chiave pubblica corrispondente è pubblicata nel DNS del dominio. Il server ricevente la recupera e verifica due cose: che il messaggio sia stato firmato da chi controlla il dominio e che intestazioni e corpo non siano stati modificati lungo il percorso.
La chiave pubblica si trova sotto un “selettore”, un nome scelto dal fornitore:
google._domainkey.esempio.it. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Ogni servizio che spedisce per te (posta aziendale, CRM, piattaforma newsletter, software di fatturazione) dovrebbe avere il proprio selettore e la propria chiave. Così puoi ruotare o revocare una chiave senza toccare le altre.
Rispetto a SPF, DKIM ha un vantaggio importante: la firma viaggia con il messaggio, quindi in genere sopravvive a un inoltro semplice, purché il contenuto non venga alterato. Per questo è la gamba più solida dell’autenticazione. Il nostro consiglio pratico: dove il provider lo consente, usa chiavi RSA a 2048 bit e pianifica una rotazione periodica.

Come verificare che DKIM funzioni
Il metodo più rapido non richiede strumenti: invia un’email dal tuo dominio a un account Gmail, apri il messaggio e scegli “Mostra originale”. In alto trovi l’esito di SPF, DKIM e DMARC, con la dicitura PASS o FAIL. Nell’intestazione DKIM-Signature il campo d= indica il dominio firmatario e s= il selettore. Se d= riporta il dominio del fornitore anziché il tuo, la firma è valida ma non allineata, e DMARC non la conterà.
DMARC: la regola che tiene insieme tutto
DMARC (Domain-based Message Authentication, Reporting and Conformance) è descritto nella RFC 7489. Fa tre cose: verifica l’allineamento, applica una policy e invia report.
L’allineamento è il cuore del sistema. Un messaggio supera DMARC se almeno uno tra SPF e DKIM dà esito positivo e il dominio autenticato corrisponde a quello visibile nel campo “Da:”. È questo il passaggio che rende inutile lo spoofing del mittente.
Il record si pubblica come TXT sul sottodominio _dmarc:
_dmarc.esempio.it. TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@esempio.it; adkim=r; aspf=r"
| Tag | Funzione | Valori tipici |
|---|---|---|
p |
Policy per il dominio | none (solo monitoraggio), quarantine (spam), reject (rifiuto) |
sp |
Policy per i sottodomini | come p |
rua |
Indirizzo per i report aggregati | mailto: di una casella dedicata |
ruf |
Indirizzo per i report forensi | mailto: facoltativo, dettaglio sui singoli messaggi |
pct |
Percentuale di messaggi a cui applicare la policy | da 1 a 100 |
adkim / aspf |
Allineamento DKIM / SPF | r (rilassato, ammette sottodomini) o s (stretto) |
I report aggregati (RUA) sono file XML che i provider inviano ogni giorno: elencano quali IP hanno spedito a nome tuo, quanti messaggi e con quale esito. Sono lo strumento che ti fa scoprire il gestionale dimenticato o il fornitore che usa il tuo dominio senza firma.
SPF, DKIM e DMARC a confronto
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Domanda a cui risponde | Questo server può spedire per il dominio? | Il messaggio è integro e firmato dal dominio? | I controlli corrispondono al mittente visibile? Cosa faccio se no? |
| Dove si pubblica | TXT sul dominio | TXT su selettore._domainkey |
TXT su _dmarc |
| Cosa controlla | IP del server e dominio Return-Path | Firma crittografica di intestazioni e corpo | Allineamento con il campo “Da:” |
| Sopravvive all’inoltro | Di solito no | Sì, se il contenuto non cambia | Dipende da SPF e DKIM |
| Da solo basta? | No | No | No: ha bisogno di almeno uno degli altri due |
Come configurarli: il percorso in sei passi
- Fai l’inventario dei mittenti. Elenca ogni sistema che invia email con il tuo dominio: casella aziendale, CRM, gestionale, software di fatturazione, e-commerce, piattaforma newsletter, centralino che spedisce i messaggi vocali, stampanti multifunzione. Se il marketing usa uno strumento dedicato, un confronto tra le piattaforme di email marketing per agenzie aiuta a capire quali servizi sono in gioco e quali impostazioni di autenticazione offrono. Chiedi a ogni reparto: è il passaggio che evita più problemi.
- Pubblica un unico record SPF. Unisci tutti gli include in un solo TXT, controlla di restare sotto le 10 ricerche DNS e parti con
~all. - Attiva DKIM per ogni servizio. Genera la chiave dal pannello di ciascun fornitore, pubblica il record sul selettore indicato e attiva la firma. Verifica con “Mostra originale” che il campo
d=riporti il tuo dominio. - Pubblica DMARC in monitoraggio. Record con
p=nonee un indirizzoruadedicato. Nessun messaggio viene bloccato: raccogli solo dati. - Leggi i report. Per qualche settimana analizza chi spedisce a tuo nome. Ogni sorgente legittima che fallisce va sistemata in SPF o DKIM; ogni sorgente sconosciuta è un potenziale abuso.
- Stringi la policy per gradi. Passa a
p=quarantineconpctbasso, poi aumenta fino a 100, infinep=reject. Solo a questo punto il dominio è davvero protetto contro lo spoofing.
La RFC 7489 prevede proprio questo uso graduale: la policy none serve a osservare i flussi prima di chiedere ai riceventi di intervenire.
Gli errori che vediamo più spesso nelle PMI
- Due record SPF sullo stesso dominio. Capita quando un fornitore chiede di “aggiungere il suo record” e qualcuno ne crea uno nuovo invece di modificare quello esistente. Il risultato è un errore: vanno fusi in uno solo.
- Troppe ricerche DNS. Include accumulati negli anni, servizi dismessi mai rimossi. Oltre le 10 ricerche l’SPF fallisce.
- Passare subito a
p=reject. Le notifiche del gestionale, le fatture inviate dal software contabile o le email transazionali dell’e-commerce, se non autenticate, vengono rifiutate senza preavviso. - DKIM firmato con il dominio del fornitore. La firma è valida, ma non allineata: per DMARC è come se non ci fosse.
- Nuovo software, record vecchi. Si attiva un CRM o una piattaforma di marketing che spedisce a nome dell’azienda e nessuno aggiorna SPF e DKIM. Le email legittime finiscono nello spam.
- Report che nessuno legge. L’indirizzo
ruariceve centinaia di file XML che restano in una casella dimenticata. Senza lettura, DMARC resta fermo ap=noneper sempre. - Sottodomini scoperti. Un dominio protetto con un sottodominio senza policy lascia aperta una porta: usa il tag
sp.
Inoltri e mailing list: il caso che manda in crisi DMARC
Quando un’email viene inoltrata automaticamente, ad esempio da una vecchia casella a quella nuova, il server che la consegna non è più il tuo: SPF fallisce. Se una mailing list modifica oggetto o corpo aggiungendo un prefisso o un piè di pagina, anche la firma DKIM si rompe. La RFC 7960 descrive in dettaglio questi problemi di interoperabilità con i flussi indiretti.
Le contromisure principali sono tre: affidarsi a DKIM, che resiste meglio agli inoltri semplici; preferire, dove possibile, il recupero della posta via IMAP rispetto all’inoltro automatico; scegliere servizi di inoltro che supportano ARC (Authenticated Received Chain), un meccanismo che conserva l’esito dei controlli originali. Anche l’IETF ha adattato il proprio sistema di mailing list a DMARC, segno che il problema riguarda chiunque.
PEC e DMARC: due strumenti diversi
In Italia molte aziende pensano che la PEC risolva il problema. Non è così. La Posta Elettronica Certificata, disciplinata da AgID, dà valore legale alla comunicazione e attesta invio e consegna con data certa. Funziona però in un circuito dedicato, tra gestori accreditati.
Le offerte commerciali, le conferme d’ordine, le comunicazioni con i clienti esteri e le notifiche dei software aziendali viaggiano invece sulla posta ordinaria del tuo dominio. È lì che SPF, DKIM e DMARC fanno la differenza. Le due cose convivono: la PEC per ciò che richiede valore legale, la posta autenticata per tutto il resto.
Il nostro punto di vista
Nel nostro lavoro con le PMI italiane vediamo un pattern ricorrente. L’autenticazione email viene trattata come un’impostazione da fare una volta, delegata a chi ha registrato il dominio anni fa. Poi arrivano un nuovo CRM, un software per le presenze, un gestionale in cloud, e ognuno inizia a spedire email a nome dell’azienda. I record DNS restano fermi, le email finiscono nello spam e nessuno capisce perché.
Per noi SPF, DKIM e DMARC sono parte della cybersecurity aziendale, non un dettaglio del reparto IT. Un dominio senza DMARC è un’identità che chiunque può usare: per chiedere un bonifico, per far aprire un allegato, per arrivare al gestionale o alla piattaforma HR. Il vero bivio non è tra configurare o no questi record, ma tra un’autenticazione subita, sistemata solo quando qualcosa si rompe, e una guidata con consapevolezza. Noi scegliamo la seconda: inventario dei mittenti, monitoraggio dei report, policy stretta per gradi e verifica ogni volta che entra un nuovo software.
— Ufficio
Come possiamo aiutarti
Con il servizio di cybersecurity e sicurezza informatica per aziende affianchiamo le PMI nell’adeguamento a NIS2, ISO 27001 e GDPR, e la protezione del dominio email rientra in questo percorso. Se le email dell’azienda passano dal CRM, Processi integra una webmail aziendale IMAP multi-account che lavora con la tua casella esistente. Quando i messaggi arrivano in posta in arrivo conta anche come sono costruiti: leggi la nostra guida sull’HTML nelle email aziendali.
Domande frequenti
A cosa serve il DKIM?
Il DKIM serve a dimostrare che un’email è stata inviata da chi controlla il dominio e che non è stata modificata durante il percorso. Funziona con una coppia di chiavi: quella privata firma il messaggio, quella pubblica nel DNS permette di verificarlo. È anche il controllo che resiste meglio agli inoltri.
Cos’è un record SPF e cosa significa SPF in informatica?
SPF significa Sender Policy Framework. È un record TXT nel DNS del dominio che elenca i server e i servizi autorizzati a inviare email per quel dominio. Il server ricevente confronta l’IP di provenienza con l’elenco e decide se il messaggio è legittimo.
Come verificare DKIM, SPF e DMARC?
Invia un’email dal tuo dominio a un account Gmail e apri “Mostra originale”: trovi l’esito PASS o FAIL di tutti e tre i controlli. In alternativa puoi interrogare il DNS con il comando nslookup -type=txt sul dominio, su _dmarc.tuodominio.it e su selettore._domainkey.tuodominio.it. I report DMARC aggregati, infine, mostrano l’esito su tutti i messaggi inviati.
Basta DMARC con p=none per essere protetti?
No. Con p=none soddisfi il requisito minimo di Gmail per chi invia grandi volumi, ma non chiedi ai server riceventi di bloccare i falsi. La protezione contro lo spoofing arriva solo con quarantine o reject, da attivare dopo aver analizzato i report e autenticato tutti i mittenti legittimi.
Una piccola azienda che invia poche email deve configurarli?
Sì. Gmail richiede almeno SPF o DKIM a tutti i mittenti, indipendentemente dal volume. E il rischio di spoofing non dipende da quante email invii tu, ma da quanto il tuo nome è credibile per chi riceve un messaggio falso.
Fonti
- Gmail: linee guida per i mittenti di email
- Gmail: FAQ sulle linee guida per i mittenti
- Google Workspace: configurare SPF
- RFC 7208: Sender Policy Framework (SPF)
- RFC 7489: DMARC
- RFC 7960: DMARC e flussi email indiretti
- IETF: uso di DMARC nel sistema di posta IETF
- AgID: Posta Elettronica Certificata