Brevo authentifizieren: SPF, DKIM und DMARC-Alignment

Von Thomas · virtueller CISO · 2026-07-28

Brevo — die E-Mail-Plattform, die unter dem Namen Sendinblue gestartet ist — verschickt Tag für Tag die Newsletter, Bestellbestätigungen und Automatisierungsstrecken von Hunderttausenden Organisationen. Ein beträchtlicher Teil dieser Konten läuft dennoch in der Standardkonfiguration: Die Nachrichten gehen raus, kommen meistens an, und alles wirkt in Ordnung. Hinter den Kulissen ist das Bild deutlich weniger schmeichelhaft. Ohne Domain-Authentifizierung sind diese Sendungen im Namen einer geteilten Infrastruktur signiert, nicht im Namen der Organisation, die im Absenderfeld steht. DMARC kann sie deshalb nie validieren, und die Zustellbarkeit stößt an eine Decke, die keine noch so geschickte Betreffzeilen- oder Inhaltsoptimierung jemals anheben wird.

Das Paradox daran: Brevo macht die Sache eigentlich richtig. Die Plattform bietet eine vollständige Domain-Authentifizierung an, mit DNS-Einträgen, die fertig zum Einfügen in der Oberfläche bereitliegen. Was in der Praxis meistens fehlt, ist der Konfigurationsschritt selbst — oder das Verständnis dafür, was er wirklich ändert. Zwei TXT-Einträge zu veröffentlichen dauert zehn Minuten; zu begreifen, warum die DKIM-Signatur im Namen der eigenen Domain genau das ist, was DMARC bestehen lässt, dauert etwas länger. Genau dafür ist dieser Leitfaden gedacht.

Auf dem Programm: warum ein nicht authentifizierter ESP die Zustellbarkeit bremst, die Einrichtung auf Brevo-Seite (mail._domainkey und der Verifizierungscode), der entscheidende Punkt des DKIM-Alignments, die Envelope-Frage bei SPF — die am häufigsten missverstandene von allen —, die Anforderungen der großen Mailbox-Anbieter an Massenversender und schließlich der Beleg, abzulesen in den RUA-Berichten.

Warum ein nicht authentifizierter ESP die Zustellbarkeit deckelt

Ein Brevo-Konto ohne Domain-Authentifizierung versendet technisch korrekte Nachrichten: Die Plattform signiert sie mit DKIM, aber mit einer Domain, die ihr selbst gehört oder unter Tausenden Kunden geteilt wird. Das From:-Feld zeigt marketing@beispiel.de, während die Kryptographie im Namen eines Dritten spricht. Die beiden Stimmen decken sich nicht, und diese Dissonanz hat zwei sehr verschiedene Konsequenzen.

Die erste ist mechanisch: DMARC scheitert. Das Protokoll verlangt nicht bloß, dass SPF oder DKIM bestehen; es verlangt, dass mindestens einer der beiden Mechanismen besteht und mit der Domain des From: ausgerichtet ist. Eine kryptographisch einwandfreie DKIM-Signatur einer geteilten Domain erfüllt diese Bedingung nicht. Solange nichts ausgerichtet ist, bleibt die DMARC-Policy von beispiel.de auf p=none festgenagelt: Eine Verschärfung würde die eigenen Kampagnen der Organisation erst in die Quarantäne und dann in die Abweisung schicken.

Die zweite ist heimtückischer: die Reputation. Die Filter von Gmail, Yahoo und Microsoft bauen ihr Vertrauen pro authentifizierter Domain auf. Gehört die Signatur einer geteilten Infrastruktur, verdünnt sich die durch sorgfältige Versandpraxis verdiente Reputation im Verhalten Tausender anderer Versender — die am wenigsten sorgfältigen eingeschlossen. beispiel.de sammelt nichts Eigenes an: Jede Kampagne beginnt wieder bei null, und die gläserne Decke bleibt an Ort und Stelle, ganz gleich, wie ausgefeilt der Inhalt daherkommt.

Die Domain-Authentifizierung bei Brevo

In der Brevo-Oberfläche spielt sich alles in den Einstellungen ab, in der Rubrik für Absender und Domains. Für jede Versanddomain erzeugt die Plattform einen Satz von DNS-Einträgen, die in der Zone der Domain beim gewohnten DNS-Hoster zu veröffentlichen sind. Zwei Einträge tragen die Substanz: der öffentliche DKIM-Schlüssel, platziert unter dem Selektor mail, und ein Verifizierungscode, der die Kontrolle über die Domain nachweist.

mail._domainkey.beispiel.de.   TXT   "k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…"
beispiel.de.                   TXT   "brevo-code:7f3a92c1d5e84b06"

Die Werte oben sind illustrativ: Jedes Konto erhält seine eigenen, die wortwörtlich aus der Oberfläche zu übernehmen sind — insbesondere der öffentliche Schlüssel, lang und ohne jede Toleranz für Tippfehler. Zwei klassische Fallen lauern bei der Eingabe: Manche DNS-Hoster hängen den Domainnamen automatisch an das Namensfeld an (dann gehört nur mail._domainkey in das Feld, sonst entsteht mail._domainkey.beispiel.de.beispiel.de), und lange Schlüssel müssen je nach Zoneneditor in mehrere Zeichenketten in Anführungszeichen aufgeteilt werden. Eine Prüfung auf der Kommandozeile räumt jeden Zweifel aus:

dig TXT mail._domainkey.beispiel.de +short

Existiert unter _dmarc.beispiel.de noch kein DMARC-Eintrag, ist dies der richtige Moment, einen zu veröffentlichen — mit p=none und einer rua-Adresse, damit die Berichte einzutreffen beginnen, ohne dass irgendetwas blockiert wird. Fertige DMARC-Eintragsbeispiele zum Anpassen decken die gängigsten Startkonfigurationen ab. Sobald die Einträge propagiert sind — je nach TTL Minuten bis Stunden —, validiert Brevo die Domain, und jede Nachricht verlässt die Plattform fortan signiert mit d=beispiel.de, Selektor mail.

DKIM-Alignment: was DMARC wirklich bestehen lässt

Das entscheidende Wort in dieser ganzen Operation ist weder „Signatur" noch „Schlüssel": Es ist Alignment. Eine Nachricht, die von einer technischen Domain der Plattform signiert wurde, besteht DKIM im kryptographischen Sinn — die Signatur ist gültig, niemand hat den Inhalt verändert. DMARC fügt jedoch eine Identitätsanforderung obendrauf: Die d=-Domain der Signatur muss zur Domain des sichtbaren From: passen. d=beispiel.de bei einem From: auf beispiel.de: ausgerichtet, DMARC besteht. d= auf einer geteilten Domain: DKIM „pass", DMARC „fail".

Im Relaxed-Modus — dem Standard und der richtigen Wahl für einen ESP — findet der Abgleich auf Ebene der Organisationsdomain statt: Ein From: auf news.beispiel.de, signiert mit d=beispiel.de, bleibt ausgerichtet. DMARCbis, die aktuelle Fassung des Standards, bestimmt diese Organisationsdomain inzwischen über einen Lauf durch den DNS-Baum (den Tree Walk) statt über die alte Public Suffix List — eine Änderung der inneren Mechanik, die am Konfigurationsschritt selbst nichts ändert. Der Strict-Modus verlangt dagegen die exakte Übereinstimmung beider Domains; er bleibt Konstellationen vorbehalten, in denen feinkörnige Kontrolle Vorrang vor Flexibilität hat.

Der gesamte Wert der Brevo-Domain-Authentifizierung liegt in dieser Verschiebung: Aus der geteilten Signatur wird eine Signatur im Namen der Organisation. Die Mechanik ist im Übrigen keineswegs Brevo-spezifisch: Die entsprechende Einrichtung bei Mailjet folgt demselben Muster, und das Alignment bei Mailchimp stellt genau dieselbe Frage mit anderen Bildschirmen und einem CNAME mehr. Das Prinzip bleibt von ESP zu ESP konstant: Die Domain, die signiert, muss die Domain sein, die angezeigt wird.

SPF und der Envelope: warum das Alignment nicht von dort kommt

Der verbreitetste Reflex besteht darin, ein include der Plattform in den SPF-Eintrag der Domain aufzunehmen und die Arbeit für erledigt zu halten. Das ist ein doppelter Lesefehler. SPF wird nicht gegen das sichtbare From: ausgewertet, sondern gegen das MAIL FROM des SMTP-Envelopes — den Return-Path, jene technische Adresse, die die Bounces einsammelt. Bei Brevo bleibt diese Envelope-Adresse, wie bei den meisten ESPs, auf einer von der Plattform betriebenen Domain: Genau das erlaubt ihr, Rückläufer und Listenhygiene im großen Maßstab zu verarbeiten. SPF besteht also durchaus… aber im Namen der Envelope-Domain von Brevo, nicht im Namen von beispiel.de. Das Ergebnis: ein „pass" ohne Alignment, also ohne jeden Beitrag zu DMARC.

Den SPF-Eintrag von beispiel.de zu ändern, hilft dagegen nicht — die empfangenden Server fragen den Eintrag der Envelope-Domain ab, nie den der From:-Domain. Ein überflüssiges include verbraucht lediglich das Budget der zehn DNS-Abfragen, das SPF gewährt, ohne im Gegenzug etwas beizusteuern. Diese Trennung zwischen dem rohen SPF-Ergebnis und dem DMARC-Urteil gehört zu den häufigsten Verwirrungen beim Lesen von Berichten; sie wird in warum DMARC scheitert, obwohl SPF besteht im Detail auseinandergenommen.

Die praktische Schlussfolgerung ist glasklar: Bei einem ESP trägt DKIM das Alignment allein — und das genügt, denn DMARC verlangt nur einen der beiden Mechanismen in ausgerichteter Form. Manche ESPs bieten optional eine eigene, anpassbare Envelope-Domain an, die zusätzlich das SPF-Alignment herstellt; das ist eine willkommene Verfeinerung, aber keine Voraussetzung.

Gmail, Yahoo, Microsoft: kein optionales Thema mehr

Seit Februar 2024 verlangen Gmail und Yahoo von Massenversendern — in der Größenordnung von 5.000 Nachrichten pro Tag an ihre Postfächer — ein Fundament: SPF und DKIM eingerichtet, ein veröffentlichter DMARC-Eintrag (mindestens p=none), ein tatsächlich ausgerichtetes From:, die Ein-Klick-Abmeldung und eine Beschwerderate unter rund 0,3 %. Microsoft zog 2025 mit vergleichbaren Anforderungen für seine Consumer-Postfächer nach. Ein halbwegs aktiver Brevo-Newsletter überschreitet diese Schwellen schneller, als es den meisten Marketingteams bewusst ist.

Konkret hakt ein Brevo-Konto ohne Domain-Authentifizierung das Kästchen „DKIM" im technischen Sinn ab, scheitert aber am Alignment-Kriterium — genau dem, auf das diese Anforderungen zielen. Die Folgen kommen in Stufen: erst häufigere Einordnung in den Spam-Ordner, dann glatte Abweisungen bei den volumenstärksten Kampagnen. Was einmal gute Praxis war, ist zum Eintrittspreis für den Posteingang geworden; die Domain-Authentifizierung ist kein Experten-Feinschliff mehr, sondern das Grundticket. Wer parallel Google Postmaster Tools beobachtet, sieht den Effekt der Umstellung übrigens direkt in der Domain-Reputation.

Der Beleg in den RUA-Berichten

Sobald die Domain authentifiziert ist, wird die Validierung weder in der Brevo-Oberfläche noch auf Basis einer einzelnen Testnachricht abgelesen, sondern in den aggregierten DMARC-Berichten (RUA), die die Empfänger selbst täglich verschicken. Diese Berichte verzeichnen, IP für IP, was Gmail, Microsoft oder Yahoo tatsächlich beobachtet haben. Nach der Aktivierung müssen die Versand-IPs von Brevo dort mit einem DKIM-„pass" erscheinen, dessen Signaturdomain beispiel.de lautet:

<row>
  <policy_evaluated><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
</row>
<auth_results>
  <dkim><domain>beispiel.de</domain><selector>mail</selector><result>pass</result></dkim>
</auth_results>

Die spf-Zeile der Auswertung bleibt im DMARC-Sinn oft auf „fail" — das ist der Envelope der Plattform, nicht ausgerichtet — und das ist völlig normal: Das ausgerichtete dkim genügt, um das Gesamturteil zu tragen. Die echten Wachsamkeitspunkte liegen woanders: Sendungen, die weiterhin von der geteilten Domain signiert werden (ein vergessenes Unterkonto, ein separat konfigurierter Transaktionsstrom, eine Abteilung, die auf eigene Faust ein anderes Werkzeug angeschlossen hat), oder eine unbekannte Quelle, die im Namen der Domain sendet und mit Brevo gar nichts zu tun hat. Genau diese Art von Drift deckt eine kontinuierliche Lektüre der Berichte auf — und von Hand geöffnete XML-Dateien decken sie nicht lange auf: Für diesen Dauerbetrieb gibt es werkzeuggestützte Überwachung.

Fazit

Ein nicht authentifiziertes Brevo-Konto funktioniert, aber es stößt an die Decke: geteilte Signatur, verdünnte Reputation, dauerhaft scheiterndes DMARC. Die Domain-Authentifizierung — der DKIM-Schlüssel unter mail._domainkey plus der Verifizierungscode, mit Werten, die die Plattform liefert — verlegt die Signatur auf die Domain der Organisation; das Alignment dieses d= mit dem From: ist es, was DMARC bestehen lässt. SPF, ausgewertet am Envelope der Plattform, liefert dieses Alignment in aller Regel nicht: DKIM trägt es allein, und das reicht vollkommen aus. Die Anforderungen von Gmail, Yahoo und Microsoft haben daraus eine Eintrittsbedingung für den Massenversand gemacht, und die RUA-Berichte liefern den Beleg, IP für IP.

Zur Bestimmung des Ausgangspunkts zeigt ein Durchlauf der Domain durch die kostenlose DMARC-Analyse in Sekunden, ob die Sendungen unter dem richtigen Namen signieren und was die veröffentlichte Policy taugt. Die Eröffnung eines Kontos erlaubt anschließend, die RUA-Berichte Woche für Woche zu verfolgen und die Policy in Richtung p=reject anzuheben, sobald das Alignment belegt ist — mit dem authentifizierten Brevo-Verkehr an der Spitze des Zuges.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos