BIMI Draft -11 de 9 de outubro de 2025: o que muda e como se preparar

⚡TL;DR

TL;DR - 🗞️ O draft BIMI -11 (publicado em 9 de outubro de 2025) introduz oficialmente os Local-Part Selectors (lps=) para direcionar o selector BIMI a partir do endereço remetente, atualiza a gramática ABNF e o fluxo de discovery, confirma que **l= precisa servir um logo SVG/SVGZ em HTTPS e reforça os pré-requisitos de DMARC (nada de p=none, pct=100 obrigatório quando p=quarantine).

🧩 BIMI em 1 minuto

BIMI (Brand Indicators for Message Identification) permite que um domínio declare no DNS qual logo aparece ao lado de um e-mail autenticado. Os receptores validam a política BIMI e o MUA decide se renderiza o logo conforme sua política local.

🗞️ Novidades da revisão -11 (9 de outubro de 2025)

• lps= (Local-Part Selectors): nova tag opcional no BIMI Assertion Record que permite uma consulta baseada no local-part do remetente – útil quando não dá para inserir o cabeçalho BIMI-Selector no MTA de saída.
• ABNF atualizada: o registro agora cita explicitamente o bloco local-part-selector e a ordem dos componentes (exceto v=) passa a ser intercambiável.
• Discovery ampliado: com lps=, o receptor normaliza o local-part, tenta uma query com o selector derivado e volta ao registro original se necessário.
• Formatos de imagem: por enquanto apenas SVG e SVGZ são aceitos; um registro IANA "BIMI formats" lista os formatos suportados.
• Lembretes de cabeçalho: BIMI-Selector deve ser assinado por DKIM (alinhado a DMARC); BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference não podem ser assinados e precisam ser removidos se chegarem de fora.

🔧 lps=: direcionar o selector pelo local-part

Objetivo: exibir logos diferentes conforme o endereço de envio sem injetar BIMI-Selector. O registro padrão pode habilitar lps= e redirecionar a consulta para <localpart>._bimi.<domain>.

Algoritmo de normalização (-11):

1. Remover o trecho de plus addressing (+...).
2. Trocar _ e . por -, compactar duplicidades e aparar - no início/fim.
3. Permitir apenas [A-Za-z0-9-], comprimento ≤ 63.
4. Comparação do selector insensível a maiúsculas/minúsculas.

Exemplos:

# Habilitar lps= mas recusar BIMI por padrão
default._bimi.example.org. IN TXT "v=BIMI1; l=; a=; lps=brand-indicators-"

# Dois selectores derivados do local-part
brand-one-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-one.svg"
brand-two-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-two.svg; a=https://mva.example/vmc.pem"

🧪 Discovery, ABNF e estrutura do registro

O BIMI Assertion Record continua sendo um TXT em <selector>._bimi.<domain>. A gramática ABNF (-11) agora permite o bloco local-part-selector e reforça que a ordem (menos v=) é livre.

Pontos principais:

• Fallback: se houver lps=, tente primeiro <localpart>._bimi.<domain> e depois volte ao selector original.
• Recusa explícita: v=BIMI1; l=; a=; rejeita BIMI para aquele selector.
• IANA: um registro de formatos controla o que l= pode devolver (hoje, SVG/SVGZ).

🖼️ Logos: formatos e validação

• l= precisa ser um URI HTTPS.
• Formatos permitidos: SVG e SVGZ (gzip).
• Os receptores validam tamanho, perfil SVG e segurança antes de exibir.
• Se houver uma evidence a= (ex. VMC/CMC), o receptor pode comparar o SVG obtido em l= com o embutido no certificado.

🔐 Requisitos de autenticação e política

• DMARC: a mensagem deve passar DMARC (ou política local equivalente).
• Política: nada de p=none (no domínio autor e no organizacional).
• Com p=quarantine, pct precisa ser 100.
• Receptores podem usar métodos adicionais (como ARC confiável) para tratar certos casos como "pass".

✉️ Cabeçalhos BIMI no receptor

• BIMI-Selector: se existir, deve ser assinado por DKIM (alinhado a DMARC). Caso contrário, o receptor ignora.
• BIMI-Location, BIMI-Indicator, BIMI-Logo-Preference: jamais assine e remova se vierem de fora.

Exemplo de Authentication-Results:

Authentication-Results: mx.example.org; dmarc=pass header.from=example.org;
  bimi=pass header.d=example.org header.selector=brand-one-noreply;
  policy.indicator-uri=https://cdn.example.org/logo-one.svg;
  policy.indicator-hash=1a2b3c4d

🗓️ Linha do tempo

• 2025-10-09 (-11): adiciona lps= e atualiza discovery/ABNF.
• 2025-06-16 (-10): consolidação de cabeçalhos, avp= (preferência de avatar), hash opcional.
• 2025-05-01 (-09): iterações de discovery/evidence.
• 2024-11-04 (-08/-07): CMC passa a acompanhar o VMC.

ℹ️ Status: Internet-Draft (work in progress); cada MBP/MUA mantém o controle total da política de exibição.

✅ Checklist de implementação

• DNS: desenhe uma estratégia de selectores (padrão, variantes de produto, lps= quando fizer sentido).
• Logos: entregue SVG/SVGZ limpos (perfil/peso) e versione as URLs.
• Evidence: publique a= (VMC/CMC) quando existir e mantenha a cadeia atualizada.
• MTAs de saída: não adicione BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference; assine BIMI-Selector se usá-lo.
• Receptores: implemente a normalização LPS, remova cabeçalhos recebidos e considere incluir policy.indicator-hash em Authentication-Results.

🧭 Conclusão

BIMI -11 não revoluciona o protocolo, mas destrava um cenário recorrente (selector guiado pelo local-part) e esclarece discovery, formatos e cabeçalhos. Domínios que desejam controlar com precisão a exibição do logo ganham flexibilidade — desde que mantenham uma postura DMARC robusta e SVG impecáveis.

Artigo informativo baseado em um Internet-Draft sujeito a mudanças; consulte o texto do IETF para detalhes normativos.