Anti-phishing, impersonation e autenticazione del dominio con DKIM

Il phishing mirato non si ferma con i filtri antispam: serve combinare le policy anti-phishing di Microsoft Defender for Office 365 con l’autenticazione del dominio (SPF, DKIM, DMARC). Le due leve sono complementari — la prima valuta il contenuto e il comportamento del mittente, la seconda dimostra crittograficamente che un messaggio proviene davvero dal tuo dominio.

Anti-phishing policy: cosa configuri e dove

Le policy si gestiscono in Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Anti-phishing. Attenzione al livello di licenza:

Impersonation protection

Sono tre controlli distinti da attivare nella policy:

• User impersonation: elenco esplicito di indirizzi da proteggere (CEO, CFO, direzione, ma anche partner esterni). Il limite è di 350 utenti per policy. Se non inserisci l’indirizzo, la protezione non si applica a quell’utente.
• Domain impersonation: puoi selezionare Include domains I own (tutti i domini accepted del tenant) e/o Include custom domains per i domini di partner e fornitori che non gestisci.
• Mailbox intelligence: costruisce il grafo delle relazioni di posta di ciascun utente e rileva mittenti anomali. Va abilitata insieme a Enable intelligence for impersonation protection, che è l’interruttore che trasforma il rilevamento in un’azione concreta.

Per ogni categoria imposti l’azione: Quarantine the message, Redirect to another address, Move to Junk, Don’t apply any action, più i safety tips (mittente non autenticato, tag “via”, domini simili). Le eccezioni si dichiarano in Trusted senders and domains, da usare con parsimonia perché disattivano completamente la valutazione.

Advanced phishing thresholds

Quattro livelli progressivi che regolano l’aggressività del machine learning:

1. Standard — bilanciato, default.
2. Aggressive
3. More aggressive
4. Most aggressive — massimo recall, alto rischio di falsi positivi.

Alzare la soglia è la risposta corretta quando “il phishing passa nonostante la policy attiva”; abbassarla quando la posta legittima finisce in quarantena.

Autenticare il dominio: SPF, DKIM, DMARC

SPF è un record TXT che elenca gli host autorizzati a inviare per il dominio (v=spf1 include:spf.protection.outlook.com -all). Da solo non sopravvive al forwarding e non protegge l’header From visibile all’utente.

DKIM firma il messaggio con una chiave privata; il destinatario verifica con la chiave pubblica pubblicata in DNS. In Exchange Online la firma per il dominio onmicrosoft.com è attiva di default, ma per ogni dominio personalizzato devi:

1. Pubblicare due record CNAME presso il registrar:
   • selector1._domainkey.contoso.it → selector1-contoso-it._domainkey.contoso.onmicrosoft.com
   • selector2._domainkey.contoso.it → selector2-contoso-it._domainkey.contoso.onmicrosoft.com
2. Attendere la propagazione DNS.
3. In Defender portal → Policies & rules → Threat policies → Email authentication settings → DKIM, selezionare il dominio e portare Sign messages for this domain with DKIM signatures su Enabled.

I due selector servono alla rotazione automatica delle chiavi: Microsoft alterna selector1 e selector2, quindi pubblicarne uno solo fa fallire l’abilitazione o la rotazione successiva.

DMARC è un record TXT su _dmarc.contoso.it che dice ai destinatari cosa fare quando SPF e DKIM falliscono l’allineamento con il dominio del From:

v=DMARC1; p=none; pct=100; rua=mailto:dmarc@contoso.it

La progressione operativa corretta è p=none (solo monitoraggio e report aggregati) → p=quarantine → p=reject, irrigidendo solo dopo aver verificato dai report che tutte le sorgenti legittime (CRM, marketing automation, ERP, MFP) siano allineate.

Scenario tipico

Gli utenti ricevono messaggi che imitano il CEO da contoso-it.com invece di contoso.it. La risposta completa: aggiungere l’indirizzo del CEO alla lista degli utenti protetti, attivare domain impersonation con i domini di proprietà, abilitare mailbox intelligence con azione di quarantena, e in parallelo completare SPF + DKIM sul dominio custom prima di alzare DMARC.

Trappole tipiche d’esame

• Scenario: “Abbiamo già SPF configurato, i messaggi in uscita risultano non firmati DKIM” → la risposta giusta è pubblicare i due CNAME dei selector e abilitare DKIM per quel dominio custom; SPF non firma nulla e l’abilitazione DKIM è per dominio, non a livello di tenant.
• Scenario: “Vogliamo bloccare subito lo spoofing del nostro dominio” → non impostare p=reject come primo passo: prima SPF e DKIM allineati, poi DMARC p=none per raccogliere i report, infine irrigidimento. Passare a reject troppo presto blocca posta legittima di terze parti.
• Scenario: “La policy anti-phishing è attiva ma le mail che fingono di essere il CFO passano” → la protezione impersonation richiede l’inserimento esplicito degli utenti da proteggere (fino a 350); non protegge automaticamente tutti gli utenti del tenant.
• Scenario: “Serve rilevare mittenti anomali rispetto alle abitudini di ogni utente” → mailbox intelligence (Defender for Office 365), non spoof intelligence né SPF.
• Scenario: “Il phishing continua a passare con impostazioni standard e vogliamo più aggressività” → alzare gli advanced phishing thresholds al livello 2/3/4, accettando più falsi positivi; non è un compito di SPF/DKIM/DMARC.