E-Mail-Zustellbarkeit verstehen — SPF, DKIM, DMARC und warum Mails im Spam landen

Redaktion ·

Warum dich E-Mail-Zustellbarkeit angeht

Eine versendete Mail ist noch lange keine zugestellte Mail. Zwischen deinem „Senden”-Klick und dem Posteingang des Empfängers liegen mindestens drei Filterstufen, eine Reputation-Datenbank und ein paar DNS-Einträge, die entweder funktionieren oder nicht. Wenn nur einer der Bausteine wackelt, landet die Mail im Spam-Ordner — oder wird gleich kommentarlos verworfen. Der Absender bekommt davon nichts mit, der Empfänger sieht nichts, und das Geschäft, das an dieser Mail hing, passiert nicht.

Das Thema ist deshalb so undankbar, weil es kein einzelnes „Funktioniert”-Signal gibt. Es gibt nur viele kleine Indikatoren, die zusammen darüber entscheiden, ob du als legitimer Absender gelten oder im Rauschen untergehen. Wer die drei zentralen Authentifizierungs-Standards SPF, DKIM und DMARC versteht, hat den größten Teil verstanden. Der Rest sind Reputation, Listenhygiene und ein Setup, das man einmal richtig macht und dann in Ruhe lässt.

Dieser Artikel führt dich durch die Mechanik der Zustellung, die DNS-Einträge in der richtigen Reihenfolge, die typischen Stolperfallen und konkrete Szenarien — vom ersten Newsletter bis zur transaktionalen Mail aus deiner App.

Die Grundmechanik: Wie eine Mail zugestellt wird

Eine E-Mail reist über SMTP (Simple Mail Transfer Protocol) von einem Mailserver zum nächsten. Der entscheidende Punkt: Auf dem Weg gibt es keinerlei eingebaute Identitätsprüfung. SMTP wurde Anfang der 80er entworfen, als das Internet noch ein vertrauensvoller Ort unter Universitäten war. Jeder Server kann behaupten, im Namen jeder Domain zu schreiben — und genau das machen Spammer seit den 90ern.

Die heutige E-Mail-Welt hat deshalb drei Authentifizierungs-Schichten obendrauf gebaut, die per DNS überprüfen, ob ein Server berechtigt ist, im Namen einer Domain zu senden. Empfänger-Server (Gmail, Outlook, iCloud, große Mail-Provider) prüfen diese Schichten bei jeder eingehenden Mail und fällen daraus eine Entscheidung: Inbox, Spam, oder verworfen.

Die drei Filterstufen beim Empfänger

Wenn eine Mail bei Gmail ankommt, läuft sie grob durch drei Stufen.

Erste Stufe: Authentifizierung. SPF, DKIM und DMARC werden geprüft. Schlägt DMARC fehl und die Domain hat eine reject-Policy gesetzt, ist die Mail an dieser Stelle weg. Niemand sieht sie, der Absender bekommt eine Bounce-Meldung — oder auch nicht.

Zweite Stufe: Reputation. Der Empfänger prüft, ob die sendende IP-Adresse und die sendende Domain bekannt sind und welchen Ruf sie haben. Hier zählt Geschichte: Wie viele Mails kamen von hier, wie oft wurden sie als Spam markiert, wie oft gelöscht ohne Öffnen, wie oft beantwortet. Diese Reputation wird pro Empfänger-Provider geführt — Gmail vertraut dir nicht, nur weil Outlook dir vertraut.

Dritte Stufe: Inhalt. Erst wenn die ersten beiden Stufen sauber sind, schaut der Filter wirklich auf den Inhalt. Spam-Wörter, ungewöhnliche Link-Strukturen, irreführende Header — das spielt eine Rolle, ist aber nachrangig. Eine technisch saubere Mail von einem Absender mit guter Reputation kommt durch, auch wenn sie das Wort „Gewinn” enthält.

SPF — wer darf in deinem Namen senden

SPF (Sender Policy Framework) ist die älteste der drei Schichten. Per TXT-Eintrag im DNS deiner Domain veröffentlichst du eine Liste der Server, die berechtigt sind, Mails mit deiner Domain im Absender zu verschicken. Der empfangende Server holt diesen Eintrag und vergleicht ihn mit der IP-Adresse des einliefernden Servers.

Ein typischer SPF-Eintrag sieht so aus:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all

Übersetzt: Berechtigt sind alle Server, die im SPF von Google Workspace stehen, alle Server von Sendgrid, plus die einzelne IP 203.0.113.5. Alle anderen sollen die Mail ablehnen (-all = hard fail).

Stolperfalle: das 10-Lookup-Limit

SPF erlaubt maximal 10 DNS-Lookups pro Auswertung. Jeder include: zählt — und kann selbst weitere Includes enthalten. Wer seine Mails über fünf verschiedene Dienste versendet (Newsletter, Transaktional, CRM, Helpdesk, Marketing), reißt das Limit schnell. Folge: SPF-Auswertung scheitert mit permerror, alle Mails werden behandelt, als hätten sie keinen SPF-Eintrag.

Lösung: SPF-Flattening (Tools wie EasyDMARC oder Cloudflare lösen Includes auf statische IP-Listen auf) oder bewusste Konsolidierung der Sende-Dienste.

Stolperfalle: SPF überlebt Weiterleitungen nicht

Wenn ein Empfänger eine Mail an seine eigene Adresse weiterleitet (z. B. info@firma.dechef@gmail.com), wechselt der einliefernde Server. Die ursprüngliche IP ist nicht mehr im SPF des Absenders. Folge: SPF-Fail. Genau hier rettet DKIM die Mail.

DKIM — die kryptografische Signatur

DKIM (DomainKeys Identified Mail) signiert jede Mail kryptografisch. Der versendende Server berechnet einen Hash über bestimmte Header und den Body und signiert ihn mit einem privaten Schlüssel. Den passenden öffentlichen Schlüssel veröffentlicht der Domain-Inhaber im DNS — als TXT-Eintrag unter einem Selektor wie s1._domainkey.deinedomain.de.

Der empfangende Server holt den öffentlichen Schlüssel, verifiziert die Signatur und weiß damit zwei Dinge: Erstens, die Mail wurde tatsächlich von einem Server signiert, der den privaten Schlüssel der Domain hat. Zweitens, die signierten Inhalte wurden seit dem Versand nicht verändert.

Im Gegensatz zu SPF überlebt DKIM Weiterleitungen — die Signatur reist mit der Mail mit. Das ist der Hauptgrund, warum DKIM heute der wichtigere der beiden klassischen Standards ist.

Praxis: Selektor pro Dienst

Jeder Versand-Dienst (Google Workspace, Sendgrid, Mailgun, dein eigener Server) bekommt typischerweise einen eigenen Selektor und damit einen eigenen DNS-Eintrag. Beispiel: google._domainkey.deinedomain.de für Workspace, s1._domainkey.deinedomain.de für Sendgrid. Vorteil: Du kannst einzelne Dienste unabhängig rotieren oder abklemmen, ohne die anderen zu stören.

DMARC — die Klammer um SPF und DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist die Policy-Schicht über SPF und DKIM. Sie sagt empfangenden Servern drei Dinge:

  1. Was tun, wenn weder SPF noch DKIM bestätigen, dass die Mail aus deiner Domain stammt — none (nichts), quarantine (Spam-Ordner), reject (verwerfen).
  2. Wohin die Reports schicken — täglich aggregierte Berichte, wer in deinem Namen sendet und ob die Authentifizierung funktioniert.
  3. Wie streng “Alignment” geprüft wird — die Domain im SPF/DKIM muss zur Domain im sichtbaren From:-Header passen.

Ein DMARC-Eintrag liegt unter _dmarc.deinedomain.de und sieht so aus:

v=DMARC1; p=quarantine; rua=mailto:dmarc@deinedomain.de; pct=100; adkim=r; aspf=r

Der Alignment-Punkt — oft übersehen

DMARC besteht eine Mail nur, wenn mindestens eine der beiden Prüfungen funktioniert UND ausgerichtet ist:

  • SPF passt UND die Domain im Return-Path matched die From:-Domain (SPF-Alignment)
  • ODER DKIM passt UND die signierende Domain matched die From:-Domain (DKIM-Alignment)

Viele Newsletter-Tools senden technisch SPF-konform — aber mit ihrer eigenen Domain im Return-Path. SPF besteht, Alignment scheitert, DMARC scheitert. Lösung: Custom Return-Path / Custom DKIM-Domain auf deiner eigenen Domain einrichten (Mailchimp, Sendgrid und Co. bieten das alle an).

Setup-Reihenfolge: nicht mit reject anfangen

Eine harte DMARC-Policy ohne Vorlauf ist der schnellste Weg, eigene legitime Mails zu blockieren. Empfohlene Reihenfolge:

  1. Woche 1–2: p=none; rua=... — sammelt Reports, blockt nichts. Schau in die Reports, finde alle Dienste, die in deinem Namen senden, richte für jeden SPF/DKIM ein.
  2. Woche 3–6: p=quarantine; pct=10 — zehn Prozent der nicht-authentifizierten Mails landen im Spam. Beobachte die Berichte und Beschwerden.
  3. Woche 7+: schrittweise auf pct=100, dann p=reject.

BIMI — das Logo neben dem Absender

BIMI (Brand Indicators for Message Identification) ist die jüngste Schicht und betrifft nicht die Zustellung, sondern die Darstellung. Wer eine starke DMARC-Policy (quarantine oder reject) hat und sein Markenlogo als spezielles SVG im DNS hinterlegt, bekommt das Logo direkt neben dem Absender im Posteingang angezeigt — bei Gmail, Apple Mail, Yahoo und einigen anderen.

Der Effekt: höhere Wiedererkennung, mehr Vertrauen, in Tests typischerweise 5–15 % höhere Öffnungsraten. Aufwand: ein VMC-Zertifikat (Verified Mark Certificate), das jährlich rund 1.500 Euro kostet, plus eine SVG-Datei in einem sehr restriktiven Subset (SVG Tiny PS).

BIMI lohnt sich für Marken mit hohem Mailvolumen und erkennbarem Logo. Für eine Drei-Personen-Agentur ist es eher Vanity als ROI.

Reputation und IP-Warmup

Authentifizierung ist die Eintrittskarte — Reputation entscheidet, ob du in die Inbox darfst oder im Spam landest. Die Empfänger-Provider führen interne Scores für jede sendende IP-Adresse und jede sendende Domain. Bewertet werden:

  • Volumen-Konstanz. Plötzlich von 100 auf 10.000 Mails pro Tag zu springen ist verdächtig. Spammer machen das.
  • Engagement. Wie viele Empfänger öffnen, lesen, antworten? Wie viele markieren als Spam, löschen ungelesen?
  • Bounce-Rate. Hoher Anteil an unzustellbaren Adressen ist ein klares Spam-Signal — Spammer haben oft alte Datenleak-Listen.
  • Spam-Traps. Speziell platzierte Adressen, die niemals jemand abonniert haben sollte. Wer die anschreibt, hat seine Liste schlecht gepflegt oder gekauft.
  • Beschwerderate. Klicks auf „Als Spam markieren” — über 0,3 % gilt als Warnsignal, über 0,5 % als rote Linie.

IP-Warmup — die ersten Wochen sind entscheidend

Wer mit einer neuen IP oder neuen Domain startet, hat keine Reputation. Empfänger behandeln das als „erstmal misstrauisch” — und das zu Recht. Lösung: schrittweises Hochfahren des Volumens.

Typischer Plan: Tag 1 — 50 Mails an die engagiertesten Empfänger. Tag 2 — 100. Tag 3 — 200. Verdopplung alle ein bis zwei Tage. Dabei nur an Adressen senden, von denen man weiß, dass sie öffnen und reagieren. Schlechte Adressen (alte, nie geöffnet, alte Bounces) bleiben in den ersten vier Wochen außen vor — der frühe Eindruck zählt überproportional.

Bei dedizierten IPs für Newsletter-Versand dauert ein vollständiger Warmup vier bis acht Wochen. Wer das überspringt, brennt die IP an und braucht Monate, um die Reputation zurückzugewinnen.

Listenhygiene — Bounce-Rate und Spam-Traps

Eine saubere Liste ist nicht „nice to have”, sie ist Reputations-relevant. Drei Mechaniken bestimmen die Listenqualität.

Bounces sind unzustellbare Adressen. Hard Bounce (Adresse existiert nicht) muss sofort und dauerhaft aus der Liste raus. Soft Bounce (Mailbox voll, temporär) darf zwei bis drei Mal probieren, dann ebenfalls raus. Eine Bounce-Rate über 2 % ist auffällig, über 5 % wird kritisch.

Spam-Traps sind Adressen, die ausschließlich existieren, um Spammer zu fangen. Es gibt zwei Arten: Pristine Traps wurden nie aktiv genutzt — wer die anschreibt, hat seine Liste gekauft oder gescraped. Recycled Traps sind alte, längst aufgegebene Adressen, die ein Provider nach Jahren reaktiviert hat — wer die anschreibt, pflegt seine Liste nicht.

Engagement-Hygiene ist die freiwillige Variante: regelmäßig Empfänger entfernen, die seit sechs oder zwölf Monaten nichts mehr geöffnet haben. Klingt schmerzhaft, ist aber gesund. Inaktive Empfänger ziehen die Engagement-Rate runter und schwächen die Reputation für die aktiven.

Setup-Reihenfolge in der Praxis

Wer eine neue Domain für Mailversand aufsetzt, geht in dieser Reihenfolge vor:

  1. MX-Eintrag — wo Mails an die Domain hingeschickt werden sollen (Google Workspace, eigener Server, Mailgun-Empfang etc.).
  2. SPF-Eintrag — alle berechtigten Sende-Dienste eintragen, mit ~all (soft fail) für den Anfang, später -all.
  3. DKIM-Schlüssel — bei jedem Sende-Dienst aktivieren, die vom Dienst gelieferten Selektoren als TXT-Einträge im DNS anlegen.
  4. DMARC — mit p=none; rua=... starten, Reports zwei Wochen sammeln.
  5. DMARC verschärfen — schrittweise auf quarantine, dann reject.
  6. Optional: BIMI — wenn DMARC auf quarantine/reject und Markenpflege wichtig.

Zwischen Schritt 4 und 5 liegen die echten Erkenntnisse: Welche Dienste senden in deinem Namen, von denen du nichts wusstest? Typische Funde sind altes Helpdesk-Tool, vergessenes Newsletter-Konto vom Vorgänger, ein Server der Marketing-Agentur. Erst wenn das alle sauber authentifiziert ist, hält DMARC reject wirklich.

Drei typische Szenarien

Szenario 1: Newsletter aus Mailchimp, alles wirkt sauber, trotzdem Spam

DNS-Check zeigt: SPF und DKIM grün, DMARC p=none gesetzt. In den DMARC-Reports steht: SPF passt (Mailchimp-Domain), DKIM passt (Mailchimp-Selektor) — aber Alignment scheitert. Die From:-Domain ist firma.de, signiert ist mail.mailchimp.com. DMARC bewertet das als unausgerichtet, Gmail wird vorsichtig.

Lösung: Im Mailchimp-Account „Domain Authentication” einrichten, dadurch wird DKIM mit firma.de signiert. SPF muss zusätzlich include:servers.mcsv.net enthalten. Nach 24 Stunden meist sichtbarer Sprung in der Inbox-Quote.

Szenario 2: Transaktionale Mails aus eigener App landen im Spam

App schickt direkt über sendmail vom Web-Server. SPF kennt diese IP nicht (steht nicht im DNS), DKIM gibt es gar nicht. Empfänger-Provider sehen: keine Authentifizierung, IP einer Hosting-Plattform — Spam-Verdacht hoch.

Lösung: nicht über den Web-Server senden. Stattdessen einen Transactional-Provider (Postmark, Sendgrid, Mailgun, Amazon SES) einbinden, dort Domain authentifizieren (SPF + DKIM), Mails über deren API verschicken. Der Provider hat eine etablierte IP-Reputation und korrekte Authentifizierung. Aufwand: ein Nachmittag.

Szenario 3: DMARC-Report zeigt unbekannte Sender

Im wöchentlichen Report taucht eine IP aus Russland auf, die in deinem Namen sendet — und scheitert an SPF und DKIM. Erste Reaktion: Panik. Realistische Diagnose: jemand spoofed deine Domain. Das passiert ständig, vor allem bei bekannten Marken.

DMARC mit p=reject löst genau dieses Problem. Die gespooften Mails kommen nicht durch, dein Markenruf bleibt sauber. Die Reports zeigen weiter, dass jemand es versucht — das ist informativ, nicht alarmierend.

FAQ

Wie lange dauert ein DNS-Eintrag, bis er wirkt?
Der Eintrag selbst ist binnen Minuten bei den meisten DNS-Providern aktiv. Der TTL (Time-to-live) bestimmt, wie lange Caches alte Werte halten — typisch 1–24 Stunden. Vor wichtigen Änderungen TTL temporär auf 5 Minuten setzen, dann ändern, dann wieder hochsetzen.
Reicht SPF allein nicht?
Nein. SPF überlebt keine Weiterleitungen, deckt nur den Envelope-Sender (Return-Path) ab und bietet keine Inhaltsintegrität. DKIM ergänzt beides. Beides zusammen ist Pflicht für DMARC.
Brauche ich eine eigene IP für Mailversand?
Erst ab etwa 100.000 Mails pro Monat sinnvoll. Darunter ist die geteilte Reputation eines etablierten Providers besser als deine eigene IP, die du erst warmlaufen müsstest.
Was tun, wenn meine Domain auf einer Blocklist landet?
Erstmal prüfen welche Liste — Spamhaus, SORBS, Barracuda haben unterschiedliche Listen und unterschiedliche Delisting-Prozesse. Ursache finden (kompromittiertes Postfach? gehackte Form? gekaufte Liste?), beheben, dann beim Listen-Betreiber Delisting beantragen.
Wie messe ich Zustellbarkeit ohne Spezial-Tool?
Saatlisten („Seed Lists") über GlockApps, Mailtrap o. ä. Eine Versendung an deren Test-Adressen zeigt pro Provider, ob die Mail in der Inbox, im Spam oder gar nicht ankommt. Kostet 30–80 Euro pro Monat und gibt klare Diagnose.

Fazit

E-Mail-Zustellbarkeit ist kein Marketing-Thema, sondern ein Infrastruktur-Thema. Wer SPF, DKIM und DMARC einmal sauber aufsetzt — mit dem stufenweisen DMARC-Rollout — hat 80 % der Hürden hinter sich. Der Rest ist Listenhygiene und Volumen-Konstanz.

Die häufigsten Fehler: zu schnell auf p=reject springen, Mails über den eigenen Web-Server statt über einen Transactional-Provider verschicken, Domain-Alignment in Newsletter-Tools nicht einrichten. Alle drei sind innerhalb eines Nachmittags behebbar — vorausgesetzt, man weiß, wonach man sucht.

Wer transaktional und marketing-mäßig viel sendet, sollte die DMARC-Reports einmal pro Woche überfliegen. Tools wie Postmark, EasyDMARC oder Valimail Monitor parsen die XML-Berichte in lesbare Dashboards. Das ist die einzige laufende Pflege, die das Setup wirklich braucht.

Themenuebersicht