Email spoofing su Hotmail/Outlook: perché arriva nonostante SPF e DMARC falliti e come bloccarla

Hai ricevuto un’e‑mail con oggetto “You’ve been hacked / Pegasus” che sembra inviata dal tuo stesso indirizzo Hotmail/Outlook? Ecco perché è successo, cosa indicano i fail SPF/DMARC/DKIM e come prevenire definitivamente lo spoofing.

Indice

Scenario reale: l’e‑mail “You’ve been hacked / Pegasus” inviata dal tuo stesso indirizzo

Nel caso in esame un messaggio con oggetto “You’ve been hacked / Pegasus” è arrivato nella posta in arrivo dell’utente. A un primo sguardo il mittente visualizzato coincide con l’indirizzo Hotmail del destinatario (es: tuoaccount@hotmail.com), inducendo la sensazione che qualcuno abbia violato l’account e stia inviando messaggi “da dentro”.

L’analisi dell’intestazione (header) rivela però che il messaggio ha fallito i controlli SPF e DMARC e non era firmato DKIM. Nonostante ciò è stato comunque recapitato.

Esempio di header semplificato

From: "Tuo Nome" <tuoaccount@hotmail.com>
Received-SPF: Fail (protection.outlook.com: domain of hotmail.com does not
                 designate 185.23.45.67 as permitted sender)
Message-ID: <random-uuid@server-attacker.example>

Il campo From: è stato “falsificato”; l’IP sorgente non è autorizzato per hotmail.com (SPF fail), non esiste una firma DKIM e DMARC fallisce, ma la policy risulta p=none, quindi il server ricevente non è tenuto al rifiuto automatico.

Perché oggi è ancora possibile falsificare il mittente

Lo spoofing dell’indirizzo e‑mail si verifica perché il protocollo SMTP, nato in un’epoca di “fiducia tra server”, consente ancora di impostare liberamente l’intestazione From:, che è quella visualizzata dai client. Alcuni punti chiave:

SMTP permette di scrivere qualsiasi valore nel campo “From:”: il protocollo non impone un controllo critico sull’identità visualizzata nel messaggio. Esistono due identità distinte:
- Envelope From / Return‑Path (mittente tecnico usato per i bounce, verificato da SPF).
- Header From (mittente “visibile” all’utente, usato da DMARC per l’allineamento).
Gli attaccanti usano server SMTP propri o mal configurati: open relay o host fuori policy che non validano il mittente.
Forging con script/strumenti: toolkit e librerie consentono di costruire manualmente i pacchetti SMTP e gli header.
Outlook.com/Hotmail non consente di cambiare arbitrariamente “From:” da interfaccia: se vedi il tuo indirizzo come mittente ma i controlli falliscono, il messaggio non è partito da Outlook.com ma da un server esterno che ha simulato l’indirizzo Hotmail.

Come funzionano SPF, DKIM e DMARC (e perché servono tutti)

SPF, DKIM e DMARC sono tre meccanismi complementari che mirano a dimostrare l’autenticità del mittente e l’integrità del messaggio.

Meccanismo	Scopo	Passaggi chiave
SPF (Sender Policy Framework)	Elenca, nel DNS del dominio, gli IP autorizzati a inviare posta.	Il server ricevente confronta l’IP del mittente con il record TXT del dominio indicato nell’envelope (MAIL FROM/Return‑Path). Se l’IP non è in lista ⇒ fail.
DKIM (DomainKeys Identified Mail)	Firma digitale di porzioni di header e del corpo per garantire integrità e identità del dominio.	Il server uscente firma con una chiave privata; il ricevente verifica con la chiave pubblica pubblicata nel DNS (selector._domainkey.dominio).
DMARC (Domain‑based Message Authentication, Reporting & Conformance)	Coordina SPF e DKIM e indica cosa fare se falliscono.	Richiede allineamento tra il dominio visibile nel `From:` e almeno uno tra SPF o DKIM. La policy `p=` può essere `none`, `quarantine` o `reject`; opzionali i report `rua`/`ruf`.

Esiti tipici e cosa significano

Esito	Descrizione	Impatto
`pass`	Verifica riuscita (SPF IP autorizzato, DKIM firma valida, DMARC allineato).	Maggiore fiducia; non garantisce l’assenza di spam, ma è un forte segnale positivo.
`fail`	Verifica fallita (es. IP non autorizzato, firma invalida, allineamento assente).	Se DMARC è `quarantine`/`reject`, tipicamente spam o rifiuto. Con `none`, consegna a discrezione del ricevente.
`softfail` (SPF)	Indicazione “probabilmente non autorizzato” (record termina con `~all`).	Spesso consegnato ma con punteggio di spam più alto.
`neutral`/`none`	Nessun giudizio (record assente o non applicabile).	Decisione delegata ad altri filtri.
`temperror`/`permerror`	Errori temporanei/definitivi nella valutazione (DNS/non conformità).	Il ricevente decide: ritentare, consegnare o filtrare.

Allineamento DMARC: relaxed vs strict

DMARC non chiede che entrambi SPF e DKIM passino, ma che almeno uno passi e sia allineato al dominio nel campo From:.

Allineamento relaxed (default): i sottodomini sono accettati (es. mail.example.com è allineato a example.com).
Allineamento strict: il dominio deve combaciare esattamente.

Le opzioni aspf e adkim nella policy DMARC consentono di scegliere tra r (relaxed) e s (strict).

Perché serve anche DKIM se ho SPF?

SPF si basa sull’IP di invio e sull’envelope; può rompersi nei forward o nelle mailing list. DKIM “viaggia” con il messaggio e resta valido anche dopo inoltri. DMARC considera valido il messaggio se uno tra SPF o DKIM passa e si allinea al dominio nel From:.

Perché l’e‑mail arriva nonostante i fail

Policy DMARC “none” del dominio hotmail.com: nel caso descritto, i report mostrano DMARC fallito con policy p=none del dominio hotmail.com. Questo indica al server ricevente di non scartare automaticamente il messaggio anche se SPF/DKIM falliscono; spesso finisce nello spam, ma può apparire in posta in arrivo a seconda di altri segnali.
Tolleranza anti‑falso‑positivo: molti provider preferiscono consegnare (o mettere in posta indesiderata) anziché rischiare falsi rifiuti. Il punteggio antispam finale è la somma di centinaia di segnali (reputazione IP, contenuto, linguaggio, pattern, interazioni pregresse, ecc.).
Segnali di “relazione”: se il tuo indirizzo compare nel From: e nei contatti o se dialoghi spesso con te stesso (es. inoltri), alcuni filtri possono attenuare la severità.

Cosa fare subito se ricevi la minaccia “Pegasus / You’ve been hacked”

Non pagare e non rispondere. Si tratta di una campagna estorsiva (sextortion) diffusa che usa mittenti falsificati.
Segnala come phishing nel tuo client (Outlook/Outlook.com). Questo allena i filtri a bloccare campagne simili.
Cambia la password del tuo account Microsoft e abilita la verifica in due passaggi (2FA).
Controlla le regole di posta nell’account: rimuovi eventuali regole sospette che inoltrano o nascondono e‑mail.
Verifica l’attività dell’account (accessi recenti, dispositivi riconosciuti). Se vedi accessi anomali, esegui logout forzato da tutti i dispositivi e rinnova la password.

Approfondimento tecnico: interpretare gli header

Per indagare, apri il messaggio e visualizza “Origine messaggio”/“Visualizza sorgente”/“Proprietà” a seconda del client. Cerca queste sezioni:

Authentication‑Results: indica gli esiti di spf=, dkim=, dmarc= e talvolta metadati aggiuntivi.
Received-SPF: dettaglia il controllo SPF con host e IP osservati.
Return‑Path: mittente tecnico usato per i bounce (rilevante per SPF).
Received: catena dei server attraversati con IP e timestamp (dal basso verso l’alto).

Checklist rapida di lettura

Il dominio nel header From coincide con quello che ha passato SPF o DKIM? (allineamento DMARC)
L’IP sorgente è un host “Microsoft” o un server terzo sconosciuto?
Ci sono Received che partono da un dominio sospetto non correlato a Microsoft?
Il testo del messaggio contiene richieste di pagamento in criptovalute o minacce? È un forte indicatore di truffa.

Best practice di pubblicazione DNS: esempi pronti

SPF

Consigli:

Elencare solo gli IP/servizi che inviano davvero.
Limitare gli include: ai provider necessari.
Chiudere con -all per rifiutare ciò che non è esplicitamente consentito (dopo un periodo di test con ~all).

_spf.example.com.   3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:spf.mailprovider.example -all"
example.com.        3600  IN  TXT  "v=spf1 redirect=_spf.example.com"

DKIM

Genera una coppia di chiavi per ogni servizio mittente e pubblica la chiave pubblica per il selector scelto:

selector1._domainkey.example.com.  3600 IN TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Imposta il tuo MTA o provider per firmare le uscite con selector1. Ruota periodicamente le chiavi (ad esempio ogni 6‑12 mesi).

DMARC

Parti in monitoraggio, poi aumenta la severità:

_dmarc.example.com. 3600 IN TXT
"v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1; aspf=s; adkim=s"

Dopo 2‑4 settimane di analisi dei report e sistemazione di tutti i flussi di posta:

_dmarc.example.com. 3600 IN TXT
"v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-agg@example.com; aspf=s; adkim=s"

Infine, enforcement completo:

_dmarc.example.com. 3600 IN TXT
"v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-agg@example.com; aspf=s; adkim=s"

Nota: i report ruf (forensic) possono contenere frammenti di messaggi: valutare gli aspetti privacy e conservazione.

Contromisure consigliate (per ruolo)

Proprietari di dominio personalizzato

Inventario dei mittenti: elenca tutti i sistemi/terze parti che inviano per tuo conto (marketing, CRM, ticketing, PEC, ecc.).
SPF rigoroso: pubblica un record che comprende solo i mittenti noti; riduci gli include: inutili; chiudi con -all dopo il test.
DKIM Everywhere: abilita DKIM su ogni servizio e usa selector diversi. Verifica periodicamente la firma.
DMARC a fasi: none → quarantine → reject, monitorando rua e sistemando gli errori di allineamento.
Allineamento s (strict): per massima protezione imposta aspf=s e adkim=s.
Subdomain policy: usa sp=reject per evitare abusi su sottodomini “orfani”.
Rotazione chiavi DKIM e TTL sensati (es. 1 ora) per rapide modifiche d’emergenza.

Utenti finali Hotmail/Outlook

Segnala come phishing i messaggi sospetti: aiuta i filtri Microsoft a bloccare future campagne.
2FA attiva sull’account, password lunga e unica.
Diffida di richieste di pagamento minacciose o in criptovalute: sono indicatori classici di truffa.
Regole di posta pulite: elimina regole che spostano/nascondono e‑mail.
Tip: crea eventualmente una regola che marchi i messaggi con dmarc=fail e From: tuodominio come “sospetti”.

Aziende

Gateway e‑mail con DMARC enforcement (es. soluzioni dedicate) per bloccare spoofing di domini esterni e interni.
Security awareness: formazione continua dei dipendenti su spoofing, display name, allegati pericolosi.
Monitoraggio dei report DMARC con dashboard e alert per anomalie.
Politiche di inoltro: limita o riscrivi i forward che rompono SPF; valuta l’adozione/rispetto di ARC nei flussi complessi.

Display name, “Header From” e perché ci caschiamo

Molti client mostrano solo il display name (“Tuo Nome”) e non l’indirizzo. Un attaccante può usare display name identico al tuo, o combinazioni come Tuo Nome <supporto‑recupero@attacker.example> sperando che il lettore non apra i dettagli. Abituati a toccare/cliccare il mittente per vedere l’indirizzo completo.

Domande frequenti

Posso impedire a chiunque di scrivere il mio indirizzo nel campo From?
No. Il protocollo lo consente. Quello che puoi fare è rendere inutile quel tentativo: con DMARC reject per il tuo dominio, i riceventi conformi rifiuteranno lo spoofing.

Perché vedo SPF=fail ma il messaggio è arrivato lo stesso?
Perché il dominio del From può avere DMARC p=none (monitoraggio) o perché altri segnali hanno spinto il ricevente a consegnare (magari in posta indesiderata). Senza enforcement, lo spoofing può passare.

Se DKIM passa ma SPF fallisce, il messaggio è legittimo?
Dipende: se DKIM è allineato al dominio nel From, DMARC può passare. Se DKIM appartiene a un altro dominio non allineato, DMARC fallirà.

Che cos’è ARC e a cosa serve?
ARC (Authenticated Received Chain) permette ai server intermedi (es. forwarder) di attestare che, all’origine, i controlli erano validi. Aiuta a ridurre i falsi negativi quando SPF si rompe in inoltri.

È pericoloso aprire l’e‑mail?
Aprire il testo non dovrebbe eseguire codice, ma clic su link/allegati sì: evita di aprire allegati eseguibili/script e non seguire link sospetti.

Workflow operativo: da “monitoraggio” a “reject” senza rompersi nulla

Baseline (2‑3 settimane): imposta p=none e raccogli rua. Mappa tutti i mittenti in uscita.
Correzioni: abilita DKIM su ogni servizio; aggiungi i relativi IP/host in SPF; elimina mittenti legacy.
Allineamento: imposta aspf=s/adkim=s quando sei sicuro che tutti i servizi usano il dominio corretto nel From.
Quarantine (2‑4 settimane): passa a p=quarantine; monitora impatti su newsletter e partner.
Reject: porta a p=reject e mantieni un processo di onboarding per nuovi mittenti.

Regole pratiche in Outlook/Exchange per segnalare spoofing

Se gestisci una cassetta aziendale, puoi creare regole di trasporto (mail flow) o regole client per evidenziare i messaggi che mostrano chiari segni di spoofing del tuo dominio:

Condizione: Authentication‑Results contiene dmarc=fail AND Header From termina con @example.com
Azioni: Prependere oggetto con “[ATTENZIONE: poss. spoofing]”, inviare a quarantena, notificare SecOps.

Per il solo client Outlook, una regola utente può spostare in una cartella i messaggi con parole chiave tipiche (“bitcoin”, “sextortion”, “Pegasus”) e mittente uguale al proprio indirizzo.

Errori comuni da evitare

SPF con troppi include: ogni include: può a sua volta includere altri domini, rischiando il limite DNS (10 lookup). Ottimizza e usa IP diretti quando possibile.
Record SPF duplicati: deve esistere un solo record TXT SPF per dominio. Unisci i contenuti.
DKIM senza rotazione: chiavi troppo longeve aumentano il rischio. Pianifica la rotazione.
DMARC senza monitoraggio: passare subito a reject senza misurare può bloccare flussi legittimi.

Checklist essenziale

Il tuo dominio usa SPF + DKIM + DMARC (con policy almeno quarantine)?
Hai abilitato 2FA sull’account Microsoft?
Segnali sempre come phishing le e‑mail sospette per allenare i filtri?
Hai revisionato le regole di posta e l’attività recente dell’account?

Conclusioni

Il fatto che un’e‑mail con mittente uguale al destinatario arrivi in posta in arrivo, nonostante SPF/DMARC fail e DKIM assente, non significa che l’account sia stato compromesso. Significa che il protocollo lo consente e che, in assenza di una policy DMARC severa (come reject), alcuni messaggi di spoofing possono ancora passare i filtri. La difesa efficace richiede una combinazione di pubblicazione DNS corretta (SPF, DKIM, DMARC), buone pratiche utente (2FA, segnalazione) e, in ambito aziendale, gateway e processi che applicano l’enforcement. Integrando questi passi, riduci drasticamente la probabilità che un attaccante riesca a far passare o a rendere credibile uno spoofing del tuo indirizzo Hotmail/Outlook.

Riassunto operativo

Perché è successo: SMTP consente di impostare liberamente From:. L’attaccante ha usato un server esterno e un indirizzo Hotmail “simulato”.
Cosa hai visto: SPF e DMARC fail, DKIM assente, ma messaggio consegnato per policy p=none e tolleranza anti‑falsi positivi.
Cosa fare ora: segnalare come phishing, 2FA, controllare regole e accessi, ignorare richieste di pagamento.
Come prevenire: per domini propri: SPF rigoroso, DKIM su tutte le uscite, DMARC fino a reject, monitoraggio continuo.