SPF, DKIM & DMARC für Postmark.
Postmark authentifiziert Ihre Domain auf Kontoebene im Bereich Sender Signatures → Domains und will – ungewöhnlich für einen Anbieter, der technisch gesehen ein "SPF include" besitzt – bewusst NICHT, dass Sie eine gemeinsam genutzte SPF-Zeile in Ihre Root-Domain einfügen. Stattdessen fügen Sie zwei Records hinzu, die auf Ihrer eigenen Domain liegen: einen DKIM-TXT-Schlüssel unter einem von Postmark zugewiesenen Selector sowie einen benutzerdefinierten Return-Path-CNAME (pm-bounces.yourdomain.com → pm.mtasv.net). Sobald beide verifiziert sind, versendet Postmark unter Ihrer Domain – DKIM von Ihnen signiert und SPF, das über einen ausgerichteten Return-Path besteht –, sodass DMARC sauber besteht. Und include:spf.mtasv.net veröffentlichen Sie dabei nie in Ihrer Root-Domain.
Warum Postmark authentifizieren?
Postmark ist ein Anbieter mit Fokus auf Transaktions-E-Mails – Passwort-Resets, Belege, Bestellbestätigungen, Einmalcodes –, sodass die Zustellung in den Posteingang nicht kosmetisch ist, sondern das gesamte Produkt ausmacht. Seit Februar 2024 verlangen Gmail und Yahoo von jedem Absender, dass er SPF, DKIM und DMARC mit Ausrichtung (Alignment) besteht (streng durchgesetzt für Massenversender ab etwa 5.000 Nachrichten pro Tag), und Microsoft begann 2025, nicht konforme E-Mails abzulehnen. Wenn Sie über Postmark versenden, ohne Ihre Domain zu verifizieren, kann Postmark zwar weiterhin zustellen, doch die Nachrichten sind mit Postmarks eigener Domain DKIM-signiert und laufen über einen Return-Path auf pm.mtasv.net – weder DKIM noch SPF sind also zu Ihrer From-Adresse ausgerichtet. Das wird bei DMARC p=none toleriert, aber sobald Sie (oder jemand auf einer gemeinsam genutzten übergeordneten Domain) auf p=quarantine oder p=reject wechseln, wird nicht ausgerichtete Postmark-Post in Quarantäne verschoben oder abgewiesen. Die Verifizierung der Domain löst das mit zwei Records: DKIM richtet sich an Ihrer Domain aus, der benutzerdefinierte Return-Path richtet auch SPF aus, DMARC besteht bei beiden, und die aufgebaute Absenderreputation kommt Ihrer Domain zugute statt Postmarks gemeinsam genutzter Infrastruktur.
Die SPF-Realität bei Postmark
Postmark hat durchaus ein gemeinsam genutztes SPF include – der Host ist include:spf.mtasv.net (mtasv ist Postmarks Domain für die Mail-Transfer-Infrastruktur) –, doch Postmark bittet Kunden bewusst nicht mehr darum, es in ihre Root-Domain aufzunehmen, und für nahezu alle ist das die richtige Wahl. Der Grund: SPF wird gegen den Return-Path (das Envelope-MAIL FROM) validiert, nicht gegen Ihre sichtbare From-Adresse. Standardmäßig liegt Postmarks Return-Path auf seiner eigenen Domain (pm.mtasv.net), sodass SPF bereits besteht – aber es besteht für Postmarks Domain, die NICHT zu Ihrer From-Domain ausgerichtet ist und DMARC daher nicht helfen kann. include:spf.mtasv.net in Ihr ROOT-SPF aufzunehmen ändert daran nichts, denn Ihre Root-Domain ist nicht das, was im Return-Path erscheint; das include würde einfach nur dort stehen und ohne Nutzen einen Lookup verbrauchen. Der richtige Schritt ist ein benutzerdefinierter Return-Path: Fügen Sie einen CNAME unter pm-bounces.yourdomain.com hinzu, der auf pm.mtasv.net zeigt. Diese Subdomain erbt Postmarks eigenes veröffentlichtes SPF (ein Live-Lookup bestätigt, dass pm.mtasv.net v=spf1 include:spf.mtasv.net -all veröffentlicht) sowie die Bounce-MX-Records, sodass SPF dort besteht UND der Return-Path nun auf Ihrer Organisationsdomain liegt – womit SPF für DMARC ausgerichtet ist. Fazit: Das gemeinsam genutzte include (spf.mtasv.net) existiert, aber das moderne, empfohlene Postmark-Setup ist ein benutzerdefinierter Return-Path-CNAME plus ein DKIM-TXT-Schlüssel, ohne dass Ihrem Root-SPF etwas hinzugefügt wird. Das include ist nur in dem seltenen Fall relevant, in dem Sie speziell von Ihrem Apex aus über Postmark versenden und dort eine explizite Autorisierung wünschen – und selbst dann sagt Postmark, dass es nicht erforderlich ist.
Zwei Wege zur Einrichtung
Benutzerdefinierter Return-Path-CNAME + DKIM (empfohlen)
- Fügen Sie einen DKIM-TXT-Schlüssel und einen pm-bounces-CNAME → pm.mtasv.net hinzu; in Ihr Root-SPF kommt nichts
- SPF besteht UND richtet sich aus, weil der Return-Path nun auf Ihrer eigenen Domain liegt, sodass DMARC bei SPF und DKIM gleichermaßen besteht
- Fügt Ihrem Root-SPF-Record null DNS-Lookups hinzu – es gibt nichts, was hineingemergt werden müsste
- Genau dazu fordert Sie das Dashboard von Postmark auf; es ist der unterstützte Weg
include:spf.mtasv.net in Ihr Root-SPF aufnehmen (unnötig)
- Sie würden v=spf1 a mx include:spf.mtasv.net ~all selbst in Ihren Apex einfügen
- Postmark sagt ausdrücklich, dass dies NICHT erforderlich ist – und es bringt für die Ausrichtung nichts
- In Ihrer Root-Domain kann es DMARC nicht helfen, weil Ihre Root nicht der Return-Path ist, den Postmark verwendet
- Nur denkbar relevant, wenn Sie von Ihrem nackten Apex aus über Postmark versenden; kostet sonst einen Lookup ohne Nutzen
Schritt für Schritt
- 1
Sender Signatures → Domains öffnen
Melden Sie sich unter account.postmarkapp.com an, öffnen Sie Sender Signatures im Kontomenü und wechseln Sie dann zum Tab Domains. Die gesamte Domain zu verifizieren (nicht nur einen einzelnen bestätigten Absender) ist das, was jeder Adresse auf Ihrer Domain SPF-/DKIM-Ausrichtung verschafft.
- 2
Ihre Domain hinzufügen
Klicken Sie auf Add Domain und geben Sie yourdomain.com ein. Postmark erstellt den Record-Satz und öffnet die Seite DNS Settings der Domain, auf der die DKIM- und Return-Path-Zeilen darauf warten, verifiziert zu werden.
- 3
Den DKIM-Record kopieren
Beachten Sie auf der Seite DNS Settings die DKIM-Zeile: einen TXT-Record, dessen Hostname ein von Postmark zugewiesener Selector ist, der auf pm._domainkey endet (zum Beispiel 20260727pm._domainkey), und dessen Value ein langer Schlüssel v=DKIM1; k=rsa; p=… ist. Dieser Selector und Schlüssel sind für Ihre Domain einzigartig.
- 4
Den Return-Path-Record kopieren
Beachten Sie im Abschnitt Return-Path den CNAME: Der Hostname ist standardmäßig pm-bounces (also pm-bounces.yourdomain.com) und der Value ist pm.mtasv.net. Dies ist der Record, der SPF an Ihrer Domain ausrichtet. Sie können das Label pm-bounces ändern, es muss aber ein CNAME auf pm.mtasv.net bleiben.
- 5
Den DKIM-TXT-Record hinzufügen
Erstellen Sie bei Ihrem DNS-Host einen TXT-Record. Host = der Selector, den Postmark anzeigt (z. B. 20260727pm._domainkey), Value = die vollständige Zeichenfolge v=DKIM1;…, genau eingefügt. Postmark stellt 2048-Bit-Schlüssel aus, sodass der Wert lang ist – siehe die Stolperfalle zum Aufteilen, falls Ihr Panel ein Limit von 255 Zeichen pro String erzwingt.
- 6
Den Return-Path-CNAME hinzufügen
Erstellen Sie einen CNAME-Record: Host = pm-bounces, Value = pm.mtasv.net. Fügen Sie keinen weiteren Record (kein TXT, kein A) auf der Subdomain pm-bounces hinzu – ein CNAME kann nicht mit anderen Record-Typen auf demselben Namen koexistieren.
- 7
Ihr Root-SPF unangetastet lassen
Fügen Sie include:spf.mtasv.net NICHT zu Ihrem Apex-SPF hinzu. Es ist nicht erforderlich und bringt für die Ausrichtung nichts. Falls Sie bereits einen Root-SPF-Record für andere Absender haben (Google Workspace, Microsoft 365 usw.), lassen Sie ihn unverändert – der pm-bounces-CNAME kümmert sich um Postmarks SPF auf seiner eigenen Subdomain.
- 8
Einen DMARC-Record veröffentlichen oder beibehalten
Falls Sie noch kein DMARC haben, fügen Sie einen TXT-Record unter _dmarc hinzu, der auf v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com zeigt. Falls Sie bereits einen haben, lassen Sie ihn – Sie behalten für die gesamte Domain immer nur einen einzigen _dmarc-Record.
- 9
In Postmark auf Verify klicken
Klicken Sie zurück auf der Seite DNS Settings der Domain auf Verify neben DKIM und Return-Path. Die Propagierung dauert meist Minuten, kann aber bis zu 24–48 Stunden in Anspruch nehmen; beide Zeilen werden grün, sobald sie auflösen.
- 10
Einen echten Test senden und Original anzeigen
Senden Sie nach der Verifizierung über Postmark einen Test von einer Adresse auf Ihrer Domain, öffnen Sie ihn in Gmail und nutzen Sie ⋮ → Original anzeigen. Sie möchten SPF: PASS und DKIM: PASS, beide mit yourdomain.com (nicht mtasv.net), plus DMARC: PASS sehen.
Einzutragende Einträge
Postmark erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| TXT | 20260727pm._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…DKIM-Schlüssel. Der Selector (das Label YYYYMMDDpm._domainkey) und der Schlüssel sind für Ihre Domain einzigartig – kopieren Sie die exakten Werte von Postmarks Seite DNS Settings. 2048-Bit, sodass er ggf. in mehrere Strings in Anführungszeichen aufgeteilt werden muss. |
| CNAME | pm-bounces | pm.mtasv.netBenutzerdefinierter Return-Path. Dies ist das, was SPF PASS macht und für DMARC AUSRICHTET – er erbt Postmarks SPF (live verifiziert: pm.mtasv.net veröffentlicht v=spf1 include:spf.mtasv.net -all) und die Bounce-MX von pm.mtasv.net. Halten Sie ihn auf dieser Subdomain ausschließlich als CNAME. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comIhre DMARC-Policy – ein Record pro Domain, getrennt von Postmark. Beginnen Sie mit p=none zur Beobachtung. |
| TXT | @ | v=spf1 a mx include:spf.mtasv.net ~allNICHT erforderlich und nicht empfohlen – fügen Sie dies nicht hinzu. Postmark fragt nicht mehr danach; in Ihrer Root-Domain bringt es für die Return-Path-Ausrichtung nichts. Nur gezeigt, damit Sie das veraltete include wiedererkennen, falls Sie es bereits vorfinden. |
Behalten Sie genau einen SPF-TXT-Eintrag (v=spf1) auf Ihrer Root-Domain — führen Sie jeden Absender darin zusammen. Zwei SPF-Einträge sind bereits an sich ein Fehler.
Das Budget von 10 Lookups
SPF ist auf harte 10 DNS-Lookups begrenzt — wird dieser Wert überschritten, gibt SPF einen permerror zurück und validiert überall nicht mehr. Hier sehen Sie, was die Einrichtung von Postmark von diesem Budget verbraucht.
Die empfohlene Einrichtung von Postmark fügt 0 Lookups hinzu — alle 10 bleiben frei für die Absender, die tatsächlich ein include benötigen.
DKIM
DKIM ist bei Postmark ein TXT-Record, den Sie selbst veröffentlichen – keine CNAME-Delegation wie bei SendGrid oder Mailchimp. Postmark weist Ihnen einen datumsbasierten Selector zu, der auf pm._domainkey endet (zum Beispiel 20260727pm._domainkey), und generiert einen 2048-Bit-RSA-Schlüssel; Sie erstellen einen TXT-Record mit diesem Hostname und fügen den vollständigen Wert v=DKIM1; k=rsa; p=… genau so ein, wie er auf der Seite DNS Settings angezeigt wird. Da es sich um einen TXT-Record mit dem öffentlichen Schlüssel handelt (Postmark behält den privaten Schlüssel), kann Postmark ihn nicht still rotieren, wie es ein per CNAME delegierender Anbieter kann – stattdessen bietet Postmark eine manuelle Aktion Rotate DKIM Key an, die einen frischen Schlüssel unter einem neuen Selector generiert und Ihnen einen ausstehenden Record zum Veröffentlichen anzeigt; sobald der neue TXT verifiziert ist, stellt Postmark die Signierung um und Sie können den alten entfernen. Eine regelmäßige Rotation (ein paar Mal pro Jahr ist eine sinnvolle Kadenz) ist gute Hygiene. Wichtig: Ein verifizierter DKIM-Schlüssel allein reicht bereits aus, damit Postmark-Post DMARC besteht, denn DKIM richtet sich an Ihrer Domain aus – der benutzerdefinierte Return-Path ist das, was Ihnen zusätzlich SPF-Ausrichtung verschafft.
DMARC
DMARC ist ein separater Policy-Record auf Ihrer Root-Domain – er gehört nicht zu den Postmark-Records, und Sie behalten für die gesamte Domain genau einen _dmarc-TXT, egal wie viele Absender Sie nutzen. Veröffentlichen Sie ihn unter _dmarc.yourdomain.com, beginnend mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none ist reiner Monitor-Modus, wirkt sich also nicht auf die Zustellung aus, während Sie bestätigen, dass Postmark-Post besteht. Beobachten Sie die aggregierten (rua-)Berichte ein bis zwei Wochen lang: Mit verifiziertem DKIM sehen Sie Postmark als DKIM-ausgerichtet und bestehend gelistet, und sobald der benutzerdefinierte pm-bounces-Return-Path eingerichtet ist, wird auch SPF als ausgerichtet angezeigt. Erst nachdem Postmark (und jeder andere legitime Absender) ausgerichtet besteht, sollten Sie auf p=quarantine und schließlich p=reject verschärfen. Beachten Sie die Wechselwirkung, auf die Postmark selbst hinweist: Wenn Ihre Domain auf p=quarantine/reject steht und Sie den benutzerdefinierten Return-Path auslassen, ist SPF nicht ausgerichtet – Sie würden sich allein auf DKIM-Ausrichtung verlassen, was funktioniert, Ihnen aber kein SPF-Fallback lässt; fügen Sie also den pm-bounces-CNAME hinzu.
Prüfen, ob es wirklich funktioniert hat
Verlassen Sie sich nicht allein auf die grünen "Verified"-Badges – bestätigen Sie es an einer echten Nachricht. Senden Sie sich über Postmark einen Test von einer Adresse auf Ihrer Domain, öffnen Sie ihn in Gmail und wählen Sie ⋮ → Original anzeigen: Sie möchten SPF: PASS und DKIM: PASS, beide mit yourdomain.com (nicht mtasv.net), plus DMARC: PASS sehen. Prüfen Sie die Return-Path-/mailed-by-Zeile – sie sollte pm-bounces.yourdomain.com lauten, was der Beweis dafür ist, dass Ihr benutzerdefinierter Return-Path seine Aufgabe erfüllt. Lieber ein Prüfbericht? Lassen Sie die Domain durch Qualisends Domain-Health-Check laufen, um zu bestätigen, dass der DKIM-TXT und der pm-bounces-CNAME auflösen, nutzen Sie den SPF-/DKIM-/DMARC-Checker für ein schnelles Auslesen der Records, und sobald die aggregierten DMARC-Berichte eintreffen, laden Sie einen in den DMARC-Berichtsanalysator – Postmark sollte dort als ausgerichtete, bestehende Quelle auftauchen.
Häufige Stolperfallen
- Bricht die Authentifizierung
Fügen Sie include:spf.mtasv.net nicht zu Ihrem Root-SPF hinzu. Postmark hat bewusst aufgehört, danach zu fragen – in Ihrem Apex bringt es für die Ausrichtung nichts, weil Ihre Root-Domain nicht der Return-Path ist, den Postmark verwendet. Fügen Sie stattdessen den benutzerdefinierten pm-bounces-Return-Path-CNAME hinzu.
- Abdeckung
Der include-Host ist spf.mtasv.net, nicht postmarkapp.com. MTASV ist Postmarks Domain für die Mail-Transfer-Infrastruktur; das Return-Path-Ziel (pm.mtasv.net) und dessen Bounce-MX liegen ebenfalls dort.
- DNS-Einrichtung
Die Subdomain pm-bounces muss ausschließlich ein CNAME sein. DNS erlaubt es nicht, dass ein CNAME mit einem anderen Record-Typ auf demselben Namen koexistiert; legen Sie also nicht zusätzlich einen TXT- oder A-Record auf pm-bounces.yourdomain.com an, sonst schlägt die Verifizierung fehl.
- DNS-Einrichtung
2048-Bit-DKIM-Werte sind lang. Manche DNS-Panels begrenzen einen TXT-String auf 255 Zeichen und verlangen, dass Sie den Schlüssel in mehrere Strings in Anführungszeichen aufteilen – teilen Sie ihn auf, lassen Sie keine Zeichen weg und fügen Sie keine überflüssigen Leerzeichen innerhalb des p=-Werts ein.
- DNS-Einrichtung
Setzen Sie den pm-bounces-CNAME bei Cloudflare auf DNS only (graue Wolke). Ein per Orange-Cloud proxied Record löst nicht auf pm.mtasv.net auf und die Return-Path-Verifizierung schlägt fehl.
- DNS-Einrichtung
Verdopplung des Host-Felds: Viele Registrare hängen Ihre Domain automatisch an, sodass die Eingabe von 20260727pm._domainkey.yourdomain.com zu …yourdomain.com.yourdomain.com wird. Geben Sie nur das Label (den Selector oder pm-bounces) ein, wenn das Panel die Domain für Sie ergänzt.
- Abdeckung
Eine einzelne bestätigte Sender Signature ist keine Domain-Authentifizierung – sie verifiziert eine From-Adresse, verschafft Ihnen aber keine DKIM-/SPF-Ausrichtung über die gesamte Domain. Verifizieren Sie die gesamte Domain (DKIM + Return-Path) im Tab Domains.
- Bricht die Authentifizierung
Behalten Sie genau einen SPF-TXT und einen _dmarc-TXT auf Ihrer Root. Wenn Sie auch über andere Anbieter versenden, mergen Sie deren Mechanismen in einen einzigen v=spf1-Record – zwei SPF-Records sind selbst ein PermError.
Erstellen Sie Ihren SPF-Eintrag
Postmark benötigt kein SPF-include: auf Ihrer Root-Domain — nutzen Sie den Generator, um für Ihre übrigen Absender einen sauberen Eintrag zusammenzustellen, und halten Sie ihn auf einer einzigen Zeile.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listPostmark SPF — FAQ
Weiterführende Lektüre
Sobald der Eintrag veröffentlicht ist, prüfen Sie mit dem Domain-Health-Check, ob alles korrekt aufgelöst wird, und lesen Sie mit der DMARC-Berichtsanalyse nach, wer in Ihrem Namen versendet. Durchsuchen Sie alle Versandquellen im Generator. Authentifizierung ist allerdings nur die halbe Zustellbarkeit — eine gelistete Absender-IP oder -Domain bringt Sie unabhängig davon, wie sauber Ihr SPF ist, im Spam-Ordner unter, deshalb lohnt es sich, mit Blacklist-Überwachung die Blacklists im Blick zu behalten.
Authentifiziert — jetzt die Liste sauber halten
SPF, DKIM und DMARC zu bestehen bringt Sie in den Posteingang; eine saubere Liste hält Sie dort. Verifizieren Sie Ihre — starten Sie kostenlos mit 100 Credits, ohne Kreditkarte.