Verificare SPF, DKIM e DMARC per ogni percorso di invio

Quando un’applicazione invia e-mail tramite un servizio esterno, non basta guardare l’indirizzo aziendale nel programma di posta. Registri il percorso effettivo e verifichi un messaggio di prova autorizzato nel punto di ricezione previsto. I record DNS e il controllo del messaggio rispondono a domande diverse.

Partire da un percorso di invio concreto

Nel progetto immaginario, un portale clienti invia notifiche di stato. Il mittente visibile è hinweis@firma.example; il servizio esterno usa versand.example come dominio per il mittente SMTP e per la firma. Questi nomi servono solo a questo progetto. Non è stato inviato alcun messaggio né interrogato alcun record DNS.

Chiarisca prima quale applicazione attiva l’e-mail, quale servizio la trasmette e chi gestisce la configurazione di dominio del servizio. Registri separatamente altri percorsi, come le notifiche di un sistema di assistenza. La configurazione di un servizio non dimostra quella di un altro.

Verificare insieme DNS e messaggio effettivo

SPF descrive i server autorizzati per le identità SMTP. Associ il record pubblicato al dominio SMTP effettivamente usato. La sola presenza di un record TXT non è ancora un esito positivo per quello specifico percorso.

DKIM associa le parti firmate del messaggio al dominio firmatario. Verifichi anche che il servizio firmi davvero e che la firma sia valida nel punto di ricezione previsto. Pubblicare una chiave pubblica nel DNS non lo conferma da solo. Consideri i servizi che elaborano il messaggio dopo la firma.

DMARC richiede un controllo SPF o DKIM riuscito con l’allineamento di dominio appropriato al mittente visibile. Questa corrispondenza è detta alignment, o allineamento. Individui quindi anche il record DMARC applicabile e le condizioni di allineamento che prevede.

Valutare correttamente un singolo esito positivo

La tabella seguente contiene ipotesi costruite deliberatamente per lo stesso progetto, non risultati misurati.

Per l’approvazione, il servizio concreto deve supportare una configurazione di dominio adeguata e il relativo invio. La modifica necessaria dipende dal servizio. Copiare un record DNS esistente qualsiasi o impostare troppo presto una politica di rifiuto non risolve il problema di allineamento.

Conservare il test di invio controllato come prova

Documenti percorso, domini usati, messaggio verificato e risultati del test. Se intervengono altri servizi, anche quel percorso richiede un caso di prova adeguato. Ripeta la verifica dopo modifiche al servizio, al dominio o all’elaborazione dei messaggi.

Google considera l’autenticazione parte dei propri requisiti di invio. Anche un caso di prova tecnico riuscito non dimostra né la collocazione nella posta in arrivo né la lettura. Registri separatamente l’osservazione della ricezione e individui chi gestisce le verifiche fallite e i riscontri sul recapito.

Fonti

• IETF: Sender Policy Framework

• IETF: DKIM Signatures

• IETF: DMARC

• Google: Email sender guidelines