SPF: chi ha il diritto di inviare
La RFC 7208 parte da una constatazione: nulla, nel protocollo di posta elettronica, impedisce a un server di dichiarare un qualsiasi indirizzo di spedizione. SPF permette al titolare di un dominio di pubblicare nel DNS l’elenco dei server autorizzati a inviare a suo nome, e al server che riceve di verificare questa autorizzazione.
Due precisazioni cambiano tutto:
- SPF verifica l’indirizzo della busta (quello del dialogo tra server, detto «MAIL FROM») e il nome dichiarato dal server, non l’indirizzo che il destinatario legge nel campo «Da».
- SPF giudica l’ultimo server che ha consegnato il messaggio. Quando un messaggio viene inoltrato da un altro server, a consegnarlo non è più un server autorizzato dal dominio di origine: la verifica può fallire anche se il messaggio è legittimo.
Un dominio pubblica un solo record SPF. Tutte le fonti di invio vi devono comparire: servizio di posta, software di fatturazione, strumento per newsletter, CRM, fotocopiatrice che scansiona verso l’e-mail.
DKIM: il messaggio è firmato
Secondo la RFC 6376, DKIM permette al titolare di un dominio firmatario di assumersi una parte di responsabilità per un messaggio, per mezzo di una firma crittografica. La chiave pubblica si trova nel DNS. Verificare la firma attesta che le parti firmate non sono cambiate dopo la firma.
La firma viaggia con il messaggio. Sopravvive quindi meglio di SPF a un relay o a un inoltro, purché questo relay non modifichi l’oggetto o il corpo. Una lista di distribuzione che aggiunge una nota in fondo al messaggio la invalida.
Che cosa DKIM non fa, secondo la stessa RFC: non cifra il messaggio, un esito negativo non impone di rifiutarlo, e il dominio che firma non deve per forza essere quello visualizzato nel campo «Da». È proprio la lacuna che DMARC colma.
DMARC: l’allineamento e la policy
La RFC 7489 definisce DMARC come un mezzo con cui il titolare di un dominio esprime una policy a livello di dominio. Il meccanismo si basa sull’allineamento: il dominio dell’indirizzo visualizzato nel campo «Da» deve corrispondere al dominio convalidato da SPF o da DKIM. Se nessuno dei due è allineato, DMARC fallisce.
Il dominio pubblica allora ciò che desidera:
- none: nessuna azione richiesta, si osserva;
- quarantine: trattare il messaggio come sospetto;
- reject: rifiutare il messaggio.
DMARC prevede anche dei report: report aggregati, che riassumono quali server hanno inviato a nome del dominio e con quale esito, e report di errore, messaggio per messaggio. Sono loro a permettere di scoprire uno strumento dimenticato che invia per conto suo, o qualcuno che usurpa il suo dominio.
| Meccanismo | Che cosa verifica | Che cosa non guarda |
|---|
| SPF | Il server che consegna il messaggio è autorizzato per il dominio della busta | L’indirizzo visualizzato, il contenuto |
| DKIM | Il messaggio firmato non è stato modificato; un dominio se ne assume la responsabilità | L’indirizzo visualizzato, l’onestà del contenuto |
| DMARC | Il dominio visualizzato è allineato con SPF o DKIM; policy in caso di esito negativo | I domini somiglianti, il nome visualizzato, il testo |
DMARC blocca il phishing?
Blocca una parte dell’usurpazione del dominio, non il phishing in generale. La RFC 7489 lo dice esplicitamente: DMARC non tratta i nomi di dominio visivamente simili, né l’abuso del nome visualizzato, e l’analisi del contenuto esula dal suo perimetro. Non cerca di risolvere tutti i problemi della posta fraudolenta.
In concreto, DMARC non vede:
- un dominio simile: il truffatore autentica perfettamente il proprio dominio, che somiglia al suo;
- un nome visualizzato usurpato: «Ufficio contabilità» che scrive da un indirizzo senza alcun legame;
- un account compromesso che firma correttamente, perché a inviare è il vero server;
- un messaggio senza legame con il suo dominio: un falso avviso di un corriere arriva da un dominio che non ha nulla a che vedere con il suo;
- un dominio senza policy: se il dominio imitato pubblica «none», il destinatario non ha alcuna istruzione di rifiuto.
Questi casi richiedono altre analisi: somiglianza dei domini, reputazione, contenuto, comportamento. Veda spam, phishing, malware e account compromesso.
Inoltri e liste di distribuzione: ARC
Un inoltro spesso invalida SPF, una lista che modifica il messaggio invalida DKIM, e DMARC fallisce allora su un messaggio legittimo. ARC, descritto nella RFC 8617 (stato sperimentale), permette a ogni intermediario di attestare il risultato di autenticazione che ha rilevato. Il server finale può scegliere di tenerne conto.
Proteggere il proprio dominio, filtrare ciò che arriva
Sono due temi che vengono spesso confusi.
- Proteggere il dominio che invia: pubblicare SPF, DKIM e DMARC per il suo dominio, affinché gli altri possano rifiutare i messaggi che lo usurpano. È lei a pubblicare; sono i destinatari ad applicare.
- Filtrare ciò che arriva: verificare i record degli altri domini sulla posta che riceve, poi applicare tutte le altre analisi.
Implementazione graduale
- Inventario di tutto ciò che invia a nome del dominio.
- Un unico record SPF che li autorizza; una firma DKIM per ogni servizio in grado di firmare.
- DMARC in «none», con un indirizzo per la ricezione dei report.
- Lettura dei report per diverse settimane; correzione delle fonti dimenticate.
- Passaggio a «quarantine», poi a «reject» quando gli invii legittimi sono tutti allineati.
Esempio, a titolo illustrativo. Uno studio professionale pubblica DMARC in «none» e legge i primi report. Vi scopre tre fonti: il suo servizio di posta, correttamente allineato; il suo software di fatturazione, che invia le fatture con il dominio dello studio senza firma DKIM; e un server sconosciuto all’estero che invia centinaia di messaggi a suo nome. Corregge il software di fatturazione, attende un ciclo di report pulito, poi passa a «quarantine»: i destinatari che applicano DMARC trattano ormai come sospetti i messaggi del server sconosciuto.
Il giorno in cui si cambia servizio di posta, questi record si preparano prima del cambio di MX. La guida migrare la posta elettronica senza interruzioni descrive questo momento; non viene ripreso qui.
Domande frequenti
Una policy DMARC «none» protegge?
No. Permette di osservare grazie ai report. La protezione inizia con «quarantine» o «reject».
Perché un messaggio legittimo non supera DMARC?
Il più delle volte: un inoltro, una lista di distribuzione o un servizio che invia per conto suo senza essere dichiarato in SPF né firmare con DKIM.
Il nostro servizio di posta non firma con DKIM: che cosa fare?
Un gateway posto sul percorso degli invii può firmare al suo posto. Veda Proteggere la posta elettronica che già utilizza.
Dove leggere il risultato di questi controlli su un messaggio ricevuto?
Nelle intestazioni del messaggio. Per Klytic MTA, veda Leggere ed esportare una decisione del filtro.
Dove si colloca Klytic
Klytic MTA si occupa di entrambi i temi, davanti a qualsiasi servizio di posta:
- Essential e Advanced: controllo SPF, DKIM e MX; verifica DMARC, anche per i messaggi inoltrati grazie ad ARC; firma DKIM degli invii, anche se il suo servizio di posta non lo fa.
- Advanced: console DMARC, con i report dei suoi domini, avvisi e indicazioni di correzione, per gestire il passaggio graduale a «reject».
DMARC è solo un livello: Klytic MTA aggiunge il rilevamento dei domini sosia, del nome visualizzato e degli scenari di frode, descritto in usurpazione d’identità e frode del CEO.
Se utilizza Klytic Mail, SPF, DKIM e DMARC sono configurati per il suo dominio: è la protezione del dominio che invia. Klytic MTA, invece, si sottoscrive con o senza Klytic Mail.
Fonti
Consultate a ottobre 2026.
- RFC 7208, SPF: il titolare di un dominio pubblica gli host autorizzati a usare il suo dominio nell’identità «MAIL FROM» o «HELO», e il ricevente verifica questa autorizzazione. rfc-editor.org
- RFC 6376, DKIM: un dominio si assume la responsabilità di un messaggio tramite una firma crittografica; nessuna cifratura, nessun rifiuto imposto, dominio firmatario eventualmente diverso dall’autore visualizzato. rfc-editor.org
- RFC 7489, DMARC: allineamento del dominio di «From» con SPF o DKIM, policy none, quarantine e reject, report aggregati e di errore; domini visivamente simili, nome visualizzato e analisi del contenuto fuori perimetro. rfc-editor.org
- RFC 9989 (maggio 2026), che sostituisce la RFC 7489: stessi valori di policy e stesse esclusioni (domini somiglianti, nome visualizzato). rfc-editor.org
- RFC 8617, ARC (sperimentale): catena di trasmissione autenticata; un ricevente DMARC può accettare le valutazioni riportate da una catena ARC valida. rfc-editor.org
- Klytic, pagina Klytic MTA: controlli di autenticazione, firma DKIM in uscita e console DMARC delle offerte Essential e Advanced, opzioni, modalità di implementazione, attivazione tramite il record MX. klytic.com
