En BIMI post är ingen visningsgaranti
A BIMI rekord builder kan hjälpa till att formatera ett föreslaget DNS påstående, men det kan inte garantera att en mottagare kommer att visa logotypen. Publicering, tillgångens giltighet, märkesbevis, behörighet för autentisering och mottagarpolicy är separata villkor. Byggherren bör förklara besluten bakom varje fält och identifiera vad som förblir overifierat. En kopierbar post utan dessa gränser kan förvandla ett användbart konfigurationshjälpmedel till ett löfte som inte stöds.
Den behållna BIMI Group implementeringsguide beskriver praktisk uppställning, medan Googles installationsdokumentation beskriver dess mottagarspecifika krav. Ingen av källorna bevisar att EmailAuth implementerar en byggare eller att varje mottagare beter sig identiskt. Detta manuskript föreslår utdata och testkrav; ingen post genererades för en riktig domän, publicerades eller skannades.
Upprätta domänen och väljarkontexten
Spela in den avsedda sändningsdomänen, väljare, DNS publikationsägare och godkänd logotyp. En byggare bör inte tyst anta att standardväljaren representerar varje meddelande eller varje varumärkesarbetsflöde. BIMI Groups väljarvägledning förklarar väljaranvändning och dess förhållande till meddelandesignalering. Den tillämpliga väljaren måste vara ansluten till den avsedda sändningsprocessen istället för att väljas endast för att dess DNS namn är bekant.
Hålla BIMI väljarnamn separat från DKIM väljare. De tjänar olika syften och upptar olika uppslagssammanhang. En byggare bör förklara publikationsägarens namn som den föreslår, inklusive hur DNS redigeraren förväntar sig relativa eller fullt kvalificerade namn. Det bör inte blint duplicera ett domänsuffix eller hävda att en leverantörs indatakonvention gäller överallt. Befintligt tillstånd och leverantörsbeteende kräver auktoriserad granskning innan publicering.
Förklara varje föreslaget fält
Anteckningen bör identifiera versionspåståendet, logotyp-platsfältet och alla bevis-placeringsfält som stöds av den riktade vägledningen eller specifikationsversionen. Det ska stå vilka värden som tillhandahålls, vilka som är platshållare och varför de behövs för den avsedda mottagaren. Infoga inte en riktig URL eller certifikatplats utan domänägarens godkännande och bevis på att slutpunkten tjänar den avsedda tillgången.
Okända eller ostödda fält behöver explicit hantering i byggarens egen validering. Eftersom BIMI -vägledning och förslag utvecklas, bör verktyget identifiera dess regeluppsättning som stöds i stället för att uppfinna en universell bearbetningsregel för varje tagg. Testplanen bör särskilja input som byggaren vägrar att generera från ett påstående om hur varje mottagare hanterar ett okänt påstående. Inget taggbeteende som inte stöds testades här.
Verifiera tillgångs- och HTTPS-förutsättningar
BIMI Group SVG vägledning beskriver den striktare SVG Portable/Secure-profilen. En byggare bör inte acceptera någon bildadress som likvärdigt bevis. Den föreslagna utdatan bör referera till en godkänd tillgång med en bibehållen innehållshash och valideringspost, samtidigt som strukturell och visuell granskning hålls åtskilda. En logotyp som visas i en webbläsare kan fortfarande inte uppfylla de relevanta profilkraven.
Google kräver HTTPS-värd för BIMI -filer i sin dokumenterade installation. Byggaren bör identifiera om värdslutpunkten har kontrollerats och om de hämtade byten matchar den godkända tillgången. HTTPS-transportbevis fastställer inte behörighet för märkescertifikat eller mottagarvisning. Om ingen hämtning har utförts, bör utgången säga unverified istället för att behandla ett https-prefix som ett lyckat anslutningstest.
Omfattningsmärke bevis och mottagare krav
Googles bibehållna vägledning anger att Gmail kräver en stödd VMC eller CMC och beskriver den VMC-relaterade bockmarkeringen. Andra mottagare kan ha andra behörighetsregler. Byggherren bör fråga vilka mottagare som är viktiga och citera deras nuvarande krav innan ett fält för evidenslokalisering presenteras som allmänt tillräckligt eller onödigt. Ett certifikatköp eller utfärdarens godkännande antyds inte genom att ange en URL.
De Yahoo BIMI vägledning illustrerar en annan mottagarens omfattning, inklusive dess behandling av VMC krav och andra behörighetsöverväganden. Denna kontrast stöder en noggrann mottagarspecifik granskning, inte ett påstående om att varje meddelande som möter den publicerade checklistan kommer att visa en logotyp. Byggherren bör undvika att märka en ofullständig konfiguration som garanterad varumärkessynlighet.
Håll DMARC kvalificering och avsändarberedskap åtskilda
BIMI -mottagarvägledning kan införa DMARC-relaterade villkor, men en byggare får inte anta att en DNS tillämpningspolicy bevisar att varje legitim avsändare anpassar sig. RFC 9989 definierar ström DMARC beteende och dess gränser. Den föreslagna BIMI utgången bör länka till en separat beredskapsbedömning snarare än att tyst ändra autentiseringspolicyn för att uppfylla en logotypinställningsformulär.
Om mottagarens dokumentation använder konventioner som skiljer sig från det nuvarande protokollets ordförråd, behåll källdatum och tillämplighetsfråga. Skriv inte om en policy automatiskt eller uppfinn en ny versionstoken. En BIMI -byggares uppgift är inte tillåtelse att ändra DMARC , inköpsmärkesbevis eller ändra en leverantörs sändningskonfiguration. Dessa beslut behöver sin egen godkända omfattning och verifiering.
Förbered en förändringsplan med exakt rekord
Att inspektera befintligt tillstånd och förbereda en avsedd diff är separata från publicering. Byggherren bör skilja utbyte av ett godkänt register från tillägg av ett konkurrerande påstående hos samma ägare. RFC 1035 definierar TXT struktur, inklusive distinktionen mellan strängar inom ett rekord och separata register. Bevara orelaterade TXT data och hela den berörda postuppsättningen i ändringsplanen.
Registrera återställningsmaterial, ägarens godkännande och observationsplanen efter bytet. En genererad sträng bör inte automatiskt auktorisera en DNS skrivning. Om verktyget stöder publicering, behöver den förmågan separata bevis på hyresgästens bindning, godkännande och verifiering; detta manuskript gör inga anspråk på att EmailAuth erbjuder det. Inget DNS tillstånd lästes eller ändrades för denna övning.
Ett kalkylblad med anteckningar
Skapa ett kalkylblad med domän, väljare, exakt publikationsägare, föreslagna påstående, varje fälts syfte, tillgångshash, slutpunktsbevis, mark-bevis status och avsedda mottagare. Lägg till versioner av källregel, referens för aktuellt tillstånd, avsedd diff, godkännandeägare och olösta förutsättningar. Behåll utsignalens giltighet, driftberedskap och mottagarvisning som separata statusar.
De obligatoriska testfallen bör täcka ett positivt påstående, ogiltig inmatning, dubbletter av poster och fält som inte stöds. Varje fall behöver originalinmatning, förväntat beteende och verklig verktygsutgång när ett auktoriserat test har körts. Märk inte en fixtur som godkänts eftersom den föreslagna utgången ser rimlig ut. Ett dokumentationsexempel är inte ett utfört byggtest, och detta utkast innehåller varken en produktionspost eller uppmätta resultat.
Fiktiv diagnos: ett giltigt påstående utan visningsbevis
Ett fiktivt team genererar en syntaktisk plausibel BIMI post som pekar på en logotyp och antar att varje mottagare nu kommer att se den. Den föreslagna granskningen frågar om tillgången uppfyller profilen, om HTTPS-hämtning har verifierats, vilka märkesbevis som finns och vilka mottagarkrav som gäller. Postens formatering besvarar ingen av dessa frågor i sig.
Teamet skulle lämna visningsberedskapen olöst och samla in de saknade auktoriserade bevisen. Det skulle inte köpa ett certifikat eller ändra autentiseringspolicyn enbart för att få en byggarstatus att bli grön. Detta scenario är fiktivt och beskriver inte ett verkligt mottagarefel eller produktbegränsning. Det visar varför utdata måste förbli kommenterade och villkorade.
Publicera endast det påvisade påståendet
Katalogen kräver en kommenterad post och positiva, ogiltiga, dubbletter och taggtestfall som inte stöds. Dessa ursprungliga artefakter förblir öppna, liksom granskning av mänsklig specialist, källans tillämplighet, produktionsvägar, tillgänglighet och ägarens frigivning. Detta utkast tillhandahåller krav och en fiktiv övning, inte implementerat verktygsbeteende eller ett löfte om logotypvisning. Ett publicerbart exempel måste behålla den faktiska utgången och testerna som stöds samtidigt som mottagarens diskretion hålls synlig.