Rafael Pfister

Consulting

SPF, DKIM e DMARC: un’autenticazione della posta che regge

I grandi provider di posta richiedono messaggi autenticati, eppure il tuo DMARC è fermo a p=none da anni e nessuno sa quali sistemi inviano con il dominio aziendale. Porto i domini a una policy applicabile in modo controllato: prima l’inventario completo, poi l’inasprimento a tappe, senza perdere posta legittima.

La consulenza si svolge in tedesco o in inglese.

  • SPF
  • DKIM
  • DMARC
  • p=reject
  • Report DMARC
  • Protezione dallo spoofing
  • Recapitabilità

Perché sono più di tre record DNS

Pubblicare i record è la parte rapida. Il lavoro vero sta nella domanda su chi invii legittimamente con il dominio: l’ERP, il servizio di newsletter, il sistema di ticketing, i dispositivi multifunzione, il fornitore esterno delle paghe. Ogni fonte dimenticata significa posta persa dopo l’applicazione della policy. Per questo ogni mio progetto DMARC inizia con un inventario delle fonti di invio effettive dai report DMARC e dai log di posta, non con la modifica della zona DNS.

Servizi

  • Inventario delle fonti di invioIndividuare ogni sistema che invia con i tuoi domini, compresi quelli dimenticati; da report, log e analisi del tenant.
  • Progettazione dei recordSPF entro il limite di lookup, firma DKIM per ogni fonte di invio, DMARC con una strategia di allineamento sensata, sottodomini e domini parcheggiati inclusi.
  • Piano a tappe verso p=rejectInasprimento tramite none, quarantine e livelli pct, con analisi dei report prima di ogni passo e criteri di interruzione definiti.
  • I casi difficiliInoltri, mailing list, gateway davanti a Microsoft 365, sigillatura ARC: i casi su cui di solito falliscono i progetti DMARC.

Esempi dalla pratica