Alojamento BIMI: onde e como alojar o seu logo SVG e o seu certificado

Q: Posso alojar meu logo BIMI no GitHub Pages?

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

Q: O logo e o certificado precisam de estar no mesmo servidor?

Não. O registo 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, pode alojar o logo em um CDN para performance e o certificado no CaptainDNS para se beneficiar dos alertas de expiração.

Q: Como verificar se o meu alojamento BIMI está a funcionar?

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, alojamento, formato SVG, certificado), use a ferramenta BIMI Record Check do CaptainDNS.

Por CaptainDNS
Publicado em 31 de março de 2026

Atualizado em 25 de agosto de 2026

TL;DR

O alojamento do logo é o elo mais frágil da cadeia BIMI: HTTPS obrigatório, TLS 1.2+, content-type image/svg+xml, zero redirecionamento, ficheiro menor que 32 KB
53% dos registos BIMI contêm pelo menos um erro: o alojamento 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 (primeira ferramenta gratuita, depois 3 €/mês sem IVA por domínio) aloja 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 concentram-se 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: o alojamento do ficheiro SVG.

O princípio é simples na aparência. O registo DNS BIMI contém uma URL (l=) que aponta para o seu logo. Os fornecedores de e-mail (Gmail, Yahoo Mail, Apple Mail) buscam o ficheiro 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 introduz na cadeia: o logo não aparece. Nenhuma mensagem de erro. Nenhum retorno. O fornecedor 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 registos BIMI contêm pelo menos um erro. Entre esses erros, as falhas de alojamento (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 o seu servidor de alojamento deve atender. Em seguida, as cinco opções de alojamento disponíveis, com os seus pontos fortes e as suas limitações. Por fim, um tutorial passo a passo para alojar o seu logo e o seu certificado com o CaptainDNS, em menos de três minutos.

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

Porque o alojamento do logo BIMI é crítica?

Para entender porque o alojamento é tão crítica, é preciso compreender como os fornecedores de e-mail buscam o logo. O processo segue uma cadeia precisa:

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

O ponto crucial é a etapa 5. O fornecedor 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 do alojamento BIMI

Estes são os requisitos que o seu servidor de alojamento deve atender para que os fornecedores 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 ficheiro	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 fornecedores

Porque esses requisitos são mais rigorosos que o alojamento web convencional?

Na web convencional, um navegador segue redirecionamentos, exibe uma página de erro, refaz a requisição se ela falha. Um fornecedor 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 fornecedor considera que o ficheiro é inacessível. Essa é a armadilha mais comum para equipas que configuram o seu servidor web com redirecionamento HTTP para HTTPS por predefinição. A URL no registo 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 fornecedores 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 fornecedor espera image/svg+xml. Se recebe text/plain (padrão de muitos servidores para ficheiros .svg) ou application/octet-stream, ele rejeita o ficheiro. Ele não tenta detetar 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 fornecedores de e-mail não oferecem um "continuar mesmo assim" como um navegador web.

Um comportamento de cache variável. Alguns fornecedores como o Gmail colocam o logo em cache após a primeira busca bem-sucedida. Esse cache mascara os problemas de alojamento temporários: o logo continua a ser 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 fornecedor 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 ficheiro SVG em si (formato Tiny-PS, dimensões, conteúdo), consulte nosso guia de criação de logo BIMI.

As cinco opções de alojamento comparadas

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

Servidor web autogerido (nginx, apache)

A abordagem mais direta: alojar o ficheiro SVG no seu próprio servidor web. Se já possui um servidor nginx ou apache exposto na Internet, basta em teoria depositar o ficheiro 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:

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

Limitações:

Gestão 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 monitorização integrada (é necessário implementar uma monitorização externa)

Caso de uso ideal: equipas com infraestrutura existente, uma equipa de operações ativa e experiência em gestão de servidores web. Se já gere dezenas de sites web, adicionar um ficheiro SVG é trivial. Se o seu único servidor é um VPS que ninguém monitoriza, é 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 registo DNS, o redirecionamento 301 provocará uma rejeição silenciosa pelo fornecedor 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 ficheiro é alojado 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 ficheiro 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 gerido automaticamente pelo CDN
Distribuição geográfica (redução de latência)
Custo muito baixo (alguns centavos por mês para um único ficheiro)

Limitações:

O content-type deve ser definido explicitamente durante o upload (se 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: pode fazer upload de um ficheiro inválido sem saber
Sem alerta de expiração para certificados VMC/CMC alojados no mesmo bucket
Configuração inicial não trivial (IAM, bucket policy, distribuição CDN)

Caso de uso ideal: equipas 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 faz upload de um ficheiro .svg em um bucket S3 sem especificar o content-type, o S3 o serve com application/octet-stream. O ficheiro é descarregado em vez de ser interpretado como uma imagem. Os fornecedores de e-mail o rejeitam.

Outra armadilha comum com CDNs é a configuração do domínio personalizado. Se associa um nome de domínio à sua distribuição CloudFront ou ao seu bucket R2, 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 fornecedores de e-mail.

GitHub Pages

O GitHub Pages é uma opção gratuita que funciona para casos simples. Crie um repositório, deposite o ficheiro SVG, ative o GitHub Pages: o ficheiro é 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 ficheiros .svg (gerido automaticamente)
Atualização simples (git push)

Limitações:

Nenhum SLA de disponibilidade (GitHub Pages é projetado para sites estáticos, não para alojamento crítica)
Alojamento de certificados PEM problemática: GitHub Pages serve ficheiros .pem com content-type incorreto (text/plain)
Sem estatísticas de acesso (não sabe se os fornecedores estão a buscar 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 predefinição (URL github.io)

Caso de uso ideal: projetos pessoais, testes, deploy BIMI auto-declarado (sem certificado VMC/CMC). Se 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 tenta alojar um ficheiro .pem no GitHub Pages, o content-type será text/plain. Os fornecedores 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 ficheiro SVG, esses limites nunca serão atingidos, mas eles evidenciam que o serviço não foi projetado para alojamento de produção crítica. Em caso de pico de tráfego (um fornecedor que coloca o logo em cache e descarrega-o novamente com frequência), o GitHub Pages pode temporariamente limitar o acesso.

Serviço de alojamento BIMI dedicado (CaptainDNS)

Um serviço projetado especificamente para alojar os assets BIMI. O CaptainDNS cuida de toda a cadeia: upload, validação, alojamento, geração do registo DNS, monitorização.

Funcionamento:

Cria um perfil BIMI para o seu domínio
Verifica a propriedade do domínio (registo TXT)
Faz upload do seu logo SVG (validado automaticamente no formato Tiny-PS)
Faz upload do seu certificado VMC/CMC (opcional)
O CaptainDNS gera o registo DNS BIMI completo
Copia o registo na sua zona DNS

Os ficheiros 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 gerir, sem content-type para configurar
Validação SVG Tiny-PS no upload: se o ficheiro não é conforme, é rejeitado com uma mensagem de erro explícita
Alojamento 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 registo DNS BIMI
primeira ferramenta gratuita, depois 3 €/mês sem IVA por domínio

Limitações:

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

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

Plataforma DMARC integrada

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

Vantagens:

Integração nativa com a monitorização DMARC (visão unificada da autenticação de e-mail)
Alojamento gerido (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. O alojamento BIMI é apenas uma funcionalidade entre outras
Vendor lock-in: se troca de plataforma, a URL do logo muda e precisa de atualizar o seu registo 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 a monitorização da sua autenticação de e-mail. Nesse caso, o alojamento 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	primeira ferramenta gratuita, depois 3 €/mês sem IVA por domínio	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 gerido	Manual	Automático	Automático	Automático	Automático
Geração do registo DNS	Não	Não	Não	Sim	Sim
Alojamento 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 tem uma equipa de operações e uma infraestrutura cloud pronta, um CDN é uma excelente opção. Se busca a solução mais simples e mais fiável sem configurar nada, o CaptainDNS foi projetado para isso. Se já utiliza uma plataforma DMARC, verifique se o alojamento 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 registo BIMI DNS. Se troca de solução de alojamento, também precisa de atualizar o registo DNS, o que implica um tempo de propagação durante o qual alguns fornecedores buscam a URL antiga (que ficou inacessível) e outros a nova. Para minimizar esse risco, prefira uma solução que não precisará de trocar nos próximos anos.

Os cinco erros de alojamento que quebram o seu BIMI

Mesmo com a opção de alojamento 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 fornecedor de e-mail, apesar de um registo BIMI válido e um ficheiro SVG conforme.

Causa: a URL na tag l= do registo BIMI usa http:// em vez de https://. Ou então o registo 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 registo 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 registo 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 registo BIMI aponta diretamente para o endpoint HTTPS. Não conte com um redirecionamento HTTP para HTTPS: os fornecedores 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 digita a URL HTTP em um navegador, ele segue o redirecionamento e exibe o ficheiro normalmente. Tudo parece funcionar. Mas os agentes automatizados dos fornecedores de e-mail param no primeiro código de resposta: se não é 200, o ficheiro é considerado inacessível.

Erro 2: content-type incorreto

Sintoma: o ficheiro 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 ficheiro 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 testa no navegador, mas os fornecedores 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 fornecedores 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 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 registo 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 registo. Se o seu servidor redireciona www para o domínio raiz, use o domínio raiz no registo.

Erro 4: servidor indisponível

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

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

Manutenção planeada 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 monitorizado)

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 uma monitorização externa 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 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 fornecedores.

Causa: o certificado TLS do servidor de alojamento expirou. Não se trata do certificado VMC/CMC (que é um ficheiro alojado), mas do certificado HTTPS do servidor em si. Os fornecedores de e-mail recusam-se a ligar 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 geridos (Cloudflare, CaptainDNS) gerem a renovação TLS automaticamente.

Se 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. Também pode usar a ferramenta de verificação BIMI do CaptainDNS para validar automaticamente toda a cadeia.

Alojar o certificado VMC ou CMC

O alojamento do logo SVG é apenas metade do problema. Se possui um certificado VMC (Verified Mark Certificate) ou CMC (Common Mark Certificate), ele também deve ser alojado em HTTPS e acessível aos fornecedores de e-mail.

O certificado é referenciado na tag a= do registo 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 alojamento 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 ficheiros PEM. O content-type esperado para um certificado PEM é application/x-pem-file ou application/pkix-cert. Alguns servidores servem ficheiros .pem com text/plain, o que pode funcionar em certos fornecedores 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 registo 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 contactar a autoridade certificadora, fornecer as provas necessárias (marca registada para VMC, prova de uso para CMC), aguardar a validação. O processo pode levar de alguns dias a várias semanas. Se espera a expiração para iniciar a renovação, 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 registo 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 quer alojar o logo em um CDN rápido e o certificado em um serviço dedicado que gere os alertas de expiração.

Exemplo de registo 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 do alojamento 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 regista 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 a sua compatibilidade com os fornecedores de e-mail, consulte nosso artigo sobre a compatibilidade VMC, CMC e DNS.

Aloje o seu logo BIMI em 3 minutos com o CaptainDNS

Este tutorial detalha as seis etapas para alojar o seu logo SVG e o 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). Aceda a secção BIMI Hosting no painel de controlo. Clique em Novo perfil BIMI e introduza o seu domínio (por exemplo, captaindns.com).

O seletor padrão (default) é adequado na grande maioria dos casos. Um seletor personalizado só é útil se 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 prove que controla o domínio. Adicione um registo 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 o seu DNS em intervalos regulares e valida assim que o registo é detetado. 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 ficheiro SVG Tiny-PS. O CaptainDNS valida o ficheiro automaticamente no upload:

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

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

Se o ficheiro é conforme, o CaptainDNS o aloja 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 possui um certificado VMC ou CMC, faça upload do ficheiro 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-o 30 dias antes do vencimento para que possa renovar o certificado sem interrupção na exibição.

O certificado é alojado em uma URL estável:

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

Etapa 5: copiar e publicar o registo DNS

O CaptainDNS gera automaticamente o registo 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 registo e adicione-o na sua zona DNS no seu registrar ou fornecedor de DNS. O tipo de registo é TXT, o nome é default._bimi.captaindns.com (substitua pelo seu domínio).

Atenção à sintaxe ao copiar: alguns painéis de gestão DNS adicionam automaticamente o domínio como sufixo. Nesse caso, introduza apenas default._bimi como nome de host, sem o domínio. Verifique com dig após a criação para confirmar que o registo está a resolver 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 registo 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)

Também pode verificar manualmente com dig e curl:

# Verificar o registo 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 no alojamento CaptainDNS

Em resumo, o alojamento BIMI CaptainDNS inclui:

primeira ferramenta gratuita, depois 3 €/mês sem IVA por domínio
Estatísticas de acesso: número de requisições servidas e timestamp da última requisição, para verificar se os fornecedores estão a buscar 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 gerido automaticamente, sem intervenção
Validação SVG Tiny-PS no upload: rejeição imediata de ficheiros não conformes com mensagem de erro explícita
Geração do registo DNS: o registo BIMI completo é gerado automaticamente, pronto para copiar

Checklist de alojamento BIMI

Antes de considerar o seu alojamento como operacional, verifique estes oito pontos:

✅ URL em HTTPS (não HTTP)
✅ Certificado TLS válido e não expirado no servidor de alojamento
✅ 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 ficheiro SVG menor que 32 KB
✅ Servidor acessível 24/7 sem restrição geográfica
✅ Se certificado VMC/CMC: alojado em HTTPS com Content-Type apropriado e data de expiração monitorizada

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 ligação segura, nada funciona), depois o content-type, depois o tamanho do ficheiro.

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 fornecedores de e-mail buscam o logo a partir dos seus próprios data centers, distribuídos ao redor do mundo.

Plano de ação

Três etapas para garantir o alojamento do seu logo BIMI:

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

FAQ

Onde alojar meu logo BIMI?

Cinco opções: servidor autogerido (nginx, apache), CDN (S3, Cloudflare R2), GitHub Pages, serviço dedicado como o CaptainDNS (primeira ferramenta gratuita, depois 3 €/mês sem IVA por domínio), ou plataforma DMARC integrada (PowerDMARC, Valimail). O mais simples é um serviço dedicado que gere automaticamente HTTPS, content-type e geração do registo DNS.

O logo BIMI precisa obrigatoriamente estar em HTTPS?

Sim. HTTP é rejeitado por todos os fornecedores 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 ficheiro 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 o seu ficheiro 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 alojar meu logo BIMI no GitHub Pages?

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

O alojamento BIMI pode ser gratuita?

Sim. GitHub Pages e CaptainDNS (primeira ferramenta gratuita, depois 3 €/mês sem IVA por domínio) oferecem alojamento. O GitHub Pages é limitado ao logo SVG (sem certificado, sem monitorização). O CaptainDNS adiciona a gestão TLS automático, a validação SVG Tiny-PS no upload, o alojamento do certificado VMC/CMC e os alertas de expiração.

O logo e o certificado precisam de estar no mesmo servidor?

Não. O registo 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, pode alojar 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 alojamento ficar indisponível?

O fornecedor de e-mail não consegue buscar o logo e não o exibe. Alguns fornecedores 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, um alojamento de alta disponibilidade é essencial.

Como verificar se o meu alojamento BIMI está a funcionar?

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, alojamento, formato SVG, certificado), use a ferramenta BIMI Record Check do CaptainDNS.

Descarregue as tabelas comparativas

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

📚 Guias BIMI relacionados

Certificado VMC e CMC para BIMI: escolher, comprar e implantar: guia completo de compra e implantação de certificados BIMI

FAQ

Onde alojar meu logo BIMI?

O logo BIMI precisa obrigatoriamente estar em HTTPS?

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

Posso alojar meu logo BIMI no GitHub Pages?

O alojamento BIMI pode ser gratuita?

O logo e o certificado precisam de estar no mesmo servidor?

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

Como verificar se o meu alojamento BIMI está a funcionar?

Descarregue as tabelas comparativas

Artigos relacionados