SPF, DKIM e DMARC spiegati semplice

SPF, DKIM e DMARC in una frase ciascuno

Chiunque può scrivere qualsiasi indirizzo nel campo mittente di un’email. SPF, DKIM e DMARC servono a dimostrare che un messaggio con il tuo dominio arriva davvero da te. Sono tre record di testo (TXT) che pubblichi nel DNS del dominio:

• SPF (Sender Policy Framework, RFC 7208): la lista dei server che possono inviare email per il tuo dominio.
• DKIM (DomainKeys Identified Mail, RFC 6376): una firma digitale su ogni messaggio, che prova che è partito da te e non è stato modificato.
• DMARC (RFC 7489, sostituito a maggio 2026 da RFC 9989): la regola che controlla che SPF o DKIM corrispondano al dominio del From e dice al provider cosa fare se non è così.

Nessuno dei tre da solo basta. Insieme, sono il primo controllo che Gmail, Yahoo e Outlook fanno su ogni email che ricevono.

SPF: chi può inviare per il tuo dominio

Il record SPF si pubblica sul dominio stesso. Un esempio per tuonegozio.it, che invia con una piattaforma di email marketing e con un proprio server:

tuonegozio.it. TXT "v=spf1 include:spf.piattaforma-esempio.it ip4:203.0.113.10 -all"

Si legge da sinistra a destra:

• v=spf1: è un record SPF.
• include:spf.piattaforma-esempio.it: autorizza tutti i server elencati nel record SPF della piattaforma.
• ip4:203.0.113.10: autorizza un singolo indirizzo IP.
• -all: tutti gli altri server non sono autorizzati. Con ~all il risultato è “softfail”: non autorizzati, ma con una indicazione meno netta.

Due regole dell’RFC 7208 che causano molti problemi:

• Un solo record SPF per dominio. Se ne pubblichi due, il controllo restituisce un errore permanente (permerror) e SPF fallisce.
• Massimo 10 termini che richiedono una ricerca DNS: include, a, mx, ptr, exists e il modificatore redirect. Ogni include conta, insieme a quelli annidati al suo interno. Oltre il limite, anche qui permerror.

Un dettaglio che confonde: SPF non controlla l’indirizzo che il destinatario vede, ma il dominio usato nella comunicazione tra server (il “MAIL FROM”, detto anche return-path). Per questo da solo non basta.

DKIM: la firma su ogni messaggio

Con DKIM il server che invia firma ogni email con una chiave privata. La chiave pubblica sta nel DNS, sotto un nome che contiene un “selettore” scelto da chi configura la firma. Esempio con selettore s1:

s1._domainkey.tuonegozio.it. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

• s1 è il selettore. Puoi averne più di uno, per esempio uno per piattaforma.
• k=rsa indica il tipo di chiave.
• p= contiene la chiave pubblica, una lunga stringa che ti fornisce la piattaforma di invio.

Nell’email firmata trovi un header DKIM-Signature con d=tuonegozio.it (il dominio che firma) e s=s1 (il selettore). Il provider che riceve recupera la chiave pubblica, verifica la firma e sa che il messaggio non è stato modificato lungo la strada.

Sulla lunghezza della chiave, Google chiede almeno 1024 bit e consiglia 2048 bit. Il punto più importante è un altro: la firma deve usare il tuo dominio, non quello della piattaforma che invia. Altrimenti DKIM passa ma non aiuta DMARC.

DMARC: la regola che tiene insieme tutto

Il record DMARC si pubblica sul sottodominio _dmarc:

_dmarc.tuonegozio.it. TXT "v=DMARC1; p=none; rua=mailto:dmarc@tuonegozio.it"

• p= è la policy, cioè cosa chiedi al provider se un messaggio non supera DMARC: none (nessuna azione, solo monitoraggio), quarantine (trattalo come sospetto, di solito spam), reject (rifiutalo).
• rua= è l’indirizzo che riceve i report aggregati: file che i provider inviano periodicamente con l’elenco dei server che hanno inviato email a tuo nome e l’esito dei controlli.

Un messaggio supera DMARC se almeno uno tra SPF e DKIM passa ed è allineato con il dominio del From. Una nota tecnica: a maggio 2026 l’IETF ha pubblicato l’RFC 9989, che sostituisce l’RFC 7489. Tra le novità c’è la rimozione del tag pct, che serviva ad applicare la policy solo a una percentuale dei messaggi. Se lo usi nel tuo record, è il momento di toglierlo e gestire il passaggio con le policy.

L’allineamento, con un esempio

È il concetto che più spesso manca. Prendi una newsletter con mittente offerte@tuonegozio.it:

• SPF passa sul return-path bounce.piattaforma-esempio.it. Il dominio è diverso da tuonegozio.it: SPF non è allineato.
• DKIM passa con d=piattaforma-esempio.it. Anche qui il dominio è diverso: DKIM non è allineato.
• Risultato: SPF e DKIM sono verdi, ma DMARC fallisce.

La soluzione è firmare con d=tuonegozio.it e usare un return-path su un tuo sottodominio, come mail.tuonegozio.it. Con l’allineamento “rilassato”, che è quello predefinito e che Yahoo indica come sufficiente, un sottodominio dello stesso dominio principale va bene.

Il percorso da p=none a p=reject

1. Configura SPF e DKIM su tutti i servizi che inviano per tuo conto: newsletter, email transazionali dell’ecommerce, CRM, helpdesk, fatturazione.
2. Pubblica DMARC con p=none e un indirizzo rua. È il minimo richiesto oggi da Gmail, Yahoo e Outlook.com ai mittenti massivi.
3. Leggi i report per alcune settimane. Cerca i servizi legittimi che non passano: un gestionale dimenticato, un vecchio server. Sistemali uno a uno.
4. Passa a p=quarantine quando i report mostrano solo fonti legittime e allineate.
5. Arriva a p=reject, che Microsoft raccomanda. Da qui chi prova a inviare a nome tuo viene respinto.

Non saltare il passo 3. Una policy restrittiva pubblicata troppo presto blocca anche le tue email legittime, come conferme d’ordine o fatture.

Gli errori più comuni

• Due record SPF sullo stesso dominio, di solito perché un nuovo servizio ne aggiunge uno invece di modificare quello esistente. Va unito in un solo record.
• Troppi include: oltre 10 ricerche DNS SPF fallisce. Togli i servizi che non usi più.
• DKIM firmato con il dominio della piattaforma: passa, ma non è allineato.
• DMARC senza rua: sei in regola sulla carta, ma non sai chi invia a tuo nome.
• Nessuno legge i report: sono file XML. Serve uno strumento che li riassuma, o resti a p=none per sempre.
• Record modificato e mai verificato: dopo ogni modifica invia un’email di prova a una casella Gmail, apri “Mostra originale” e controlla che SPF, DKIM e DMARC risultino PASS.

Per sapere cosa chiede nel dettaglio ciascun provider, leggi i requisiti di Gmail, Yahoo e Outlook.

Come lo gestisce beMail

beMail invia da server e IP propri, genera le chiavi DKIM per il tuo dominio, ti indica l’include SPF e il record DMARC consigliato e verifica che i record DNS siano pubblicati correttamente. Una casella dedicata raccoglie i report DMARC. Con DMARC in applicazione puoi aggiungere anche il logo del brand con BIMI. Se vuoi un controllo dei tuoi record, scrivici.

I record di esempio usano domini fittizi e un indirizzo IP riservato alla documentazione: sostituiscili con i valori che ti fornisce la tua piattaforma. Fonti: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 9989 (DMARC, maggio 2026) e linee guida Google per i mittenti.