Chiunque può scrivere il suo dominio nel campo Da (From) di un’email. SPF, DKIM e DMARC permettono al server ricevente di verificare se un messaggio proviene davvero da lei e gli indicano cosa fare quando non è così. Configurati con cura, rendono molto più difficile lo spoofing del dominio esatto. Configurati in fretta, possono bloccare le sue stesse fatture.
Cosa fa ciascun meccanismo
SPF (Sender Policy Framework, RFC 7208) è un record DNS TXT che elenca i server autorizzati a inviare posta per un dominio. Il destinatario confronta l’indirizzo IP del server che si connette con quell’elenco. SPF verifica il mittente della busta (le identità MAIL FROM e HELO), non l’indirizzo From che vede il destinatario.
DKIM (DomainKeys Identified Mail, RFC 6376) aggiunge una firma crittografica a ogni messaggio. Il tag d= indica il dominio firmatario e s= indica un selettore. La chiave pubblica è pubblicata nel DNS in selector._domainkey.domain. Una firma valida dimostra che le parti firmate del messaggio non sono cambiate da quando quel dominio le ha firmate.
DMARC collega entrambi al dominio From visibile. Una versione rivista è stata pubblicata a maggio 2026 come RFC 9989, un documento Standards Track che sostituisce la RFC 7489. Un record DMARC dichiara la sua policy e chiede ai destinatari di inviarle dei report.
| Meccanismo | Cosa dimostra | Dove si pubblica | Limite se usato da solo |
|---|---|---|---|
| SPF | L’IP mittente è autorizzato per il dominio della busta | Sul dominio stesso | Non dice nulla sull’indirizzo From che le persone leggono |
| DKIM | Un dominio garantisce per il messaggio | selector._domainkey.domain | Il dominio firmatario può essere un dominio qualsiasi |
| DMARC | SPF o DKIM superato per un dominio che corrisponde al dominio From | _dmarc.domain | Presuppone che SPF e DKIM siano già configurati correttamente |
L’allineamento è la parte che sfugge
Un messaggio supera DMARC quando SPF o DKIM viene superato e il dominio autenticato è allineato con il dominio From. L’allineamento flessibile (relaxed), quello predefinito, accetta una corrispondenza sul dominio organizzativo, quindi mail.example.eu è allineato con example.eu. L’allineamento rigoroso (adkim=s o aspf=s) richiede una corrispondenza esatta.
È con i mittenti terzi che di solito le cose vanno storte. Una piattaforma di newsletter potrebbe usare un dominio della busta come bounces.platform.example. SPF viene superato per il dominio della piattaforma, ma quel dominio non è allineato con example.eu, quindi non contribuisce in alcun modo al risultato DMARC.
La soluzione è far firmare la piattaforma con DKIM usando d=example.eu, oppure configurare un return-path personalizzato su uno dei propri sottodomini. La RFC 9989 raccomanda ai titolari dei domini di usare sia SPF sia DKIM. In questo modo, se uno fallisce, l’altro può comunque garantire il risultato, ad esempio dopo un inoltro.
Come sono fatti i record
Gli esempi seguenti usano un indirizzo IP riservato alla documentazione e un provider fittizio. Li sostituisca con i suoi valori.
example.eu. TXT "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"Il record DMARC qui sopra è in modalità di monitoraggio. Richiede report aggregati, ma nessuna azione sulla posta che non supera i controlli. I report aggregati, ora specificati nella RFC 9990, mostrano quali server inviano posta usando il suo dominio e se superano i controlli.
Per le chiavi DKIM, la RFC 6376 richiede chiavi RSA di almeno 1024 bit per le chiavi di lunga durata. Google richiede almeno 1024 bit per la posta diretta agli account Gmail personali e consiglia 2048 bit dove il provider li supporta.
Un passaggio sicuro da p=none a p=reject
- Elenchi tutti i mittenti. Includa la piattaforma di posta, il CRM, i sistemi di fatturazione e paghe, l’helpdesk, i moduli del sito web e dispositivi come gli scanner che inviano documenti via email.
- Configuri SPF e DKIM per ciascuno. Chieda a ogni servizio di firmare con DKIM sotto il suo dominio, ovunque sia possibile.
- Pubblichi
p=nonecon un indirizzorua. La RFC 9989 lo descrive come il consueto punto di partenza, così da individuare i mittenti dimenticati durante la configurazione. - Legga i report e colmi le lacune. Si dia almeno diverse settimane, e di più se ha invii mensili o trimestrali, come le buste paga o i rendiconti annuali.
- Passi a
p=quarantine, poi ap=reject. La RFC 9989 ha eliminato il vecchio tagpct. Al suo posto c’è la modalità test:t=ychiede ai destinatari di applicare la policy un livello più in basso, quindip=reject; t=yviene gestito come quarantena. - Copra sottodomini e domini parcheggiati. Il tag
spimposta la policy per i sottodomini esistenti, e il nuovo tagnpcopre i sottodomini che non esistono.
Consideri t=y un’attenuazione, non una garanzia. Sia la RFC 7489 sia la RFC 9989 indicano ai destinatari di ignorare i tag che non riconoscono. Un destinatario che non ha ancora adottato la nuova specifica potrebbe quindi applicare per intero la policy pubblicata.
Per il passaggio 6, un dominio che non invia mai posta dovrebbe dichiararlo esplicitamente. Pubblichi un record SPF che non autorizza nessuno e una policy di rifiuto:
parked-example.eu. TXT "v=spf1 -all"
_dmarc.parked-example.eu. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu. TXT "v=DMARC1"Il terzo record è importante perché i report vengono inviati a un dominio diverso. La RFC 9990 impone ai destinatari di verificare, prima di inviarli, che il dominio di destinazione abbia accettato di ricevere report per il dominio della policy.
I grandi provider di caselle email si aspettano già questo lavoro. Dal 1° febbraio 2024 Google richiede ai mittenti massivi (più di 5.000 messaggi al giorno verso Gmail) di usare SPF, DKIM e DMARC con allineamento. Una policy p=none soddisfa questo requisito minimo, ma non protegge il dominio.
Errori comuni
Due record SPF
Un dominio può pubblicare un solo record SPF. Se un destinatario ne trova più di uno, l’esito SPF è permerror anziché pass. Quando aggiunge un nuovo servizio, unisca il suo include al record esistente invece di crearne un secondo.
Più di dieci lookup DNS
La RFC 7208 limita la valutazione SPF a 10 termini che generano query DNS: include, a, mx, ptr, exists e il modificatore redirect. Contano anche gli include annidati all’interno dei suoi include. Se si supera il limite, l’esito è permerror.
I termini ip4, ip6 e all non contano, quindi elencare i propri server per indirizzo aiuta. Rimuova gli include dei servizi che non usa più. La RFC suggerisce inoltre di limitare a due i “void lookup”, cioè le query che non restituiscono alcuna risposta.
+all e ?all
Il meccanismo all corrisponde sempre, e il suo qualificatore decide l’esito. +all autorizza quindi qualsiasi server su internet: non lo pubblichi mai. ?all restituisce neutral, che secondo la RFC 7208 va trattato esattamente come l’assenza di un esito SPF. Usi ~all (softfail) o -all (fail).
Quale dei due? La specifica DMARC originale (RFC 7489, sezione 6.7) osserva che rifiutare un messaggio in caso di fail SPF impedisce al destinatario di valutare DKIM. Questo può penalizzare la posta inoltrata, in cui SPF fallisce ma la firma DKIM è ancora valida. Quando DMARC è applicato, ~all lascia a DMARC la decisione finale.
Ignorare inoltri e mailing list
Un messaggio inoltrato arriva dall’indirizzo IP del server che lo inoltra, che non è nel suo record SPF. Una firma DKIM di solito sopravvive all’inoltro se il messaggio non viene modificato. Le mailing list che modificano l’oggetto o aggiungono un piè di pagina possono però invalidarla. Per questo, quando si passa a p=reject, una firma DKIM affidabile sotto il proprio dominio conta più di SPF.
Usare ptr
La RFC 7208 stabilisce che il meccanismo ptr non dovrebbe essere pubblicato. È lento, meno affidabile e conta comunque ai fini del limite di lookup.
Applicare la policy senza leggere i report
Passare direttamente a p=reject è un modo facile per bloccare i propri reset delle password, le fatture o le risposte dell’assistenza. I report indicano quali mittenti sono stati dimenticati. Li legga prima di applicare la policy, e continui a leggerli anche dopo, perché nel tempo si aggiungono nuovi servizi.
Da dove iniziare
- Verifichi cosa pubblica oggi il suo dominio con la nostra verifica della sicurezza email.
- Crei o riordini i suoi record con il generatore SPF e DMARC.
- Annoti tutti i sistemi che inviano posta a nome del suo dominio. Questo elenco le servirà prima di applicare la policy.
- Pubblichi subito
p=nonecon un indirizzo per i report e fissi una data per analizzare i primi report. - Aggiunga
v=spf1 -alle un record DMARCp=rejecta ogni dominio di sua proprietà che non invia posta.
Se preferisce affidare a noi l’analisi dei report e il passaggio all’applicazione della policy, il nostro servizio di sicurezza gestita può aiutarla in entrambi.
