L'autenticazione delle e-mail nelle più grandi aziende di intelligenza artificiale al mondo

Il settore dell’intelligenza artificiale ha dedicato due anni a rendere la creazione di identità digitali convincenti un’operazione alla portata di tutti. Abbiamo deciso di verificare in che misura le principali aziende mondiali specializzate in IA difendono i propri domini aziendali proprio da questi stessi rischi di usurpazione d’identità. Il 6 agosto 2026 abbiamo condotto test in tempo reale di ricerca DNS ricorsiva su otto protocolli fondamentali di sicurezza della posta elettronica per 30 grandi aziende del settore dell’IA.

Il risultato principale è semplice. Ogni singola azienda ha implementato il livello base di autenticazione delle e-mail. Tutte e 30 pubblicano record SPF e DMARC, e almeno 28 confermano l’utilizzo di DKIM. Una volta che si va oltre questi elementi di base, il livello di sicurezza crolla drasticamente. Solo due aziende su trenta pubblicano MTA-STS. Solo sei firmano i propri record DNS con DNSSEC, e 19 lasciano ancora i propri record SPF impostati su “softfail”.

Nessuna delle aziende specializzate in IA incluse nel nostro benchmark pubblica MTA-STS. Gli unici due operatori oggetto dell’analisi che lo fanno sono Google e Microsoft.

Ciò rende tutte le startup specializzate in IA del gruppo vulnerabili agli attacchi di downgrade e all'intercettazione del traffico in transito, anche se i loro record DMARC superano la verifica.

Verifica la sicurezza del tuo dominio

Vuoi sapere a che punto è il tuo dominio? Controlla la configurazione del tuo dominio in tempo reale utilizzando il PowerDMARC Domain Analyzer mentre esplori il set di dati completo dei benchmark.

Cosa abbiamo misurato e come

Il nostro campione di ricerca comprende 30 delle principali organizzazioni nel campo dell’IA: OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney, Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer e Glean. Abbiamo valutato il dominio principale di ciascuna entità il 6 agosto 2026; in questo rapporto, Google e DeepMind sono considerati come domini principali distinti.

Abbiamo valutato otto protocolli e parametri specifici: configurazione dei record SPF, presenza del selettore DKIM, implementazione delle politiche DMARC, convalida DNSSEC, MTA-STS, TLS-RPT, BIMI (Brand Indicators for Message Identification) e provider di servizi MX. Abbiamo interrogato i resolver ricorsivi pubblici (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) con EDNS0 abilitato ed eseguito da tre a quattro tentativi per ogni record. I record TXT SPF apex sono stati recuperati utilizzando DNS-over-HTTPS per evitare problemi di fallback su TCP/53 in presenza di insiemi di record TXT di grandi dimensioni. I conteggi delle ricerche ricorsive SPF sono stati calcolati rigorosamente secondo quanto previsto dalla sezione 4.6.4 della RFC 7208.

Per garantire la massima trasparenza di questa ricerca, segnaliamo sei evidenti limiti analitici:

• Limiti delle verifiche DKIM: i selettori DKIM non possono essere individuati tramite query DNS standard. Il nostro conteggio di 28 su 30 rappresenta un limite minimo. Ad esempio, meta.com non ha restituito alcun risultato su oltre 100 selettori verificati, il che indica la presenza di un selettore personalizzato piuttosto che l’assenza di DKIM.
• Caratteri jolly: databricks.com utilizza un carattere jolly DNS sotto _domainkey. Qualsiasi query con selettore viene risolta, rendendo irrilevante il conteggio esatto dei selettori. Abbiamo registrato questa configurazione come un risultato relativo ai caratteri jolly.
• Ambito di analisi: abbiamo testato esclusivamente i domini principali di livello superiore delle aziende. I sottodomini dedicati al marketing o alle transazioni non sono stati valutati.
• Errori DNS nei sub-include: amazon.com fa riferimento a spf3.amazon.com, che non è stato possibile risolvere a causa delle dimensioni. Il totale di quattro ricerche registrate da Amazon rappresenta il valore minimo.
• Ambito temporale: le configurazioni DNS sono soggette a modifiche. Questi dati rappresentano un’istantanea in tempo reale del 6 agosto 2026.
• Approccio vs. Violazione: una politica di autenticazione più permissiva riflette una posizione meno rigorosa in materia di anti-spoofing. Ciò non implica una violazione della sicurezza né una negligenza operativa.

Ogni dato contenuto nel presente rapporto può essere verificato in modo indipendente utilizzando i comandi dig standard su resolver pubblici.

Tutti superano l'esame sulle nozioni di base dell'autenticazione delle e-mail

I protocolli di riferimento sono adottati all’unanimità in tutto il settore dell’intelligenza artificiale. Tutte e 30 le aziende pubblicano un record SPF, tutte e 30 pubblicano un record DMARC e 29 pubblicano un indirizzo di segnalazione aggregato (rua) valido. Il 90% del campione applica il DMARC con p=quarantine (12 aziende) o p=reject (15 aziende).

Tuttavia, il contesto è importante. Esattamente il 50,0% di queste aziende leader nel settore dell’IA applica una rigorosa politica “p=reject”. Per contestualizzare, il nostro recente rapporto sull’adozione di DMARC e MTA-STS negli Stati Uniti mostra un tasso di applicazione della politica “p=reject” pari al 49,0% a livello nazionale. Le aziende di IA con il maggior valore al mondo si collocano esattamente nella media nazionale per quanto riguarda l’applicazione di base del DMARC.

Se volete capire a cosa serve effettivamente l'impostazione p=reject, essa funge da ultimo filtro per bloccare i messaggi non autorizzati prima che raggiungano la casella di posta in arrivo. Tre aziende incluse nel benchmark, Hugging Face, Stability AI e Cerebras, mantengono l'impostazione p=none, che monitora il traffico senza bloccare le e-mail contraffatte.

Matrice di adozione dei protocolli (campione di 30 principali aziende del settore dell'IA)

Fonte: Ricerca PowerDMARC sul DNS in tempo reale (6 agosto 2026)

Solo due su trenta pubblicano MTA-STS

Mentre la verifica di base dei domini è ormai diffusa ovunque, la sicurezza a livello di trasporto presenta un quadro ben diverso. Su 30 leader di mercato, solo Google e Microsoft pubblicano i record RFC 8461 MTA-STS (Mail Transfer Agent Strict Transport Security) e TLS-RPT (SMTP TLS Reporting). Nessuna startup specializzata in IA né alcun fornitore di hardware specializzato pubblica questi record. La nostra guida introduttiva all’MTA-STS illustra in dettaglio il funzionamento del protocollo.

DMARC e MTA-STS risolvono problemi completamente diversi all'interno dello stack di sicurezza. DMARC autentica l'identità del mittente per impedire lo spoofing delle intestazioni. MTA-STS impone l'uso di connessioni TLS crittografate tra i server di posta per prevenire attacchi di tipo "man-in-the-middle" e attacchi di downgrade. Nessuno dei due protocolli sostituisce l'altro.

A onor del vero, un tasso di adozione del 6,7% all’interno di questo campione supera comunque il valore di riferimento nazionale dell’1,7% riportato nella nostra ricerca sugli Stati Uniti. Il vero insegnamento da trarne è di natura strutturale: le uniche aziende nell’ecosistema dell’IA che garantiscono la sicurezza del trasporto sono i due giganti tecnologici che gestiscono piattaforme di posta elettronica cloud a livello globale. È possibile verificare lo stato della crittografia del trasporto con lo strumento MTA-STS Checker di PowerDMARC.

Il divario del DNSSEC – Coinvolgendo tutti i principali attori del settore dell'intelligenza artificiale

Il protocollo DNSSEC (Domain Name System Security Extensions) fornisce una prova crittografica che le risposte DNS non siano state falsificate. Solo sei delle trenta aziende oggetto della nostra ricerca firmano la propria zona aziendale con DNSSEC: Hugging Face, ElevenLabs, Databricks, Scale AI, Writer e Glean. Ciò rappresenta un tasso di adozione del 20,0%, leggermente superiore alla media nazionale statunitense del 18,0%.

Il dato che salta all’occhio è chi manca all’appello. Nessuna delle grandi aziende tecnologiche incluse nel nostro campione ha firmato con DNSSEC il proprio dominio aziendale principale. Google, Microsoft, Meta, NVIDIA, Amazon, Apple e IBM lasciano tutte il proprio dominio di primo livello non firmato.

Tassi di adozione dei protocolli: le prime 30 aziende nel settore dell’IA rispetto ai valori di riferimento (2026)

Fonte: Ricerca originale di PowerDMARC (agosto 2026) | Rapporto di settore Valimail 2026

Implementazione incompleta di Stability AI

Le nostre analisi hanno evidenziato una classica lacuna di implementazione presso Stability AI. Il dominio pubblica un record DNSKEY valido all’interno della propria zona, ma manca il corrispondente record DS (Delegation Signer) presso il registrar di primo livello. Poiché la catena di fiducia si interrompe al livello superiore, i resolver di convalida trattano la zona come se fosse completamente priva di firma. Si tratta di una protezione solo sulla carta, che non garantisce alcuna sicurezza agli utenti finali.

Il protocollo DNSSEC è fondamentale per la sicurezza della posta elettronica, poiché i record SPF, DKIM e DMARC vengono tutti trasmessi tramite il DNS standard. Senza la firma crittografica delle zone, gli aggressori possono manipolare le risposte DNS durante il transito per aggirare completamente i controlli sulla posta elettronica.

Diciannove su trenta continuano a registrare un "softfail" dell'SPF

Dalla nostra ricerca emerge che 19 aziende su 30 concludono il proprio record SPF con un qualificatore ~all (softfail) anziché con un -all (hardfail). Solo nove utilizzano l’hardfail, mentre due aziende (Meta e Writer) ricorrono al meccanismo redirect=.

È interessante notare che 10 delle 15 aziende che applicano il parametro p=reject continuano a utilizzare ~all nei propri record SPF. L'elenco comprende Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq e Glean. È possibile verificare la sintassi SPF del proprio dominio utilizzando lo strumento di ricerca SPF di PowerDMARC.

In questo contesto è fondamentale comprendere la differenza tra la sintassi "softfail" e "hardfail" dell'SPF. Quando un dominio applica il DMARC con p=reject, è la politica DMARC complessiva a determinare la consegna dei messaggi. Un "softfail" nell'SPF non crea una falla di sicurezza quando il DMARC è attivo. Tuttavia, l'uso di -all fornisce un segnale esplicito e inequivocabile ai destinatari che valutano l'SPF in modo indipendente. Passare da "softfail" a "hardfail" rimane un modo semplice per rafforzare la propria sicurezza.

Analisi dettagliata dei dati di qualificazione SPF per p=reject (15 aziende)

Nessuno ha superato il limite di consultazione SPF – per ora

La RFC 7208 stabilisce un limite rigoroso di 10 ricerche DNS per la valutazione SPF. Il superamento di tale limite provoca un PermError, che invalida completamente il controllo SPF. Nessuna delle 30 aziende supera il limite massimo di 10 ricerche. Writer è quella che si avvicina di più al limite, con 9 ricerche, seguita da Perplexity con 8. OpenAI, Microsoft e Cohere si attestano a 7 ricerche.

Il record SPF di OpenAI offre un ottimo esempio delle moderne infrastrutture di posta elettronica aziendali. La loro catena di inclusioni comprende Google Workspace, Microsoft 365, HubSpot, Marketo e Oracle Cloud. Tale configurazione utilizza sette ricerche, lasciando un margine di tre ricerche. L’aggiunta di un solo ulteriore strumento di marketing esterno potrebbe causare un malfunzionamento del record.

Margine di ricerca DNS di SPF (aziende selezionate vicine al limite di 10 ricerche)

Cinque aziende hanno già esternalizzato la gestione dell’SPF

La gestione manuale delle verifiche diventa complessa quando si raggiungono grandi dimensioni. Cinque aziende incluse nel nostro benchmark utilizzano servizi di terze parti dedicati per gestire la propria infrastruttura SPF:

Quattro di queste cinque organizzazioni utilizzano le macro SPF anziché semplici elenchi di indirizzi IP. Le macro SPF valutano dinamicamente le connessioni in entrata al momento della richiesta, rendendole uno standard consolidato per le reti aziendali complesse.

Le organizzazioni che desiderano aggirare i limiti di ricerca senza ricorrere al monitoraggio manuale possono valutare le soluzioni SPF in hosting PowerSPF di PowerDMARC.

La configurazione descritta dall'autore evidenzia perché è importante un'implementazione corretta. Il loro meccanismo di reindirizzamento di terze parti consuma nove delle dieci ricerche consentite in un unico passaggio. L'utilizzo di un servizio SPF gestito e ospitato dovrebbe semplificare il record, non consumare quasi tutto il budget a disposizione per le ricerche.

Tre corsi di laurea sono ancora in fase di monitoraggio

Hugging Face, Stability AI e Cerebras applicano una politica DMARC con impostazione p=none. Questa configurazione consente di raccogliere i rapporti di consegna senza proteggere il dominio dagli abusi. Gli autori degli attacchi possono inviare messaggi non autorizzati utilizzando questi nomi di dominio e i server di posta destinatari continueranno a consegnarli normalmente.

Questa scelta strategica è particolarmente rilevante per Hugging Face, che funge da piattaforma centrale per il download dei pesi dei modelli di intelligenza artificiale open source. Un’e-mail contraffatta e convincente proveniente da Hugging Face potrebbe facilmente indurre gli sviluppatori a scaricare codice o file di modelli compromessi. D’altro canto, Hugging Face merita un riconoscimento per essere una delle sole sei aziende del nostro campione ad aver protetto il proprio dominio con il protocollo DNSSEC.

Cosa significa – e cosa bisogna correggere

Queste raccomandazioni concrete in materia di sicurezza forniscono alle aziende operanti nel settore dell’intelligenza artificiale oggetto dell’analisi una tabella di marcia mirata per eliminare le vulnerabilità legate allo spoofing e proteggere la reputazione dei propri domini. L’implementazione di questi controlli relativi all’autenticazione delle e-mail e al DNS garantisce una rigorosa verifica del mittente, assicura la crittografia durante il transito dei dati e instaura un monitoraggio operativo continuo.

1. Attuazione di DMARC: modifica la tua politica da p=none a p=quarantine, quindi stabilisci una data precisa entro la quale passare a p=reject.
2. Requisiti Harden SPF: modifica il finale del tuo record SPF da ~all a -all una volta che i rapporti aggregati DMARC confermano che tutti i mittenti legittimi sono allineati.
3. Implementa MTA-STS e TLS-RPT: proteggi la tua posta durante il transito. DMARC verifica l'identità del mittente, mentre MTA-STS garantisce la crittografia del trasporto tra i server.
4. Abilita correttamente il protocollo DNSSEC: firma la tua zona DNS e assicurati che il tuo registrar pubblichi il record DS corrispondente per completare la catena di fiducia.
5. Gestione dei limiti di ricerca SPF: monitora attentamente il numero totale di ricerche DNS. Utilizza strumenti SPF in hosting basati su macro per evitare di raggiungere il limite massimo di 10 ricerche.
6. Definire esplicitamente i sottodomini: impostare una politica sp= esplicita nel proprio record DMARC per impedire agli aggressori di falsificare i sottodomini non protetti.
7. Assegnare la responsabilità operativa: i controlli tecnici richiedono una supervisione regolare. Scegliete un membro del team dedicato che si occupi di esaminare i rapporti DMARC ogni settimana.

Colmare il divario nell'autenticazione delle e-mail

La nostra ricerca dell'agosto 2026 mostra che tutte e 30 le principali aziende del settore dell'intelligenza artificiale hanno implementato gli elementi fondamentali dell'autenticazione delle e-mail: SPF, DKIM e DMARC sono presenti in tutte. Tuttavia, l'adozione si ferma non appena si va oltre questi primi passi. Solo due pubblicano MTA-STS, solo sei utilizzano la firma DNSSEC e diciannove continuano ad affidarsi a record SPF con softfail.

Il settore dell'intelligenza artificiale ha completato con successo la fase iniziale di configurazione. Il prossimo passo consiste nell'adottare controlli avanzati, quali la crittografia del trasporto e la firma delle zone, per colmare le lacune residue. Questi miglioramenti non richiedono il cambio di fornitore, ma solo un'attenzione particolare a livello operativo.

Vuoi sapere qual è lo stato del tuo dominio? Puoi verificare il tuo dominio con lo strumento gratuito di verifica dei record di dominio di PowerDMARC oppure esplorare la suite gratuita di strumenti di sicurezza di PowerDMARC per rafforzare la sicurezza della tua posta elettronica. Il phishing via e-mail continua ad aumentare di anno in anno e le aziende qui citate sono esattamente il tipo di marchi che gli hacker amano imitare. Se preferisci discutere di cosa comportino queste lacune per il tuo dominio, puoi rivolgerti direttamente al nostro team.

Domande frequenti

Le principali aziende del settore dell'intelligenza artificiale utilizzano il DMARC?

Sì, il 100% delle 30 principali aziende specializzate in IA valutate nella nostra ricerca pubblica un record DMARC valido. Tuttavia, solo il 90% applica una politica attiva (quarantena o rifiuto), mentre il 10% rimane in modalità di solo monitoraggio (p=nessuna).

Quante aziende che si occupano di intelligenza artificiale applicano il DMARC con p=reject?

Esattamente 15 aziende su 30 (50,0%) applicano il protocollo DMARC con il parametro p impostato su "reject". Questo dato corrisponde all'attuale media nazionale statunitense del 49,0% registrata nei benchmark di settore più ampi.

Che cos’è l’MTA-STS e perché il DMARC non lo sostituisce?

MTA-STS impone l'uso di connessioni TLS crittografate per le e-mail in transito tra i server. DMARC autentica l'identità del mittente per impedire lo spoofing dell'indirizzo. Questi protocolli proteggono parti diverse del flusso delle e-mail, il che significa che nessuno dei due può sostituire l'altro.

Il protocollo DNSSEC è importante per l'autenticazione delle e-mail?

Sì, il protocollo DNSSEC protegge il tuo dominio dallo spoofing DNS e dal cache poisoning. Poiché i record SPF, DKIM e DMARC si basano su query DNS, il protocollo DNSSEC garantisce che tali record non possano essere manomessi durante il transito.

SPF ~all (softfail) rappresenta un problema di sicurezza?

Non se il tuo dominio applica DMARC con p=quarantine o p=reject. Quando l'applicazione di DMARC è attiva, essa ha la precedenza sul softfail. Tuttavia, passare a -all (hardfail) offre un segnale di sicurezza più forte per i destinatari che verificano l'SPF in modo indipendente.

Qual è il limite massimo per la ricerca con SPF 10 e chi si sta avvicinando a tale limite?

La RFC 7208 limita le valutazioni SPF a 10 ricerche DNS ricorsive per prevenire l'uso improprio dei server. Il superamento delle 10 ricerche genera un PermError. Nel nostro studio, Writer è in testa con 9 ricerche, seguito da Perplexity con 8.

Come è stata condotta questa ricerca?

I dati sono stati raccolti il 6 agosto 2026 tramite query DNS in tempo reale effettuate su resolver ricorsivi pubblici. Abbiamo valutato i domini di primo livello aziendali di 30 principali società operanti nel settore dell’intelligenza artificiale in relazione a otto protocolli fondamentali di sicurezza della posta elettronica, in conformità con gli standard RFC.

• Informazioni su
• Ultimi messaggi

Milena Baghdasaryan

Specialista dei contenuti presso PowerDMARC

Milena è un'abile scrittrice e creatrice di contenuti con oltre 7 anni di esperienza nella creazione di contenuti coinvolgenti su IT, cybersicurezza, eventi virtuali e altro. Ha una comprovata esperienza nella realizzazione di lavori di alta qualità per riviste internazionali e si è laureata in istituzioni prestigiose come la New York University Abu Dhabi, l'UWC China e il College of Europe.

Ultimi messaggi di Milena Baghdasaryan (vedi tutti)

• L'autenticazione delle e-mail nelle più grandi aziende di intelligenza artificiale del mondo - 10 agosto 2026
• I 5 migliori strumenti per la lotta al Business Email Compromise (BEC) nel 2026 - 31 luglio 2026
• Strumenti DMARC gratuiti: strumenti di verifica, generatori e monitoraggio (2026) - 30 luglio 2026