Diagnosticare i problemi di delivery

Quando un utente segnala che una mail non arriva, il primo bivio d’esame è capire se la causa è un comportamento utente (filtro personale, regola client, mailbox piena) oppure una policy amministrativa (routing rule, spam control, Gmail DLP che ha bloccato l’allegato). Prima di ipotizzare un bug, chiediti sempre qual è il comportamento atteso della configurazione corrente per quella organizational unit (OU).

Lo strumento di base è la Email Log Search, che traccia il percorso di un singolo messaggio: mostra se è stato consegnato, respinto, messo in admin quarantine o instradato altrove da una routing rule (split delivery, dual delivery, inbound gateway), con lo status finale. Per un’analisi più profonda si passa al security investigation tool, che consente di cercare su condizioni multiple (mittente, oggetto, allegato) e di eseguire azioni bulk (delete, mark as spam/phishing, rimozione dalle inbox già consegnate). L’analisi degli header del messaggio rivela i risultati di SPF/DKIM/DMARC, gli hop SMTP e i ritardi; per problemi lato browser/UI si raccoglie invece un HAR file oltre ai log.

Autenticare la posta in uscita: SPF, DKIM, DMARC, MTA-STS

Questi record vivono nel DNS del dominio; solo l’attivazione di DKIM parte dalla Admin console.

  • SPF: record TXT che elenca i server autorizzati a inviare per il dominio (per Google Workspace include i server Google). Verifica che l’IP mittente sia legittimo.
  • DKIM: firma crittografica applicata al messaggio. Si genera la chiave nella Admin console, si pubblica il record nel DNS e si conferma l’attivazione. Garantisce che il contenuto non sia stato alterato.
  • DMARC: policy pubblicata nel DNS che dice al destinatario cosa fare quando SPF o DKIM falliscono l’alignment con il From visibile: none (solo monitoraggio), quarantine o reject. Genera anche i report aggregati.

L’ordine corretto è: prima SPF e DKIM funzionanti e allineati, poi DMARC partendo da p=none per osservare i report senza bloccare mail legittime, quindi inasprendo a quarantine/reject.

MTA-STS non firma nulla: impone che la posta in ingresso verso il tuo dominio sia consegnata solo su connessioni TLS con certificato valido, contro downgrade e man-in-the-middle. È complementare, non alternativo, a SPF/DKIM/DMARC.

Mitigare spam, phishing e attacchi

Le difese si stratificano per OU tramite policy ereditate con override. Le Gmail safety settings coprono attachments, links & external images e spoofing/authentication: alzarle sposta i messaggi sospetti in spam o quarantine invece di consegnarli.

Per il fine-tuning dei controlli spam: la allowlist (approved senders/IP) fa saltare i controlli per mittenti fidati — utile ma rischiosa, perché apre una porta allo spoofing; la blocked senders list rifiuta o filtra mittenti specifici. L’admin quarantine trattiene i messaggi che matchano una regola in attesa di revisione manuale, evitando sia il blocco cieco sia la consegna. Per la conformità si usano le compliance rules: attachment compliance (blocca o instrada per tipo/contenuto) e secure transport compliance (forza TLS verso domini partner specifici).

Attenzione al trade-off classico: mettere in allowlist un intero dominio o inbound gateway disattiva l’autenticazione per quel traffico ed è spesso la causa reale del phishing che “supera” i filtri.

Trappole tipiche d’esame

  • Mail legittime finiscono in spam nonostante SPF corretto → verifica DKIM e l’alignment DMARC: SPF autentica l’envelope sender, ma DMARC richiede l’alignment con il From visibile; senza DKIM allineato molte mail inoltrate falliscono.
  • Bloccare lo spoofing senza rifiutare subito → DMARC p=none prima, poi inasprisci: parti dal monitoraggio dei report, altrimenti scarti mail legittime non ancora autenticate.
  • Forzare la crittografia verso un partner → secure transport compliance (TLS), non MTA-STS: MTA-STS protegge l’inbound verso di te; per imporre TLS in uscita verso un dominio serve la TLS compliance rule.
  • Esaminare o rimuovere un phishing già consegnato a molti utenti → security investigation tool: consente ricerca e azione bulk (delete/mark) su tutte le inbox; l’Email Log Search traccia solo il percorso di consegna.
  • Un utente non riceve mail da un mittente, gli altri sì → controlla filtri utente e policy della sua OU: è comportamento utente o policy per OU, non un problema di autenticazione globale.
  • Allegato bloccato solo per alcuni → Gmail DLP o attachment compliance ereditata per OU: la policy applicata alla OU dell’utente spiega la differenza; verifica ereditarietà e override.