Adskil en beskrevet mekanisme fra dokumenteret støtte
En funktion med flere logoer kan dokumenteres af BIMI arbejdsgruppe uden at være tilgængelig i hver modtagende postkasse. Det nyttige planlægningsspørgsmål er ikke blot, om et tag eksisterer, men om den påtænkte modtager implementerer den relevante adfærd, og om afsenderen kan bevise resultatet for sine faktiske beskeder. Bevar specifikationsstatus, udbydersupport, observeret visning og forretningspåvirkning som fire separate beviskategorier.
BIMI gruppen offentliggjorde sin lps-forklaring den 23. juli 2026; denne anmeldelse beholdt denne side den 8. november 2026. Den kalder funktionen relativt ny og siger udtrykkeligt, at modtagersupport stadig er ved at dukke op. Denne artikel opsummerer den gruppebeskrevne mekanisme, ikke en universelt implementeret standard. Fuldt aktuelt udkast til tekst var ikke tilgængeligt til verifikation, så nøjagtige normative edge-sager og modtagerimplementering forbliver begrænsede bevishuller. Der er ikke udført live udbydersupport eller displaytest.
Forstå ideen med lokaldelen på højt niveau
Gruppen forklarer lp'er som Local-part som Vælger. Den lokale del er den del af en afsenderadresse før ved-tegnet. I dens beskrevne arbejdsgang undersøger en modtager først standard BIMI påstanden og kan udføre et yderligere opslag ved hjælp af afsenderens lokale del, når lps-betingelsen gælder. Dette flytter et valg til DNS i stedet for at kræve, at afsenderens platform indsætter en brugerdefineret vælgeroverskrift. BIMI Group lps forklaring
Artiklen beskriver kommaseparerede præfikser og en tom lps-værdi, der gør det muligt for hver afsender at udløse det ekstra opslag. Den beskriver også normaliseringseksempler, herunder fjernelse af plusadressering og konvertering af punktummer eller understregninger til bindestreger. Behandl disse som arbejdsgruppens dokumenterede forklaring, ikke en komplet parser-specifikation. Før implementering skal du løse nøjagtig normalisering, matchning og fallback-adfærd i forhold til det gældende udkast og modtagerbevis i stedet for at ekstrapolere fra nogle få eksempler.
Sammenlign lp'er med en beskedvælger
BIMI Groups separate vælgervejledning beskriver en BIMI-vælger-header, der identificerer en alternativ påstand under vælgeren. _bimi.domain. Det anbefaler at beskytte denne header med DMARC-justeret DKIM signatur og advarer om, at en usigneret præference kan blive ignoreret. Dette er et andet kontrolpunkt end lps-tilgangen, som beskrives som at udlede valget fra adressen og DNS . BIMI vælgervejledning
Valget mellem disse tilgange afhænger af afsenderplatformen og målmodtagere. En platform, der ikke kan tilføje en passende header, kan finde den DNS-baserede idé attraktiv, men det etablerer ikke modtagerunderstøttelse. Omvendt beviser understøttelse af konventionelle BIMI vælgere ikke understøttelse af lp'er. Behold begge funktioner som separate rækker i udbydermatricen med kildebevis eller en eksplicit ukendt værdi.
Design standardadfærden først
Lps-artiklen siger, at udbydere, der ikke implementerer tagget, ignorerer det og evaluerer standarden BIMI rekord. Det betyder, at standardpåstanden forbliver et bevidst kompatibilitetsvalg. En plan, der udgiver et standardlogo, men som forventer, at lp'er begrænser branding til udvalgte adresser, skal overveje, hvad ikke-understøttede modtagere ville gøre med standarden. Gruppen illustrerer et tomt standardlogo sammen med udvalgte opslag i lokale dele, men dette eksempel er ikke bevis på adfærd hos en navngiven modtager. BIMI Gruppens fallback diskussion
Behandl ikke logoundertrykkelse som en sikkerhedsgrænse. En fraværende brand-indikator er ikke et leveringsforbud, et identitetsgodkendelsessystem eller garanti for, at ingen anden avatar vises. En modtager kan have kontaktbilleder eller andre præsentationsmekanismer uden for BIMI . Det foreslåede design skal angive den ønskede branding-adfærd, samtidig med at meddelelsesgodkendelse og adgangskontrol overlades til deres faktiske mekanismer.
Planlæg aktiv- og rettighedsafhængighederne for hvert logo
Navne på flere vælgere eliminerer ikke de krav, der er knyttet til hvert billede. BIMI Groups vælgervejledning beskriver bevisdokumenter som knyttet til ét logo, selv når et dokument kan dække flere domæner. En plan for forskellige mærkekunstværker kræver derfor en udsteder- og rettighedsgennemgang for hvert påtænkt logo i stedet for at antage, at ét certifikat automatisk dækker en kampagnesamling. Bekræft den aktuelle udstederemballage og kategoriregler for den rigtige applikation. Bevisafhængigheder med flere logoer
Hold aktiv, certifikatmateriale, DNS påstand og ejer forbundet i ændringsposten. Hvis en supportadresse ændres, eller et produkt trækkes tilbage, skal du gennemgå den tilsvarende påstand og hostede ressourcer. Undgå automatisk at generere vælgere for hver postkasse uden at forstå navnekollisioner, adresseændringer og ejerskab. Normalisering kan få tilsyneladende forskellige adresser til at kortlægges på samme måde; nøjagtig kollisionsadfærd forbliver et spørgsmål for den gældende implementering og kontrollerede test.
Original support og display test matrix
Det følgende er en foreslået matrix, ikke et testresultat. Hver celle skal skelne mellem dokumenteret støtte, observeret adfærd og uafklaret fortolkning. Få autorisation, før du sender testmeddelelser eller ændrer DNS , og brug kontrollerede konti og ikke-følsomt indhold.
- Modtager og klient: service, web- eller mobiloverflade, version hvis tilgængelig og observationsdato.
- Mekanisme: almindelig standardpåstand, BIMI-vælger-header eller lps-baseret valg.
- Input case: godkendt matchende præfiks, ikke-matchende adresse, plus adresse eller normaliseringstilfælde.
- Standardadfærd: tilsigtet tilbagefald og forventet adfærd, når lps ikke understøttes.
- Autentificering: faktiske meddelelsesidentiteter, tilpasset resultat og pålidelige verifikatorbeviser.
- Aktivkæde: valgt påstand, offentligt svar, godkendt logo og certifikatafhængighed.
- Observation: faktisk vist billede, intet billede eller ubestemt resultat, med bevaret kontekst.
- Begrænsninger: caching, kontokontaktbilleder, ukendt implementering og ufuldstændig dækning.
Begynd med de enkleste sager før kantsager. En standardpåstand og én eksplicit valgt adresse kan fastslå, om den grundlæggende tilsigtede sti er observerbar i det autoriserede miljø. Først derefter udvider matrixen til normalisering, fallback og klientforskelle. Et enkelt skærmbillede bør ikke bruges til at udlede alle adressetilknytninger eller alle modtageroverflader.
Hold resultatmåling adskilt fra displaytest
Et logo, der vises, er en visningsobservation, ikke et bevis på øgede åbninger, klik eller tillid. Hvis virksomheden ønsker et kontrolleret resultatkrav, skal du definere metrik, sammenligningsgrupper, prøveperiode og begrænsninger på forhånd. Undgå at blande ændringer af indhold, publikum eller sende omdømme med et logoeksperiment og tilskrive hele forskellen til BIMI . Dette er foreslået eksperimentel disciplin, ikke en påstand om, at en kontrolleret undersøgelse er blevet udført.
Ethvert rapporteret resultat skal skelne mellem levering, gengivelse og engagement. Manglende gengivelsesbevis svækker en påstand om, at publikum faktisk så behandlingen. Klientcaching og privatlivsrelateret måleadfærd kan også komplicere fortolkningen. Bevar disse begrænsninger og indhent passende gennemgang, før du fremsætter en markedsføringspåstand. Ingen procentvis stigning, årsagsvirkning eller estimat af investeringsafkast understøttes af dette manuskript.
Fiktivt eksempel: et delt domæne med to kundevendte adresser
Fictional Juniper Desk vil have anderledes illustrationer til nyhedsbreve og supportmeddelelser, mens de efterlader medarbejdermail uden et BIMI logo. Det foreslåede design bruger lps, fordi dets platform ikke nemt kan indsætte en brugerdefineret header. Gennemgangen spørger først, om de påtænkte modtagere understøtter lp'er, og hvad de ville gøre med standardpåstanden, hvis de ikke gør det. Disse spørgsmål skal besvares, før teamet stoler på branding på adresseniveau.
Den planlagte testmatrix vil omfatte de to godkendte adresser, en ikke-matchende medarbejderadresse og udvalgte normaliseringstilfælde med separate rækker for hver modtager og klient. Det ville også kræve rettigheder og certifikatgennemgang for hvert logo. Juniper Desk er fiktiv: ingen optegnelser blev offentliggjort, ingen post sendt og ingen visning eller engagement målt.
Kataloget kræver en modtager-display testmatrix og, hvis påstået, kontrolleret resultatmåling med begrænsninger. Denne artikel giver kun en foreslået matrix. Originale beviser, menneskelig SMV, kildeanvendelighed, produktionsruter, visuel tilgængelighed og ejerudgivelse forbliver åbne. LPS-diskussionen er velegnet til scoped planlægning, ikke en påstand om implementeret støtte eller målt fordel.