Mailjet authentifizieren: SPF, DKIM und DMARC-Alignment

Von Thomas · virtueller CISO · 2026-07-29

Mailjet nimmt im E-Mail-Versand eine besondere Stellung ein: in Paris gegründet, heute Teil der schwedischen Sinch-Gruppe, bleibt der ESP einer der beliebtesten Router europäischer Organisationen, für Newsletter wie für Transaktionspost — mit einem Argument europäischer Infrastruktur, das in mancher DSGVO-Akte Gewicht hat. Diese Popularität hat eine direkte Folge: Die DKIM-Konfiguration für Mailjet gehört zu den häufigsten Fragen von Teams, die mitten in einem DMARC-Projekt oder unter den Anforderungen, die Gmail und Yahoo Massenversendern seit 2024 auferlegen, entdecken, dass die Plattform im Namen einer Domain Post versendet — ohne vollständige Authentifizierung.

Die gute Nachricht passt in einen Satz: Mailjet gehört zu den ESPs, die die Dinge sauber machen. Die Plattform signiert DKIM mit der Domain des Kunden — nicht mit einer eigenen technischen Domain —, was einen direkten Weg zur DMARC-Konformität öffnet. Der komplette Weg umfasst drei Schritte: die Domain in der Oberfläche validieren, zwei DNS-Einträge veröffentlichen (ein SPF-Include und einen DKIM-Schlüssel), dann das Alignment in den aggregierten Berichten kontrollieren.

Dieser Leitfaden geht diese Schritte von Anfang bis Ende durch und verweilt bei dem, was die offizielle Dokumentation überfliegt: was diese Einträge für DMARC wirklich ändern, warum das SPF-Alignment in der Standardkonfiguration außer Reichweite bleibt — und warum das kein Problem ist —, und die Veröffentlichungsfehler, die in auditierten DNS-Zonen immer wieder auftauchen.

Die Domain-Validierung, Voraussetzung für alles

Bevor Mailjet auch nur einen Versand im Namen von beispiel.de akzeptiert, verlangt die Plattform den Nachweis, dass die Domain zum Konto gehört. In der Oberfläche, im Bereich der Absenderdomains und -adressen, löst das Hinzufügen einer Domain die Erzeugung eines Validierungs-Tokens aus, das wahlweise veröffentlicht wird: in einer Textdatei im Stammverzeichnis der Website oder in einem TXT-Eintrag in der DNS-Zone. Die zweite Option ist vorzuziehen — sie hängt nicht von der Konfiguration des Webservers ab, überlebt Website-Relaunches und bleibt bei einem späteren Audit der Zone sichtbar.

Dieser Schritt wird oft zu Unrecht im Eiltempo erledigt, denn er legt den genauen Umfang dessen fest, was authentifiziert wird. Die Validierung von beispiel.de autorisiert Absenderadressen genau dieser Domain; ein geplanter Versand von news.beispiel.de setzt die Validierung dieser Subdomain voraus, mit eigenem Token. Die Unterscheidung wirkt nebensächlich; sie bestimmt jedoch, wo die SPF- und DKIM-Einträge veröffentlicht werden müssen — und ein guter Teil der weiter unten aufgeführten Fehler entsteht genau hier, in einer Diskrepanz zwischen dem validierten Niveau und dem in den Adressen tatsächlich genutzten.

Ein Punkt zum Vokabular, bevor es weitergeht: Die Validierung beweist den Besitz der Domain, nicht mehr — und authentifiziert keine einzige Nachricht. Die eigentliche Authentifizierung ist Sache der beiden folgenden Einträge.

Die beiden zu veröffentlichenden Einträge

Ist die Domain validiert, schlägt Mailjet zwei DNS-Einträge vor.

SPF zuerst. Die Plattform bittet darum, ihre Versandserver über den Mechanismus include:spf.mailjet.com in den SPF-Eintrag der Domain aufzunehmen. Auf einer Domain, die nur über Mailjet versendet, sieht der vollständige Eintrag so aus:

beispiel.de.  IN TXT  "v=spf1 include:spf.mailjet.com ~all"

Auf einer Domain, die auch aus Microsoft 365 oder Google Workspace versendet, wird der Mechanismus dem bestehenden Eintrag hinzugefügt — er ersetzt ihn nie: v=spf1 include:spf.protection.outlook.com include:spf.mailjet.com ~all. Ein einziger v=spf1-Eintrag pro Namen: Die Regel ist absolut, und der Fehlerabschnitt kommt darauf zurück.

DKIM danach — und das ist der Eintrag, der für DMARC wirklich zählt. Mailjet erzeugt ein Schlüsselpaar und liefert den öffentlichen Teil, zu veröffentlichen in einem TXT unter dem Selektor mailjet:

mailjet._domainkey.beispiel.de.  IN TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQEB…"

Der Hostname setzt sich zusammen aus dem Selektor (mailjet), dem Literal _domainkey und der validierten Domain. Sobald der Eintrag propagiert ist, aktiviert ein Klick auf die Prüfung auf Mailjet-Seite die Signatur: Jede ausgehende Nachricht trägt dann einen DKIM-Signature-Header mit d=beispiel.de und s=mailjet.

Dieses d=beispiel.de verdient eine Sekunde Aufmerksamkeit, denn das gesamte DMARC-Gebäude ruht darauf.

Das Alignment: Die DKIM-Signatur trägt die Konformität

DMARC begnügt sich nicht mit einem SPF oder DKIM, das bloß „besteht": Verlangt wird, dass mindestens einer der beiden Mechanismen eine Domain validiert, die mit der im From:-Feld — der, die der Empfänger im Postfach sieht — ausgerichtet ist. Das ist das zentrale Konzept des Standards, und es ist das, was die ESPs voneinander trennt.

Bei Mailjet wird die DKIM-Signatur mit der Domain des Kunden angebracht: Eine Nachricht mit From: kontakt@beispiel.de trägt eine Signatur d=beispiel.de. Signierende und sichtbare Domain sind identisch — das DKIM-Alignment ist erreicht, im Strict- wie im Relaxed-Modus. Das Ergebnis: DMARC besteht, egal welche Policy veröffentlicht ist, p=none heute wie p=reject morgen.

Das ist die Eigenschaft, die aus diesem ganzen Artikel hängen bleiben sollte: Bei Mailjet ruht die DMARC-Konformität auf DKIM. Solange der Schlüssel mailjet._domainkey in der Zone liegt und die Signatur aktiv ist, ist der Fluss konform. Das SPF-Include dient der Reputation und der Zustellbarkeit, aber es ist nicht das, was DMARC bestehen lässt — der nächste Abschnitt erklärt, warum.

Um diesen Baustein im Gesamtaufbau zu verorten — Policy, Berichtsadressen, Tags —, dient der Hub mit kommentierten Eintragsbeispielen, Policy für Policy als Referenz: Der _dmarc-Eintrag wird dort von der reinen Überwachung bis zum Reject durchdekliniert.

Umschlag und Return-Path: wo das SPF-Alignment endet

Bleibt zu verstehen, warum SPF seinerseits nicht ausgerichtet sein wird — und warum das nicht schlimm ist.

SPF bewertet nicht das sichtbare From:, sondern die Umschlagadresse: das MAIL FROM der SMTP-Sitzung, nachträglich im Header Return-Path sichtbar. Wie die meisten ESPs setzt Mailjet in diesen Umschlag eine eigene technische Domain (von der Form bnc3.mailjet.com): So kann die Plattform Bounces einsammeln und Abmeldungen im Auftrag des Kunden verarbeiten. Die mechanische Folge: Der empfangende Server prüft SPF gegen die Bounce-Domain von Mailjet. Der Test gelingt — die Versand-IPs stehen sehr wohl im SPF dieser Domain —, aber die so validierte Domain hat mit beispiel.de nichts zu tun: SPF besteht, ohne ausgerichtet zu sein, und trägt nichts zum DMARC-Urteil bei.

In den aggregierten Berichten erzeugt dieses Verhalten eine verwirrende Lektüre: spf=pass auf der einen Zeile, SPF-Alignment im Fehlschlag auf der nächsten, und doch eine positive DMARC-Bewertung dank DKIM. Diese Turnübung wird in dem Artikel über diese scheinbar widersprüchlichen Urteile seziert, der lehrt, solche Zeilen ohne Panik zu lesen.

Manche Angebote gehen weiter: Je nach Tarif erlaubt Mailjet, den Return-Path über einen CNAME zu personalisieren — bounce.beispiel.de zeigt dann auf die Bounce-Infrastruktur des ESP. Der Umschlag wird zu einer Subdomain der sichtbaren Domain, und das SPF-Alignment im Relaxed-Modus wird erreichbar. Das ist eine nützliche Verfeinerung für die Reputation, keine Voraussetzung: Ausgerichtetes DKIM genügt DMARC, und die Jagd nach dem doppelten Alignment ergibt erst Sinn, wenn der Rest des Projekts abgeschlossen ist.

Eine dedizierte Versand-Subdomain: die gute Praxis

Nichts zwingt dazu, Kampagnen von der Organisationsdomain selbst abgehen zu lassen. Die empfohlene Praxis — bei Mailjet wie anderswo — besteht darin, den E-Mail-Versand an eine dedizierte Subdomain zu delegieren: news.beispiel.de für das Marketing, während beispiel.de der menschlichen Korrespondenz vorbehalten bleibt und etwa rechnung.beispiel.de dem Transaktionsversand.

Die Vorteile sind konkret. Erstens die Abschottung der Reputation: Ein Kampagnenvorfall — eine Beschwerdewelle, eine schlecht gepflegte Liste — verschlechtert die Reputation der versendenden Subdomain, nicht die der Hauptdomain, von der der Alltagsverkehr abhängt. Zweitens die Lesbarkeit der Berichte: Jede Subdomain erzählt einen Fluss, und eine unerwartete Quelle fällt dort auf einen Blick auf. Drittens die Flexibilität der Policy: DMARC kann Subdomains gezielt behandeln (das Tag sp=, ergänzt um np= für nicht existierende Subdomains), und DMARCbis — der aktuelle Standard — findet die anwendbare Policy durch den Aufstieg im DNS-Baum, den Tree Walk, Subdomain für Subdomain.

Konkret bleibt das Vorgehen dasselbe, eine Ebene tiefer: news.beispiel.de bei Mailjet validieren, das SPF-Include und den DKIM-Schlüssel auf dieser Subdomain veröffentlichen (mailjet._domainkey.news.beispiel.de) und das Relaxed-Alignment — den Standardmodus — die Brücke zur Organisationsdomain schlagen lassen: Ein From: brief@news.beispiel.de, signiert mit d=news.beispiel.de, bleibt mit beispiel.de ausgerichtet.

Die Überlegung gilt für alle Router, jeder mit eigenen Umschlag- und Selektor-Eigenheiten: Die Leitfäden zur Authentifizierung bei Brevo und zur Einrichtung auf SendGrid-Seite folgen demselben Muster, und der Vergleich der drei ist lehrreich.

Die Fehler aus der Praxis

DNS-Zonen, die nach einem „DKIM besteht nicht" auditiert werden, erzählen fast immer eine dieser vier Geschichten.

Das duplizierte SPF. Der Assistent des Hosters oder ein zu schnelles Copy-Paste erzeugt einen zweiten v=spf1-Eintrag neben dem bestehenden, statt die Mechanismen in einem einzigen zu verschmelzen. Zwei SPF-Einträge auf demselben Namen ergeben einen permerror: Die Empfänger ignorieren beide, und ein Mechanismus, der helfen sollte, wird zum systematischen Fehlschlag für alle Flüsse der Domain, nicht nur für Mailjet. Die Korrektur passt in eine Zeile: ein einziges v=spf1, alle Includes darin.
Der Eintrag auf der falschen Ebene. Ein Klassiker der DNS-Oberflächen, die den Zonennamen automatisch anhängen: Der Schlüssel landet unter mailjet._domainkey.beispiel.de.beispiel.de — die Domain doppelt —, weil der von Mailjet gelieferte vollständige Name in ein Feld geklebt wurde, das einen relativen Namen erwartete. Häufige Variante: das SPF-Include auf beispiel.de hinzugefügt, während die validierte, im From: genutzte Domain news.beispiel.de ist — oder umgekehrt der DKIM-Schlüssel auf der Apex, während der Versand von der Subdomain abgeht. In allen Fällen bleibt die Mailjet-Prüfung rot oder springt, schlimmer, auf einem Umfang auf Grün, der nicht der der realen Sendungen ist.
Der abgeschnittene Schlüssel. Ein beim Einfügen amputierter p=-Wert — zu kurzes Feld, verlorene Anführungszeichen, ein störender Zeilenumbruch — erzeugt eine nicht verifizierbare Signatur. Ein dig TXT mailjet._domainkey.beispiel.de erlaubt den zeichengenauen Vergleich des veröffentlichten Werts mit dem von der Plattform gelieferten.
Die nie aktivierte Signatur. Der Eintrag liegt korrekt in der Zone, aber die abschließende Prüfung auf Mailjet-Seite wurde nie erneut angestoßen: Die Nachrichten gehen ohne Signatur der eigenen Domain hinaus. Das DNS stimmt, der Fluss nicht — der frustrierendste Fall, weil er von der Zone aus unsichtbar ist.

Keiner dieser Fehler ist gravierend; alle kosten Tage verschlechterter Zustellbarkeit, wenn niemand auf die richtigen Signale schaut. Daher der letzte Schritt.

Die Prüfung in den Berichten

Die Konfiguration gilt nicht als abgeschlossen, wenn die Oberfläche auf Grün springt: Bestätigt wird sie in den aggregierten Berichten. Mit einem DMARC-Eintrag, der eine Sammeladresse veröffentlicht:

_dmarc.beispiel.de.  IN TXT  "v=DMARC1; p=none; rua=mailto:berichte@beispiel.de"

sendet jeder große Empfänger — Gmail, Microsoft, Yahoo — eine tägliche Bilanz der im Namen der Domain empfangenen Nachrichten, IP für IP, Urteil für Urteil.

In diesen Berichten erkennt man einen korrekt konfigurierten Mailjet-Fluss an drei Signalen: Die Versand-IPs der Plattform erscheinen als identifizierte Quelle; DKIM zeigt pass mit einer signierenden Domain gleich der From:-Domain — das Alignment; SPF zeigt pass auf der Bounce-Domain von Mailjet, ohne Alignment, was das erwartete Verhalten ist und keine Anomalie. Schlägt DKIM fehl, oder trägt die Signatur eine Mailjet-Domain statt der eigenen, ist sehr wahrscheinlich einer der Fehler des vorigen Abschnitts die Ursache.

Diese Lektüre ist auch das Geländer der Verschärfung: Der Übergang von p=none zu p=quarantine und dann p=reject setzt mehrere Wochen von Berichten voraus, in denen der Mailjet-Fluss — und jeder andere legitime Versender — ausnahmslos ausgerichtet bleibt. DMARCbis liefert übrigens einen expliziten Testmodus (t=y), um eine Policy in der Einfahrphase zu kennzeichnen, wo das alte pct-Tag aus dem Standard verschwunden ist.

Fazit

Mailjet zu authentifizieren folgt einem kurzen, gut markierten Weg: Validierung der Domain — oder besser der dedizierten Versand-Subdomain —, ein in den bestehenden SPF-Eintrag verschmolzenes Include spf.mailjet.com, ein unter mailjet._domainkey veröffentlichter DKIM-Schlüssel, eine aktivierte und anschließend kontrollierte Signatur. Die DMARC-Konformität ruht auf DKIM, signiert mit der eigenen Domain; SPF besteht ohne Alignment wegen des technischen Return-Path des ESP — normales Verhalten, gegebenenfalls durch einen personalisierten Return-Path korrigierbar. Die in der Praxis angetroffenen Fehlschläge kommen selten vom Standard, sondern von einem duplizierten SPF, einem Eintrag auf der falschen Ebene, einem abgeschnittenen oder nie aktivierten Schlüssel — lauter Diagnosen, die sich schwarz auf weiß in den aggregierten Berichten lesen lassen.

Um zu wissen, wo eine Domain steht, vor oder nach diesem Projekt, erstellt eine kostenlose DMARC-Analyse in wenigen Sekunden die Bestandsaufnahme: veröffentlichte Einträge, vorhandene Includes, geltende Policy. Und um die Berichte über die Zeit zu verfolgen, bis hin zu p=reject, gibt die Eröffnung eines Kontos Zugang zur kontinuierlichen Überwachung der Domain — Mailjet-Fluss inklusive.

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