Hosting BIMI: dove e come ospitare il logo SVG e il certificato

Q: Posso ospitare il mio logo BIMI su GitHub Pages?

Sì per il logo SVG: GitHub Pages serve i file .svg con il content-type image/svg+xml automaticamente. Tuttavia, GitHub Pages non è adatto per ospitare un certificato PEM (content-type errato) e non offre né SLA di disponibilità né monitoraggio. È un'opzione accettabile per BIMI auto-dichiarato (senza certificato), ma non per un deployment completo con VMC/CMC.

Di CaptainDNS
Pubblicato il 31 marzo 2026

TL;DR

L'hosting del logo è l'anello più fragile della catena BIMI: HTTPS obbligatorio, TLS 1.2+, content-type image/svg+xml, zero redirect, file inferiore a 32 KB
Il 53% dei record BIMI contiene almeno un errore: l'hosting errato del logo è una delle cause più frequenti
5 opzioni a confronto: server autogestito, CDN (S3, R2), GitHub Pages, servizio dedicato (CaptainDNS), piattaforma integrata (PowerDMARC, Valimail)
CaptainDNS ospita gratuitamente logo SVG e certificato VMC/CMC, con TLS automatico, statistiche di accesso e avviso di scadenza del certificato

Quando si parla di BIMI, le discussioni tecniche si concentrano quasi sempre su tre temi: portare DMARC in enforcement, convertire il logo nel formato SVG Tiny-PS, ottenere un certificato VMC o CMC. Questi passaggi sono documentati, supportati da strumenti, trattati in decine di guide. Ma esiste un quarto tema, raramente affrontato, che provoca tuttavia tanti fallimenti quanti gli altri tre messi insieme: l'hosting del file SVG.

Il principio è semplice in apparenza. Il record DNS BIMI contiene un URL (l=) che punta al vostro logo. I provider di posta elettronica (Gmail, Yahoo Mail, Apple Mail) scaricano il file da questo URL per visualizzarlo nella casella di posta. Se il server non risponde, se il certificato TLS è scaduto, se il content-type è errato, se un redirect si inserisce nella catena: il logo non viene mostrato. Nessun messaggio di errore. Nessun feedback. Il provider passa semplicemente al messaggio successivo senza logo.

I numeri confermano la portata del problema. Secondo un'analisi URIports del 2025 condotta sul top 1 milione di domini, il 53,6% dei record BIMI contiene almeno un errore. Tra questi errori, i problemi di hosting (server irraggiungibile, certificato TLS non valido, content-type errato, redirect) figurano tra le cause più frequenti. Non è un problema di nicchia: è un problema strutturale.

Questa guida affronta tre domande. Innanzitutto, i requisiti tecnici esatti che il vostro server di hosting deve rispettare. Poi, le cinque opzioni di hosting disponibili, con i relativi punti di forza e limiti. Infine, un tutorial passo-passo per ospitare il logo e il certificato gratuitamente con CaptainDNS, in meno di tre minuti.

Che siate amministratori di sistema, responsabili tecnici o consulenti email, questa guida vi fornisce gli strumenti per scegliere la soluzione di hosting giusta ed evitare gli errori che compromettono silenziosamente il vostro deployment BIMI.

Perché l'hosting del logo BIMI è critico?

Per capire perché l'hosting è così critico, bisogna comprendere come i provider di posta elettronica scaricano il logo. Il processo segue una catena precisa:

Un'email arriva al provider (Gmail, Yahoo, Apple Mail)
Il provider verifica l'autenticazione: SPF, DKIM, DMARC
Se DMARC è in modalità enforcement, il provider cerca un record BIMI su default._bimi.captaindns.com
Il provider estrae l'URL dal tag l= nel record BIMI
Il provider invia una richiesta HTTPS GET a questo URL
Se la risposta è HTTP 200 con Content-Type: image/svg+xml e un file SVG valido: il logo viene visualizzato
Se qualcosa fallisce in questa catena: nessun logo, nessuna notifica

Il punto cruciale è il passaggio 5. Il provider di posta non è un browser web. È un agente automatizzato che applica regole rigide e non tollera alcuna deviazione.

I requisiti tecnici dell'hosting BIMI

Ecco i requisiti che il vostro server di hosting deve rispettare affinché i provider di posta possano scaricare il logo:

Requisito	Dettaglio	Conseguenza se non rispettato
HTTPS obbligatorio	TLS 1.2 minimo, certificato valido (non autofirmato)	Logo rifiutato silenziosamente
Content-Type esatto	`image/svg+xml` (non `text/plain`, `application/octet-stream`)	Logo rifiutato
Risposta HTTP 200	Nessun redirect 301/302	Logo rifiutato (i client di posta non seguono i redirect)
Dimensione file	Inferiore a 32 KB	Logo rifiutato
Disponibilità 24/7	Nessuna manutenzione prolungata, nessun rate limiting	Logo assente durante l'indisponibilità
Nessun blocco geografico	Il server di posta può trovarsi ovunque	Logo assente per alcuni provider

Perché questi requisiti sono più severi dell'hosting web tradizionale?

Nel web tradizionale, un browser segue i redirect, mostra una pagina di errore, ritenta la richiesta se fallisce. Un provider di posta che scarica un logo BIMI non fa nulla di tutto ciò.

Nessun follow dei redirect. Se il vostro server risponde 301 o 302 (anche per un semplice HTTP verso HTTPS), il provider considera il file come irraggiungibile. È la trappola più comune per i team che configurano il server web con un redirect HTTP verso HTTPS predefinito. L'URL nel record BIMI deve puntare direttamente alla destinazione finale.

Nessun retry automatico. Se il vostro server è indisponibile nel momento in cui Gmail tenta di scaricare il logo, il logo non viene mostrato per quella email. Alcuni provider come Gmail utilizzano una cache e possono ritentare in seguito, ma questo comportamento non è né garantito né documentato.

Nessuna negoziazione del content-type. Il provider si aspetta image/svg+xml. Se riceve text/plain (impostazione predefinita di molti server per i file .svg) o application/octet-stream, rifiuta il file. Non tenta di rilevare il formato analizzando il contenuto.

Nessuna tolleranza per gli errori TLS. Un certificato autofirmato, un certificato scaduto, una catena di certificati incompleta: tutto questo provoca un rifiuto immediato. I provider di posta non propongono di "continuare nonostante l'errore" come un browser web.

Comportamento della cache variabile. Alcuni provider come Gmail memorizzano il logo in cache dopo il primo scaricamento riuscito. Questa cache maschera i problemi di hosting temporanei: il logo continua a essere visualizzato anche se il server è in down. Ma questa cache ha una durata limitata e non documentata. Quando scade, il provider ritenta lo scaricamento. Se il server è ancora indisponibile in quel momento, il logo scompare. La cache crea un falso senso di sicurezza: tutto sembra funzionare mentre l'infrastruttura sottostante è in difficoltà.

Per i requisiti del file SVG stesso (formato Tiny-PS, dimensioni, contenuto), consultate la nostra guida alla creazione del logo BIMI.

Le cinque opzioni di hosting a confronto

Non esiste una soluzione unica per ospitare un logo BIMI. La scelta dipende dalla vostra infrastruttura esistente, dalle vostre competenze tecniche e dalle vostre esigenze di monitoraggio. Ecco le cinque opzioni più comuni, con i rispettivi vantaggi, limiti e caso d'uso ideale.

Server web autogestito (nginx, apache)

L'approccio più diretto: ospitare il file SVG sul vostro server web. Se disponete già di un server nginx o apache esposto su Internet, è sufficiente in teoria depositare il file SVG in una directory accessibile.

Configurazione nginx tipica:

location /bimi/logo.svg {
    root /var/www/bimi;
    types {
        image/svg+xml svg;
    }
    add_header Content-Type "image/svg+xml";
    add_header Cache-Control "public, max-age=86400";
}

Configurazione apache:

<Directory /var/www/bimi>
    AddType image/svg+xml .svg
</Directory>

Vantaggi:

Controllo totale sulla configurazione
Nessuna dipendenza da servizi terzi
Nessun costo aggiuntivo se il server esiste già

Limiti:

Gestione manuale del certificato TLS (rinnovo, catena dei certificati)
Responsabilità della disponibilità 24/7
Rischio di interruzione durante le manutenzioni
Configurazione del content-type da fare manualmente
Nessun monitoraggio integrato (serve un monitoring esterno)

Caso d'uso ideale: team con un'infrastruttura esistente, un team ops attivo e esperienza nella gestione di server web. Se gestite già decine di siti web, aggiungere un file SVG è banale. Se il vostro unico server è un VPS che nessuno monitora, è un rischio.

Trappola frequente: il redirect da HTTP a HTTPS. La maggior parte delle configurazioni nginx e apache include un blocco server che reindirizza la porta 80 verso la porta 443. Se il vostro URL BIMI è in HTTPS, nessun problema. Ma se qualcuno copia l'URL HTTP per errore nel record DNS, il redirect 301 provocherà un rifiuto silenzioso da parte del provider di posta.

CDN generico con cloud storage

I servizi di cloud storage con CDN sono un'opzione popolare. Il file è ospitato in un bucket (AWS S3, Cloudflare R2, Google Cloud Storage) e servito tramite un CDN (Cloudflare, AWS CloudFront, Cloud CDN).

Deploy AWS S3 + CloudFront:

# Upload del file con il content-type corretto
aws s3 cp logo.svg s3://mon-bucket-bimi/logo.svg \
  --content-type "image/svg+xml" \
  --cache-control "public, max-age=86400"

# Verifica
curl -I https://d1234abcd.cloudfront.net/logo.svg

Deploy Cloudflare R2:

# Upload via wrangler
npx wrangler r2 object put mon-bucket-bimi/logo.svg \
  --file=logo.svg \
  --content-type="image/svg+xml"

Vantaggi:

Disponibilità molto elevata (SLA 99,9% e oltre)
TLS gestito automaticamente dal CDN
Distribuzione geografica (riduzione della latenza)
Costo molto basso (pochi centesimi al mese per un singolo file)

Limiti:

Il content-type deve essere definito esplicitamente durante l'upload (se lo dimenticate, il bucket serve application/octet-stream)
Il CDN può aggiungere redirect se il dominio personalizzato non è configurato correttamente
Nessuna validazione SVG: potete caricare un file non valido senza saperlo
Nessun avviso di scadenza per i certificati VMC/CMC ospitati nello stesso bucket
Configurazione iniziale non banale (IAM, bucket policy, distribuzione CDN)

Caso d'uso ideale: team che utilizzano già AWS, Cloudflare o GCP per altre risorse. L'infrastruttura è già in piedi, le competenze sono presenti e il costo marginale è quasi nullo.

Trappola frequente: il content-type predefinito. Se caricate un file .svg in un bucket S3 senza specificare il content-type, S3 lo serve con application/octet-stream. Il file viene scaricato invece di essere interpretato come immagine. I provider di posta lo rifiutano.

Un'altra trappola comune con i CDN è la configurazione del dominio personalizzato. Se associate un nome di dominio alla vostra distribuzione CloudFront o al vostro bucket R2, dovete assicurarvi che la risoluzione DNS punti direttamente al CDN senza redirect intermedi. Una configurazione errata del CNAME o della zona DNS può introdurre un redirect 301 invisibile che interrompe il recupero del logo da parte dei provider di posta.

GitHub Pages

GitHub Pages è un'opzione gratuita che funziona per i casi semplici. Create un repository, depositate il file SVG, attivate GitHub Pages: il file viene servito in HTTPS con il content-type corretto.

Deploy:

# Creare un repository dedicato
mkdir bimi-assets && cd bimi-assets
git init
cp ~/logo.svg ./logo.svg
git add logo.svg
git commit -m "add BIMI logo"
git remote add origin git@github.com:captaindns/bimi-assets.git
git push -u origin main

Attivate GitHub Pages nelle impostazioni del repository (sorgente: branch main). L'URL sarà: https://captaindns.github.io/bimi-assets/logo.svg

Vantaggi:

Gratuito
TLS automatico (Let's Encrypt via GitHub)
Content-type corretto per i file .svg (gestito automaticamente)
Aggiornamento semplice (git push)

Limiti:

Nessuno SLA di disponibilità (GitHub Pages è progettato per siti statici, non per hosting critico)
Hosting di certificati PEM problematico: GitHub Pages serve i file .pem con un content-type errato (text/plain)
Nessuna statistica di accesso (non sapete se i provider scaricano il logo)
Nessun avviso di scadenza del certificato
Dipendenza da GitHub (cambiamenti di policy, interruzioni di servizio)
Nessun dominio personalizzato predefinito (URL github.io)

Caso d'uso ideale: progetti personali, test, deployment BIMI auto-dichiarato (senza certificato VMC/CMC). Se volete testare BIMI su Yahoo Mail prima di investire in un certificato, GitHub Pages è un buon punto di partenza.

Trappola frequente: il certificato VMC/CMC. Se tentate di ospitare un file .pem su GitHub Pages, il content-type sarà text/plain. I provider di posta possono rifiutare il certificato. Per un deployment BIMI completo (con certificato), GitHub Pages non è adatto.

Bisogna anche tenere presente che GitHub Pages ha limiti di banda (100 GB/mese) e di dimensione del sito (1 GB). Per un singolo file SVG, questi limiti non verranno mai raggiunti, ma sottolineano che il servizio non è progettato per hosting di produzione critico. In caso di picco di traffico (un ISP che mette in cache il logo e lo riscarica frequentemente), GitHub Pages potrebbe temporaneamente limitare l'accesso.

Servizio di hosting BIMI dedicato (CaptainDNS)

Un servizio progettato specificamente per ospitare gli asset BIMI. CaptainDNS gestisce l'intera catena: upload, validazione, hosting, generazione del record DNS, monitoraggio.

Funzionamento:

Create un profilo BIMI per il vostro dominio
Verificate la proprietà del dominio (record TXT)
Caricate il vostro logo SVG (validato automaticamente nel formato Tiny-PS)
Caricate il vostro certificato VMC/CMC (opzionale)
CaptainDNS genera il record DNS BIMI completo
Copiate il record nella vostra zona DNS

I file vengono serviti da assets.captaindns.com con TLS automatico (Let's Encrypt), il content-type corretto e senza alcun redirect.

Vantaggi:

Configurazione zero: nessun server da gestire, nessun content-type da configurare
Validazione SVG Tiny-PS all'upload: se il file non è conforme, viene rifiutato con un messaggio di errore esplicito
Hosting del certificato VMC/CMC con estrazione automatica dei metadati (emittente, date di validità, tipo)
Avviso di scadenza del certificato (30 giorni prima della scadenza)
Statistiche di accesso: numero di richieste ricevute e timestamp dell'ultima richiesta
Generazione automatica del record DNS BIMI
Gratuito per i primi 5 domini

Limiti:

Dipendenza da un servizio terzo (come ogni soluzione in hosting)
Dominio di hosting fisso (assets.captaindns.com, nessun dominio personalizzato per l'URL)

Caso d'uso ideale: qualsiasi organizzazione che desidera un hosting BIMI affidabile senza preoccuparsi della configurazione tecnica. Particolarmente adatto alle PMI senza un team ops dedicato.

Piattaforma DMARC integrata

Le piattaforme di monitoraggio DMARC come PowerDMARC, Valimail o Red Sift propongono spesso l'hosting BIMI come funzionalità inclusa nella loro offerta. Il logo e il certificato vengono caricati nella dashboard della piattaforma, che si occupa dell'hosting e della generazione del record DNS.

Vantaggi:

Integrazione nativa con il monitoraggio DMARC (visione unificata dell'autenticazione email)
Hosting gestito (TLS, content-type, disponibilità)
Supporto e assistenza inclusi nell'abbonamento

Limiti:

Costo elevato: queste piattaforme fatturano tra 50 e 500 $/mese (o più) per la suite DMARC completa. L'hosting BIMI è solo una funzionalità tra le tante
Vendor lock-in: se cambiate piattaforma, l'URL del logo cambia e dovete aggiornare il record DNS
Funzionalità BIMI variabili: alcune piattaforme non offrono validazione SVG all'upload né avviso di scadenza del certificato

Caso d'uso ideale: grandi aziende che utilizzano già una piattaforma DMARC per il monitoraggio dell'autenticazione email. In questo caso, l'hosting BIMI è un bonus incluso nell'abbonamento esistente.

Tabella comparativa delle cinque opzioni

Criterio	Server autogestito	CDN (S3/R2)	GitHub Pages	CaptainDNS	Piattaforma integrata
Costo	Variabile	0-5 $/mese	Gratuito	Gratuito	50-500+ $/mese
Configurazione	Manuale	Media	Semplice	Nessuna	Nessuna
Content-Type automatico	No	Configurazione richiesta	Sì (SVG)	Sì	Sì
TLS gestito	Manuale	Automatico	Automatico	Automatico	Automatico
Generazione record DNS	No	No	No	Sì	Sì
Hosting certificato	Sì	Sì	No (PEM)	Sì	Sì
Avviso scadenza certificato	No	No	No	Sì	Variabile
Statistiche di accesso	Log server	CloudWatch/R2 Analytics	No	Sì	Variabile
Validazione SVG all'upload	No	No	No	Sì (SVG Tiny-PS)	Variabile

La scelta dipende dalla vostra situazione. Se avete un team ops e un'infrastruttura cloud operativa, un CDN è un'ottima opzione. Se cercate la soluzione più semplice e affidabile senza configurare nulla, CaptainDNS è progettato per questo. Se utilizzate già una piattaforma DMARC, verificate se l'hosting BIMI è incluso nel vostro abbonamento.

Un criterio spesso trascurato in questa scelta è la durabilità dell'URL. L'URL del logo è inciso nel vostro record BIMI DNS. Se cambiate soluzione di hosting, dovete anche aggiornare il record DNS, il che comporta un ritardo di propagazione durante il quale alcuni provider scaricano il vecchio URL (divenuto irraggiungibile) e altri il nuovo. Per ridurre al minimo questo rischio, privilegiate una soluzione che non dovrete cambiare nei prossimi anni.

I cinque errori di hosting che compromettono il vostro BIMI

Anche con la giusta opzione di hosting, errori di configurazione possono impedire la visualizzazione del logo. Ecco i cinque errori più frequenti, con per ciascuno il sintomo, il comando diagnostico e la soluzione.

Errore 1: HTTP invece di HTTPS

Sintomo: il logo non compare presso nessun provider di posta, nonostante un record BIMI valido e un file SVG conforme.

Causa: l'URL nel tag l= del record BIMI utilizza http:// invece di https://. Oppure il record contiene https:// ma il server risponde solo sulla porta 80 (HTTP) e reindirizza verso HTTPS. La specifica BIMI richiede un URL HTTPS che risponda direttamente con 200, senza alcun redirect.

Diagnostica:

# Verificare il record BIMI
dig default._bimi.captaindns.com TXT +short

# Testare la risposta HTTPS diretta
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Verificate che:

L'URL nel record inizi con https://
La risposta curl restituisca un codice HTTP/2 200 (non 301, 302, 307)

Soluzione: assicuratevi che l'URL nel record BIMI punti direttamente all'endpoint HTTPS. Non contate su un redirect da HTTP a HTTPS: i provider di posta non lo seguono. Se il vostro server supporta solo HTTP, dovete configurare TLS prima di implementare BIMI.

Questo errore è particolarmente insidioso perché è invisibile durante i test manuali. Se digitate l'URL HTTP in un browser, questo segue il redirect e visualizza il file normalmente. Tutto sembra funzionare. Ma gli agenti automatizzati dei provider di posta si fermano al primo codice di risposta: se non è 200, il file è considerato irraggiungibile.

Errore 2: content-type errato

Sintomo: il file SVG è accessibile in HTTPS, il codice HTTP è 200, ma il logo non compare.

Causa: il server restituisce un content-type errato. I casi più frequenti:

text/plain: impostazione predefinita di molti server quando il tipo MIME non è configurato per l'estensione .svg
application/octet-stream: impostazione predefinita di alcuni servizi di cloud storage (S3 senza configurazione esplicita)
text/html: se il server restituisce una pagina di errore HTML invece del file SVG

Diagnostica:

curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Cercate la riga Content-Type nella risposta. Deve contenere esattamente image/svg+xml:

HTTP/2 200
content-type: image/svg+xml

Soluzione secondo il vostro server:

nginx: aggiungete nel blocco server o location:

types {
    image/svg+xml svg;
}

apache: aggiungete nel vostro .htaccess o nella configurazione globale:

AddType image/svg+xml .svg

S3: specificate il content-type durante l'upload:

aws s3 cp logo.svg s3://bucket/logo.svg --content-type "image/svg+xml"

R2: specificate il content-type nel comando wrangler:

npx wrangler r2 object put bucket/logo.svg --file=logo.svg --content-type="image/svg+xml"

Errore 3: redirect HTTP

Sintomo: curl restituisce un codice 200 quando testate nel browser, ma i provider di posta non scaricano il logo.

Causa: ci sono uno o più redirect nella catena. I browser li seguono automaticamente e vi mostrano il risultato finale, mascherando il problema. I provider di posta BIMI non seguono i redirect.

I redirect più comuni:

Da HTTP a HTTPS (301 da http:// a https://)
Da www a non-www (301 da www.captaindns.com a captaindns.com)
Da vecchio URL a nuovo URL (301 dopo riorganizzazione del server)
Trailing slash (301 da /bimi/logo.svg/ a /bimi/logo.svg)

Diagnostica:

# Seguire la catena di redirect
curl -IL https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Se vedete più risposte HTTP (301, 302, 307) prima del 200 finale, è il problema. La prima risposta deve essere un 200 diretto.

Soluzione: aggiornate l'URL nel vostro record BIMI per puntare alla destinazione finale, quella che restituisce direttamente un 200. Se il vostro server reindirizza http:// verso https://, usate l'URL https:// nel record. Se il vostro server reindirizza www verso il dominio nudo, usate il dominio nudo nel record.

Errore 4: server indisponibile

Sintomo: il logo appare in modo intermittente, oppure appariva prima e poi è scomparso.

Causa: il server di hosting è temporaneamente irraggiungibile. Le possibili cause:

Manutenzione pianificata del server
Superamento della quota o rate limiting
Restrizione geografica (il server blocca alcuni IP)
Saturazione del server (troppe richieste simultanee)
Server virtuale spento (VPS non monitorato)

Diagnostica:

# Verificare la disponibilità dalla vostra macchina
curl -o /dev/null -s -w "%{http_code}" https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Testare da un IP diverso (opzionale, tramite un servizio online)

Se il codice HTTP non è 200, il server è irraggiungibile.

Soluzione: implementate un monitoring esterno che verifichi la disponibilità dell'URL del logo ogni 5 minuti. Servizi come UptimeRobot, Pingdom o BetterStack possono avvisarvi in caso di indisponibilità. CaptainDNS fornisce un contatore di richieste e il timestamp dell'ultima richiesta servita: se il contatore non si muove nonostante stiate inviando email, è un indicatore di problema.

Per un server autogestito, evitate le manutenzioni prolungate senza un server di backup. Per un CDN o un servizio dedicato, il rischio di indisponibilità è molto più basso grazie alla ridondanza integrata.

Errore 5: certificato TLS del server scaduto

Sintomo: il logo funzionava e improvvisamente è scomparso presso tutti i provider.

Causa: il certificato TLS del server di hosting è scaduto. Non si tratta del certificato VMC/CMC (che è un file ospitato), ma del certificato HTTPS del server stesso. I provider di posta rifiutano di connettersi a un server il cui certificato TLS non è valido.

Questo errore è distinto dalla scadenza del certificato VMC/CMC. Qui è il server stesso a essere rifiutato, non il certificato BIMI.

Diagnostica:

# Verificare la validità del certificato TLS del server
curl -vI https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg 2>&1 | grep "expire date"

# Oppure con openssl
echo | openssl s_client -connect assets.captaindns.com:443 2>/dev/null | openssl x509 -noout -dates

Soluzione: attivate il rinnovo automatico del certificato TLS. Let's Encrypt offre certificati gratuiti con rinnovo automatico tramite Certbot o alternative come acme.sh. I CDN e i servizi gestiti (Cloudflare, CaptainDNS) gestiscono il rinnovo TLS automaticamente.

Se utilizzate un server autogestito, configurate un cron job per il rinnovo:

# Rinnovo automatico con Certbot
0 0 * * * certbot renew --quiet

Per una diagnostica completa di tutti gli errori BIMI, consultate la nostra guida logo BIMI che non viene visualizzato: 5 errori da correggere. Potete anche utilizzare lo strumento di verifica BIMI di CaptainDNS per validare automaticamente l'intera catena.

Ospitare il certificato VMC o CMC

L'hosting del logo SVG è solo metà del problema. Se disponete di un certificato VMC (Verified Mark Certificate) o CMC (Common Mark Certificate), anche questo deve essere ospitato in HTTPS e accessibile ai provider di posta.

Il certificato è referenziato nel tag a= del record BIMI:

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg; a=https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem"

I requisiti di hosting del certificato

I requisiti sono simili a quelli del logo, con alcune specificità:

HTTPS obbligatorio. Come per il logo, il certificato deve essere servito in HTTPS con un certificato TLS valido sul server. Nessun redirect, nessun errore TLS.

Content-type per i file PEM. Il content-type atteso per un certificato PEM è application/x-pem-file o application/pkix-cert. Alcuni server servono i file .pem con text/plain, il che può funzionare presso alcuni provider ma non è conforme alla raccomandazione.

Risposta HTTP 200 diretta. Come per il logo, nessun redirect è tollerato.

Il problema della scadenza del certificato

I certificati VMC e CMC hanno una durata di validità limitata, generalmente un anno. Quando il certificato scade:

Gmail smette di visualizzare il logo (il certificato è obbligatorio per Gmail)
Il record BIMI resta valido, ma il campo a= punta a un certificato scaduto
Nessuna notifica automatica da parte di Gmail o Yahoo

È un problema insidioso. A differenza di un certificato TLS di un server web (che provoca errori visibili nel browser), la scadenza di un certificato VMC/CMC passa inosservata. Il logo scompare silenziosamente da Gmail e nessuno se ne accorge finché un collega o un cliente non lo segnala.

Il rinnovo di un certificato VMC o CMC non è istantaneo: bisogna contattare l'autorità di certificazione, fornire le prove necessarie (marchio registrato per un VMC, prova d'uso per un CMC), attendere la validazione. Il processo può richiedere da pochi giorni a diverse settimane. Se aspettate la scadenza per avviare il rinnovo, il vostro logo sarà assente da Gmail per tutta quella durata. Ecco perché un avviso 30 giorni prima della scadenza è essenziale.

Logo e certificato su server diversi

Il record BIMI contiene due campi separati: l= per il logo e a= per il certificato. Ciascuno può puntare a un server diverso. È una flessibilità utile se volete ospitare il logo su un CDN veloce e il certificato su un servizio dedicato che gestisce gli avvisi di scadenza.

Esempio di record con server diversi:

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://cdn.captaindns.com/bimi/logo.svg; a=https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem"

La soluzione CaptainDNS per i certificati

CaptainDNS gestisce l'hosting del certificato VMC/CMC con diverse funzionalità specifiche:

Estrazione automatica dei metadati: all'upload, CaptainDNS analizza il certificato PEM ed estrae l'emittente, le date di validità e il tipo (VMC o CMC)
Avviso di scadenza: 30 giorni prima della scadenza del certificato, CaptainDNS invia un avviso per ricordarvi di rinnovarlo
Statistiche di accesso: come per il logo, CaptainDNS conta le richieste ricevute e registra il timestamp dell'ultima richiesta
Content-type corretto: il certificato viene servito con il content-type appropriato, senza alcuna configurazione da parte vostra

Per una guida completa sulle differenze tra VMC e CMC e la loro compatibilità con i provider di posta, consultate il nostro articolo sulla compatibilità VMC, CMC e DNS.

Ospitare il logo BIMI in 3 minuti con CaptainDNS

Questo tutorial descrive i sei passaggi per ospitare il logo SVG e il certificato VMC/CMC con CaptainDNS. Il processo completo richiede meno di tre minuti (esclusa la propagazione DNS).

Passaggio 1: creare un profilo BIMI

Accedete al vostro account CaptainDNS (o createne uno gratuitamente). Andate alla sezione BIMI Hosting dalla dashboard. Cliccate su Nuovo profilo BIMI e inserite il vostro dominio (ad esempio captaindns.com).

Il selettore predefinito (default) è adatto nella grande maggioranza dei casi. Un selettore personalizzato è utile solo se avete bisogno di loghi diversi per sotto-brand o dipartimenti che inviano email dallo stesso dominio.

Passaggio 2: verificare la proprietà del dominio

CaptainDNS vi chiede di provare che controllate il dominio. Aggiungete un record TXT nella vostra zona DNS con il valore fornito da CaptainDNS:

_captaindns-verify.captaindns.com. 3600 IN TXT "captaindns-verification=abc123xyz"

La verifica è automatica. CaptainDNS interroga il vostro DNS a intervalli regolari e conferma non appena il record viene rilevato. La propagazione DNS può richiedere da pochi minuti a qualche ora a seconda del vostro registrar.

Passaggio 3: caricare il logo SVG

Una volta verificato il dominio, caricate il vostro file SVG Tiny-PS. CaptainDNS valida il file automaticamente all'upload:

Verifica del formato SVG Tiny-PS (attributi version="1.2" e baseProfile="tiny-ps")
Verifica del viewBox quadrato
Rilevamento degli elementi vietati (<script>, <style>, <image>, <animate>)
Verifica della dimensione del file (inferiore a 32 KB)

Se il file non è conforme, CaptainDNS mostra un messaggio di errore esplicito con la lista dei problemi rilevati. In questo caso, utilizzate il convertitore SVG Tiny-PS per correggere automaticamente il vostro file, poi ricaricate la versione convertita.

Se il file è conforme, CaptainDNS lo ospita immediatamente a un URL stabile:

https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Passaggio 4: caricare il certificato (opzionale)

Se disponete di un certificato VMC o CMC, caricate il file PEM. CaptainDNS estrae automaticamente i metadati:

Emittente: DigiCert, Entrust, ecc.
Date di validità: inizio e fine del periodo di validità
Tipo: VMC (Verified Mark Certificate) o CMC (Common Mark Certificate)

L'avviso di scadenza si attiva automaticamente: CaptainDNS vi avvisa 30 giorni prima della scadenza affinché possiate rinnovare il certificato senza interruzione della visualizzazione.

Il certificato è ospitato a un URL stabile:

https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem

Passaggio 5: copiare e pubblicare il record DNS

CaptainDNS genera automaticamente il record DNS BIMI completo, pronto per essere copiato nella vostra zona DNS.

Con certificato:

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg; a=https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem"

Senza certificato (auto-dichiarato):

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg; a=;"

Copiate il record e aggiungetelo nella vostra zona DNS presso il registrar o il provider DNS. Il tipo di record è TXT, il nome è default._bimi.captaindns.com (sostituite con il vostro dominio).

Attenzione alla sintassi durante la copia: alcuni pannelli di gestione DNS aggiungono automaticamente il dominio come suffisso. In questo caso, inserite solo default._bimi come hostname, senza il dominio. Verificate con dig dopo la creazione per confermare che il record è risolto correttamente.

Passaggio 6: verificare il deployment

Dopo la propagazione DNS (da pochi minuti a qualche ora), verificate che tutto funzioni. CaptainDNS offre uno strumento di verifica integrato che controlla l'intera catena:

Risoluzione DNS del record BIMI
Accessibilità HTTPS del logo SVG
Validazione del content-type
Verifica del formato SVG Tiny-PS
Accessibilità HTTPS del certificato (se presente)
Validità del certificato VMC/CMC (se presente)

Potete anche verificare manualmente con dig e curl:

# Verificare il record DNS
dig default._bimi.captaindns.com TXT +short

# Verificare l'accesso al logo
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Verificare l'accesso al certificato
curl -I https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem

Funzionalità incluse nell'hosting CaptainDNS

In sintesi, l'hosting BIMI CaptainDNS include:

Fino a 5 domini gratuiti: nessun costo per le piccole organizzazioni
Statistiche di accesso: numero di richieste servite e timestamp dell'ultima richiesta, per verificare che i provider stiano effettivamente scaricando il vostro logo
Avvisi di scadenza del certificato: notifica 30 giorni prima della scadenza del VMC/CMC
TLS automatico: certificato Let's Encrypt gestito automaticamente, senza intervento
Validazione SVG Tiny-PS all'upload: rifiuto immediato dei file non conformi con messaggio di errore esplicito
Generazione del record DNS: il record BIMI completo viene generato automaticamente, pronto da copiare

Checklist di hosting BIMI

Prima di considerare il vostro hosting come operativo, verificate questi otto punti:

✅ URL in HTTPS (non HTTP)
✅ Certificato TLS valido e non scaduto sul server di hosting
✅ TLS 1.2 o versione superiore
✅ Risposta HTTP 200 diretta (nessun redirect 301/302)
✅ Content-Type image/svg+xml per il logo
✅ Dimensione del file SVG inferiore a 32 KB
✅ Server accessibile 24/7 senza restrizioni geografiche
✅ Se presente un certificato VMC/CMC: ospitato in HTTPS con Content-Type appropriato e data di scadenza monitorata

Potete verificare i punti da 1 a 6 con un singolo comando curl:

curl -IL -o /dev/null -s -w "HTTP: %{http_code}\nContent-Type: %{content_type}\nSize: %{size_download} bytes\nTLS: %{ssl_version}\n" https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Risultato atteso:

HTTP: 200
Content-Type: image/svg+xml
Size: 8432 bytes
TLS: TLSv1.3

Se uno di questi punti fallisce, il logo non verrà visualizzato. Correggete in ordine: i problemi HTTPS e TLS prima di tutto (senza connessione sicura, niente funziona), poi il content-type, poi la dimensione del file.

Ricordatevi anche di eseguire questa verifica da un server esterno (non solo dalla vostra rete locale). Un server che funziona perfettamente dal vostro ufficio può essere bloccato da un firewall o un WAF per le richieste provenienti da IP in altri paesi. I provider di posta scaricano il logo dai propri data center, distribuiti in tutto il mondo.

Piano d'azione

Tre passaggi per mettere in sicurezza l'hosting del vostro logo BIMI:

Verificare l'hosting attuale: utilizzate la checklist qui sopra e il comando curl per controllare che il vostro server soddisfi gli otto requisiti. Se avete già un record BIMI pubblicato, testatelo con lo strumento BIMI Record Check di CaptainDNS
Migrare verso un hosting affidabile: se il vostro hosting attuale non soddisfa tutti i requisiti, migrate verso CaptainDNS per una configurazione zero, o verso un CDN se avete l'infrastruttura necessaria. In ogni caso, eliminate i redirect e verificate il content-type
Implementare il monitoraggio: configurate un avviso di scadenza per il certificato VMC/CMC (CaptainDNS lo fa automaticamente) e un monitoring di disponibilità per l'URL del logo (UptimeRobot, BetterStack, o le statistiche di accesso CaptainDNS)

FAQ

Dove ospitare il mio logo BIMI?

Cinque opzioni: server autogestito (nginx, apache), CDN (S3, Cloudflare R2), GitHub Pages, servizio dedicato come CaptainDNS, o piattaforma DMARC integrata (PowerDMARC, Valimail). La soluzione più semplice è un servizio dedicato che gestisce automaticamente HTTPS, content-type e generazione del record DNS. CaptainDNS offre questo hosting gratuitamente per i primi 5 domini.

Il logo BIMI deve obbligatoriamente essere in HTTPS?

Sì. HTTP è rifiutato da tutti i provider di posta. Il certificato TLS del server deve essere valido (non autofirmato) e in versione 1.2 minimo. Un certificato scaduto o una catena di certificati incompleta provoca ugualmente un rifiuto silenzioso del logo.

Qual è la dimensione massima di un file SVG BIMI?

La specifica raccomanda un massimo di 32 KB. In pratica, un SVG Tiny-PS ben ottimizzato pesa tra 2 e 15 KB. Se il vostro file supera i 32 KB, semplificate i tracciati, riducete il numero di punti di ancoraggio o rimuovete i metadati inutili con uno strumento di ottimizzazione SVG.

Posso ospitare il mio logo BIMI su GitHub Pages?

Sì per il logo SVG: GitHub Pages serve i file .svg con il content-type image/svg+xml automaticamente. Tuttavia, GitHub Pages non è adatto per ospitare un certificato PEM (content-type errato) e non offre né SLA di disponibilità né monitoraggio. È un'opzione accettabile per BIMI auto-dichiarato (senza certificato), ma non per un deployment completo con VMC/CMC.

L'hosting BIMI può essere gratuito?

Sì. GitHub Pages e CaptainDNS offrono un hosting gratuito. GitHub Pages è limitato al logo SVG (nessun certificato, nessun monitoraggio). CaptainDNS aggiunge la gestione TLS automatica, la validazione SVG Tiny-PS all'upload, l'hosting del certificato VMC/CMC e gli avvisi di scadenza. L'offerta gratuita copre 5 domini.

Il logo e il certificato devono essere sullo stesso server?

No. Il record BIMI contiene due campi separati: l= per il logo e a= per il certificato. Ciascuno può puntare a un server diverso. Ad esempio, potete ospitare il logo su un CDN per le prestazioni e il certificato su CaptainDNS per beneficiare degli avvisi di scadenza.

Cosa succede se il server di hosting è indisponibile?

Il provider di posta non riesce a scaricare il logo e non lo visualizza. Alcuni provider come Gmail utilizzano una cache interna: un'interruzione breve potrebbe non avere un impatto immediato sulle email già in cache. Ma un'interruzione prolungata (diverse ore o giorni) comporta la scomparsa del logo per tutte le nuove email. Ecco perché un hosting ad alta disponibilità è essenziale.

Come verificare che il mio hosting BIMI funzioni?

Utilizzate curl -I seguito dall'URL del logo per verificare il codice HTTP (deve essere 200), il content-type (deve essere image/svg+xml) e il certificato TLS (deve essere valido). Per una diagnostica completa dell'intera catena BIMI (DNS, hosting, formato SVG, certificato), utilizzate lo strumento BIMI Record Check di CaptainDNS.

Scarica le tabelle comparative

Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.

FAQ

Dove ospitare il mio logo BIMI?

Il logo BIMI deve obbligatoriamente essere in HTTPS?

Qual è la dimensione massima di un file SVG BIMI?

Posso ospitare il mio logo BIMI su GitHub Pages?

L'hosting BIMI può essere gratuito?

Il logo e il certificato devono essere sullo stesso server?

Cosa succede se il server di hosting è indisponibile?

Come verificare che il mio hosting BIMI funzioni?

Scarica le tabelle comparative

Articoli simili