Hospedagem BIMI: onde e como hospedar seu logo SVG e seu certificado

Q: Posso hospedar meu logo BIMI no GitHub Pages?

Sim para o logo SVG: o GitHub Pages serve arquivos .svg com o content-type image/svg+xml automaticamente. Por outro lado, o GitHub Pages não é adequado para hospedar um certificado PEM (content-type incorreto) e não oferece SLA de disponibilidade nem monitoramento. É uma opção aceitável para BIMI auto-declarado (sem certificado), mas não para um deploy completo com VMC/CMC.

Por CaptainDNS
Publicado em 31 de março de 2026

TL;DR

A hospedagem do logo é o elo mais frágil da cadeia BIMI: HTTPS obrigatório, TLS 1.2+, content-type image/svg+xml, zero redirecionamento, arquivo menor que 32 KB
53% dos registros BIMI contêm pelo menos um erro: a hospedagem incorreta do logo é uma das causas mais frequentes
5 opções comparadas: servidor autogerido, CDN (S3, R2), GitHub Pages, serviço dedicado (CaptainDNS), plataforma integrada (PowerDMARC, Valimail)
O CaptainDNS hospeda gratuitamente logo SVG e certificado VMC/CMC, com TLS automático, estatísticas de acesso e alerta de expiração do certificado

Quando se fala em BIMI, as discussões técnicas se concentram quase sempre em três assuntos: elevar o DMARC para enforcement, converter o logo para o formato SVG Tiny-PS, obter um certificado VMC ou CMC. Essas etapas são documentadas, possuem ferramentas e são cobertas por dezenas de guias. Mas existe um quarto assunto, raramente abordado, que provoca tantas falhas quanto os três anteriores somados: a hospedagem do arquivo SVG.

O princípio é simples na aparência. O registro DNS BIMI contém uma URL (l=) que aponta para o seu logo. Os provedores de e-mail (Gmail, Yahoo Mail, Apple Mail) buscam o arquivo nessa URL para exibi-lo na caixa de entrada. Se o servidor não responde, se o certificado TLS está expirado, se o content-type está incorreto, se um redirecionamento se insere na cadeia: o logo não aparece. Nenhuma mensagem de erro. Nenhum retorno. O provedor simplesmente passa para a próxima mensagem sem logo.

Os números confirmam a dimensão do problema. Segundo uma análise da URIports de 2025 sobre o top 1 milhão de domínios, 53,6% dos registros BIMI contêm pelo menos um erro. Entre esses erros, as falhas de hospedagem (servidor inacessível, certificado TLS inválido, content-type incorreto, redirecionamentos) estão entre as causas mais frequentes. Não é um problema de nicho: é um problema estrutural.

Este guia aborda três questões. Primeiro, os requisitos técnicos exatos que seu servidor de hospedagem deve atender. Em seguida, as cinco opções de hospedagem disponíveis, com seus pontos fortes e suas limitações. Por fim, um tutorial passo a passo para hospedar seu logo e seu certificado gratuitamente com o CaptainDNS, em menos de três minutos.

Seja você administrador de sistemas, responsável técnico ou consultor de e-mail, este guia fornece as chaves para escolher a solução de hospedagem certa e evitar os erros que quebram silenciosamente seu deploy BIMI.

Por que a hospedagem do logo BIMI é crítica?

Para entender por que a hospedagem é tão crítica, é preciso compreender como os provedores de e-mail buscam o logo. O processo segue uma cadeia precisa:

Um e-mail chega ao provedor (Gmail, Yahoo, Apple Mail)
O provedor verifica a autenticação: SPF, DKIM, DMARC
Se o DMARC passa em modo enforcement, o provedor busca um registro BIMI em default._bimi.captaindns.com
O provedor extrai a URL da tag l= no registro BIMI
O provedor envia uma requisição HTTPS GET para essa URL
Se a resposta é HTTP 200 com Content-Type: image/svg+xml e um arquivo SVG válido: o logo é exibido
Se qualquer coisa falha nessa cadeia: nenhum logo, nenhuma notificação

O ponto crucial é a etapa 5. O provedor de e-mail não é um navegador web. É um agente automatizado que aplica regras rigorosas e não tolera nenhum desvio.

Os requisitos técnicos da hospedagem BIMI

Estes são os requisitos que seu servidor de hospedagem deve atender para que os provedores de e-mail possam buscar o logo:

Requisito	Detalhe	Consequência se não atendido
HTTPS obrigatório	TLS 1.2 no mínimo, certificado válido (não autoassinado)	Logo rejeitado silenciosamente
Content-Type exato	`image/svg+xml` (não `text/plain`, `application/octet-stream`)	Logo rejeitado
Resposta HTTP 200	Sem redirecionamento 301/302	Logo rejeitado (os clientes de e-mail não seguem redirecionamentos)
Tamanho do arquivo	Menor que 32 KB	Logo rejeitado
Disponibilidade 24/7	Sem manutenção prolongada, sem rate limiting	Logo ausente durante a indisponibilidade
Sem bloqueio geográfico	O servidor de e-mail pode estar em qualquer lugar	Logo ausente para certos provedores

Por que esses requisitos são mais rigorosos que a hospedagem web convencional?

Na web convencional, um navegador segue redirecionamentos, exibe uma página de erro, refaz a requisição se ela falha. Um provedor de e-mail que busca um logo BIMI não faz nada disso.

Sem seguir redirecionamentos. Se o seu servidor responde 301 ou 302 (mesmo para um simples HTTP para HTTPS), o provedor considera que o arquivo é inacessível. Essa é a armadilha mais comum para equipes que configuram seu servidor web com redirecionamento HTTP para HTTPS por padrão. A URL no registro BIMI deve apontar diretamente para o destino final.

Sem retry automático. Se o seu servidor está indisponível no momento em que o Gmail tenta buscar o logo, o logo não é exibido para esse e-mail. Alguns provedores como o Gmail usam um cache e podem tentar novamente mais tarde, mas esse comportamento não é garantido nem documentado.

Sem negociação de content-type. O provedor espera image/svg+xml. Se recebe text/plain (padrão de muitos servidores para arquivos .svg) ou application/octet-stream, ele rejeita o arquivo. Ele não tenta detectar o formato analisando o conteúdo.

Sem tolerância a erros TLS. Um certificado autoassinado, um certificado expirado, uma cadeia de certificados incompleta: tudo isso provoca uma rejeição imediata. Os provedores de e-mail não oferecem um "continuar mesmo assim" como um navegador web.

Um comportamento de cache variável. Alguns provedores como o Gmail colocam o logo em cache após a primeira busca bem-sucedida. Esse cache mascara os problemas de hospedagem temporários: o logo continua sendo exibido mesmo que o servidor esteja fora do ar. Mas esse cache tem uma duração limitada e não documentada. Quando ele expira, o provedor tenta buscar o logo novamente. Se o servidor ainda estiver indisponível naquele momento, o logo desaparece. O cache cria uma falsa sensação de segurança: tudo parece funcionar enquanto a infraestrutura subjacente está com falhas.

Para os requisitos do arquivo SVG em si (formato Tiny-PS, dimensões, conteúdo), consulte nosso guia de criação de logo BIMI.

As cinco opções de hospedagem comparadas

Não existe uma solução única para hospedar um logo BIMI. A escolha depende da sua infraestrutura existente, das suas competências técnicas e das suas necessidades de monitoramento. Aqui estão as cinco opções mais comuns, com suas vantagens, suas limitações e seu caso de uso ideal.

Servidor web autogerido (nginx, apache)

A abordagem mais direta: hospedar o arquivo SVG no seu próprio servidor web. Se você já possui um servidor nginx ou apache exposto na Internet, basta em teoria depositar o arquivo SVG em um diretório acessível.

Configuração nginx típica:

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";
}

Configuração apache:

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

Vantagens:

Controle total sobre a configuração
Sem dependência de um serviço terceiro
Nenhum custo adicional se o servidor já existe

Limitações:

Gerenciamento manual do certificado TLS (renovação, cadeia de certificados)
Responsabilidade pela disponibilidade 24/7
Risco de interrupção durante manutenções do servidor
Configuração do content-type a ser feita manualmente
Sem monitoramento integrado (é necessário implementar um monitoramento externo)

Caso de uso ideal: equipes com infraestrutura existente, uma equipe de operações ativa e experiência em gerenciamento de servidores web. Se você já gerencia dezenas de sites web, adicionar um arquivo SVG é trivial. Se o seu único servidor é um VPS que ninguém monitora, é um risco.

Armadilha frequente: o redirecionamento HTTP para HTTPS. A maioria das configurações nginx e apache inclui um bloco server que redireciona a porta 80 para a porta 443. Se a sua URL BIMI está em HTTPS, sem problemas. Mas se alguém copia a URL HTTP por engano no registro DNS, o redirecionamento 301 provocará uma rejeição silenciosa pelo provedor de e-mail.

CDN genérico com armazenamento em nuvem

Os serviços de armazenamento em nuvem com CDN são uma opção popular. O arquivo é hospedado em um bucket (AWS S3, Cloudflare R2, Google Cloud Storage) e servido via CDN (Cloudflare, AWS CloudFront, Cloud CDN).

Deploy AWS S3 + CloudFront:

# Upload do arquivo com o content-type correto
aws s3 cp logo.svg s3://mon-bucket-bimi/logo.svg \
  --content-type "image/svg+xml" \
  --cache-control "public, max-age=86400"

# Verificação
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"

Vantagens:

Disponibilidade muito alta (SLA 99,9% ou mais)
TLS gerenciado automaticamente pelo CDN
Distribuição geográfica (redução de latência)
Custo muito baixo (alguns centavos por mês para um único arquivo)

Limitações:

O content-type deve ser definido explicitamente durante o upload (se você esquecer, o bucket serve application/octet-stream)
O CDN pode adicionar redirecionamentos se o domínio personalizado não estiver configurado corretamente
Sem validação SVG: você pode fazer upload de um arquivo inválido sem saber
Sem alerta de expiração para certificados VMC/CMC hospedados no mesmo bucket
Configuração inicial não trivial (IAM, bucket policy, distribuição CDN)

Caso de uso ideal: equipes que já utilizam AWS, Cloudflare ou GCP para outros recursos. A infraestrutura já está pronta, as competências estão disponíveis e o custo marginal é praticamente zero.

Armadilha frequente: o content-type padrão. Se você faz upload de um arquivo .svg em um bucket S3 sem especificar o content-type, o S3 o serve com application/octet-stream. O arquivo é baixado em vez de ser interpretado como uma imagem. Os provedores de e-mail o rejeitam.

Outra armadilha comum com CDNs é a configuração do domínio personalizado. Se você associa um nome de domínio à sua distribuição CloudFront ou ao seu bucket R2, você deve garantir que a resolução DNS aponte diretamente para o CDN sem redirecionamento intermediário. Uma configuração incorreta do CNAME ou da zona DNS pode introduzir um redirecionamento 301 invisível que quebra a busca do logo pelos provedores de e-mail.

GitHub Pages

O GitHub Pages é uma opção gratuita que funciona para casos simples. Crie um repositório, deposite o arquivo SVG, ative o GitHub Pages: o arquivo é servido em HTTPS com o content-type correto.

Deploy:

# Criar um repositório dedicado
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

Ative o GitHub Pages nas configurações do repositório (fonte: branch main). A URL será: https://captaindns.github.io/bimi-assets/logo.svg

Vantagens:

Gratuito
TLS automático (Let's Encrypt via GitHub)
Content-type correto para arquivos .svg (gerenciado automaticamente)
Atualização simples (git push)

Limitações:

Nenhum SLA de disponibilidade (GitHub Pages é projetado para sites estáticos, não para hospedagem crítica)
Hospedagem de certificados PEM problemática: GitHub Pages serve arquivos .pem com content-type incorreto (text/plain)
Sem estatísticas de acesso (você não sabe se os provedores estão buscando o logo)
Sem alerta de expiração de certificado
Dependência do GitHub (mudanças de política, interrupções de serviço)
Sem domínio personalizado por padrão (URL github.io)

Caso de uso ideal: projetos pessoais, testes, deploy BIMI auto-declarado (sem certificado VMC/CMC). Se você quer testar o BIMI no Yahoo Mail antes de investir em um certificado, GitHub Pages é um bom ponto de partida.

Armadilha frequente: o certificado VMC/CMC. Se você tenta hospedar um arquivo .pem no GitHub Pages, o content-type será text/plain. Os provedores de e-mail podem rejeitar o certificado. Para um deploy BIMI completo (com certificado), GitHub Pages não é adequado.

Também é importante considerar que o GitHub Pages tem limites de largura de banda (100 GB/mês) e de tamanho do site (1 GB). Para um único arquivo SVG, esses limites nunca serão atingidos, mas eles evidenciam que o serviço não foi projetado para hospedagem de produção crítica. Em caso de pico de tráfego (um provedor que coloca o logo em cache e o baixa novamente com frequência), o GitHub Pages pode temporariamente limitar o acesso.

Serviço de hospedagem BIMI dedicado (CaptainDNS)

Um serviço projetado especificamente para hospedar os assets BIMI. O CaptainDNS cuida de toda a cadeia: upload, validação, hospedagem, geração do registro DNS, monitoramento.

Funcionamento:

Você cria um perfil BIMI para o seu domínio
Você verifica a propriedade do domínio (registro TXT)
Você faz upload do seu logo SVG (validado automaticamente no formato Tiny-PS)
Você faz upload do seu certificado VMC/CMC (opcional)
O CaptainDNS gera o registro DNS BIMI completo
Você copia o registro na sua zona DNS

Os arquivos são servidos a partir de assets.captaindns.com com TLS automático (Let's Encrypt), o content-type correto e sem nenhum redirecionamento.

Vantagens:

Configuração zero: sem servidor para gerenciar, sem content-type para configurar
Validação SVG Tiny-PS no upload: se o arquivo não é conforme, é rejeitado com uma mensagem de erro explícita
Hospedagem do certificado VMC/CMC com extração automática de metadados (emissor, datas de validade, tipo)
Alerta de expiração do certificado (30 dias antes do vencimento)
Estatísticas de acesso: número de requisições recebidas e timestamp da última requisição
Geração automática do registro DNS BIMI
Gratuito para os 5 primeiros domínios

Limitações:

Dependência de um serviço terceiro (como qualquer solução hospedada)
Domínio de hospedagem fixo (assets.captaindns.com, sem domínio personalizado para a URL)

Caso de uso ideal: qualquer organização que deseja uma hospedagem BIMI confiável sem se preocupar com a configuração técnica. Particularmente indicado para PMEs sem equipe de operações dedicada.

Plataforma DMARC integrada

As plataformas de monitoramento DMARC como PowerDMARC, Valimail ou Red Sift frequentemente oferecem a hospedagem BIMI como funcionalidade incluída na sua oferta. O logo e o certificado são enviados pelo painel da plataforma, que cuida da hospedagem e da geração do registro DNS.

Vantagens:

Integração nativa com o monitoramento DMARC (visão unificada da autenticação de e-mail)
Hospedagem gerenciada (TLS, content-type, disponibilidade)
Suporte e acompanhamento incluídos na assinatura

Limitações:

Custo elevado: essas plataformas cobram entre 50 e 500 $/mês (ou mais) pela suíte DMARC completa. A hospedagem BIMI é apenas uma funcionalidade entre outras
Vendor lock-in: se você troca de plataforma, a URL do logo muda e você precisa atualizar seu registro DNS
Funcionalidades BIMI variáveis: algumas plataformas não oferecem validação SVG no upload nem alerta de expiração de certificado

Caso de uso ideal: grandes empresas que já utilizam uma plataforma DMARC para o monitoramento da sua autenticação de e-mail. Nesse caso, a hospedagem BIMI é um bônus incluído na assinatura existente.

Tabela comparativa das cinco opções

Critério	Servidor autogerido	CDN (S3/R2)	GitHub Pages	CaptainDNS	Plataforma integrada
Custo	Variável	0-5 $/mês	Gratuito	Gratuito	50-500+ $/mês
Configuração	Manual	Média	Simples	Nenhuma	Nenhuma
Content-Type automático	Não	Configuração necessária	Sim (SVG)	Sim	Sim
TLS gerenciado	Manual	Automático	Automático	Automático	Automático
Geração do registro DNS	Não	Não	Não	Sim	Sim
Hospedagem de certificado	Sim	Sim	Não (PEM)	Sim	Sim
Alerta de expiração do certificado	Não	Não	Não	Sim	Variável
Estatísticas de acesso	Logs do servidor	CloudWatch/R2 Analytics	Não	Sim	Variável
Validação SVG no upload	Não	Não	Não	Sim (SVG Tiny-PS)	Variável

A escolha depende da sua situação. Se você tem uma equipe de operações e uma infraestrutura cloud pronta, um CDN é uma excelente opção. Se você busca a solução mais simples e mais confiável sem configurar nada, o CaptainDNS foi projetado para isso. Se você já utiliza uma plataforma DMARC, verifique se a hospedagem BIMI está incluída na sua assinatura.

Um critério frequentemente esquecido nessa escolha é a permanência da URL. A URL do logo está gravada no seu registro BIMI DNS. Se você troca de solução de hospedagem, também precisa atualizar o registro DNS, o que implica um tempo de propagação durante o qual alguns provedores buscam a URL antiga (que ficou inacessível) e outros a nova. Para minimizar esse risco, prefira uma solução que você não precisará trocar nos próximos anos.

Os cinco erros de hospedagem que quebram seu BIMI

Mesmo com a opção de hospedagem certa, erros de configuração podem impedir a exibição do logo. Aqui estão os cinco erros mais frequentes, com o sintoma, o comando de diagnóstico e a solução para cada um.

Erro 1: HTTP em vez de HTTPS

Sintoma: o logo não aparece em nenhum provedor de e-mail, apesar de um registro BIMI válido e um arquivo SVG conforme.

Causa: a URL na tag l= do registro BIMI usa http:// em vez de https://. Ou então o registro contém https:// mas o servidor responde apenas na porta 80 (HTTP) e redireciona para HTTPS. A especificação BIMI exige uma URL HTTPS que responda diretamente com 200, sem nenhum redirecionamento.

Diagnóstico:

# Verificar o registro BIMI
dig default._bimi.captaindns.com TXT +short

# Testar a resposta HTTPS direta
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Verifique que:

A URL no registro começa com https://
A resposta curl retorna um código HTTP/2 200 (não 301, 302, 307)

Solução: certifique-se de que a URL no registro BIMI aponta diretamente para o endpoint HTTPS. Não conte com um redirecionamento HTTP para HTTPS: os provedores de e-mail não o seguem. Se o seu servidor suporta apenas HTTP, é necessário configurar TLS antes de implementar o BIMI.

Esse erro é particularmente traiçoeiro porque é invisível durante os testes manuais. Se você digita a URL HTTP em um navegador, ele segue o redirecionamento e exibe o arquivo normalmente. Tudo parece funcionar. Mas os agentes automatizados dos provedores de e-mail param no primeiro código de resposta: se não é 200, o arquivo é considerado inacessível.

Erro 2: content-type incorreto

Sintoma: o arquivo SVG está acessível em HTTPS, o código HTTP é 200, mas o logo não aparece.

Causa: o servidor retorna um content-type incorreto. Os casos mais frequentes:

text/plain: padrão de muitos servidores quando o tipo MIME não está configurado para a extensão .svg
application/octet-stream: padrão de certos serviços de armazenamento em nuvem (S3 sem configuração explícita)
text/html: quando o servidor retorna uma página de erro HTML em vez do arquivo SVG

Diagnóstico:

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

Procure a linha Content-Type na resposta. Ela deve conter exatamente image/svg+xml:

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

Solução conforme o seu servidor:

nginx: adicione no seu bloco server ou location:

types {
    image/svg+xml svg;
}

apache: adicione no seu .htaccess ou configuração global:

AddType image/svg+xml .svg

S3: especifique o content-type durante o upload:

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

R2: especifique o content-type no comando wrangler:

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

Erro 3: redirecionamentos HTTP

Sintoma: curl retorna um código 200 quando você testa no navegador, mas os provedores de e-mail não buscam o logo.

Causa: há um ou mais redirecionamentos na cadeia. Os navegadores os seguem automaticamente e mostram o resultado final, o que mascara o problema. Os provedores de e-mail BIMI não seguem redirecionamentos.

Os redirecionamentos mais comuns:

HTTP para HTTPS (301 de http:// para https://)
www para não-www (301 de www.captaindns.com para captaindns.com)
URL antiga para URL nova (301 após reorganização do servidor)
Trailing slash (301 de /bimi/logo.svg/ para /bimi/logo.svg)

Diagnóstico:

# Seguir a cadeia de redirecionamentos
curl -IL https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Se você vê múltiplas respostas HTTP (301, 302, 307) antes do 200 final, esse é o problema. A primeira resposta deve ser um 200 direto.

Solução: atualize a URL no seu registro BIMI para apontar para o destino final, aquele que retorna diretamente um 200. Se o seu servidor redireciona http:// para https://, use a URL https:// no registro. Se o seu servidor redireciona www para o domínio raiz, use o domínio raiz no registro.

Erro 4: servidor indisponível

Sintoma: o logo aparece de forma intermitente, ou aparecia antes e desapareceu.

Causa: o servidor de hospedagem está temporariamente inacessível. As causas possíveis:

Manutenção planejada do servidor
Excesso de cota ou rate limiting
Restrição geográfica (o servidor bloqueia certos IPs)
Saturação do servidor (requisições simultâneas demais)
Servidor virtual desligado (VPS não monitorado)

Diagnóstico:

# Verificar a disponibilidade a partir da sua máquina
curl -o /dev/null -s -w "%{http_code}" https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Testar a partir de um IP diferente (opcional, via serviço online)

Se o código HTTP não é 200, o servidor está inacessível.

Solução: implemente um monitoramento externo que verifique a disponibilidade da URL do logo a cada 5 minutos. Serviços como UptimeRobot, Pingdom ou BetterStack podem alertar em caso de indisponibilidade. O CaptainDNS fornece um contador de requisições e o timestamp da última requisição servida: se o contador para de se mover enquanto você envia e-mails, é um indicador de problema.

Para um servidor autogerido, evite manutenções longas sem servidor de backup. Para um CDN ou serviço dedicado, o risco de indisponibilidade é muito menor graças à redundância integrada.

Erro 5: certificado TLS do servidor expirado

Sintoma: o logo funcionava e desapareceu repentinamente em todos os provedores.

Causa: o certificado TLS do servidor de hospedagem expirou. Não se trata do certificado VMC/CMC (que é um arquivo hospedado), mas do certificado HTTPS do servidor em si. Os provedores de e-mail recusam se conectar a um servidor cujo certificado TLS é inválido.

Esse erro é diferente da expiração do certificado VMC/CMC. Aqui, é o próprio servidor que é rejeitado, não o certificado BIMI.

Diagnóstico:

# Verificar a validade do certificado TLS do servidor
curl -vI https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg 2>&1 | grep "expire date"

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

Solução: ative a renovação automática do certificado TLS. O Let's Encrypt oferece certificados gratuitos com renovação automática via Certbot ou alternativas como acme.sh. CDNs e serviços gerenciados (Cloudflare, CaptainDNS) gerenciam a renovação TLS automaticamente.

Se você usa um servidor autogerido, configure um cron job para a renovação:

# Renovação automática com Certbot
0 0 * * * certbot renew --quiet

Para um diagnóstico completo de todos os erros BIMI, consulte nosso guia logo BIMI que não aparece: 5 erros para corrigir. Você também pode usar a ferramenta de verificação BIMI do CaptainDNS para validar automaticamente toda a cadeia.

Hospedar o certificado VMC ou CMC

A hospedagem do logo SVG é apenas metade do problema. Se você possui um certificado VMC (Verified Mark Certificate) ou CMC (Common Mark Certificate), ele também deve ser hospedado em HTTPS e acessível aos provedores de e-mail.

O certificado é referenciado na tag a= do registro 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"

Os requisitos de hospedagem do certificado

Os requisitos são semelhantes aos do logo, com algumas especificidades:

HTTPS obrigatório. Assim como para o logo, o certificado deve ser servido em HTTPS com um certificado TLS válido no servidor. Sem redirecionamento, sem erro TLS.

Content-type para arquivos PEM. O content-type esperado para um certificado PEM é application/x-pem-file ou application/pkix-cert. Alguns servidores servem arquivos .pem com text/plain, o que pode funcionar em certos provedores mas não está em conformidade com a recomendação.

Resposta HTTP 200 direta. Assim como para o logo, nenhum redirecionamento é tolerado.

O problema da expiração do certificado

Os certificados VMC e CMC têm uma duração de validade limitada, geralmente um ano. Quando o certificado expira:

O Gmail para de exibir o logo (o certificado é obrigatório para o Gmail)
O registro BIMI continua válido, mas o campo a= aponta para um certificado expirado
Nenhuma notificação automática por parte do Gmail ou Yahoo

É um problema traiçoeiro. Diferentemente de um certificado TLS de servidor web (que provoca erros visíveis no navegador), a expiração de um certificado VMC/CMC passa despercebida. O logo desaparece silenciosamente do Gmail, e ninguém percebe até que um colega ou cliente reporte.

A renovação de um certificado VMC ou CMC não é instantânea: é preciso contatar a autoridade certificadora, fornecer as provas necessárias (marca registrada para VMC, prova de uso para CMC), aguardar a validação. O processo pode levar de alguns dias a várias semanas. Se você espera a expiração para iniciar a renovação, seu logo ficará ausente do Gmail durante todo esse período. Por isso, um alerta 30 dias antes do vencimento é essencial.

Logo e certificado em servidores diferentes

O registro BIMI contém dois campos separados: l= para o logo e a= para o certificado. Cada um pode apontar para um servidor diferente. Essa é uma flexibilidade útil se você quer hospedar o logo em um CDN rápido e o certificado em um serviço dedicado que gerencia os alertas de expiração.

Exemplo de registro com servidores diferentes:

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"

A solução CaptainDNS para certificados

O CaptainDNS cuida da hospedagem do certificado VMC/CMC com várias funcionalidades específicas:

Extração automática de metadados: no upload, o CaptainDNS analisa o certificado PEM e extrai o emissor, as datas de validade e o tipo (VMC ou CMC)
Alerta de expiração: 30 dias antes do vencimento do certificado, o CaptainDNS envia um alerta para lembrá-lo de renová-lo
Estatísticas de acesso: assim como para o logo, o CaptainDNS conta as requisições recebidas e registra o timestamp da última requisição
Content-type correto: o certificado é servido com o content-type apropriado, sem configuração da sua parte

Para um guia completo sobre as diferenças entre VMC e CMC e sua compatibilidade com os provedores de e-mail, consulte nosso artigo sobre a compatibilidade VMC, CMC e DNS.

Hospede seu logo BIMI em 3 minutos com o CaptainDNS

Este tutorial detalha as seis etapas para hospedar seu logo SVG e seu certificado VMC/CMC com o CaptainDNS. O processo completo leva menos de três minutos (excluindo a propagação DNS).

Etapa 1: criar um perfil BIMI

Faça login na sua conta CaptainDNS (ou crie uma gratuitamente). Acesse a seção BIMI Hosting no painel de controle. Clique em Novo perfil BIMI e insira seu domínio (por exemplo, captaindns.com).

O seletor padrão (default) é adequado na grande maioria dos casos. Um seletor personalizado só é útil se você precisa de logos diferentes para submarcas ou departamentos que enviam e-mails a partir do mesmo domínio.

Etapa 2: verificar a propriedade do domínio

O CaptainDNS solicita que você prove que controla o domínio. Adicione um registro TXT na sua zona DNS com o valor fornecido pelo CaptainDNS:

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

A verificação é automática. O CaptainDNS consulta seu DNS em intervalos regulares e valida assim que o registro é detectado. A propagação DNS pode levar de alguns minutos a algumas horas dependendo do seu registrar.

Etapa 3: fazer upload do seu logo SVG

Com o domínio verificado, faça upload do seu arquivo SVG Tiny-PS. O CaptainDNS valida o arquivo automaticamente no upload:

Verificação do formato SVG Tiny-PS (atributos version="1.2" e baseProfile="tiny-ps")
Verificação do viewBox quadrado
Detecção de elementos proibidos (<script>, <style>, <image>, <animate>)
Verificação do tamanho do arquivo (menor que 32 KB)

Se o arquivo não é conforme, o CaptainDNS exibe uma mensagem de erro explícita com a lista dos problemas detectados. Nesse caso, use o conversor SVG Tiny-PS para corrigir automaticamente seu arquivo e depois faça upload da versão convertida.

Se o arquivo é conforme, o CaptainDNS o hospeda imediatamente em uma URL estável:

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

Etapa 4: fazer upload do seu certificado (opcional)

Se você possui um certificado VMC ou CMC, faça upload do arquivo PEM. O CaptainDNS extrai automaticamente os metadados:

Emissor: DigiCert, Entrust, etc.
Datas de validade: início e fim do período de validade
Tipo: VMC (Verified Mark Certificate) ou CMC (Common Mark Certificate)

O alerta de expiração é ativado automaticamente: o CaptainDNS avisa você 30 dias antes do vencimento para que possa renovar o certificado sem interrupção na exibição.

O certificado é hospedado em uma URL estável:

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

Etapa 5: copiar e publicar o registro DNS

O CaptainDNS gera automaticamente o registro DNS BIMI completo, pronto para ser copiado na sua zona DNS.

Com certificado:

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"

Sem certificado (auto-declarado):

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

Copie o registro e adicione-o na sua zona DNS no seu registrar ou provedor de DNS. O tipo de registro é TXT, o nome é default._bimi.captaindns.com (substitua pelo seu domínio).

Atenção à sintaxe ao copiar: alguns painéis de gerenciamento DNS adicionam automaticamente o domínio como sufixo. Nesse caso, insira apenas default._bimi como nome de host, sem o domínio. Verifique com dig após a criação para confirmar que o registro está resolvendo corretamente.

Etapa 6: verificar o deploy

Após a propagação DNS (de alguns minutos a algumas horas), verifique se tudo funciona. O CaptainDNS oferece uma ferramenta de verificação integrada que controla toda a cadeia:

Resolução DNS do registro BIMI
Acessibilidade HTTPS do logo SVG
Validação do content-type
Verificação do formato SVG Tiny-PS
Acessibilidade HTTPS do certificado (se presente)
Validade do certificado VMC/CMC (se presente)

Você também pode verificar manualmente com dig e curl:

# Verificar o registro DNS
dig default._bimi.captaindns.com TXT +short

# Verificar o acesso ao logo
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Verificar o acesso ao certificado
curl -I https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem

Funcionalidades incluídas na hospedagem CaptainDNS

Em resumo, a hospedagem BIMI CaptainDNS inclui:

Até 5 domínios gratuitos: nenhum custo para pequenas organizações
Estatísticas de acesso: número de requisições servidas e timestamp da última requisição, para verificar se os provedores estão buscando o seu logo
Alertas de expiração do certificado: notificação 30 dias antes do vencimento do VMC/CMC
TLS automático: certificado Let's Encrypt gerenciado automaticamente, sem intervenção
Validação SVG Tiny-PS no upload: rejeição imediata de arquivos não conformes com mensagem de erro explícita
Geração do registro DNS: o registro BIMI completo é gerado automaticamente, pronto para copiar

Checklist de hospedagem BIMI

Antes de considerar sua hospedagem como operacional, verifique estes oito pontos:

✅ URL em HTTPS (não HTTP)
✅ Certificado TLS válido e não expirado no servidor de hospedagem
✅ TLS 1.2 ou versão superior
✅ Resposta HTTP 200 direta (nenhum redirecionamento 301/302)
✅ Content-Type image/svg+xml para o logo
✅ Tamanho do arquivo SVG menor que 32 KB
✅ Servidor acessível 24/7 sem restrição geográfica
✅ Se certificado VMC/CMC: hospedado em HTTPS com Content-Type apropriado e data de expiração monitorada

Você pode verificar os pontos 1 a 6 em um único 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

Resultado esperado:

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

Se qualquer um desses pontos falha, o logo não será exibido. Corrija na ordem: os problemas de HTTPS e TLS primeiro (sem conexão segura, nada funciona), depois o content-type, depois o tamanho do arquivo.

Lembre-se também de executar essa verificação a partir de um servidor externo (não apenas da sua rede local). Um servidor que funciona perfeitamente do seu escritório pode estar bloqueado por um firewall ou WAF para requisições provenientes de IPs em outros países. Os provedores de e-mail buscam o logo a partir de seus próprios data centers, distribuídos ao redor do mundo.

Plano de ação

Três etapas para garantir a hospedagem do seu logo BIMI:

Auditar sua hospedagem atual: use a checklist acima e o comando curl para verificar se o seu servidor atende aos oito requisitos. Se você já tem um registro BIMI publicado, teste-o com a ferramenta BIMI Record Check do CaptainDNS
Migrar para uma hospedagem confiável: se sua hospedagem atual não satisfaz todos os requisitos, migre para o CaptainDNS para configuração zero, ou para um CDN se você tem a infraestrutura pronta. Em todos os casos, elimine os redirecionamentos e verifique o content-type
Implementar o monitoramento: configure um alerta de expiração para seu certificado VMC/CMC (o CaptainDNS faz isso automaticamente) e um monitoramento de disponibilidade para a URL do logo (UptimeRobot, BetterStack, ou as estatísticas de acesso do CaptainDNS)

FAQ

Onde hospedar meu logo BIMI?

Cinco opções: servidor autogerido (nginx, apache), CDN (S3, Cloudflare R2), GitHub Pages, serviço dedicado como o CaptainDNS, ou plataforma DMARC integrada (PowerDMARC, Valimail). O mais simples é um serviço dedicado que gerencia automaticamente HTTPS, content-type e geração do registro DNS. O CaptainDNS oferece essa hospedagem gratuitamente para os 5 primeiros domínios.

O logo BIMI precisa obrigatoriamente estar em HTTPS?

Sim. HTTP é rejeitado por todos os provedores de e-mail. O certificado TLS do servidor deve ser válido (não autoassinado) e na versão 1.2 no mínimo. Um certificado expirado ou uma cadeia de certificados incompleta também provoca uma rejeição silenciosa do logo.

Qual é o tamanho máximo de um arquivo SVG BIMI?

A especificação recomenda um máximo de 32 KB. Na prática, um SVG Tiny-PS bem otimizado pesa entre 2 e 15 KB. Se seu arquivo ultrapassa 32 KB, simplifique os traçados, reduza o número de pontos de ancoragem ou remova os metadados desnecessários com uma ferramenta de otimização SVG.

Posso hospedar meu logo BIMI no GitHub Pages?

Sim para o logo SVG: o GitHub Pages serve arquivos .svg com o content-type image/svg+xml automaticamente. Por outro lado, o GitHub Pages não é adequado para hospedar um certificado PEM (content-type incorreto) e não oferece SLA de disponibilidade nem monitoramento. É uma opção aceitável para BIMI auto-declarado (sem certificado), mas não para um deploy completo com VMC/CMC.

A hospedagem BIMI pode ser gratuita?

Sim. GitHub Pages e CaptainDNS oferecem hospedagem gratuita. O GitHub Pages é limitado ao logo SVG (sem certificado, sem monitoramento). O CaptainDNS adiciona o gerenciamento TLS automático, a validação SVG Tiny-PS no upload, a hospedagem do certificado VMC/CMC e os alertas de expiração. A oferta gratuita cobre 5 domínios.

O logo e o certificado precisam estar no mesmo servidor?

Não. O registro BIMI contém dois campos separados: l= para o logo e a= para o certificado. Cada um pode apontar para um servidor diferente. Por exemplo, você pode hospedar o logo em um CDN para performance e o certificado no CaptainDNS para se beneficiar dos alertas de expiração.

O que acontece se o servidor de hospedagem ficar indisponível?

O provedor de e-mail não consegue buscar o logo e não o exibe. Alguns provedores como o Gmail usam um cache interno: uma queda curta pode não ter impacto imediato nos e-mails já em cache. Mas uma queda prolongada (várias horas ou dias) resulta no desaparecimento do logo para todos os novos e-mails. Por isso, uma hospedagem de alta disponibilidade é essencial.

Como verificar se minha hospedagem BIMI está funcionando?

Use curl -I seguido da URL do logo para verificar o código HTTP (deve ser 200), o content-type (deve ser image/svg+xml) e o certificado TLS (deve ser válido). Para um diagnóstico completo de toda a cadeia BIMI (DNS, hospedagem, formato SVG, certificado), use a ferramenta BIMI Record Check do CaptainDNS.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.

FAQ

Onde hospedar meu logo BIMI?

O logo BIMI precisa obrigatoriamente estar em HTTPS?

Qual é o tamanho máximo de um arquivo SVG BIMI?

Posso hospedar meu logo BIMI no GitHub Pages?

A hospedagem BIMI pode ser gratuita?

O logo e o certificado precisam estar no mesmo servidor?

O que acontece se o servidor de hospedagem ficar indisponível?

Como verificar se minha hospedagem BIMI está funcionando?

Baixe as tabelas comparativas

Artigos relacionados