BIMI einrichten: vom DNS-Record zur möglichen Logoanzeige

Was BIMI leistet – und was ein Logo nicht beweist

BIMI steht für Brand Indicators for Message Identification. Am 27. September 2026 ist die maßgebliche Spezifikation der individuelle Internet-Draft Version 14 vom 1. Mai 2026. „Intended status: Standards Track“ ist ein Ziel, kein verabschiedeter RFC. Anbieter betreiben BIMI bereits mit eigenen Regeln. IETF Datatracker

Ein BIMI-Record verweist auf ein Logo und gegebenenfalls auf einen Nachweis. Er signiert oder verschlüsselt keine E-Mail. Ein Markenzertifikat bestätigt bestimmte geprüfte Zuordnungen von Organisation, Domain und Logo; es ist weder eine DKIM-Signatur noch das TLS-Zertifikat eines Mailservers. Ein sichtbares Logo macht Links, Rechnungen oder Anhänge nicht harmlos. Ein fehlendes Logo beweist umgekehrt keine Fälschung. BIMI-Entwurf §§4.1, 8

Zuerst den Versand absichern, dann die Markenanzeige planen

Der BIMI-Entwurf verlangt eine durchgesetzte DMARC-Policy für die sichtbare From-Domain und deren Organisationsdomain. p=none und ein ausdrücklich gesetztes sp=none schließen BIMI dort aus. Bei p=quarantine darf ein vorhandenes pct nach diesem Entwurf nicht kleiner als 100 sein. Zusätzlich muss die konkrete Nachricht die Authentifizierungsanforderungen erfüllen; der Entwurf erlaubt dem Empfänger unter Bedingungen zusätzliche lokale Vertrauensentscheidungen, etwa mit ARC. Ein DNS-Record allein genügt nie. BIMI-Entwurf §7.1

Der aktuelle DMARC-Standard RFC 9989 hat pct entfernt. Google nennt in seiner BIMI-Hilfe weiterhin pct=100; BIMI-Entwurf und Anbieterhilfe verwenden hier den älteren Anforderungskontext. Das macht pct nicht wieder zu einer wirksamen Begrenzung nach RFC 9989. Der neue DMARC-Testmodus t=y wird im BIMI-Entwurf 14 nicht ausdrücklich geregelt. Verlassen Sie sich deshalb nicht darauf, dass eine nominelle Reject-Policy im Testmodus als volle BIMI-Durchsetzung anerkannt wird. Google: BIMI einrichten

MTA-STS, DANE und DNSSEC behandeln weitere Schutzaufgaben. Sie sind keine universelle, allein aus dem BIMI-Entwurf folgende Voraussetzung für jedes Logo; zusätzliche Empfängeranforderungen bleiben möglich.

Empfangsanbieter und Mail-App bestimmen die Anzeige

Die folgende Übersicht gibt die am 27. September 2026 gelesenen Herstellerangaben wieder. Sie beschreibt keine von uns gemessene Anzeige.

Quellen: Google, Apple, Yahoo, Fastmail. Einzelne Herstellerhilfen beschreiben andere Anbieter veraltet: Fastmails Aussage, Gmail brauche ausschließlich VMC, wird beispielsweise durch Googles eigene aktuelle VMC-/CMC-Angabe überholt.

Ein Logo kann auch aus einem Adressbuch, Profil oder einem anderen Markenprogramm stammen. Aus dem sichtbaren Bild allein lässt sich kein BIMI-, VMC- oder CMC-Prüfweg rekonstruieren. Programme wie trustedDialog oder Apples eigene Markenangebote dürfen nicht ohne konkrete Anbieterbelege mit BIMI gleichgesetzt werden.

VMC oder CMC: zuerst Nachweis und Akzeptanz klären

VMC (Verified Mark Certificate) und CMC (Common Mark Certificate) unterscheiden sich insbesondere in den zulässigen Markennachweisen. Ein VMC beruht häufig auf einer registrierten Marke; die Ausstellerregeln kennen weitere zulässige Kategorien. Ein CMC kann auch für bestimmte nicht registrierte Logos in Betracht kommen. „Seit zwölf Monaten irgendwo benutzt“ ist dafür keine allgemeine Freigabe: Beim Prior-Use-Weg gelten konkrete Nachweise der früheren Nutzung auf der betreffenden Website. Andere CMC-Kategorien haben andere Voraussetzungen.

Die BIMI-Group-Liste nennt am Prüftag DigiCert, GlobalSign und SSL.com. Die Gruppe zertifiziert diese Aussteller nicht selbst und garantiert keine Akzeptanz durch Postfachanbieter. Bestellen Sie erst nach Abgleich der aktuellen Ausstellerbedingungen und Ziel-Empfängerregeln. Dieses Kapitel prüft keine Markenrechte und nennt keine Preis- oder Lieferzusage.

Logo als SVG Tiny Portable/Secure vorbereiten

Ein normaler SVG-Export ist nicht automatisch für BIMI geeignet. Das Tiny-PS-Profil schließt aktive Inhalte, externe Ressourcen und Animationen aus. Zum Profil gehören der SVG-Namensraum, version="1.2", baseProfile="tiny-ps" und ein nicht leerer Titel. Google verlangt zusätzlich absolute Abmessungen von mindestens 96 × 96 Pixeln; quadratische, zentrierte Darstellung, deckender Hintergrund und höchstens 32 KB sind dort Empfehlungen. Fastmail verlangt weniger als 16 KB. SVG-Tiny-PS-Entwurf, Google

Dieses frei erfundene Zweifarbenlogo demonstriert die Dateistruktur. Es ist weder eine Marke noch ein zertifiziertes Logo:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2"
     baseProfile="tiny-ps" width="96" height="96" viewBox="0 0 96 96">
  <title>Beispiellogo</title>
  <desc>Blaues Quadrat mit kleinerem weißen Quadrat.</desc>
  <rect width="96" height="96" fill="#16324f"/>
  <rect x="28" y="28" width="40" height="40" fill="#ffffff"/>
</svg>

Hinweise gehören außerhalb der XML-Datei. Attribute x und y an Formen wie rect sind etwas anderes als die im Profil unzulässigen gleichnamigen Attribute am svg-Wurzelelement. Prüfen Sie Profil, verbotene Elemente, Größe und Empfängervorgaben. Wohlgeformtes XML beweist noch keine vollständige Tiny-PS-Konformität und keine Zertifizierbarkeit. Verwenden Sie für den Nachweisantrag und die veröffentlichte Datei das abgestimmte identische Logo.

Record, Selektor und HTTPS-Dateien einrichten

Der Standardselektor ist default; andere Selektoren sind nach Spezifikation möglich. Für example.com könnte ein synthetischer Record so aussehen:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://assets.example.com/logo.svg; a=https://assets.example.com/mark.pem"

Die Beispieladressen sind nicht bereitgestellte Dateien. Ohne Zertifikatsanforderung des Empfängers kann ein Record nur mit v und gültigem l verwendet werden; das ist kein kostengünstiger Ersatz für einen von Ihrem Zielanbieter verlangten Nachweis.

Ein dokumentierter Unterschied: Der Entwurf 14 verlangt für die Logoanzeige einen gültigen l-Verweis und beschreibt leeres l als Verzicht. Google zeigt dagegen einen PEM-Weg mit l=;a=https://…, wenn der Nachweis das Logo enthält. Das ist eine Anbieterangabe, keine universelle BIMI-Regel. Unser Beispiel veröffentlicht ausdrücklich beide URLs. BIMI-Entwurf §§4.3, 7.3, Google, Schritt 4

Bei der Suche wird zunächst die From-Domain und gegebenenfalls mit demselben Selektor die Organisationsdomain betrachtet. Mehrere passende Records sind keine zulässige Ausfallsicherheitsstrategie. Für das Hosten braucht es öffentlich erreichbare HTTPS-Dateien und eine passende Zertifikatskette. Eine erfolgreiche HEAD-Anfrage allein validiert weder SVG-Inhalt noch Markenzertifikat. BIMI-Entwurf §§7.2–7.4

Einführung und Betrieb in einer sinnvollen Reihenfolge

1. Ziele klären: Relevante Empfangsanbieter und Mail-Apps bestimmen, deren aktuelle Bedingungen lesen. Eine pauschale DACH-Quote hilft dabei nicht.
2. Versand prüfen: From- und Organisationsdomain, alle Versanddienste, DMARC-Policy und Nachrichtenauthentifizierung erfassen. Bei unklaren legitimen Fehlschlägen anhalten.
3. Logo und Nachweis vorbereiten: Profil prüfen, Rechte und Nachweisart klären, gegebenenfalls akzeptierten Aussteller beauftragen. Ein Logo nicht allein für die Anzeige ungeprüft ändern.
4. Dateien veröffentlichen: SVG und erforderlichen Nachweis über HTTPS erreichbar machen; Inhalte und Zertifikatskette kontrollieren.
5. Record setzen: Genau einen passenden BIMI-Record veröffentlichen; alle für die From-/Organisationsdomain relevanten DMARC-Bedingungen nochmals vergleichen.
6. Eigene Nachrichten beobachten: Von den tatsächlich genutzten Diensten an eigene oder ausdrücklich abgestimmte Zielpostfächer senden. Header, Anbieter, App, Zeitpunkt und Anzeige getrennt dokumentieren.
7. Pflegen: Ablauf und Widerruf des Nachweises, HTTPS-Erreichbarkeit, Logoänderungen und Änderungen der Empfängerregeln betreuen.

Diese Betriebsprobe wurde für dieses Manuskript nicht durchgeführt. Bei einem Fehler korrigieren Sie Logo, Nachweis oder Record. Wenn eine zur BIMI-Einführung geänderte DMARC-Policy legitime Mail beeinträchtigt, hat deren kontrollierte Rücknahme Vorrang vor dem Logo. Das Entfernen eines BIMI-Records beendet nicht sofort jede gecachte Darstellung und widerruft kein Zertifikat.

Reichweite und Nutzen am eigenen Versand beurteilen

Postfachmarktanteil ist keine BIMI-Reichweite. Ein DNS-Eintrag an einer einzelnen Unternehmensdomain belegt weder die Nutzung einer ganzen Marke noch die tatsächliche Anzeige. Auch Öffnungsraten oder ein vermeintlicher Schutz vor Phishing lassen sich daraus nicht ableiten.

Was der E-Mail Security Check bei BIMI liest

Der E-Mail Security Check fragt default._bimi.<eingegebener Name> ab und liest aus einem eindeutig erkannten Record HTTPS-Adressen für Logo und Nachweis. Er ruft die Dateien nicht ab. Weder SVG, VMC/CMC-Typ, Gültigkeitszeitraum, Vertrauenskette, Markenberechtigung noch Postfachanzeige werden validiert. BIMI und Zertifikatsverweise sind ungewichtete Hinweise; ihr Fehlen ist kein Nachweis einer E-Mail-Sicherheitslücke.

Auch die BIMI-Voraussetzungen prüft dieser Weg nicht vollständig: keine Nachricht, keine anderen Selektoren, keine vollständige BIMI-Suche zur Organisationsdomain und kein lückenloser Abgleich beider Policies samt sp und historischem pct. Der zusätzliche DMARC-Hinweis im Check ist keine BIMI-Freigabe. Eine Ablaufwarnung für Markenzertifikate wird dadurch ebenfalls nicht angeboten.

Markenanzeige ist kein Compliance-Nachweis

Ein Logo oder Markenzertifikat belegt keine Erfüllung gesetzlicher Sicherheitsanforderungen. Rechte am Logo, Ausstellungsbedingungen, Datenverarbeitung und technische Sicherheit sind getrennte Fragen. Der rechtliche und organisatorische Anschluss steht im Kapitel E-Mail-Compliance; BIMI ersetzt dessen Prüfung nicht.