Verifique as dependências antes de editar DNS
Publicando um BIMI asserção é uma pequena alteração DNS com várias dependências externas. O registro pode se referir a um logotipo ou documento de evidência hospedado por outra equipe, e o provedor receptor pode rejeitar um arquivo que de outra forma seria legível porque seu certificado ou condições de autenticação não foram atendidos. Comece com um domínio aprovado, um plano específico para o destinatário e versões exatas dos ativos, em vez de uma string TXT genérica.
Este guia aborda o fluxo de trabalho documentado do seletor padrão. O documento BIMI versão 15 retido descreve seletores adicionais e regras de descoberta, mas permanece um rascunho da Internet, não uma RFC. Não introduza avançados seletor comportamento meramente porque uma plataforma de envio pode inserir um cabeçalho; confirme primeiro a implementação pretendida do remetente e do destinatário. BIMI Internet-Draft 15, seções 4.3–4.4.
Estabeleça o proprietário correto e o valor de afirmação
Para o caso padrão simples em example.com, o proprietário da asserção é default._bimi.example.com. A tag da versão é v=BIMI1; a localização do indicador usa l=, e o local da evidência da autoridade usa a=. O rascunho define a localização da evidência como uma sintaxe opcional, mas isso não torna a evidência opcional para todos os receptores. BIMI Internet-Draft 15, seção 4.3.
Uma ilustração fictícia de localização dupla é v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. Este não é um registro de produção, um ativo hospedado ou uma recomendação de certificado. Não substitua nem uma asserção real nem um URL de certificado real por esses valores de exemplo.
O Google documenta uma configuração baseada em PEM para Gmail , incluindo um exemplo com um vazio l= valor e a localização do certificado em a=. Um registro somente SVG não é o mesmo caminho de implementação. Selecione a forma apoiada pelo destinatário alvo e pelas evidências fornecidas, em vez de tratar cada exemplo publicado como intercambiável. Configuração do Google BIMI , etapas 2–4.
Verifique a política de autenticação aplicável
Confirme o domínio do autor e a política de domínio organizacional aplicável usando o atual DMARC regras de descoberta. Em seguida, inspecione as mensagens reais da rota pretendida para autenticação alinhada. O Grupo BIMI apela à aplicação e observa o apoio limitado de registos autoafirmados, mas nem o texto da política nem o resultado do construtor de registos provam que o remetente está pronto. Guia de implementação BIMI; RFC 9989 , seções 4.4 e 4.10.
A documentação do provedor deve ser lida com seu contexto de versão. A página atual do Google ainda inclui pct=100, enquanto RFC 9989 removeu essa tag. Guarde esta discrepância como uma questão de compatibilidade para o administrador de correio. Não use uma configuração de porcentagem ou modo de teste como um atalho reivindicado para a elegibilidade BIMI e não enfraqueça a aplicação existente ao depurar um problema de ativo não relacionado. RFC 9989 , Apêndice A.6.
Verifique os recursos que a afirmação irá anunciar
O proprietário da hospedagem deve fornecer os URLs HTTPS públicos exatos, os bytes pretendidos e seus hashes. Uma busca proposta deve confirmar que a resposta é o ativo esperado ou pacote de certificados, em vez de uma página de login, página de erro de marca ou redirecionamento para um recurso não relacionado. Registre o status, URL final, tipo de conteúdo, tamanho e resultado TLS . Essas observações devem vir do caminho de produção real, não apenas de uma visualização do arquivo local.
Para um caminho de certificado de marca, verifique a evidência emitida e a cadeia em relação aos requisitos do fornecedor alvo. As instruções do Google descrevem seu pacote PEM e o pedido da cadeia fornecida pelo emissor. O certificado do servidor HTTPS protege a recuperação; não é o VMC ou CMC que fornece evidência de marca. Verifique ambos os relacionamentos de forma independente. Configuração do Google BIMI , requisitos do servidor web e etapas 2–3.
Nenhum URL público foi obtido em nome de uma implantação real aqui. Se a equipe não puder fornecer um ativo ou certificado aprovado, deixe essa dependência sem solução em vez de construir um espaço reservado que possa ser confundido com uma evidência válida.
Publique através da autoridade DNS correta
Identifique o serviço DNS oficial do proprietário exato e inspecione os registros existentes antes de fazer uma alteração. Confirme se o editor espera um rótulo de host relativo ou um nome totalmente qualificado. Preserve o valor e o TTL anteriores e use uma solicitação de alteração revisada que nomeie o proprietário, o tipo e o valor pretendidos. Evite asserções concorrentes duplicadas com o mesmo nome de descoberta.
Após uma publicação autorizada, as verificações propostas incluem cavar @AUTH_IP default._bimi.example.com . TXT +norecurse e cavar @RESOLVER_IP default._bimi.example.com . TXT. Os pontos finais maiúsculos são espaços reservados. Salve carimbos de data e hora, complete respostas, registre limites e os valores reais. Esses comandos são observações propostas, não executadas.
Verifique a consistência oficial antes de explicar a discordância como armazenamento em cache. Em seguida, compare os caminhos recursivos relevantes para o receptor pretendido, onde essas observações estão disponíveis. Um DNS TTL ou uma janela de exibição estimada de um provedor não é uma garantia de que cada receptor foi atualizado ou exibirá um logotipo.
Valide uma mensagem e planeje a recuperação
Envie uma mensagem controlada por meio do fluxo de trabalho aprovado exato somente depois que seus pré-requisitos estiverem prontos. Retenha o domínio do autor, identidades de assinatura, resultados de autenticação confiáveis e quaisquer diagnósticos BIMI relevantes. Registre uma observação de exibição separadamente com o provedor de caixa de correio, versão do cliente e data. O caminho BIMI do Apple Mail, por exemplo, depende do provedor receptor que fornece os cheques e cabeçalhos especificados pela Apple. Orientação do servidor Apple BIMI.
Se a recuperação falhar, repare a dependência hospedada ou restaure a afirmação anterior aprovada no plano de mudança. Se a autenticação falhar, investigue o remetente e a política. Se apenas a exibição estiver ausente, não infira um erro DNS sem verificar a linha do receptor. Mantenha as evidências antigas necessárias para uma reversão segura e autorizada; não reduzam amplamente a proteção DMARC para recuperar um logotipo.
A porta de evidência exata é “Uma matriz de elegibilidade específica do receptor e evidência para DNS , logotipo, certificado e autenticação de mensagem”. Este rascunho fornece uma matriz documental e uma ilustração de registro ficcional. Nenhuma publicação ao vivo, consulta DNS , validação de certificado, alteração de locatário ou teste de mensagem/exibição ocorreu, portanto, o portão operacional e a aprovação de liberação do proprietário permanecem abertos.