Technical Reference · 2026 Edition

BIMI: Come Funziona Brand Indicators for Message Identification

Una guida pratica e verificata sulle fonti di BIMI: applicazione DMARC, SVG Tiny P/S, record DNS, certificati VMC o CMC, policy dei receiver e validazione.

Last updated 16 agosto 2026 7 min read

BIMI: Come Funziona Brand Indicators for Message Identification

BIMI è l’acronimo di Brand Indicators for Message Identification. È uno standard di autenticazione delle email che consente a un mittente di pubblicare il logo del proprio brand affinché i provider di posta supportati possano valutarlo e, dove le rispettive policy lo consentono, visualizzarlo accanto ai messaggi del mittente.

BIMI non è una funzione di caricamento immagini. Si basa sull’autenticazione delle email, su DNS, su un formato SVG vincolato e sulla policy dei receiver. Un record BIMI corretto non obbliga una casella di posta a mostrare un logo. I provider di posta prendono le proprie decisioni per i singoli domini.[1]

Il percorso pratico si articola in quattro fasi:

  1. autenticare il dominio di invio e applicare DMARC;
  2. preparare un logo SVG Tiny Portable/Secure valido;
  3. pubblicare il record di asserzione BIMI e, dove richiesto, un file certificato; e
  4. testare il dominio distribuito, anziché presupporre che la sola pubblicazione sia sufficiente.

Esegui un audit del dominio BIMI o valida un logo prima di modificare il DNS.

Cosa fa BIMI

Un record di asserzione BIMI identifica la posizione di un file logo e, ove applicabile, di un file certificato. Un receiver supportato può recuperare tali risorse, valutarle insieme all’autenticazione del mittente e decidere se visualizzare l’indicatore.

Il risultato è un’identità del mittente riconoscibile nella casella di posta del destinatario. L’obiettivo sottostante, tuttavia, è un’autenticazione del mittente più solida. BIMI dipende da DMARC; non sostituisce DMARC, SPF o DKIM.

Cosa non fa BIMI

BIMI non garantisce il recapito in casella, la reputazione del mittente né la visualizzazione del logo. Un record tecnicamente valido può comunque non essere visualizzato se il provider ricevente applica una policy diversa, se una risorsa non può essere recuperata o validata, oppure se il messaggio non soddisfa le condizioni di autenticazione del receiver. BIMI dovrebbe pertanto essere implementato nell’ambito di un programma più ampio di email autenticate, non come scorciatoia di tipo cosmetico.[1]

Il percorso di implementazione

1. Applicare DMARC

Per il workflow BIMI documentato da Google, DMARC deve essere configurato con una policy p=quarantine o p=reject e pct=100; p=none non è qualificante.[2] Anche SPF o DKIM devono autenticare la posta in modo da soddisfare l’allineamento DMARC.

Se il dominio è ancora in modalità di monitoraggio, iniziare con un programma DMARC controllato. DMARCSwiss è il servizio del portfolio dedicato al monitoraggio continuativo dei report aggregati e alla progressione della policy. Questa pagina non considera p=none come pronto per BIMI.

Leggi la guida dettagliata sui requisiti DMARC.

2. Preparare un logo SVG Tiny P/S

BIMI utilizza un profilo SVG ristretto pensato per il rendering sicuro in un ambiente sensibile alla sicurezza. Gli export dagli strumenti di design standard contengono frequentemente elementi non supportati, riferimenti esterni, script, animazioni o geometrie che richiedono normalizzazione.

Le istruzioni pubblicate da Google includono i requisiti SVG Tiny P/S e le condizioni specifiche per Gmail, tra cui le dimensioni assolute in pixel, le raccomandazioni sulla presentazione quadrata, gli sfondi solidi, le dimensioni del file e un elemento desc.[2]

makeBIMI converte e valida gli asset SVG rispetto ai vincoli tecnici pertinenti. Il risultato è una validazione tecnica, non una garanzia che un’autorità di certificazione o un provider di posta accetterà il deployment finale.

Converti o valida un logo · Leggi la guida SVG Tiny P/S · Leggi lo standard tecnico

3. Pubblicare il record BIMI

Un record di asserzione BIMI predefinito viene pubblicato su:

text
default._bimi.example.com

Un record rappresentativo è:

text
v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/certificate.pem

Il tag v= dichiara la versione BIMI. Il tag l= identifica il file SVG ospitato. Il tag a= identifica il file certificato quando l’implementazione del receiver lo richiede.

Le risorse devono essere pubblicamente accessibili tramite HTTPS e devono rimanere stabili dopo la pubblicazione. Le istruzioni di Google spiegano la costruzione del file certificato e indicano che il certificato dell’entità, i certificati intermedi e il certificato radice vengono generalmente aggiunti in quest’ordine quando si utilizza un file PEM.[2]

Leggi la guida ai record DNS BIMI prima di pubblicare un record attivo.

4. Determinare se è necessario un certificato

I requisiti dei receiver differiscono. Google documenta un VMC o CMC per la propria configurazione BIMI e afferma che il segno di spunta verificato di Gmail è associato a un VMC.[2] Un VMC si basa su un logo registrato come marchio e su un processo di verifica rigoroso. Un CMC può essere disponibile per casi d’uso non legati a marchio registrato idonei, in conformità con i requisiti attuali dell’autorità di certificazione e del receiver.

La formulazione approvata dal portfolio per gli emittenti VMC attivi è: DigiCert ed Entrust sono gli emittenti VMC attivi. Non fare affidamento su elenchi storici di emittenti né presupporre che qualsiasi tipo di certificato produca lo stesso risultato presso il receiver.

Leggi la guida VMC e CMC · Confronta VMC e CMC · Contatta veriBIMI

La policy dei receiver è rilevante

Lo standard BIMI offre ai receiver un metodo comune per ottenere e valutare le informazioni sul logo. Non elimina la discrezionalità dei receiver. Il BIMI Group afferma esplicitamente che un provider di posta non è tenuto a visualizzare un logo per un dominio che utilizza BIMI e può adottare determinazioni locali per i singoli domini.[1]

Per questo motivo, makeBIMI manterrà una BIMI Receiver Requirements Matrix con data aggiornata. Essa separerà i requisiti documentati dei provider dalle regole generali degli standard e contrassegnerà i comportamenti incerti o non documentati come tali. Non dedurrà il supporto da screenshot, affermazioni di terze parti o post di blog non aggiornati.

Motivi comuni per cui un logo non viene visualizzato

Le cause abituali sono semplici:

  • DMARC è ancora impostato su p=none, oppure il flusso di invio non è allineato.
  • Il file SVG contiene contenuti non consentiti o non soddisfa i vincoli documentati di un receiver.
  • Il record di asserzione BIMI è malformato, pubblicato sotto il selettore errato o non ancora visibile nel DNS.
  • Il file SVG o PEM ospitato non può essere recuperato in modo sicuro.
  • La catena di certificati o la relazione con il logo non supera la validazione.
  • Una piattaforma di invio di terze parti non è configurata per l’autenticazione allineata.
  • Il provider ricevente non visualizza l’indicatore per quel messaggio o dominio.

Usa l’audit BIMI per ispezionare la configurazione osservabile del dominio, quindi segui la guida tecnica appropriata anziché modificare più controlli contemporaneamente.

Una sequenza di implementazione disciplinata

Fase Risultato Risorsa successiva
Audit del dominio attuale Identificare lo stato di DMARC e del record BIMI Audit del dominio
Preparare il logo Produrre un asset SVG Tiny P/S conforme ai vincoli Convertitore e validatore di logo
Raggiungere l’applicazione sicura di DMARC Passare dall’osservazione alla policy applicata con evidenza Guida ai requisiti DMARC
Pubblicare e ospitare le risorse Servire SVG e, ove applicabile, PEM tramite HTTPS Guida ai record DNS
Risolvere i requisiti dei certificati Selezionare il percorso appropriato in base alle condizioni attuali del receiver e del certificato Guida ai certificati
Validare il sistema distribuito Testare il dominio effettivo, le risorse e il percorso di invio Guida alla risoluzione dei problemi

Guide di implementazione correlate

Domande frequenti

BIMI funziona senza l’applicazione di DMARC?

Non nel flow BIMI documentato da Google. Google richiede una policy DMARC di p=quarantine o p=reject e pct=100, non p=none.[2]

Un SVG normale è sufficiente?

No. BIMI utilizza un profilo SVG Tiny P/S vincolato. Un logo che viene visualizzato correttamente su un sito web può comunque contenere elementi che non soddisfano i vincoli BIMI. Valida l’asset ospitato definitivo anziché presupporre che un export da uno strumento di design sia adeguato.

Un record BIMI valido garantisce un logo in ogni casella di posta?

No. La visualizzazione da parte del receiver rimane una decisione del receiver. Il BIMI Group osserva che i provider possono adottare determinazioni locali per i singoli domini.[1]

Quali emittenti VMC sono attivi?

Per i contenuti del portfolio, utilizzare la formulazione approvata: DigiCert ed Entrust sono gli emittenti VMC attivi. I requisiti dei certificati e dei receiver possono cambiare, pertanto verificare i requisiti attuali prima di presentare una richiesta.

Fonti

[1] BIMI Group — Mailbox Providers

[2] Google Workspace Admin Help — Set up BIMI

[3] BIMI Group — Supporting Documents