Verifiera beroenden innan du redigerar DNS
Publicering av a BIMI påstående är en liten DNS -ändring med flera externa beroenden. Posten kan hänvisa till en logotyp eller bevisdokument som ett annat team är värd för, och den mottagande leverantören kan avvisa en annars läsbar fil eftersom dess certifikat eller autentiseringsvillkor inte är uppfyllda. Börja med en godkänd domän, mottagarspecifik plan och exakta tillgångsversioner snarare än en generisk TXT sträng.
Den här guiden täcker det dokumenterade arbetsflödet för standardväljare. Det bibehållna BIMI version-15-dokumentet beskriver ytterligare väljare och upptäcktsregler, men det förblir ett Internet-utkast, inte en RFC. Inför inte avancerad väljare beteende bara för att en sändande plattform kan infoga en rubrik; bekräfta den avsedda avsändaren och mottagarens implementering först. BIMI Internet-Draft 15, avsnitt 4.3–4.4.
Upprätta rätt ägare och påstående värde
För det enkla standardfallet på example.com, är påståendens ägare default._bimi.example.com. Versionstaggen är v=BIMI1; indikatorplatsen använder l=, och vilken myndighetsbevis plats använder a=. Utkastet definierar bevisplatsen som valfri syntax, men det gör inte bevis valfritt för varje mottagare. BIMI Internet-Draft 15, avsnitt 4.3.
En fiktiv illustration med två platser är v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. Detta är inte en produktionspost, en värdtillgång eller en certifikatrekommendation. Ersätt varken ett verkligt påstående eller en riktig certifikat-URL med dessa exempelvärden.
Google dokumenterar en PEM-baserad konfiguration för Gmail , inklusive ett exempel med en tom l= värde och certifikatets plats i a=. En endast SVG-post är inte samma implementeringsväg. Välj det formulär som stöds av målmottagaren och det tillhandahållna beviset i stället för att behandla alla publicerade exempel som utbytbara. Google BIMI -konfiguration, steg 2–4.
Kontrollera tillämplig autentiseringspolicy
Bekräfta författarens domän och tillämplig organisationsdomänpolicy med aktuell DMARC upptäcktsregler. Inspektera sedan faktiska meddelanden från den avsedda rutten för justerad autentisering. BIMI Group efterlyser verkställighet och noterar det begränsade stödet för självhävdande poster, men varken policytext eller ett resultat av postbyggaren bevisar att en avsändare är redo. BIMI implementeringsguide; RFC 9989 , avsnitt 4.4 och 4.10.
Leverantörsdokumentation måste läsas med dess versionskontext. Den nuvarande Google-sidan innehåller fortfarande pct=100, medan RFC 9989 tog bort taggen. Behåll denna avvikelse som en kompatibilitetsfråga för e-postadministratören. Använd inte en procentinställning eller testläge som en påstådd genväg till BIMI kvalificering, och försvaga inte befintlig tillämpning när du felsöker ett orelaterade tillgångsproblem. RFC 9989 , Bilaga A.6.
Verifiera resurserna som påståendet kommer att marknadsföra
Värdägaren bör tillhandahålla de exakta offentliga HTTPS-adresserna, de avsedda byten och deras hash. En föreslagen hämtning bör bekräfta att svaret är den förväntade tillgången eller certifikatpaketet snarare än en inloggningssida, en varumärkesfelsida eller omdirigering till en icke-relaterad resurs. Registrera status, slutlig URL, innehållstyp, storlek och TLS resultat. Dessa observationer måste komma från den faktiska produktionsvägen, inte bara en lokal filförhandsvisning.
För en sökväg för märkescertifikat, verifiera det utfärdade beviset och kedjan mot målleverantörens krav. Googles instruktioner beskriver dess PEM-paket och den kedjeorder som tillhandahålls av utfärdaren. HTTPS-servercertifikatet skyddar hämtning; det är inte VMC eller CMC som tillhandahåller märkesbevis. Kontrollera båda relationerna oberoende av varandra. Google BIMI -konfiguration, webbserverkrav och steg 2–3.
Ingen offentlig webbadress har hämtats på uppdrag av en riktig implementering här. Om teamet inte kan tillhandahålla en godkänd tillgång eller certifikat, lämna det beroendet olöst istället för att konstruera en platshållare som kan misstas för giltigt bevis.
Publicera via rätt DNS myndighet
Identifiera den auktoritativa DNS tjänsten för den exakta ägaren och inspektera befintliga poster innan du gör en ändring. Bekräfta om redaktören förväntar sig en relativ värdetikett eller ett fullständigt kvalificerat namn. Bevara det tidigare värdet och TTL och använd en granskad ändringsbegäran som namnger den avsedda ägaren, typen och värdet. Undvik dubbletter av konkurrerande påståenden med samma upptäcktsnamn.
Efter en auktoriserad publicering omfattar de föreslagna kontrollerna dig @AUTH_IP default._bimi.example.com . TXT +norecurse och dig @RESOLVER_IP default._bimi.example.com . TXT. Slutpunkterna med versaler är platshållare. Spara tidsstämplar, fullständiga svar, registrera gränser och de faktiska värdena. Dessa kommandon är föreslagna, inte utförda observationer.
Kontrollera auktoritativ konsekvens innan du förklarar oenighet som cachning. Jämför sedan de rekursiva vägarna som är relevanta för den avsedda mottagaren där dessa observationer är tillgängliga. En DNS TTL eller en leverantörs uppskattade visningsfönster är inte en garanti för att varje mottagare har uppdaterat eller kommer att visa en logotyp.
Validera ett meddelande och planera återhämtningen
Skicka ett kontrollerat meddelande genom det exakta godkända arbetsflödet först efter att dess förutsättningar är klara. Behåll författarens domän, signeringsidentiteter, betrodda autentiseringsresultat och all relevant BIMI diagnostik. Spela in en visningsobservation separat med brevlådeleverantören, klientversion och datum. Apple Mails BIMI sökväg beror till exempel på att den mottagande leverantören tillhandahåller de checkar och rubriker som Apple anger. Apple BIMI -servervägledning.
Om hämtningen misslyckas, reparera det värdbaserade beroendet eller återställ det godkända tidigare påståendet enligt ändringsplanen. Om autentiseringen misslyckas, undersök avsändaren och policyn. Om endast visning saknas, dra inte slutsatsen ett DNS fel utan att kontrollera mottagarraden. Behåll de gamla bevisen som behövs för en säker, auktoriserad återställning; minska inte DMARC skyddet i stort för att återställa en logotyp.
Den exakta bevisporten är "En mottagarspecifik kvalificeringsmatris och bevis för DNS , logotyp, certifikat och meddelandeautentisering." Detta utkast tillhandahåller en dokumentär matris och fiktiv illustration. Ingen livepublicering, DNS fråga, certifikatvalidering, hyresgästbyte eller meddelande/visningstest inträffade, så driftporten och ägarens godkännande förblir öppna.