SPF, DKIM und DMARC: So kommen eure E-Mails im Posteingang an
Kurze Zusammenfassung
| Methode | Bildlich gesprochen | Wozu es da ist |
|---|---|---|
| SPF | Eine Liste der Versanddienste, die in eurem Namen Post aufgeben dürfen. | Beantwortet die Frage: Darf dieser Server E-Mails für diese Domain verschicken? |
| DKIM | Ein Siegel, das der Absender auf jede Nachricht drückt. | Beantwortet die Frage: Hat diese Domain die Mail signiert, und ist sie unterwegs unverändert geblieben? |
| DMARC | Eure Hausordnung für alle Empfänger. | Beantwortet die Frage: Passt das zum sichtbaren Absender, und was passiert, wenn nicht? Dazu kommen regelmäßige Berichte. |
Fehlt einer dieser Bausteine oder ist das Newsletter-Tool nicht richtig angebunden, landen Mails im Spam oder werden abgewiesen. Seit 2024 setzen Google und Yahoo diese Regeln für Massenversender verbindlich durch, seit 2025 auch Microsoft. Was mit abgewiesenen Kontakten passiert und wie ihr sie zurückholt, zeigt unser Praxisbeitrag zu Hard Bounces.
Worum es geht
Jede Newsletter-Anmeldung hat einen Preis. Hinter ihr stecken Content, Kampagnenbudget, Messeauftritte und Formulare, die erst einmal jemand ausfüllen muss. Genau diese Kontakte sind es, die man am wenigsten verlieren möchte.
Trotzdem landen Mails im Spam-Ordner oder werden abgewiesen – häufig aus einem technischen Grund: Die Domain weist nicht sauber nach, dass die Mail wirklich von ihr stammt. In diesem Beitrag schauen wir unter die Haube. Jeder Abschnitt beginnt mit einer einfachen Erklärung ohne Fachbegriffe, darunter folgen unter „Technisch im Detail“ die Einzelheiten – so genau, wie eure IT-Abteilung sie wissen will.
Das Fundament: DNS als öffentliches Register eurer Domain
Einfach erklärt: Jede Domain hat einen öffentlichen Steckbrief. Darin steht, wohin E-Mails für euch zugestellt werden und welche Dienste in eurem Namen E-Mails verschicken dürfen. Gepflegt wird dieser Steckbrief dort, wo eure Domain verwaltet wird, also bei Anbietern wie IONOS, Strato, All-Inkl, Hetzner, GoDaddy, Cloudflare oder AWS. Zugang hat dort meist die IT oder ein externer Dienstleister, selten das Marketing. Genau deshalb bleibt das Thema oft zwischen den Abteilungen liegen.
Technisch im Detail
Das Domain Name System (DNS) ist das Telefonbuch des Internets. Es übersetzt nicht nur Namen wie eure-firma.de in IP-Adressen, sondern ist auch das öffentliche Register, in dem eine Domain festlegt, wie mit ihr umzugehen ist. Für E-Mail sind vor allem diese Einträge relevant:
| DNS-Eintrag | Beispiel | Wozu es da ist |
|---|---|---|
| MX | eure-firma.de MX 10 eure-firma-de.mail.protection.outlook.com | Wohin Mails an eure Domain zugestellt werden |
| TXT (SPF) | v=spf1 include:spf.protection.outlook.com -all | Welche Server in eurem Namen senden dürfen |
| TXT (DKIM) | selector1._domainkey.eure-firma.de | Öffentlicher Schlüssel zur Prüfung digitaler Signaturen |
| TXT (DMARC) | _dmarc.eure-firma.de | Eure Regel, was bei fehlgeschlagener Prüfung passieren soll |
| CNAME | em123.eure-firma.de → Newsletter-Anbieter | Verweise, über die Dienstleister eure Domain nutzen dürfen |
Diese Einträge müssen öffentlich sein, sonst könnte kein Empfänger sie prüfen. Das hat eine Kehrseite: Wer euren SPF-Eintrag liest, sieht sofort, welche Cloud-Dienste, CRM-Systeme und Versandtools ihr nutzt. Angreifer nutzen genau diese Information gern als ersten Schritt, etwa für glaubwürdige Phishing-Mails im Stil eures echten Dienstleisters.
Die praktische Konsequenz ist keine Geheimhaltung, sondern Hygiene. Dienste, die ihr nicht mehr nutzt, gehören raus aus dem DNS. Ein Altlast-Eintrag für ein gekündigtes Tool erlaubt diesem Anbieter weiterhin, Mails in eurem Namen zu verschicken – und kostet bei SPF auch noch wertvolle Abfragen.
Wo die Einträge wirklich gepflegt werden
Einfach erklärt: Wo ihr eure Domain gekauft habt, ist nicht automatisch der Ort, an dem ihr ihre Einträge ändert. Entscheidend ist, wer die Domain verwaltet – die sogenannten Nameserver. Liegt die Domain bei IONOS, die Nameserver aber bei Cloudflare, bewirkt eine Änderung bei IONOS nichts.
Technisch im Detail: Maßgeblich ist die Zone auf den autoritativen Nameservern, die im NS-Eintrag der Domain stehen. Prüfen lässt sich das etwa mit dig NS eure-firma.de oder einem Online-DNS-Check. Ziehen die Nameserver um, zum Beispiel zu einem CDN, müssen alle Mail-Einträge mit umziehen. Wie ein Browser über Resolver, Root- und TLD-Server die Nameserver einer Domain findet, erklären wir in unserem Beitrag Was ist ein CDN?.
Domain und Subdomain: Was gilt wo?
Einfach erklärt: news.eure-firma.de ist für das DNS eine eigene Adresse mit eigenem Steckbrief. Manche Regeln gelten trotzdem automatisch auch für sie, andere nicht.
- SPF wird nicht vererbt. Jede Subdomain, die als Envelope-Absender auftritt, braucht einen eigenen SPF-Eintrag.
- DKIM hängt am Selector der signierenden Domain (
selector._domainkey.domain). Jedes Versandtool bekommt seinen eigenen Selector. - DMARC wird vererbt. Hat eine Subdomain keinen eigenen
_dmarc-Eintrag, gilt die Policy der Hauptdomain. Mitsp=legt ihr für Subdomains eine abweichende Policy fest. - Für das Alignment zählt die Organisationsdomain (im Standardmodus relaxed). Deshalb passt bounce.eure-firma.de zu eure-firma.de.
Zwei Stolperfallen beim Ändern
Einfach erklärt: Pro Domain gibt es genau eine Gästeliste. Wer für ein neues Tool einfach eine zweite anlegt, macht beide ungültig. Und Änderungen wirken nicht sofort überall.
Technisch im Detail: Stehen zwei TXT-Einträge mit v=spf1 im DNS, endet die Prüfung mit einem PermError. Neue Dienste kommen deshalb als zusätzliches include: in den bestehenden Eintrag. Jeder Eintrag hat eine TTL (Time to Live), die festlegt, wie lange Resolver ihn zwischenspeichern – bis eine Änderung überall wirkt, können Minuten bis Stunden vergehen. Das Reverse-DNS (PTR) der sendenden IP-Adresse, das Google voraussetzt, pflegt übrigens nicht ihr in eurer Domain, sondern der Betreiber des Mailservers oder Versanddienstes.
Der Schlüssel zum Verständnis: Jede E-Mail hat zwei Absender
Technisch im Detail
Die meisten Erklärungen zu SPF, DKIM und DMARC lassen den wichtigsten Punkt weg: Eine E-Mail trägt technisch zwei Absenderadressen, die nicht identisch sein müssen.
- Envelope-Absender (Return-Path, MAIL FROM): die Adresse auf dem „Briefumschlag“, die die Server untereinander austauschen. An sie gehen Bounce-Meldungen. Der Empfänger sieht sie normalerweise nicht.
- Header-From: die Adresse, die im Postfach als Absender angezeigt wird, also z. B. newsletter@eure-firma.de.
Versendet ein Newsletter-Tool in eurem Namen, steht im Header-From eure Domain. Im Envelope steht ab Werk aber oft eine Domain des Anbieters, weil er die Bounces selbst verarbeitet. Genau an dieser Stelle entscheidet sich später, ob DMARC besteht. Die Grafik zeigt, welche Prüfung sich auf welche Adresse bezieht.
SPF: Die Gästeliste der sendenden Server
Einfach erklärt: SPF ist eine Gästeliste. Ihr hinterlegt öffentlich, welche Systeme in eurem Namen E-Mails verschicken dürfen, etwa euer Microsoft 365, euer CRM und euer Newsletter-Tool. Kommt eine Mail von einem System, das nicht auf der Liste steht, wird der Empfänger misstrauisch. Der Haken: Die Liste darf nicht beliebig lang werden. Ab einer bestimmten Größe bricht der Empfänger die Prüfung ab – dann gilt die Mail als nicht geprüft, auch wenn sie eigentlich in Ordnung war.
Technisch im Detail
SPF (Sender Policy Framework) beantwortet eine Frage: Darf der Server, der gerade einliefert, für diese Domain senden? Geprüft wird dabei die Domain im Envelope-Absender, nicht die im Postfach angezeigte. Im DNS steht dafür ein TXT-Eintrag, zum Beispiel:
Der Empfänger arbeitet die Liste von links nach rechts ab. include: verweist auf die Liste eines Dienstleisters, ip4: erlaubt eine konkrete Adresse. Am Ende steht, was mit allen anderen Servern passiert: -all heißt „nicht erlaubt“ (Fail), ~all heißt „verdächtig“ (Softfail).
Die technische Tücke: das 10-Lookup-Limit. Die SPF-Spezifikation (RFC 7208) erlaubt bei einer Prüfung höchstens 10 DNS-Abfragen für Mechanismen wie include, a, mx und redirect. Verschachtelte Includes der Anbieter zählen mit. Das Limit soll verhindern, dass SPF-Prüfungen für Angriffe auf DNS-Server missbraucht werden. Wird es überschritten, endet die Prüfung mit einem dauerhaften Fehler (PermError), und SPF gilt als nicht bestanden – auch für eigentlich erlaubte Server.
In der Praxis passiert das schleichend. Office 365, ein CRM, ein Ticketsystem, ein Newsletter-Tool, ein Rechnungsdienst: Jeder neue Dienst bringt ein Include mit, oft mit weiteren Abfragen dahinter. Niemand merkt, wann die elfte Abfrage dazukommt.
Zwei weitere Grenzen von SPF sollte man kennen. Bei Weiterleitungen bricht SPF, weil der weiterleitende Server nicht auf eurer Liste steht. Viele Mailserver schreiben den Umschlag deshalb per SRS (Sender Rewriting Scheme) auf ihre eigene Domain um – dann besteht SPF zwar wieder, aber für die Domain des Weiterleiters, sodass für DMARC weiterhin das Alignment fehlt. Außerdem prüft SPF nur den Envelope. Allein schützt SPF die sichtbare Absenderadresse also nicht.
DKIM: Das digitale Siegel auf der Nachricht
Einfach erklärt: DKIM funktioniert wie ein Wachssiegel auf einem Brief. Das Versandsystem drückt beim Absenden ein Siegel auf jede Mail. Den passenden Musterabdruck hinterlegt ihr öffentlich bei eurem Domain-Anbieter. Der Empfänger vergleicht beides: Ist das Siegel echt und unversehrt, wurde die Mail unterwegs nicht verändert. Wichtig ist, wessen Siegel auf dem Brief ist. Viele Newsletter-Tools verwenden ab Werk ihr eigenes Siegel statt eures – die Mail ist dann zwar versiegelt, aber nicht mit eurem Firmensiegel.
Technisch im Detail
DKIM (DomainKeys Identified Mail) beantwortet eine andere Frage: Welche Domain übernimmt Verantwortung für diese Nachricht, und wurde sie unterwegs verändert? Dafür kommt asymmetrische Kryptografie zum Einsatz, also ein Schlüsselpaar aus einem geheimen Schlüssel zum Signieren und einem öffentlichen zum Prüfen.
- Das Versandsystem berechnet beim Absenden eine Prüfsumme über den Inhalt und ausgewählte Header-Felder (u. a. From, Subject, Date) und signiert sie mit dem privaten Schlüssel.
- Die Signatur steht im Header
DKIM-Signature. Darin stehen unter anderem die signierende Domain (d=eure-firma.de) und ein Selector (s=nl2026). - Der Empfänger fragt im DNS
nl2026._domainkey.eure-firma.deab, holt den öffentlichen Schlüssel und prüft die Signatur. - Passt alles, ist belegt: Die Domain aus
d=hat diese Nachricht signiert, und die signierten Teile sind unverändert.
Wichtig ist die genaue Aussage. DKIM belegt die Verantwortung der signierenden Domain. Ob das eure Domain ist, hängt vom Setup ab: Viele Newsletter-Tools signieren ab Werk mit ihrer eigenen Domain. Die Signatur ist dann gültig, sagt aber nichts über eure Domain aus.
Anders als SPF übersteht DKIM in der Regel Weiterleitungen, solange die signierten Teile nicht verändert werden. Deshalb ist DKIM für DMARC meist die verlässlichere der beiden Säulen. Schlüssel sollten mindestens 2048 Bit lang sein und gelegentlich rotiert werden.
DMARC: Die Klammer um SPF und DKIM
Einfach erklärt: Gästeliste und Siegel nützen nur etwas, wenn sie zu dem Namen passen, der im Briefkopf steht. DMARC prüft genau das und ist zugleich eure Hausordnung für alle Empfänger: Ihr legt darin fest, was mit Mails passieren soll, die angeblich von euch kommen, die Prüfung aber nicht bestehen – trotzdem zustellen, in den Spam-Ordner verschieben oder ablehnen. Als Bonus bekommt ihr regelmäßig Berichte, die zeigen, wer weltweit Mails mit eurem Absender verschickt – eure eigenen Systeme ebenso wie Betrüger.
Technisch im Detail
DMARC (Domain-based Message Authentication, Reporting and Conformance) schließt die Lücke, die SPF und DKIM allein offenlassen. Es bezieht beide Prüfungen auf die Adresse, die der Mensch tatsächlich sieht: das Header-From. Alignment ist der Kern. Eine Mail besteht DMARC, wenn mindestens eine der beiden Bedingungen erfüllt ist:
- SPF besteht und die Envelope-Domain passt zur From-Domain, oder
- DKIM besteht und die Signatur-Domain (
d=) passt zur From-Domain.
Eine der beiden Säulen reicht. DMARC schlägt also erst fehl, wenn beide keine passende, bestandene Prüfung liefern. „Passt“ bedeutet im Standardmodus (relaxed), dass die Organisationsdomain gleich ist: bounce.eure-firma.de passt zu eure-firma.de, mailer.anbieter.com nicht.
Probiert es aus: Besteht diese Mail DMARC?
Wählt ein Szenario oder stellt die Werte selbst ein. Der Absender im Postfach ist immer news@eure-firma.de.
Vereinfachte Darstellung: Die Organisationsdomain wird hier aus den letzten beiden Teilen der Domain gebildet.
Die Policy legt fest, was bei einem Fehlschlag passieren soll. Ein DMARC-Eintrag sieht zum Beispiel so aus:
| Policy | Bitte an den Empfänger | Typischer Einsatz |
|---|---|---|
| p=none | Normal zustellen, nur berichten | Start: erst einmal sehen, wer in eurem Namen sendet |
| p=quarantine | Als verdächtig behandeln, meist Spam-Ordner | Zwischenschritt, wenn alle legitimen Quellen bestehen |
| p=reject | Annahme verweigern | Ziel: Fremde können eure Domain nicht mehr fälschen |
Die Policy ist eine Bitte, keine Garantie. Große Anbieter halten sich in aller Regel daran, entscheiden am Ende aber selbst.
Die Berichte sind der unterbewertete Teil. Über rua= schicken Empfänger wie Google, Microsoft oder Yahoo täglich aggregierte XML-Berichte. Darin steht, von welchen IP-Adressen Mails mit eurer Domain kamen und ob SPF, DKIM und Alignment bestanden haben. So findet ihr vergessene Versandquellen und Fälschungsversuche gleichermaßen.
Der Weg zu p=reject führt über Daten, nicht über Mut. Zuerst p=none setzen und die Berichte einige Wochen auswerten. Dann jede legitime Quelle authentifizieren, also Office 365, CRM, Newsletter-Tool, Ticketsystem und Buchhaltung. Erst danach über quarantine zu reject verschärfen. Wer ohne Auswertung direkt auf reject geht, blockiert im Zweifel seine eigenen Rechnungsmails.
Was passiert, wenn DMARC scheitert und Kontakte als Hard Bounce gesperrt werden, zeigt unser Praxisbeitrag zu Hard Bounces.
Newsletter-Tools: Warum der Bestätigungslink im Tool nicht reicht
Einfach erklärt: Ab Werk verschicken viele Newsletter-Tools eure Mails mit ihrem eigenen Umschlag und ihrem eigenen Siegel. Im Briefkopf steht zwar euer Name, aber nichts anderes an der Mail gehört zu euch. Für den Empfänger sieht das aus, als schreibe ein Fremder in eurem Namen. Die Lösung ist kein Toolwechsel: Das Tool bekommt euren Umschlag und euer Siegel, eingerichtet über einige Einträge bei eurem Domain-Anbieter.
Technisch im Detail
| Prüfung | Ergebnis | Passt zur From-Domain? |
|---|---|---|
| SPF | bestanden für bounces.anbieter.com | nein |
| DKIM | bestanden für d=anbieter.com | nein |
| DMARC | nicht bestanden | – |
Beide technischen Prüfungen sind grün, und trotzdem scheitert DMARC, weil keine von beiden zu eurer Domain passt. Solange eure DMARC-Policy auf none steht, merkt ihr davon nichts. Sobald ihr verschärft oder ein Empfänger strengere Regeln anwendet, landen eure Newsletter im Spam oder werden abgewiesen.
Die Lösung bieten heute praktisch alle gängigen Tools, egal ob CleverReach, Brevo, Mailchimp, HubSpot, Salesforce Marketing Cloud oder Zoho Campaigns. Begriffe und Menüs unterscheiden sich, das Prinzip ist gleich:
- Eigene DKIM-Signatur: Das Tool signiert mit eurer Domain. Dafür legt ihr die vom Anbieter vorgegebenen CNAME- oder TXT-Einträge an.
- Eigene Return-Path-Domain (Custom Bounce Domain): Der Envelope läuft über eine Subdomain wie bounce.eure-firma.de, die per CNAME auf den Anbieter zeigt. Dann ist auch SPF aligned.
- SPF-Eintrag prüfen: nur die Includes, die wirklich nötig sind, und die Zahl der Lookups im Blick behalten.
- Eigene Subdomain für Marketing erwägen, etwa news.eure-firma.de. So bleibt die Reputation eurer Hauptdomain, über die Angebote und Rechnungen laufen, von Kampagnen-Effekten getrennt.
Das ist kein Hexenwerk, berührt aber in den meisten Unternehmen zwei Zuständigkeiten: Das Marketing bedient das Tool, die IT oder ein externer Dienstleister verwaltet das DNS. Genau zwischen diesen beiden bleibt das Thema häufig liegen.
Neuer Newsletter-Anbieter? SPF, DKIM und DMARC gehören zum Start
Die Spielregeln: Was Google, Yahoo und Microsoft heute verlangen
Einfach erklärt: Google, Yahoo und Microsoft sortieren den Großteil aller privaten Postfächer. Sie verlangen inzwischen von jedem, der regelmäßig viele Mails verschickt, drei Dinge: nachweisen, dass er wirklich der Absender ist, das Abmelden mit einem Klick ermöglichen und kaum Spam-Beschwerden auslösen. Wer das nicht erfüllt, landet im Spam-Ordner oder wird gar nicht erst angenommen.
Technisch im Detail
Seit Februar 2024 setzen Google und Yahoo verbindliche Anforderungen an Absender durch, Microsoft hat 2025 für seine Verbraucherpostfächer (Outlook.com, Hotmail, Live) nachgezogen. Inzwischen werden Verstöße nicht mehr nur in den Spam-Ordner sortiert, sondern zunehmend direkt abgewiesen. Die Regeln unterscheiden zwischen allen Absendern und Bulk-Sendern mit mehr als etwa 5.000 Mails pro Tag an den jeweiligen Anbieter.
| Anforderung | Alle Absender | Bulk-Sender (ab ca. 5.000 Mails/Tag an Gmail, Yahoo oder Outlook.com) |
|---|---|---|
| SPF und DKIM | SPF oder DKIM | SPF und DKIM |
| DMARC | empfohlen | Pflicht, mindestens p=none |
| Alignment | – | From-Domain passt zu SPF oder DKIM |
| Infrastruktur | gültiges Reverse-DNS (PTR: die IP des Servers führt zurück auf einen passenden Namen), TLS-verschlüsselte Verbindung | wie alle |
| Abmeldung | – | Abmelden mit einem Klick direkt im Postfach (One-Click-Unsubscribe nach RFC 8058), Umsetzung innerhalb von 2 Tagen |
| Beschwerderate | unter 0,3 % halten, Ziel unter 0,1 % | wie alle |
Zwei Punkte werden oft übersehen. Erstens zählt die 5.000er-Grenze pro Empfänger-Anbieter und über alle Systeme hinweg, die mit eurer Domain senden. Wer einmal darüber lag, wird dauerhaft als Bulk-Sender behandelt. Zweitens ist die Beschwerderate kein technischer, sondern ein inhaltlicher Wert: Mails, die niemand erwartet oder die sich schwer abbestellen lassen, treiben sie nach oben. Authentifizierung ist die Eintrittskarte, aber keine Garantie für den Posteingang.
Die Anforderungen werden laufend nachgeschärft. Vor einer Umstellung lohnt sich ein Blick in die aktuellen Absender-Richtlinien der Anbieter.
Häufige Fragen
Was ist der Unterschied zwischen SPF, DKIM und DMARC?
SPF legt fest, welche Server in eurem Namen senden dürfen. DKIM versieht jede Mail mit einer prüfbaren Signatur. DMARC prüft, ob eins von beidem zur sichtbaren Absenderadresse passt, und legt fest, was sonst passiert.
Brauche ich alle drei?
Ja. Wer täglich viele Mails an Gmail, Yahoo oder Outlook.com verschickt, muss alle drei einrichten. Für alle anderen sind sie dringend empfohlen.
Wie prüfe ich, ob meine Mails DMARC bestehen?
Was bedeutet das 10-Lookup-Limit bei SPF?
Eine SPF-Prüfung darf höchstens zehn DNS-Abfragen auslösen. Wer mehr Dienste einbindet, riskiert, dass SPF komplett scheitert – auch für eigentlich erlaubte Server.
Welche DMARC-Policy soll ich wählen?
Startet mit p=none, wertet die Berichte einige Wochen aus und verschärft dann über quarantine zu reject.
Quellen
Stand der Angaben: Oktober 2026. Die Anforderungen der Postfach-Anbieter werden laufend angepasst.
Fazit
Ob ein Newsletter im Posteingang ankommt, entscheidet sich zuerst im DNS: an einem SPF-Eintrag mit weniger als zehn Lookups, an einer DKIM-Signatur mit der eigenen Domain und an einer DMARC-Policy, die auf echten Berichten beruht. Erst danach zählen Inhalt und Relevanz.
Das Thema sitzt an der Schnittstelle von Marketing und IT – und genau dort arbeiten wir. Wenn ihr nicht sicher seid, ob euer DMARC wirklich besteht, lohnt sich ein Blick unter die Haube. Sprecht uns gern an.
Beitrag teilen
Besteht euer DMARC wirklich?
Wir prüfen SPF, DKIM und DMARC für alle Systeme, die in eurem Namen senden – vom Mailserver über das CRM bis zum Newsletter-Tool – und setzen die Korrekturen gemeinsam mit euch um.
- Prüfung aller Versandquellen und DNS-Einträge
- Auswertung eurer DMARC-Berichte
- Sicherer Weg zu p=reject
Ähnliche Inhalte
Vibe Coding im Unternehmen
Webseite erstellen lassen
SPF, DKIM und DMARC: So kommen eure E-Mails im Posteingang an
ChatGPT Ads Tracking
Know-How
Der Mehrwert moderner Visitenkarten
Eine Barrierefreiheit Webseite in der Gesetzgebung
Automatisierung im Vergleich
Styleguides im Webdesign
Unsere Leistungen
Digitale Geschäftsprozesse
IT-Sicherheit
Datenstrategie
Online Marketing
