In breve
LetsDMARC mostra failure che arrivano da servizi di sicurezza della posta e da server di inoltro che appartengono ai tuoi destinatari. I messaggi dietro a quelle failure sono copie di messaggi che tu hai inviato in modo corretto, consegnati una seconda volta da qualcun altro. La failure non nasce dai tuoi sistemi e non è un errore di LetsDMARC, e non è un motivo per rimandare il passaggio alla policy reject.
Prima di iniziare
- Accesso alla dashboard LetsDMARC per il dominio che stai guardando.
- L'elenco delle sorgenti che inviano davvero posta per conto del tuo dominio, per esempio il tuo gateway, il tuo tenant, la piattaforma di marketing e il sistema di ticketing.
- Lo stato DKIM attuale di ognuna di quelle sorgenti.
Come funziona
Il tuo messaggio esce dal gateway e supera SPF, DKIM e DMARC alla prima consegna. Il server che lo riceve lo accetta, ed è questa la consegna che conta per te e per il destinatario.
Molti destinatari però spostano il messaggio una seconda volta. Il loro server lo passa a un servizio di sicurezza esterno tramite un connettore, una regola di trasporto o una API, oppure una regola della casella lo inoltra a un altro indirizzo. In tutti e due i casi il messaggio viene consegnato di nuovo, e questa seconda consegna parte da un indirizzo IP che appartiene al servizio o al server che inoltra.
Quell'indirizzo non è nel tuo record SPF, quindi SPF fallisce, ed è giusto che fallisca, perché non hai mai autorizzato quell'host a inviare posta per il tuo dominio. Se il servizio modifica anche il messaggio, per esempio aggiungendo un avviso nel testo, riscrivendo i link o cambiando l'oggetto, si rompe anche la firma DKIM. Senza SPF né DKIM allineati, DMARC fallisce.
Il sistema che riceve questa seconda copia invia un rapporto aggregato al tuo dominio, perché il dominio nell'header From è ancora il tuo. LetsDMARC legge quel rapporto e mostra la failure con il nome del servizio come sorgente.
Sintomi
Nella pagina DMARC reports by sources vedi failure da nomi host che non riconosci e che non hai mai configurato. Compaiono anche nel riquadro Top 5 failure sources, che di solito è il punto da cui nasce la domanda. L'elenco completo è nella tabella grande Details in fondo alla pagina, con una riga per ogni sorgente che ha inviato posta con il tuo dominio nell'header From.
I nomi delle sorgenti osservati finora sono cloud-sec-av.com, inkyphishfence.com, perception-point.io, shield.security, ppe-hosted.com, mimecast.com, sonicwall.com e oraclecloud.com. L'elenco continua a crescere, perché dipende da quale prodotto ha comprato ognuno dei tuoi destinatari.
Queste sorgenti hanno una compliance vicina a zero, con SPF e DKIM entrambi a zero, mentre le tue piattaforme di invio restano al novantanove o cento per cento. Il loro volume è una piccola parte del traffico totale.
Quattro segni insieme ti dicono che sei davanti a questo caso.
| Cosa guardare | Cosa vedi in questo caso |
|---|---|
| Sorgente | Un servizio di sicurezza della posta conosciuto, oppure un server che inoltra la posta per un destinatario |
| Header From | Lo stesso dominio delle tue sorgenti legittime, perché il messaggio è una copia del tuo |
| Forwarded | Spesso un valore sopra lo zero. LetsDMARC lo calcola per conto suo, e il valore non è sempre al cento per cento: a volte è più basso, a volte resta a zero anche per un servizio che inoltra di sicuro. Leggilo come un indizio, non come una prova |
| Volume | In linea con il traffico normale verso quel destinatario, senza picchi improvvisi |
Causa
La failure la genera chi esegue la seconda consegna. Non la generano i tuoi server, che alla prima consegna hanno fatto il loro lavoro in modo corretto, e non è un errore di LetsDMARC, che mostra soltanto i rapporti che riceve dai sistemi che hanno ricevuto quella seconda copia.
Dalla tua parte non c'è niente di rotto. Non esiste nessuna impostazione, nel tuo DNS, nel tuo gateway o in LetsDMARC, che trasformi queste failure in pass, perché la consegna che fallisce la fa un host che non è tuo e che non puoi controllare.
Soluzione
- Apri la tabella grande Details in fondo alla pagina e guarda la sorgente in failure. Se è un servizio di sicurezza della posta o un server che inoltra per un tuo destinatario, non c'è niente da fare.
- Non cercare di far passare quelle failure. Provare a sistemarle è l'unica strada che porta a un cambiamento pericoloso, e la cosa giusta da fare è non contarle quando valuti lo stato di salute del tuo dominio.
- Non aggiungere mai gli indirizzi IP o l'include SPF di questi servizi al tuo record SPF.
- Assicurati che ogni tua sorgente legittima firmi con una chiave DKIM allineata. Una firma integra sopravvive a un inoltro semplice, quindi una parte di queste seconde consegne può comunque superare DMARC grazie al solo DKIM.
- Passa alla policy reject quando le tue sorgenti legittime sono conformi. Queste failure da sole non sono un motivo per aspettare.
Aggiungere un servizio di sicurezza di un destinatario al tuo record SPF è l'unica modifica che peggiora le cose, perché da quel momento chiunque usi quella piattaforma può inviare posta con il tuo dominio e superare SPF.
Verifica
Filtra la tabella Details sulle tue sorgenti di invio e controlla che ognuna sia conforme, con SPF o DKIM allineato. È questo il numero che decide se sei pronto per reject.
Poi guarda di nuovo le sorgenti in failure. Se sono tutte servizi di sicurezza o server che inoltrano, e il volume resta in linea con il traffico normale, il tuo dominio è in buono stato anche mentre il contatore delle failure continua a muoversi.
Limiti noti
- La tua prima consegna non viene mai toccata. Il messaggio che invii supera DMARC, quindi la policy reject non lo riguarda, non viene bloccato e non viene contato come failure. Le failure che vedi riguardano solo la seconda consegna.
- Cosa succede alla seconda copia non si può prevedere dalla tua parte. Dipende da come il destinatario ha configurato il servizio, da cosa il servizio fa al messaggio e da quale sistema prende la decisione finale, e un servizio configurato male può far rifiutare quella copia.
- SPF non può sopravvivere alla seconda consegna, perché il messaggio parte da un host che non hai autorizzato. SPF è fatto per funzionare così.
- DKIM sopravvive a un inoltro semplice, ma si rompe ogni volta che il servizio modifica il messaggio.
- Questi rapporti continueranno ad arrivare finché i tuoi destinatari useranno quei servizi. Non puoi fermarli dalla tua parte.