SPF, DKIM e DMARC: cosa sono e come migliorano la consegna delle email

Il punto è che si tende a trattarle come tre caselle da spuntare. Non lo sono: sono tre pezzi di un unico meccanismo, che serve a rispondere a una domanda semplice — questa email arriva davvero da chi dice di essere? — e che funziona solo se i tre pezzi parlano fra loro.

Qui vediamo cosa fa ciascuno, cosa non fa, dove si rompono le configurazioni nella pratica, cosa chiedono i grandi provider nel 2026 e perché, anche quando tutto è a posto, le email possono comunque finire nello spam.

Perché SPF, DKIM e DMARC vengono sempre citati insieme

Il protocollo con cui viaggiano le email è nato in un'epoca in cui la fiducia si dava per scontata. Chi invia un messaggio può scrivere nel campo «Da» qualunque indirizzo, e il sistema di per sé non lo verifica. È lo stesso motivo per cui un'email di phishing può sembrare arrivare dalla tua banca: nessuno ha chiesto alla banca il permesso.

SPF, DKIM e DMARC sono tre standard nati in momenti diversi per chiudere questa falla, ognuno da un lato:

• SPF risponde a «questo server aveva il permesso di inviare per questo dominio?»
• DKIM risponde a «questo messaggio è arrivato integro, ed è firmato da un dominio che ne risponde?»
• DMARC risponde a «i due controlli sopra riguardano davvero il dominio che il destinatario vede, e cosa chiede il proprietario del dominio se non tornano?»

Presi da soli, i primi due hanno buchi evidenti — li vediamo tra poco. Il terzo esiste proprio per coprirli. Per questo vengono citati insieme, e per questo configurarne uno o due e ignorare il terzo lascia il lavoro a metà.

Per chi fa email marketing questa non è più una curiosità tecnica. Dal 2024 Gmail e Yahoo, e dal 2025 Microsoft per Outlook.com, hanno reso l'autenticazione una condizione per consegnare email ai loro utenti — con requisiti diversi a seconda dei volumi. Se mandi newsletter, email di carrello abbandonato o conferme d'ordine, ti riguarda.

SPF: chi può inviare email per il tuo dominio

SPF (Sender Policy Framework) è un elenco pubblicato nel DNS del tuo dominio — la «rubrica» pubblica che associa il nome del dominio ai suoi servizi — in cui dichiari quali server e quali servizi sono autorizzati a inviare email per tuo conto.

Quando il tuo messaggio arriva a Gmail, il server di Gmail guarda da quale indirizzo IP è partito, va a leggere l'elenco SPF del dominio e verifica se quell'IP è compreso. Se sì, SPF passa. Se no, fallisce.

Il record ha una forma di questo tipo: un elenco di meccanismi (include: per delegare a un servizio esterno, ip4: per un indirizzo specifico, e così via) chiuso da un'istruzione che dice come trattare tutto ciò che non è in lista — ~all (softfail: sospetto ma non bloccare) oppure -all (fail: non autorizzato). Non serve saperlo scrivere; serve sapere una cosa precisa: nello SPF di un dominio devono esserci tutti i servizi che usano quel dominio come indirizzo tecnico di ritorno — il Return-Path, di cui parliamo subito sotto. Il server della posta aziendale, il gestionale che manda le fatture, l'help desk, e la piattaforma di newsletter se è configurata per usare il tuo dominio nel Return-Path. Se invece un servizio usa un proprio dominio come Return-Path, è lo SPF di quel dominio a essere verificato, e nel tuo record non va aggiunto nulla.

Quale dominio controlla davvero SPF

Ed ecco il primo punto che quasi nessuno spiega. Ogni email ha due «mittenti»: quello che vedi nel campo «Da» e un indirizzo tecnico di ritorno, invisibile nei client di posta, che serve per rimandare indietro i messaggi non consegnati. Si chiama Return-Path (o envelope sender, o MAIL FROM).

SPF controlla il dominio del Return-Path, non quello del campo «Da».

Nella pratica cambia molto. Quando invii da una piattaforma esterna, molto spesso il Return-Path è un dominio della piattaforma stessa — perché è lei che gestisce i rimbalzi. In quel caso SPF viene verificato sul dominio della piattaforma, passa tranquillamente, e non ha detto nulla sul tuo dominio. È il motivo per cui SPF da solo non protegge il campo «Da»: un malintenzionato può usare un Return-Path suo, con un SPF perfetto, e scrivere nel «Da» il tuo indirizzo.

Su questo torneremo con DMARC, perché è esattamente il problema che DMARC risolve.

I limiti pratici di SPF

Tre cose che rompono SPF più spesso di quanto si pensi:

• Il record deve essere uno solo. Se nel DNS ci sono due record SPF per lo stesso dominio — succede quando ogni fornitore dice «aggiungi questo record» e nessuno controlla — il risultato secondo lo standard è un errore permanente, che equivale a non avere SPF. La soluzione è un solo record che include tutti i servizi.
• C'è un tetto ai riferimenti esterni. La specifica SPF (RFC 7208) fissa a dieci il numero massimo di meccanismi che richiedono una ricerca DNS (include, a, mx e simili) per una singola verifica. Ogni include: ne consuma almeno uno, e i servizi che includi a loro volta ne consumano altri. Superato il limite, la verifica fallisce con un errore permanente. Con quattro o cinque fornitori diversi lo si raggiunge senza accorgersene.
• L'inoltro lo rompe. Se un destinatario inoltra automaticamente la tua email a un altro indirizzo, il messaggio riparte dal server di chi inoltra, il cui IP non è nel tuo SPF. SPF fallisce, senza colpa tua. È uno dei motivi per cui non conviene affidarsi solo a SPF: DKIM, come vediamo ora, sopravvive all'inoltro.

DKIM: la firma che viaggia con il messaggio

DKIM (DomainKeys Identified Mail) funziona con una logica diversa. Invece di guardare da dove parte il messaggio, guarda il messaggio stesso.

Quando invii un'email, il server che la spedisce calcola un'impronta di alcune parti del messaggio — tipicamente intestazioni come mittente, destinatario e oggetto, più il corpo — e la cifra con una chiave privata che solo lui possiede. Il risultato è una firma che viene aggiunta al messaggio in un'intestazione dedicata, invisibile a chi legge.

La chiave pubblica corrispondente è pubblicata nel DNS del dominio firmatario. Il server che riceve la usa per verificare la firma: se torna, significa due cose insieme — che il messaggio è stato firmato da chi possiede quella chiave privata, e che le parti firmate non sono state modificate nel tragitto.

Vale la pena essere precisi su cosa DKIM non fa: non cifra il contenuto. Il messaggio viaggia leggibile; la firma garantisce integrità e provenienza, non riservatezza.

Selector e dominio firmatario

Un dominio può avere più chiavi DKIM contemporaneamente — una per la piattaforma di newsletter, una per la posta aziendale, una per il gestionale. Per distinguerle si usa un'etichetta chiamata selector: la chiave pubblica si trova nel DNS a un indirizzo del tipo selector._domainkey.tuodominio.it. Quando un fornitore ti chiede di «pubblicare due record CNAME per DKIM», sta facendo esattamente questo.

Nella firma è indicato anche il dominio che firma — nel gergo il tag d=. Ed è un'informazione che conta più di quanto sembri: se la piattaforma firma con il proprio dominio invece che con il tuo, DKIM passa, ma ancora una volta non ha detto nulla su di te. Anche qui il nodo si scioglie con DMARC.

Cosa rompe una firma DKIM

Qualunque modifica alle parti firmate dopo la firma. Nella pratica: alcune liste di distribuzione e alcuni sistemi di inoltro che aggiungono un piè di pagina o riscrivono l'oggetto; sistemi intermedi che ricodificano il messaggio; una chiave revocata nel DNS mentre ci sono ancora email in coda. Un fornitore serio gestisce questi casi; il tuo compito è non toccare i record DKIM che ti ha chiesto di pubblicare e, se cambi fornitore, non dimenticare di configurare i nuovi.

DMARC: la regola che collega tutto al mittente visibile

Riassumiamo i buchi trovati finora. SPF controlla un dominio che il destinatario non vede. DKIM prova che qualcuno ha firmato, ma quel qualcuno può non essere te. Nessuno dei due, da solo, risponde alla domanda che interessa al destinatario: l'indirizzo che leggo nel campo «Da» è affidabile?

DMARC (Domain-based Message Authentication, Reporting and Conformance) nasce per rispondere a questa domanda. Non introduce un nuovo controllo tecnico: usa i risultati di SPF e DKIM e li confronta con il dominio del campo «Da». Poi permette al proprietario del dominio di dichiarare, sempre nel DNS, cosa vuole che i provider facciano con i messaggi che non superano il confronto.

L'allineamento: il passaggio che quasi tutti saltano

Il confronto si chiama allineamento (alignment), e funziona così:

• SPF è allineato se il dominio del Return-Path — quello su cui SPF ha fatto la sua verifica — coincide con il dominio del campo «Da».
• DKIM è allineato se il dominio che ha firmato (d=) coincide con il dominio del campo «Da».

DMARC passa se almeno uno dei due controlli è passato ed è allineato. Non servono entrambi. Ma non basta che passino: devono passare sul tuo dominio.

Rileggi ora l'esempio della piattaforma esterna. Return-Path della piattaforma → SPF passa ma non è allineato. Se la piattaforma firma DKIM con il suo dominio → DKIM passa ma non è allineato. Risultato: SPF pass, DKIM pass, DMARC fail. È lo scenario più frequente quando un'azienda dice «ma abbiamo tutto configurato» e le email finiscono comunque in quarantena.

La soluzione è far firmare DKIM con il tuo dominio — è quello che le piattaforme chiamano «dominio di invio dedicato», «dominio autenticato» o simili, con nomi diversi da fornitore a fornitore — e, quando il fornitore lo permette, usare anche un Return-Path su un tuo sottodominio, così da allineare pure SPF.

Una precisazione tecnica utile. «Coincide» può voler dire due cose. In modalità relaxed (quella predefinita) basta che i domini appartengano alla stessa organizzazione: newsletter.tuodominio.it è allineato con tuodominio.it. In modalità strict devono essere identici. Per la maggior parte delle aziende relaxed è la scelta corretta, ed è anche quella che i provider accettano esplicitamente.

Le tre policy: none, quarantine, reject

Nel record DMARC — pubblicato nel DNS all'indirizzo _dmarc.tuodominio.it — il proprietario dichiara una policy, cioè cosa chiede ai provider di fare con i messaggi che falliscono:

Un equivoco diffuso: p=none non significa «DMARC spento». Il record esiste, i provider lo leggono, la verifica di allineamento avviene e — se nel record hai indicato un indirizzo rua — i provider che producono report aggregati te li inviano. Semplicemente non viene chiesta un'azione sui fallimenti. È il punto di partenza raccomandato — e per Gmail, Yahoo e Outlook.com è sufficiente a soddisfare il requisito.

L'equivoco opposto è altrettanto pericoloso: passare a reject il primo giorno. Se un sistema legittimo che invia con il tuo dominio — il gestionale, l'help desk, un vecchio server dimenticato — non è allineato, con reject stai chiedendo ai provider di rifiutare le sue email — conferme d'ordine incluse. La decisione finale resta del provider, che per standard non deve rifiutare solo sulla base della tua policy ma la combina con le proprie valutazioni; nella pratica, però, chiedere il rifiuto delle proprie email legittime è un rischio concreto di mancata consegna, non un margine su cui contare. Il percorso corretto è osservare con none, sistemare le sorgenti che falliscono, e solo dopo irrigidire — fino al livello che il dominio sopporta, che non è reject per tutti: per un dominio usato anche per la posta quotidiana delle persone, esposta a mailing list e inoltri, lo standard aggiornato sconsiglia reject e quarantine è spesso il punto di arrivo.

I report

Nel record DMARC puoi indicare un indirizzo (tag rua) a cui chiedi ai provider di inviare report aggregati: riepiloghi periodici — di solito giornalieri — di quanti messaggi hanno visto con il tuo dominio nel campo «Da», da quali sorgenti, e con quali esiti di SPF, DKIM e allineamento. Senza rua non arriva nulla: lo standard vieta ai provider di generare report per un dominio che non li ha richiesti. E anche con rua, l'invio è raccomandato ma non obbligatorio: i grandi provider li mandano, non tutti lo fanno. Sono file XML poco leggibili a occhio nudo, ma sono l'unico modo per scoprire che esiste un sistema che invia per tuo conto e non è a posto, o che qualcuno sta abusando del tuo dominio. Esistono anche report per singolo fallimento (ruf), ma molti provider non li inviano per motivi di privacy: non farci affidamento.

Lo standard è stato aggiornato nel 2026

Per completezza: la specifica DMARC pubblicata nel 2015 (RFC 7489) è stata sostituita nel maggio 2026 da una nuova versione a standard IETF (RFC 9989, con i report aggregati in RFC 9990 e i report di fallimento in RFC 9991). Per chi invia newsletter le conseguenze pratiche sono poche: la logica di allineamento e le tre policy restano le stesse. Cambiano alcuni dettagli: il tag pct, che permetteva di applicare la policy solo a una percentuale dei messaggi, è stato rimosso dallo standard — e per la sola funzione di test è stato introdotto un tag t; viene aggiunto un tag np per i sottodomini che non esistono. Se un articolo o un tool ti propone ancora pct=, è fermo al vecchio standard.

Cosa controlla ciascuno e cosa non garantisce

Quest'ultima riga merita una parola. DMARC protegge il tuo dominio da chi lo usa senza permesso. Non può nulla contro chi registra un dominio che assomiglia al tuo: quella è un'altra battaglia, e nessun record DNS la vince.

Autenticazione, reputazione, Posta in arrivo: tre cose diverse

Arriviamo al punto che giustifica il titolo. SPF, DKIM e DMARC migliorano la consegna. Non la garantiscono, e vale la pena capire perché.

L'autenticazione risponde a una sola domanda: questa email viene davvero dal dominio che dichiara? Se la risposta è sì, il provider sa chi sei. Da quel momento, tutto ciò che succede al messaggio dipende da cosa il provider pensa di te — cioè dalla reputazione del tuo dominio — e da cosa pensano i tuoi destinatari delle email precedenti.

Il filtro antispam di Gmail, Yahoo o Outlook valuta, fra le altre cose: quante persone hanno segnalato le tue email come spam; la reputazione che il tuo dominio e i tuoi IP si sono costruiti nel tempo; quanti indirizzi nella tua lista non esistono più; se il volume è coerente con la tua storia o è esploso all'improvviso; se il contenuto assomiglia a quello che gli utenti segnalano di solito; più altri segnali anti-abuso che ogni provider tiene per sé. (Google, per esempio, dichiara di non tracciare i tassi di apertura.) Nessuno di questi segnali ha a che fare con SPF, DKIM o DMARC.

Anzi: un dominio perfettamente autenticato con una lista comprata finisce nello spam con precisione, perché il provider sa esattamente a chi attribuire le segnalazioni. L'autenticazione è ciò che rende la reputazione tua — nel bene e nel male.

Quindi, in ordine:

1. Senza autenticazione — con i volumi di oggi, rischi di non essere nemmeno consegnato.
2. Con autenticazione e cattive pratiche — vieni consegnato, e poi filtrato per le ragioni giuste.
3. Con autenticazione e buone pratiche — hai le condizioni per arrivare in Posta in arrivo. Non la certezza: le condizioni.

Se il tuo problema è il terzo caso che non si realizza, il tema non è più tecnico. Ne abbiamo scritto in perché le email finiscono nello spam e come evitarlo, che è la lettura naturale dopo questa.

Cosa chiedono Gmail, Yahoo e Outlook nel 2026

I tre grandi provider consumer hanno pubblicato requisiti espliciti. Li riassumiamo dalle pagine ufficiali consultate a settembre 2026; le policy cambiano, e la fonte da controllare resta sempre quella del provider.

Tre osservazioni per leggere bene la tabella.

La soglia riguarda i messaggi verso quel provider, non il totale dei tuoi invii. Un e-commerce che manda 20.000 email a settimana verso una lista in cui metà sono Gmail supera la soglia nei giorni di invio. Molte PMI non la superano mai; ma Gmail e Yahoo chiedono almeno SPF o DKIM a tutti i mittenti, sotto qualunque soglia, mentre i requisiti formali di Outlook.com trattati qui — SPF, DKIM e DMARC — riguardano chi invia 5.000 o più messaggi al giorno verso le caselle consumer Microsoft. In ogni caso, tutti e tre raccomandano a chiunque la configurazione completa.

«DMARC almeno p=none» non è una scappatoia. Serve il record, e serve che il messaggio passi l'allineamento. Yahoo lo scrive esplicitamente («DMARC must pass»); Google e Microsoft lo chiedono attraverso il requisito di allineamento.

Non generalizzare oltre le fonti. Microsoft, per esempio, non pubblica una soglia di tasso spam come Google e Yahoo; Yahoo non pubblica un numero per la soglia bulk. Dove il provider non lo dice, l'articolo non lo inventa.

Gli errori di configurazione più comuni

Nell'ordine in cui capitano più spesso a chi fa email marketing:

• Due record SPF. Ogni fornitore ha chiesto il suo; nessuno ha unito. Risultato: errore permanente, SPF nullo.
• Un servizio che manca nello SPF. Il gestionale che invia le fatture, l'help desk, il modulo contatti del sito. Se invia con il tuo dominio nel Return-Path, deve esserci.
• DKIM mai attivato sulla piattaforma. Il fornitore firma con il proprio dominio: tutto passa, niente è allineato.
• Dominio autenticato sulla piattaforma ma DMARC assente. Si è fatto il lavoro utile e non si è pubblicato il record che lo fa valere.
• DMARC pubblicato, allineamento no. Il record c'è, ma le sorgenti firmano o inviano con domini diversi dal campo «Da». È il caso «abbiamo tutto ma fallisce».
• Policy reject senza aver osservato i report. Le email del CRM possono smettere di arrivare e nessuno collega le due cose.
• Record pubblicato nel punto sbagliato. DMARC su tuodominio.it invece che su _dmarc.tuodominio.it; DKIM con il selector scritto male. Il record esiste, ma nessuno lo trova.
• Cambio di piattaforma senza aggiornare nulla. Si migra da un ESP all'altro, il nuovo non è nello SPF e non firma con il tuo dominio. La prima campagna dal nuovo sistema finisce in quarantena.
• Credere che p=none significhi che DMARC non funziona, e saltare direttamente a quarantine — o, al contrario, restare in none per anni senza mai leggere un report.
• Credere che tutto questo risolva lo spam. Non lo fa. Rende il resto misurabile.

Come verificare se il tuo dominio è a posto

Non serve essere tecnici per una prima diagnosi. Cinque controlli, dal più semplice:

Se invii volumi significativi verso Gmail, Postmaster Tools di Google mostra nel tempo autenticazione, reputazione e tasso di segnalazioni per il tuo dominio. È gratuito e va attivato una volta sola.

Quando serve l'intervento di un tecnico

Con un solo dominio e una sola piattaforma, spesso basta seguire le istruzioni del fornitore e pubblicare tre o quattro record. Le situazioni che meritano qualcuno che sappia cosa sta facendo sono altre:

• Più sistemi che inviano con lo stesso dominio — newsletter, transazionali, CRM, help desk, piattaforma e-commerce — ognuno da includere nello SPF se usa il tuo dominio come Return-Path, ognuno con il proprio DKIM da attivare con il tuo dominio, restando entro il limite dei dieci lookup.
• Dominio principale e sottodomini, con la decisione su quale usare per cosa e come impostare la policy dei sottodomini.
• Migrazione da una piattaforma all'altra senza interruzioni: il periodo in cui i due sistemi convivono va gestito.
• Passaggio da none a quarantine o reject, che richiede di leggere i report, identificare ogni sorgente e sistemarla prima.
• Inoltri e liste di distribuzione che rompono SPF e a volte DKIM.
• Chi gestisce il DNS non è chi gestisce l'email marketing: succede nella maggior parte delle aziende, e il lavoro è soprattutto di coordinamento.

In tutti questi casi l'intervento non è lungo, ma va fatto una volta bene. Un dominio con autenticazione corretta e monitorata è un lavoro che dura anni; uno sistemato a metà torna a farsi sentire alla prima campagna importante.

Continua la lettura

Email Marketing

Perché le email finiscono nello spam (e come evitarlo)

Email Marketing

Come funziona l'Email Marketing

Email Marketing

Come costruire una mailing list senza comprare contatti