7 mittenti di terze parti che spesso violano il DMARC (e come autenticarli)

La maggior parte delle organizzazioni invia e-mail da un numero di sistemi ben superiore a quello dei propri server di posta. Piattaforme di marketing, sistemi CRM, help desk, strumenti di fatturazione e una lista sempre più ampia di assistenti basati sull’intelligenza artificiale inviano tutti messaggi che riportano il vostro dominio nell’indirizzo del mittente. Ciascuno di essi è un mittente di terze parti e rappresenta un punto in cui SPF, DKIM e DMARC possono fallire senza che nessuno se ne accorga.

Gli errori hanno ora un peso maggiore. Gmail, Yahoo e Outlook.com richiedono ai mittenti che inviano più di 5.000 messaggi al giorno di autenticarsi tramite SPF, DKIM e DMARC e di allinearli al dominio “Da”; in caso contrario, potrebbero rifiutare a priori la posta di massa non conforme. Al di sotto di tale volume, un messaggio che non supera il controllo DMARC ha maggiori probabilità di finire nella cartella dello spam e non arriverà affatto una volta che si passerà a una politica di rifiuto.

Questa guida illustra sette categorie di mittenti di terze parti, spiega in che modo ciascuna di esse violi tipicamente il DMARC ed elenca i passaggi necessari per autenticarle. Si conclude con alcuni esempi di record DNS, un metodo di verifica e un piano di implementazione.

Perché i mittenti di terze parti violano il DMARC

Il DMARC viene superato quando almeno uno tra SPF e DKIM supera il controllo ed è allineato con il dominio presente nell'indirizzo "Da" visibile. L'allineamento è l'aspetto che spesso sfugge.

• Allineamento SPF confronta il dominio nel percorso di ritorno, chiamato anche mittente dell'involucro o indirizzo di rimbalzo, con il dominio "Da". I fornitori utilizzano solitamente il proprio dominio di rimbalzo, quindi l'SPF risulta valido per loro ma non è allineato con il tuo.
• Allineamento DKIM confronta il dominio firmatario presente nella firma DKIM (il valore d=) con il dominio "Da". Di norma, i fornitori firmano con il proprio dominio per impostazione predefinita, quindi DKIM viene superato ma non risulta allineato.
• Errori di configurazione compromette il resto. Tra quelli più comuni vi sono più di 10 ricerche DNS in SPF, più di un record SPF su un dominio, record DKIM mancanti e record residui relativi a fornitori che non si utilizzano più.

Con l'allineamento "rilassato", che è l'impostazione predefinita, un sottodominio si allinea al dominio organizzativo di livello superiore. L'allineamento "rigoroso" richiede una corrispondenza esatta. Poiché le firme DKIM di solito rimangono intatte dopo l'inoltro, mentre quelle SPF spesso no, la maggior parte dei team punta all'allineamento DKIM per ogni mittente di terze parti.

I Sette Mittenti in sintesi

1. Strumenti di trascrizione delle riunioni basati sull'intelligenza artificiale e assistenti per le riunioni

Gli assistenti alle riunioni inviano sintesi, punti da trattare, bozze di follow-up e condividono link, spesso con partecipanti esterni alla vostra azienda. Sia che il vostro team utilizzi Fathom o stia valutando alternative a Fathom, chiedete al fornitore come vengono autenticate le sue e-mail prima di collegare una casella di posta o abilitare l’invio dal vostro dominio.

Molti di questi strumenti inviano le email dal proprio dominio e mostrano il tuo nome come nome visualizzato. Ciò non influisce sui tuoi risultati DMARC, poiché il dominio nell’indirizzo “Da” è quello del fornitore. Il problema sorge con le funzionalità che inseriscono il tuo dominio nell’indirizzo “Da” e inviano le email dai server del fornitore, come le email di follow-up che sembrano provenire da te. Tali messaggi riportano il percorso di ritorno e la firma DKIM del fornitore, pertanto SPF e DKIM possono superare i controlli pur non riuscendo ad allinearsi con il tuo dominio. Un terzo caso è rappresentato dagli strumenti che inviano tramite la tua casella di posta Google o Microsoft. Tale posta viene firmata e consegnata dal tuo provider di posta, quindi l’allineamento è garantito purché la firma DKIM sia abilitata per il tuo dominio su quella piattaforma.

Domande da porre al venditore:

• Quale dominio compare nell'indirizzo del mittente dei riepiloghi, degli inviti e dei promemoria?
• Esiste una funzionalità che invia e-mail dai server del fornitore utilizzando il mio dominio nell'indirizzo del mittente?
• In tal caso, posso effettuare l'autenticazione con un DKIM personalizzato e un percorso di ritorno personalizzato su un sottodominio?
• È possibile limitare o disattivare l'invio di e-mail ai partecipanti esterni?
• Se lo strumento invia messaggi alla mia casella di posta, quali autorizzazioni richiede?

Come autenticarlo:

• Se il dominio del mittente appartiene al fornitore, non c'è nulla da configurare per il tuo DMARC. Concentrati su chi riceve le e-mail.
• Se il fornitore invia messaggi dal tuo dominio, aggiungi i record DKIM e return-path indicati nella sua documentazione, preferibilmente su un sottodominio dedicato.
• Se lo strumento invia le e-mail tramite la tua casella di posta, assicurati che la firma DKIM sia abilitata per il tuo dominio personalizzato in Google Workspace o Microsoft 365.
• Invia un riepilogo effettivo a una casella di posta esterna e controlla le intestazioni di autenticazione prima dell'implementazione.

2. Piattaforme di marketing e di servizi di posta elettronica

Le piattaforme di marketing inviano il maggior volume di email di terze parti, il che le rende la causa più comune di problemi con DMARC. Per impostazione predefinita, molte di esse firmano con la chiave DKIM del fornitore stesso e utilizzano il dominio di bounce del fornitore come percorso di ritorno. SPF e DKIM risultano quindi validi per il dominio del fornitore, ma nessuno dei due corrisponde al dominio presente nell’indirizzo “Da”, pertanto DMARC restituisce un errore.

Il volume aumenta la posta in gioco. Gmail, Yahoo e Outlook.com richiedono ai mittenti che inviano più di 5.000 messaggi al giorno di autenticarsi tramite SPF, DKIM e DMARC e di allinearsi al dominio "Da"; inoltre, le e-mail di marketing devono prevedere la possibilità di annullare l'iscrizione con un solo clic e presentare un basso tasso di reclami per spam. Le e-mail di massa non conformi possono essere respinte senza appello.

Come autenticarlo:

• Invia le e-mail da un sottodominio dedicato, come ad esempio news.example.com, in modo che la reputazione di marketing e i record DNS rimangano separati dalla posta aziendale.
• Completa l'autenticazione del dominio sulla piattaforma. Ciò comporta solitamente l'aggiunta di record DKIM, spesso di tipo CNAME, in modo che i messaggi siano firmati con il tuo dominio, oltre a un dominio personalizzato per il percorso di ritorno, se disponibile.
• Pubblica il record SPF dove è necessario. Se il percorso di ritorno (return-path) è un sottodominio personalizzato, il record SPF risiede su quel sottodominio, il che consente di mantenere breve il record di root.
• Imposta una politica DMARC per il sottodominio, utilizzando il parametro `sp=` nel record principale oppure creando un record dedicato, e consulta i report aggregati.
• Aggiungi intestazioni per la disiscrizione con un solo clic e monitora i tassi di reclamo.

3. Piattaforme CRM e di coinvolgimento delle vendite

Gli strumenti di vendita inviano solitamente le e-mail in uno dei due modi seguenti. Le e-mail individuali inviate tramite una casella di posta Google o Microsoft collegata vengono autenticate dal proprio provider di posta. Le sequenze di invio in massa e le opzioni “invia tramite piattaforma” utilizzano i server della piattaforma stessa e richiedono una configurazione. Un errore frequente è quello di una piattaforma che invia le e-mail dagli indirizzi personali degli utenti sul proprio dominio senza alcuna configurazione DKIM o del percorso di ritorno.

Questi strumenti accumulano anche le inclusioni SPF. Ogni inclusione comporta delle ricerche DNS, e l'SPF ne consente solo 10 per ogni valutazione (RFC 7208). Se si supera il limite, i destinatari considerano l'SPF come un errore permanente, il che comporta il fallimento del controllo.

Come autenticarlo:

• Utilizza l'invio collegato alla casella di posta per le comunicazioni personalizzate.
• Per le sequenze inviate dalla piattaforma, autenticare un sottodominio dedicato con DKIM e return-path personalizzati e mantenere le comunicazioni su un dominio o sottodominio separato dalla posta aziendale.
• Verifica quali utenti e quali piattaforme sono autorizzati a inviare messaggi a nome del tuo dominio.
• Controlla regolarmente le ricerche SPF. Unisci o rimuovi i riferimenti agli strumenti che non utilizzi più e presta attenzione all’appiattimento, poiché gli elenchi IP appiattiti diventano obsoleti quando i fornitori cambiano indirizzo.

4. Strumenti di helpdesk e assistenza clienti

I team di assistenza solitamente richiedono che le risposte provengano da [email protected]. Ciò significa che i server dell’helpdesk inviano le e-mail con il proprio dominio nell’indirizzo “Da”, il che richiede l’allineamento SPF o DKIM per superare il controllo DMARC. Molte configurazioni tralasciano questo aspetto, poiché i ticket sembrano funzionare durante i test: i controlli effettuati dal fornitore stesso vengono superati e la consegna a una casella di posta poco rigorosa va a buon fine.

La gestione dei messaggi in entrata comporta una seconda serie di problemi. L'inoltro automatico di una casella di posta di assistenza all'help desk è semplice, ma spesso l'inoltro compromette l'integrità dell'SPF poiché l'IP del server di inoltro non è autorizzato dal mittente originale. Le firme DKIM possono sopravvivere all'inoltro, il che è uno dei motivi per cui l'allineamento DKIM è più affidabile di quello SPF.

Come autenticarlo:

• Aggiungi i record DKIM del fornitore in modo che le risposte siano firmate con il tuo dominio e, se necessario, aggiungi i record SPF o return-path del fornitore.
• È preferibile utilizzare il routing MX o il metodo di inoltro supportato dal fornitore piuttosto che le regole di inoltro automatico delle caselle di posta.
• Verifica la risposta a un ticket inviata a una casella di posta esterna ed esamina le intestazioni, quindi ripeti l'operazione per i messaggi automatici, come i sondaggi sulla soddisfazione, che a volte provengono da un sistema diverso.
• Elimina i record relativi agli strumenti di help desk che non utilizzi più.

5. Strumenti per la gestione del calendario e della pianificazione

Gli strumenti di pianificazione inviano inviti, conferme e promemoria, solitamente per conto di un organizzatore. La maggior parte di essi invia le e-mail dal dominio del fornitore indicando il tuo indirizzo nel campo “Rispondi a”, il che non influisce sul tuo DMARC. I problemi derivano dalle opzioni personalizzate che inviano e-mail dal tuo dominio senza autenticazione e dalle e-mail relative al calendario che vengono inviate senza firma.

È facile non accorgersi dei casi in cui la firma manca. Se la firma DKIM non è abilitata per il tuo dominio personalizzato in Microsoft 365, la posta in uscita viene firmata con il dominio predefinito del tenant, che non corrisponde al tuo dominio "Da". Anche Google Workspace richiede che la firma DKIM sia abilitata per il tuo dominio.

Come autenticarlo:

• Verifica quale dominio viene utilizzato dallo strumento nell'indirizzo del mittente per ciascun tipo di messaggio.
• Abilita la firma DKIM per il tuo dominio personalizzato presso il tuo provider di posta elettronica, in modo che gli inviti del calendario e i messaggi inviati dalla casella di posta siano coerenti.
• Se utilizzi un'opzione di invio personalizzata, autenticala utilizzando i record DKIM e return-path del fornitore.
• Controlla le e-mail di promemoria e di cancellazione separatamente dagli inviti.

6. Piattaforme di fatturazione e pagamento

Fatture, ricevute e solleciti di pagamento sono tra i tipi di e-mail più spesso oggetto di abusi. Gli hacker li imitano perché i destinatari agiscono rapidamente quando si tratta di questioni finanziarie, e una fattura contraffatta può reindirizzare un pagamento. Queste piattaforme spesso inviano le e-mail dal proprio dominio utilizzando il nome della tua azienda e offrono la possibilità di inviare messaggi da [email protected]. Tale opzione funziona con DMARC solo se i record DNS sono correttamente configurati.

Spesso le aziende utilizzano contemporaneamente diversi strumenti legati alla fatturazione, come un software di contabilità, un sistema di elaborazione dei pagamenti e un gestore degli abbonamenti. Ciascuno di essi costituisce un mittente distinto con i propri dati.

Come autenticarlo:

• Utilizza la funzione di dominio e-mail personalizzato di ciascuna piattaforma e pubblica i record DKIM, SPF e return-path forniti dalla stessa.
• Elencare tutti i sistemi che inviano comunicazioni di fatturazione e verificare che ciascuno di essi effettui l'autenticazione e garantisca la corrispondenza dei dati.
• Passa a una politica di applicazione delle misure di sicurezza non appena i rapporti indicano che le tue fonti legittime non vengono più rilevate. È proprio questo che impedisce agli hacker di inviare fatture che sembrano le tue.
• Indica ai clienti da quali indirizzi provengono le tue fatture.

7. Sistemi per le risorse umane, il reclutamento e la gestione delle retribuzioni

I sistemi di gestione delle candidature inviano e-mail ai candidati da indirizzi careers@ o jobs@, le piattaforme di onboarding inviano messaggi di benvenuto e gli strumenti di gestione delle buste paga inviano notifiche ai dipendenti. Spesso vengono scelti e configurati dal reparto Risorse Umane senza il coinvolgimento del reparto IT, quindi nessuno controlla l’aspetto relativo al DNS. Il risultato è che le offerte finiscono nella cartella dello spam e i candidati non ricevono gli inviti ai colloqui.

Anche qui l’usurpazione d’identità è un fenomeno diffuso. Le e-mail contenenti truffe relative a offerte di lavoro che riproducono l’immagine di marca di un’azienda reale sono una tattica ben nota, e l’applicazione di una politica DMARC rende più difficile inviarle dal proprio dominio effettivo.

Come autenticarlo:

• Includere la verifica del DNS nel processo di acquisto del software per le risorse umane.
• Autenticare un sottodominio dedicato per le e-mail relative alle assunzioni, utilizzando i record DKIM e di percorso di ritorno forniti dal fornitore.
• Pubblicare un breve elenco degli indirizzi ufficiali relativi alle assunzioni e alle buste paga, in modo che i candidati e i dipendenti possano riconoscerli.
• Verifica che gli inviti alle interviste e le e-mail con le offerte di lavoro arrivino effettivamente nelle caselle di posta elettronica, comprese quelle dei provider di webmail gratuiti.

Esempi di record DNS

I nomi e i valori esatti sono riportati nella pagina di configurazione di ciascun fornitore. Gli esempi riportati di seguito illustrano cosa ci si può aspettare. I domini sono segnaposto.

SPF sul sottodominio di invio (un record per dominio)
mail.example.com. TXT “v=spf1 include:_spf.vendor.example ~all”

Record di firma DKIM, solitamente forniti come record CNAME:
selector1._domainkey.mail.example.com. CNAME selector1.dkim.vendor.example.
selector2._domainkey.mail.example.com. CNAME selector2.dkim.vendor.example.

Dominio personalizzato per il percorso di ritorno (bounce)
bounce.mail.example.com. CNAME return.vendor.example.

Record DMARC, in modalità di monitoraggio
_dmarc.example.com. TXT “v=DMARC1; p=none; rua=mailto:[email protected]” 

Come verificare un mittente prima di andare in onda

Invia un messaggio reale dal sistema a una casella di posta esterna, apri il messaggio originale e controlla i risultati dell'autenticazione. È necessario che SPF o DKIM superino il controllo e che il dominio indicato in tali controlli corrisponda al dominio del mittente.

Allineato: DMARC superato
spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=mail.example.com

Conformità, ma non allineato: DMARC non superato
spf=pass smtp.mailfrom=bounces.vendor.example
dkim=pass header.d=vendor.example
dmarc=fail header.from=example.com 

Nel secondo esempio, entrambi i controlli vengono superati, ma per il dominio del fornitore. Nessuno dei due corrisponde a example.com, quindi il DMARC fallisce. Questa è la firma di un mittente di terze parti non autenticato.

Un piano di implementazione

1. Fai un inventario dei tuoi mittenti. Chiedi all'ufficio finanziario informazioni sugli abbonamenti SaaS, esamina l'elenco delle app con autenticazione unica (single sign-on), controlla le inclusioni SPF e verifica i log di posta.
2. Pubblica DMARC con p=none e un indirizzo di segnalazione. I rapporti aggregati mostrano tutti i sistemi che inviano messaggi a nome del proprio dominio, compresi quelli di cui nessuno si ricordava.
3. Autenticare ogni mittente legittimo. Utilizzare DKIM e return-path personalizzati e privilegiare i sottodomini per i sistemi ad alto volume o ad alto rischio.
4. Passare alla fase di applicazione delle misure. Una volta che i rapporti indicano il passaggio di posta legittima, passare alla quarantena e poi al rifiuto, monitorando i rapporti in ogni fase.
5. Trasformalo in una routine. Aggiungi un controllo di autenticazione via e-mail alla procedura di integrazione dei fornitori e rimuovi i record DNS quando smetti di utilizzare uno strumento.

FAQ

Qual è la differenza tra il superamento dei controlli SPF o DKIM e il superamento dei controlli DMARC?

SPF e DKIM possono essere considerati validi per qualsiasi dominio, compreso quello del fornitore. DMARC aggiunge il requisito che il dominio considerato valido corrisponda al dominio indicato nell'indirizzo "Da".

Devo aggiungere tutti i provider al mio record SPF?

Non sempre. Se un fornitore utilizza un percorso di ritorno personalizzato sul tuo sottodominio e firma con DKIM allineato, DMARC può superare il controllo senza modificare il tuo record SPF di root. Un numero inferiore di inclusioni ti aiuta inoltre a rimanere al di sotto del limite di 10 ricerche.

È consigliabile utilizzare i sottodomini per i mittenti di terze parti?

Spesso sì. Un sottodominio separa la reputazione dai record DNS e rende più facile monitorare e controllare ciascuna fonte. Ricorda che i sottodomini ereditano la tua politica DMARC, a meno che tu non imposti "sp=" o pubblichi un record separato.

Quanto tempo ci vuole per arrivare a p=rifiuto?

Dipende dal numero di mittenti presenti e dalla rapidità con cui è possibile risolvere i problemi. Molte organizzazioni impiegano da diverse settimane a qualche mese, basandosi su report aggregati.

Cosa succede se un fornitore non riesce a effettuare l'accesso con il mio dominio?

In tal caso, DMARC dovrebbe superare l'allineamento SPF con un percorso di ritorno personalizzato. Se nessuna delle due opzioni è possibile, il fornitore dovrebbe inviare i messaggi dal proprio dominio, non dal tuo.

Il protocollo DMARC si applica alle e-mail inviate tramite Google Workspace o Microsoft 365?

Sì. Assicurati che la firma DKIM sia abilitata per il tuo dominio personalizzato in quella sezione, altrimenti le e-mail potrebbero essere firmate con un dominio predefinito che non corrisponde.