Postmark: DKIM, eigener Return-Path und DMARC-Ausrichtung

Von Thomas · virtueller CISO · 08. September 2026

Postmark hat sich seinen Ruf in einer klar umrissenen Nische erworben: transaktionale Post — Bestellbestätigungen, Passwort-Zurücksetzungen, Anwendungsbenachrichtigungen — mit einem Zustellanspruch, der sein Markenzeichen ist. Diese Ausrichtung zeigt sich in einer schlanken Authentifizierungskonfiguration, anders als bei den großen generalistischen ESPs: Wo andere drei oder vier CNAMEs stapeln, stützt sich Postmark auf zwei klar getrennte Bausteine, den DKIM-Schlüssel und den eigenen Return-Path.

Standardmäßig versendet eine zu Postmark hinzugefügte Domain unter der Identität der Plattform: Ohne veröffentlichten DKIM-Schlüssel und ohne eigenen Return-Path trägt die Signatur nicht die angezeigte Domain, und der Umschlag bleibt auf der technischen Domain von Postmark. Aus Sicht von DMARC richtet sich nichts aus, und eine p=reject-Richtlinie weist diesen an sich legitimen Verkehr ab. Beide Einträge sind also vor jeder Verschärfung der Richtlinie zu setzen.

Dieser Leitfaden behandelt den DKIM-Schlüssel und seine unmittelbare Ausrichtung, den eigenen Return-Path für die SPF-Ausrichtung, die Art, wie DMARC das Ganze validiert, die Unterscheidung zwischen transaktionalem Strom und Verteilerstrom — die die Reputation betrifft, nicht die Authentifizierung — sowie die häufigen Konfigurationsfehler und den abschließenden Gegenbeweis über die RUA-Berichte.

DKIM: der Schlüssel auf den Namen der Domain

Der erste Baustein ist die DKIM-Signatur. In der Postmark-Konsole erzeugt die Plattform bei der Deklaration einer Domain ein Schlüsselpaar und zeigt einen TXT-Eintrag an, der in der Zone zu veröffentlichen ist, unter einem von ihr gelieferten Selektor:

<selektor>._domainkey.beispiel.de.  TXT  "k=rsa; p=MIIBIjANBgkq…"

Sobald der TXT propagiert ist, bestätigt die Verifizierung in der Konsole, dass der Schlüssel erkannt wird: Von da an trägt jede ausgehende Nachricht eine Signatur d=beispiel.de — die Organisationsdomain selbst. Die DKIM-Ausrichtung ist somit von Anfang an gesichert, auch im strikten Modus, ohne zwischengeschaltete technische Subdomain.

Postmark handhabt auch die Rotation: Die Erneuerung eines Schlüssels bedeutet, ein neues Paar in der Konsole zu erzeugen, den neuen TXT zu veröffentlichen und nach bestätigter Propagierung umzuschalten. Das Überlappungsprinzip — neuer Selektor aktiv vor dem Entfernen des alten — ist dasselbe wie bei jeder Auswechslung des Signaturmaterials: Es vermeidet das Fenster, in dem Nachrichten ohne gültige Signatur verlassen würden. Der angebotene Schlüssel hat 2048 Bit, eine robuste und von den großen Anbietern erwartete Länge; 1024, von älteren Werkzeugen noch akzeptiert, ist für jede neue Konfiguration zu vermeiden.

Absendersignatur oder gesamte Domain

Postmark unterscheidet zwei Konfigurationsebenen, und ihre Verwechslung ist eine häufige Fehlerquelle. Die Absendersignatur verifiziert eine einzelne Adresse — no-reply@beispiel.de — über eine einfache Bestätigungs-E-Mail; sie autorisiert den Versand aus dieser Adresse, setzt aber weder einen DKIM-Schlüssel der Domain noch einen Return-Path. Die verifizierte Domain hingegen veröffentlicht den DKIM-Schlüssel und den Return-Path in der Zone und deckt damit alle Adressen der Domain mit einem einzigen Satz von Einträgen ab.

Für DMARC bringt nur die Konfiguration auf Domain-Ebene die Ausrichtung im Maßstab: Eine einzelne Absendersignatur lässt die übrige Post der Domain ohne ausgerichtete Signatur. Ein Konto, das mit einer Absendersignatur begonnen hat — der schnellste Weg zu einem ersten Testversand —, muss daher zur verifizierten Domain wechseln, sobald mehrere Adressen versenden, sonst scheitert DMARC an allem, was die isolierte Signatur nicht abdeckt. Es ist ein vergessener Übergang vieler im Prototyp-Stadium verbliebener Konfigurationen.

Der eigene Return-Path: SPF ausrichten

Der zweite Baustein regelt SPF. Standardmäßig liegt die Umschlagadresse — der Return-Path, den SPF tatsächlich prüft — auf der technischen Domain von Postmark (pm.mtasv.net). SPF authentifiziert diese Domain zwar, richtet sich aber an Postmark aus, nicht an beispiel.de: SPF besteht, ohne sich auszurichten, was für DMARC nicht zählt.

Die Antwort ist der eigene Return-Path, als CNAME in der Zone der Domain gesetzt:

pm-bounces.beispiel.de.  CNAME  pm.mtasv.net.

Dieser CNAME verlagert den Umschlag auf pm-bounces.beispiel.de, eine Subdomain der Organisationsdomain. Im entspannten Modus — dem Standard von DMARC — richtet sich diese Subdomain an beispiel.de aus, und SPF richtet sich seinerseits aus. Die SPF-Auflösung folgt dem CNAME zu Postmark, das dort die passende Autorisierung veröffentlicht: Es gibt also keinen include, der dem Root-SPF der Domain hinzuzufügen wäre — ein Punkt, der Postmark von Plattformen abhebt, die eine Änderung des Haupt-SPF-Eintrags verlangen.

Die DMARC-Ausrichtung: die doppelte Garantie

DMARC validiert eine Nachricht nur, wenn SPF oder DKIM besteht und sich an der From-Domain ausrichtet. Mit beiden Bausteinen bietet Postmark den günstigen Fall: DKIM richtet sich über die Signatur d=beispiel.de aus, SPF über den eigenen Return-Path. Zwei Mechanismen bestehen ausgerichtet.

Diese Redundanz hat einen konkreten Wert. Ändert eine Weiterleitung unterwegs die sendende IP, bricht SPF, aber DKIM überlebt; schreibt ein Gateway den Text um und macht die Signatur ungültig, hält SPF. Unter DMARCbis wird die als Ausrichtungsreferenz dienende Organisationsdomain über den DNS Tree Walk bestimmt statt über die alte Public Suffix List, doch die Überlegung bleibt gleich. Die Zeile für Zeile aufgeschlüsselten Einträge zeigen, wie die _dmarc-Anweisung gesetzt wird, sobald DKIM und Return-Path stehen — zuerst auf p=none, dann verschärfend.

Ein feiner Punkt zu den Ausrichtungsmodi verdient Erwähnung. Mit dieser Anordnung richtet sich DKIM sowohl im entspannten als auch im strikten Modus aus, da die Signatur die Domain exakt trägt. SPF hingegen richtet sich nur im entspannten Modus aus — der Umschlag liegt auf der Subdomain pm-bounces, nicht auf der nackten Domain. Eine DMARC-Richtlinie, die aspf=s erzwänge, ließe daher die SPF-Ausrichtung wegfallen und stützte sich ganz auf DKIM. Für nahezu jede Domain ist der voreingestellte entspannte Modus die richtige Wahl; striktes SPF ist eine bewusste, selten nötige Verschärfung, die diese Anordnung nicht verlangt.

Anzumerken: Der eigene Return-Path ist für das Bestehen von DMARC nicht zwingend, da DKIM allein genügt. Doch auf ihn zu verzichten heißt, die Redundanz aufzugeben — und an dem Tag, an dem eine Signatur wegfällt, fängt nichts die Nachricht auf. Bei transaktionaler Post, wo jede Nachricht zählt (eine Bestätigung, ein Zurücksetz-Link), ist diese Redundanz kein Luxus: Der stille Verlust einer solchen Nachricht bedeutet oft einen blockierten Nutzer, einen abgebrochenen Warenkorb oder ein Support-Ticket.

Transaktionaler Strom und Verteilerstrom

Postmark trennt die Sendungen in zwei Stromtypen: transaktional und Verteiler (broadcast). Diese Unterscheidung berührt nicht die Authentifizierung — DKIM und SPF richten sich in beiden Fällen gleich aus —, sondern die Reputation. Der transaktionale Strom, mit hohem Zustelleinsatz, wird vom Verteilerstrom isoliert, dessen Profil (Volumina, Beschwerderaten) sich unterscheidet; eine Vermischung würde die Reputation der kritischen Post beschädigen.

Für DMARC ist die Folge indirekt, aber wissenswert: In den aggregierten Berichten erscheinen beide Ströme unter derselben Postmark-Quelle, identisch ausgerichtet. Eine Ausrichtungsdifferenz zwischen ihnen signalisierte eine unvollständige Konfiguration bei einem der beiden — ein seltener Fall, den das Lesen der Berichte jedoch aufdeckt. Die Stromtrennung ist eine Frage der Zustellhygiene; die Authentifizierung wird einmal für die Domain geregelt und gilt danach für beide Ströme gleichermaßen, ohne erneute Einrichtung.

Bei hohen Volumina bietet Postmark dedizierte IPs, einem Konto vorbehalten. Wie überall wird eine frische dedizierte IP gewärmt — über mehrere Tage im Volumen hochgefahren —, und dieses Aufwärmen liest sich in den Zustellraten, nie in der Ausrichtung, die unabhängig von der sendenden IP gleich bleibt. Einen Zustelleinbruch durch eine frische IP von einem echten Authentifizierungsfehler zu unterscheiden, ist einer der unmittelbaren Vorteile der aggregierten Berichte: Der erste betrifft die Spalten SPF und DKIM nicht, der zweite schon.

Häufige Konfigurationsfehler

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Den eigenen Return-Path auslassen. DKIM genügt, damit DMARC besteht, sodass ein fehlender CNAME lange unbemerkt bleibt — bis zu dem Tag, an dem eine Signatur wegfällt und SPF, nicht ausgerichtet, nichts auffängt. Symptom in den Berichten: DKIM ausgerichtet, SPF authentifiziert, aber nicht ausgerichtet.

Den DKIM-Schlüssel veröffentlichen, ohne ihn zu verifizieren. Der TXT ist da, aber die Konsole hat die Erkennung nicht bestätigt: Solange die Domain nicht als verifiziert markiert ist, ist die Signatur nicht gesichert.

Eine Konfiguration zwischen Domains wiederverwenden. Jede Versanddomain hat ihren eigenen DKIM-Schlüssel und ihren eigenen Return-Path; die Einträge einer Domain auf eine andere zu kopieren, erzeugt Signaturen, die sich nicht ausrichten.

Die Richtlinie zu früh verschärfen. Der Wechsel zu p=reject, bevor die Berichte bestätigen, dass sich der gesamte legitime Verkehr ausrichtet, bedeutet, die Abweisung der eigenen transaktionalen Nachrichten zu riskieren — genau jener, die man sich nicht leisten kann zu verlieren.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht die Postmark-Konsole, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte bestätigt, ob der Postmark-Verkehr der Domain korrekt zugeordnet wird: DKIM ausgerichtet, und SPF ausgerichtet, sobald der eigene Return-Path gesetzt wurde.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Veröffentlichung des _dmarc-Eintrags, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Der Postmark-Verkehr ist an seinen stabilen Adressbereichen schnell zu erkennen; jede nicht ausgerichtete Quelle fällt sofort auf — ein vergessener Return-Path, eine ohne ihren Schlüssel hinzugefügte Domain. Sobald die Ausrichtung über mehrere Tage und über alle Ströme bestätigt ist, erfolgt der Wechsel zu p=reject ohne Risiko. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der zu p=reject führt.