# Che cosa significa davvero «dkim=pass»

> L’autenticazione e-mail è passata. Dimostra che il dominio ha firmato il messaggio, non che la fattura sia reale né che le coordinate bancarie siano corrette.

Canonical: https://vetthisvendor.com/it/guide/dkim-pass-does-not-mean-genuine
Published: 2026-08-12. Updated: 2026-08-12.
Author: Jose Pollman, VetThisVendor.

Se ha aperto le intestazioni di un’e-mail, ha trovato una riga come
`dkim=pass header.d=supplier.com; spf=pass; dmarc=pass` e vuole sapere se questo significa
che il messaggio è sicuro: **significa che il messaggio proviene davvero da quel dominio, e
nulla di più.** Non dice nulla sul fatto che la fattura sia autentica, che le coordinate
bancarie siano giuste o che a scrivere fosse il suo fornitore.

Non è un tecnicismo. La frode su fattura più costosa d’Europa supera tutte e tre le
verifiche, ogni volta, perché è inviata dalla casella vera del fornitore. Se ha in mano una
richiesta di pagamento, la [verifica email fornitore](/it/tools/supplier-email-check) legge
il messaggio e dice quali di queste cose ha potuto davvero stabilire e — altrettanto
importante — quali no.

## Che cosa chiede davvero ciascuna delle tre verifiche

Vengono spesso scritte come se fossero un unico verdetto. Sono tre domande diverse, e
nessuna di esse è «questa e-mail è onesta?».

**SPF** chiede se il server che ha consegnato il messaggio sia fra quelli che il titolare
del dominio ha elencato come autorizzati a inviare. È una domanda su un indirizzo IP. Non
dice nulla su chi abbia scritto il messaggio né su che cosa contenga.

**DKIM** chiede se una firma crittografica su parti del messaggio corrisponda a una chiave
pubblica pubblicata nel DNS del dominio. Il superamento significa che qualcuno in possesso
della chiave privata di quel dominio ha firmato quelle parti, e che da allora non sono state
modificate. È la più solida delle tre — ed è un’affermazione sul *dominio*, non
sull’*intenzione di chi invia*.

**DMARC** chiede se SPF o DKIM siano passati per un dominio che corrisponde all’indirizzo
`From:` che il lettore vede, e indica ai server riceventi che cosa fare quando non passa
nessuno dei due. Lega gli altri due al mittente visibile. Questo ha un valore reale, e resta
comunque una cosa diversa da un’affermazione sul contenuto.

Quindi `dkim=pass header.d=supplier.com` significa: questo è davvero il dominio del suo
fornitore. Che è esattamente ciò che ci si aspetta quando un criminale è seduto nella
casella del suo fornitore.

## La frode che supera ogni verifica

La versione della frode su fattura che riesce non è un dominio sosia. È un’**e-mail vera
dalla casella vera del fornitore vero**, raggiunta di solito con una password proveniente da
una violazione estranea o con una pagina di phishing compilata settimane prima.

Tutto autentica, perché tutto è autentico:

- il messaggio è firmato dal dominio stesso del fornitore, quindi DKIM passa;
- parte dal servizio di posta del fornitore stesso, quindi SPF passa;
- l’indirizzo `From:` corrisponde, quindi DMARC passa;
- lo storico della conversazione è reale, perché è la conversazione vera.

Solo le coordinate bancarie sono nuove. L’autenticazione e-mail non ha alcuna opinione sulle
coordinate bancarie.

Per questo «l’e-mail è autenticata» non è mai una ragione per pagare, ed è per questo che
ogni risultato su questo sito — compresi quelli puliti — finisce con la stessa frase sul
telefonare a un numero che aveva già. C’è un percorso più esteso in
[un fornitore chiede di cambiare le coordinate bancarie](/it/guide/supplier-changed-bank-details).

## Chi ha scritto la riga che sta leggendo

C’è una seconda trappola, ed è facile non vederla.

`Authentication-Results:` è un’intestazione scritta dal **server di posta che ha ricevuto il
messaggio** — di solito il suo stesso provider. Quando vi legge `dkim=pass`, sta leggendo il
verdetto di qualcun altro, registrato al momento della consegna. Di norma è affidabile,
perché l’ha scritto il suo provider.

Ma le intestazioni sono solo testo. Se il blocco le è stato inoltrato, incollato in un
ticket, copiato dallo screenshot di un collega o consegnato da chi chiede di essere pagato,
allora la riga che dice `dkim=pass` è un’affermazione di chi ha prodotto quel testo — e
chiunque può scriverla. Non c’è alcuna crittografia a proteggere un’intestazione che dice
che la crittografia è riuscita.

La distinzione onesta è fra tre situazioni piuttosto diverse:

| Che cosa ha | Che cosa si può stabilire |
|---|---|
| Il messaggio grezzo completo, firma inclusa | La firma può essere **verificata ora**, da lei |
| Solo le intestazioni, con una riga `Authentication-Results` | Il **verdetto registrato dal server ricevente**, preso per buono |
| Nessuno dei due: solo l’e-mail visibile | Solo ciò che il dominio pubblica: SPF, DMARC, MX |

Qualunque strumento le mostri il secondo caso chiamandolo il primo le sta dicendo qualcosa
che lei non ha modo di verificare. La
[verifica email fornitore](/it/tools/supplier-email-check) dichiara quale dei tre sta
facendo, e non promuove mai l’uno all’altro: un `dkim=pass` che compare in un blocco di
intestazioni incollato viene riportato come il verdetto del ricevente, detto con queste
parole.

## Quando un «fail» conta più di un «pass»

Un «pass» è una prova debole. Un **«fail» è una prova forte**, e vale la pena fermarsi.

Se la verifica DKIM viene davvero eseguita e non concorda — la firma non corrisponde al
contenuto — il messaggio è stato modificato dopo la firma, oppure non è mai stato firmato da
quel dominio. Se DMARC è impostato su `p=reject` e il messaggio è comunque fallito, non
avrebbe dovuto essere consegnato.

C’è un’asimmetria da tenere presente: *non si è potuto verificare* non è la stessa cosa di
*non ha superato*. Una consultazione DNS irraggiungibile, una chiave revocata, una firma
scaduta o una firma che copre solo parte del corpo significano tutte che il calcolo non ha
potuto essere completato. Non è un rilievo contro il mittente, e uno strumento che lo
presenta come tale spreca l’unico segnale su cui sarebbe valsa la pena agire.

## Che cosa fare con un messaggio di cui non è sicuro

1. **Non risponda.** Se la casella è compromessa, la sua risposta arriva all’aggressore, e
   una regola sulla casella può nasconderla al fornitore vero.
2. **Telefoni al fornitore** a un numero preso da una vecchia fattura, dal suo gestionale o
   dal loro sito raggiunto digitando lei stesso l’indirizzo.
3. **Verifichi gli identificativi separatamente** — la partita IVA, l’iscrizione al registro
   delle imprese e, per un fornitore polacco, se il conto è
   [sulla lista bianca](/it/guide/polish-white-list). La
   [verifica fattura](/it/tools/invoice-checker) fa tutto questo a partire dal documento
   stesso.
4. **Tratti il cambio di coordinate bancarie come l’evento**, non l’e-mail che lo
   accompagna. È quella la cosa che merita una telefonata, qualunque cosa dicano le
   intestazioni.

## Che cosa questo non può dirle

L’autenticazione e-mail è una verifica sul *canale*, non sull’*affermazione*. Non può dirle
che la merce sia stata ordinata, che l’importo sia giusto, che la persona che scrive lavori
ancora lì o che il conto appartenga al suo fornitore. La Polonia è l’unico paese dell’UE che
pubblica una risposta a quest’ultima domanda, ed è per questo che
[la lista bianca](/it/guide/polish-white-list) vale la pena di essere usata dove è
applicabile.

Ovunque altrove, il controllo che intercetta tutto questo è una telefonata a un numero che
aveva già.