E-Mail-Zustellbarkeit testen: Der vollständige Leitfaden vor dem Versand

⚡TL;DR

• Jede fünfte E-Mail erreicht nie den Posteingang, hauptsächlich wegen fehlender oder falsch konfigurierter SPF-, DKIM- oder DMARC-Authentifizierung
• Zustellbarkeits-Score: SPF (+25), DKIM (+25), DMARC (+20), MX/PTR (+15), Header (+15) = 100 mögliche Punkte
• Seit 2024: Gmail und Yahoo verlangen SPF + DKIM als Pflicht und DMARC für Massenversender (> 5.000 E-Mails/Tag)
• Prioritäre Korrektur: Ein 30-Sekunden-Test identifiziert die genauen Probleme, dieser Leitfaden erklärt Schritt für Schritt, wie du sie behebst

Du hast gerade eine E-Mail-Kampagne gestartet. Alles ist bereit: Der Inhalt ist sorgfältig formuliert, das Design ist einwandfrei, die Empfängerliste ist sauber. Drei Tage später kommen die Statistiken: 22 % deiner E-Mails haben den Posteingang nie erreicht. Keine Bounces. Keine sichtbaren Fehler. Deine Nachrichten sind einfach im Spam-Ordner verschwunden oder wurden vom Empfangsserver stillschweigend abgelehnt.

Dieses Szenario ist kein Extremfall. Laut den Daten von Validity (Sender Score) erreicht jede fünfte E-Mail weltweit nie den Posteingang des Empfängers. Für Unternehmen sind die Kosten direkt: ignorierte Rechnungen, verlorene Bestellbestätigungen, verschwendete Marketing-Leads und eine Domain-Reputation, die sich stillschweigend verschlechtert.

Die gute Nachricht: Die Mehrheit dieser Probleme ist vor dem Versand erkennbar. Ein Zustellbarkeitstest analysiert deine DNS-Konfiguration (SPF, DKIM, DMARC), prüft die Reputation deiner IP, kontrolliert deine E-Mail-Header und erzeugt einen Gesamtscore auf 100. In 30 Sekunden weißt du genau, was funktioniert und was deine E-Mails blockiert.

Dieser Leitfaden behandelt den gesamten Prozess: Warum testen, wie ein Zustellbarkeitstest funktioniert, wie du jeden Abschnitt des Scores interpretierst und vor allem, wie du die identifizierten Probleme korrigierst, um von 40/100 auf 100/100 zu kommen. Ob Systemadministrator, Entwickler oder Marketing-Verantwortlicher: Jeder Abschnitt enthält konkrete Handlungsschritte.

Warum du die Zustellbarkeit vor jedem Versand testen solltest

Das unsichtbare Problem

E-Mail-Zustellbarkeit ist ein stilles Problem. Im Gegensatz zu einer ausgefallenen Website (sofort sichtbar) erzeugt eine E-Mail, die im Spam landet, keinen Alarm. Der Absender denkt, die Nachricht wurde zugestellt. Der Empfänger weiß nicht, dass eine E-Mail im Spam-Ordner auf ihn wartet. Niemand beschwert sich, weil niemand es weiß.

Die E-Mail-Anbieter (Gmail, Outlook, Yahoo, Apple Mail) treffen Filterentscheidungen in wenigen Millisekunden, basierend auf Hunderten von Signalen. Und diese Signale ändern sich ständig. Eine Domain, die vor sechs Monaten alle Prüfungen bestanden hat, kann heute scheitern, weil ein Dienstleister einen zusätzlichen SPF-Include hinzugefügt hat oder weil die DKIM-Schlüsselrotation nicht durchgeführt wurde.

Die 5 Prüfungen eines Zustellbarkeitstests

Ein vollständiger Test prüft fünf verschiedene Kategorien, die jeweils zum Gesamtscore beitragen:

Kategorie	Punkte	Was geprüft wird
SPF	25/100	Gültiger DNS-TXT-Eintrag, IP des Absenders autorisiert, Anzahl der Lookups
DKIM	25/100	Gültige kryptografische Signatur, öffentlicher DNS-Schlüssel erreichbar, Domain-Alignment
DMARC	20/100	Richtlinie veröffentlicht, SPF/DKIM-Alignment, Berichtsadresse konfiguriert
MX / PTR	15/100	MX-Einträge vorhanden, Reverse-DNS konfiguriert, IP nicht auf Blacklist
Header	15/100	From/Reply-To konsistent, Message-ID gültig, keine verdächtigen Felder

Ein Score unter 70/100 bedeutet, dass deine E-Mails eine erhebliche Wahrscheinlichkeit haben, als Spam eingestuft zu werden. Unter 50/100 werden die meisten Anbieter deine Nachrichten ablehnen oder filtern.

Die Gmail- und Yahoo-Anforderungen 2024

Seit Februar 2024 haben Gmail und Yahoo Prüfungen verpflichtend gemacht, die zuvor optional waren. Diese Anforderungen gelten für alle Absender, mit zusätzlichen Regeln für Massenversand:

Für alle Absender:

• SPF oder DKIM gültig (mindestens eines von beiden)
• DNS-Eintrag vom Typ PTR (Reverse-DNS) für die Versand-IP konfiguriert
• Spam-Rate in Google Postmaster Tools unter 0,3 %

Für Massenversender (> 5.000 E-Mails/Tag an Gmail):

• SPF und DKIM gültig (beide Pflicht)
• DMARC veröffentlicht mit mindestens p=none
• Alignment der From-Domain mit SPF oder DKIM
• List-Unsubscribe-Header mit Ein-Klick-Abmeldung (RFC 8058)
• Formatierung gemäß RFC 5322

Die Nichteinhaltung dieser Anforderungen führt zu einer schrittweisen Ablehnung. Gmail blockiert nicht sofort 100 % der E-Mails: Es beginnt damit, 4 % der Nachrichten zu verzögern (Code 4xx), und erhöht dann den Prozentsatz bis zur dauerhaften Ablehnung (Code 5xx), wenn das Problem nicht behoben wird.

Wie funktioniert ein Zustellbarkeitstest?

Ein Zustellbarkeitstest reproduziert den exakten Prozess, den ein Empfangsserver durchführt, wenn er deine E-Mail erhält. Hier sind die vier Schritte in der richtigen Reihenfolge.

Schritt 1: DNS-Auflösung und SPF-Prüfung

Der Test beginnt mit einer DNS-Abfrage deiner Domain, um den SPF-Eintrag abzurufen.

# SPF-Eintrag von captaindns.com abrufen
dig TXT captaindns.com +short | grep "v=spf1"

Der SPF-Eintrag ist ein DNS-Eintrag vom Typ TXT, der mit v=spf1 beginnt. Er listet die Server auf, die berechtigt sind, E-Mails für deine Domain zu versenden. Hier ein reales Beispiel:

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

Der Empfangsserver vergleicht die IP des sendenden Servers mit den durch deinen SPF autorisierten IPs. Der Prozess ist rekursiv: Jedes include: löst eine neue DNS-Abfrage aus, um die IPs der referenzierten Subdomain abzurufen.

Kritischer Punkt: Die RFC 7208 begrenzt die Anzahl der DNS-Abfragen (Lookups) während der SPF-Auswertung auf 10. Die Mechanismen include, a, mx, redirect und exists zählen jeweils als ein Lookup. Die Mechanismen ip4 und ip6 zählen nicht (es sind direkte Werte). Beim 11. Lookup gibt der Server permerror zurück und dein SPF gilt als ungültig.

# Prüfen, wie viele Lookups dein SPF erzeugt
# Jedes include erzeugt mindestens 1 Lookup
dig TXT _spf.google.com +short
# Ergebnis: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ..."
# Jedes Sub-Include zählt ebenfalls!

Schritt 2: DKIM-Signaturprüfung

DKIM (DomainKeys Identified Mail) fügt jeder E-Mail eine kryptografische Signatur hinzu. Der Versandserver signiert die Nachricht mit einem privaten Schlüssel. Der Empfangsserver verifiziert diese Signatur, indem er den entsprechenden öffentlichen Schlüssel aus dem DNS abruft.

Die DKIM-Signatur befindet sich im DKIM-Signature-Header der E-Mail:

DKIM-Signature: v=1; a=rsa-sha256; d=captaindns.com; s=google;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Die wichtigsten Felder:

• d=: Die Domain, die die Signatur beansprucht (muss für DMARC mit der From-Domain übereinstimmen)
• s=: Der Selektor, der identifiziert, welcher öffentliche Schlüssel verwendet wird
• a=: Der Signaturalgorithmus (rsa-sha256 oder ed25519-sha256)
• bh=: Der Hash des Nachrichtentexts
• b=: Die Signatur selbst

Der Test ruft den öffentlichen Schlüssel per DNS ab:

# Öffentlichen DKIM-Schlüssel abrufen
# Format: selektor._domainkey.domain
dig TXT google._domainkey.captaindns.com +short

Die Antwort enthält einen TXT-Eintrag mit dem öffentlichen Schlüssel:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Der Empfangsserver verwendet diesen öffentlichen Schlüssel zur Verifizierung der Signatur. Wenn der Nachrichtentext oder die signierten Header nach der Signierung verändert wurden, schlägt die Verifizierung fehl.

RSA vs. Ed25519: Die meisten Server verwenden RSA-SHA256 mit 2048-Bit-Schlüsseln. Ed25519 ist schneller und erzeugt kürzere Signaturen, aber die Unterstützung auf Empfängerseite ist noch nicht universell. Google Workspace und Microsoft 365 unterstützen im März 2026 nur RSA für ausgehende DKIM-Signaturen.

Schritt 3: DMARC-Auswertung und Alignment

DMARC (Domain-based Message Authentication, Reporting, and Conformance) prüft, ob SPF und DKIM nicht nur gültig, sondern auch mit der im From-Feld der E-Mail sichtbaren Domain aligned sind.

# DMARC-Richtlinie abrufen
dig TXT _dmarc.captaindns.com +short

Typisches Ergebnis:

"v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"

Hier die einzelnen Tags im Detail:

Tag	Wert	Bedeutung
v=DMARC1	Pflicht	Identifiziert den Eintrag als DMARC
p=	none, quarantine, reject	Richtlinie für E-Mails, die die Prüfung nicht bestehen
rua=	E-Mail-Adresse	Ziel der aggregierten Berichte (tägliche Statistiken)
ruf=	E-Mail-Adresse	Ziel der forensischen Berichte (Stichproben von Fehlschlägen)
adkim=	r (relaxed) oder s (strict)	DKIM-Alignment-Modus
aspf=	r (relaxed) oder s (strict)	SPF-Alignment-Modus
pct=	0-100	Prozentsatz der E-Mails, die der Richtlinie unterliegen

Relaxed vs. Strict Alignment: Im Relaxed-Modus (adkim=r) muss die Domain der DKIM-Signatur (d=) dieselbe Organisationsdomain wie die From-Adresse teilen. Beispiel: Eine Signatur d=mail.captaindns.com ist aligned mit einer From-Adresse contact@captaindns.com. Im Strict-Modus (adkim=s) müssen die Domains exakt übereinstimmen.

Die DMARC-Auswertung folgt dieser Logik:

1. SPF besteht und ist aligned mit der From-Adresse? DMARC besteht.
2. DKIM besteht und ist aligned mit der From-Adresse? DMARC besteht.
3. Wenn keines von beiden aligned ist: DMARC schlägt fehl und die Richtlinie (p=) wird angewendet.

Ein oft missverstandener Punkt: DMARC besteht, wenn mindestens einer der beiden Mechanismen (SPF oder DKIM) mit Alignment besteht. Es ist nicht erforderlich, dass beide erfolgreich sind.

Schritt 4: Ergänzende Prüfungen (MX, PTR, Header, Blacklists)

Der Test prüft anschließend zusätzliche technische Elemente:

MX-Einträge: Die Domain muss gültige MX-Einträge haben, die auf aktive Mailserver zeigen. Eine Domain ohne MX signalisiert eine Domain, die nicht für den E-Mail-Empfang konfiguriert ist, was für einen Absender verdächtig ist.

dig MX captaindns.com +short
# 10 mx1.captaindns.com.
# 20 mx2.captaindns.com.

Reverse-DNS (PTR): Die IP des Versandservers muss einen PTR-Eintrag haben, der auf einen Hostnamen auflöst, und dieser Hostname muss wiederum auf dieselbe IP auflösen. Das ist die FCrDNS-Prüfung (Forward-confirmed reverse DNS).

# Reverse-DNS einer IP prüfen
dig -x 203.0.113.10 +short
# mail.captaindns.com.

# Prüfen, ob der Forward-Eintrag übereinstimmt
dig A mail.captaindns.com +short
# 203.0.113.10

Blacklists: Die Versand-IP wird gegen die wichtigsten Blacklists geprüft (Spamhaus ZEN, Barracuda, SORBS, SpamCop). Ein Eintrag auf einer einzigen großen Blacklist kann ausreichen, damit die meisten Anbieter deine E-Mails ablehnen.

E-Mail-Header: Der Test prüft die Konsistenz der Header From, Reply-To, Message-ID, Date und das Vorhandensein der gemäß RFC 5322 erforderlichen Felder.

Ergebnisse Abschnitt für Abschnitt interpretieren

Sobald der Test ausgeführt wurde, zeigt der Bericht einen Gesamtscore und eine Aufschlüsselung nach Kategorie. So liest du jeden Abschnitt und identifizierst die prioritären Maßnahmen.

Abschnitt SPF (25 Punkte)

Ergebnis	Punkte	Bedeutung	Maßnahme
pass	25/25	Die Versand-IP ist durch deinen SPF autorisiert	Keine Maßnahme
softfail	10/25	Die IP ist nicht explizit autorisiert (~all)	Nach Prüfung auf -all umstellen
fail	0/25	Die IP wird explizit durch deinen SPF abgelehnt	Fehlende IP oder fehlendes Include hinzufügen
permerror	0/25	Der SPF-Eintrag ist ungültig	Syntax korrigieren oder Lookups reduzieren
none	0/25	Kein SPF-Eintrag gefunden	SPF-Eintrag erstellen

Häufiger Fehler: Ein softfail-Ergebnis erweckt den Eindruck, dass es trotzdem funktioniert. In Wirklichkeit behandeln moderne Server den Softfail fast wie einen Fail, besonders in Kombination mit einem DMARC im Quarantine- oder Reject-Modus. Der Softfail sollte nur eine Übergangsphase während der SPF-Ersteinrichtung sein.

Abschnitt DKIM (25 Punkte)

Ergebnis	Punkte	Bedeutung	Maßnahme
pass	25/25	Gültige Signatur und öffentlicher Schlüssel gefunden	Keine Maßnahme
fail	0/25	Ungültige Signatur (Text verändert, falscher Schlüssel)	Genaue Ursache diagnostizieren
none	0/25	Keine DKIM-Signatur in der E-Mail	DKIM auf dem Versandserver konfigurieren
permerror	0/25	Oeffentlicher Schlüssel fehlerhaft oder nicht erreichbar	DNS-Eintrag des Selektors prüfen

Das Ergebnis dkim=fail ist am schwierigsten zu diagnostizieren, da die Ursachen vielfältig sind: Body-Hash durch ein Zwischenrelay verändert, öffentlicher Schlüssel nicht im DNS vorhanden, abgelaufene Signatur (Tag x= überschritten) oder falscher Kanonisierungsalgorithmus. Sieh dir den Leitfaden zur DKIM-Fail-Diagnose für einen vollständigen Entscheidungsbaum an.

Abschnitt DMARC (20 Punkte)

Ergebnis	Punkte	Bedeutung	Maßnahme
pass	20/20	SPF oder DKIM aligned und gültig	Keine Maßnahme
fail (p=none)	5/20	Fehlgeschlagen, aber ohne Konsequenzen (Überwachungsmodus)	Zu Quarantine, dann Reject fortschreiten
fail (p=quarantine)	0/20	E-Mails landen im Spam	SPF/DKIM-Alignment korrigieren
fail (p=reject)	0/20	E-Mails werden abgelehnt	SPF/DKIM-Alignment korrigieren
none	0/20	Kein DMARC-Eintrag	DMARC-Eintrag erstellen

Die Falle von p=none: Diese Richtlinie ist während der Einführungsphase unverzichtbar, da sie das Sammeln von Berichten ermöglicht, ohne die Zustellung zu beeinträchtigen. Aber dauerhaft bei p=none zu bleiben bedeutet in Bezug auf den Schutz, überhaupt kein DMARC zu haben. E-Mail-Anbieter gewähren Domains einen Vertrauensbonus, die p=quarantine oder p=reject veröffentlichen.

Abschnitt MX / PTR (15 Punkte)

Prüfung	Punkte	Kriterium
Gültige MX	5/15	Mindestens ein MX-Eintrag, der auf eine aktive IP auflöst
PTR konfiguriert	5/15	Reverse-DNS der Versand-IP löst auf einen Hostnamen auf
FCrDNS	3/15	Forward-confirmed reverse DNS (Hin- und Rückauflösung IP/Hostname)
Keine Blacklist	2/15	IP nicht auf den großen Blacklists

Der Reverse-DNS (PTR) wird oft vernachlässigt, da er vom Eigentümer des IP-Bereichs abhängt, nicht vom Domain-Eigentümer. Wenn du einen VPS oder Dedicated Server verwendest, konfigurierst du den PTR über das Panel deines Hosters. Wenn du einen Versanddienst (SendGrid, Mailgun, Brevo) verwendest, wird der PTR normalerweise vom Anbieter auf dessen dedizierten IPs verwaltet.

Abschnitt Header (15 Punkte)

Prüfung	Punkte	Kriterium
Gültiges From	4/15	Syntaktisch korrekte E-Mail-Adresse mit auflösbarer Domain
Message-ID	3/15	Vorhanden und im RFC-5322-Format
Date	3/15	Vorhanden und in einem vernünftigen Zeitfenster (nicht in der Zukunft, nicht älter als 7 Tage)
Konsistentes Reply-To	3/15	Gleiche Domain wie From oder vertrauenswürdige Domain
Kein verdächtiger X-Mailer	2/15	Keine bekannte Spam-Software in den Headern

Ein fehlender oder fehlerhafter Message-ID-Header ist ein starkes Spam-Signal für Filter. Jede E-Mail muss eine eindeutige Message-ID im Format <identifikator@domain> haben. Korrekt konfigurierte Mailserver generieren diese automatisch, aber bestimmte PHP-Skripte oder benutzerdefinierte Versandbibliotheken lassen sie weg.

Von 40/100 auf 100/100: Korrekturen Schritt für Schritt

Du hast den Test ausgeführt und der Score ist nicht gut. Hier ist die exakte Reihenfolge der Korrekturen, sortiert nach Auswirkung auf den Score.

Priorität 1: SPF erstellen oder korrigieren (+25 Punkte)

Wenn dein SPF fehlt oder ungültig ist, bringt diese Korrektur sofort die meisten Punkte.

Fall 1: Kein SPF-Eintrag

Erstelle einen DNS-TXT-Eintrag auf deiner Root-Domain:

captaindns.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

Passe die Mechanismen an deine Versanddienste an:

Dienst	Hinzuzufügendes Include
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
SendGrid	include:sendgrid.net
Mailgun	include:mailgun.org
Brevo (ehemals Sendinblue)	include:sendinblue.com
Amazon SES	include:amazonses.com
OVHcloud	include:mx.ovh.com

Fall 2: SPF PermError (zu viele Lookups)

Die Grenze von 10 Lookups ist die häufigste Ursache für den PermError. Jedes include: zählt als mindestens 1 Lookup, und verschachtelte Includes addieren sich. Google Workspace allein verbraucht 4 Lookups.

Zur Diagnose des Problems:

# Lookups deines SPF zählen
dig TXT captaindns.com +short | grep "v=spf1"
# Dann jedem Include rekursiv folgen
dig TXT _spf.google.com +short
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
# = 3 zusätzliche Lookups allein für dieses Include

Lösungen zur Reduzierung:

• include: durch direkte ip4: und ip6: ersetzen, wenn die IPs stabil sind (SPF-Flattening)
• SPF-Makros (%{i} und exists:) für fortgeschrittene Fälle verwenden
• Includes von Diensten entfernen, die du nicht mehr nutzt

Für einen ausführlichen Leitfaden zum PermError sieh dir den SPF-PermError-Leitfaden an.

Fall 3: Zwei SPF-Einträge auf derselben Domain

Die RFC 7208 verbietet strikt das Vorhandensein mehrerer TXT-Einträge, die mit v=spf1 beginnen, auf derselben Domain. Wenn du zwei hast, gibt der Server sofort permerror zurück.

# Auf Duplikate prüfen
dig TXT captaindns.com +short | grep "v=spf1"
# Wenn zwei Zeilen erscheinen: zu einem einzigen Eintrag zusammenführen

Führe die beiden Einträge zu einem zusammen, der alle Mechanismen enthält.

Priorität 2: DKIM konfigurieren (+25 Punkte)

DKIM erfordert zwei Elemente: einen privaten Schlüssel, der auf dem Versandserver installiert ist (der die Nachrichten signiert), und einen öffentlichen Schlüssel, der im DNS veröffentlicht ist (der die Verifizierung ermöglicht).

Konfiguration mit Google Workspace:

1. Google Admin Console > Apps > Google Workspace > Gmail > E-Mail authentifizieren
2. Wähle deine Domain und klicke auf "Neuen Eintrag generieren"
3. Wähle eine Schlüssellänge von 2048 Bit
4. Kopiere den bereitgestellten DNS-CNAME- oder TXT-Eintrag
5. Veröffentliche ihn in deiner DNS-Zone im Format google._domainkey.captaindns.com
6. Gehe zurück zur Konsole und klicke auf "Authentifizierung starten"

Konfiguration mit Microsoft 365:

Microsoft 365 verwendet zwei CNAME-Einträge pro Domain:

selector1._domainkey.captaindns.com  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com
selector2._domainkey.captaindns.com  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com

Prüfung nach der Konfiguration:

# Prüfen, ob der öffentliche Schlüssel erreichbar ist
dig TXT google._domainkey.captaindns.com +short
# Sollte einen Eintrag mit "v=DKIM1; k=rsa; p=MII..." zurückgeben

Wenn der Befehl nichts zurückgibt, liegt das Problem beim DNS: Entweder hat der Eintrag noch nicht propagiert (24-48 Stunden warten) oder es gibt einen Namensfehler beim Selektor.

Schlüssellänge: Verwende mindestens 2048 Bit. 1024-Bit-Schlüssel gelten seit 2020 als schwach. Einige Anbieter lehnen bereits Signaturen ab, die auf RSA-Schlüsseln mit weniger als 1024 Bit basieren.

Priorität 3: DMARC veröffentlichen und verschärfen (+20 Punkte)

Die DMARC-Einführung folgt einem Zyklus in drei Phasen.

Phase 1: Ueberwachung (2 bis 4 Wochen)

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@captaindns.com; pct=100"

Während dieser Phase wird keine E-Mail blockiert. Die aggregierten Berichte (rua=) kommen täglich im XML-Format und enthalten die Authentifizierungsstatistiken aller Server, die E-Mails für deine Domain versendet haben.

Analysiere die Berichte, um Folgendes zu identifizieren:

• Legitime Quellen, die fehlschlagen (Rechnungsserver, CRM, Marketing-Tool)
• Illegitime Quellen (Spoofing-Versuche)
• SPF- und DKIM-Alignment-Rate

Phase 2: Quarantäne (4 bis 8 Wochen)

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@captaindns.com; pct=25"

Das pct=25 wendet die Quarantäne-Richtlinie nur auf 25 % der E-Mails an, die die Prüfung nicht bestehen. Das ist ein Sicherheitsnetz: Wenn eine legitime Quelle noch nicht korrigiert wurde, kommen 75 % ihrer E-Mails noch durch. Erhöhe schrittweise: 25 %, 50 %, 75 %, 100 %.

Phase 3: Ablehnung

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"

In diesem Stadium wird jede E-Mail, die das DMARC-Alignment nicht besteht, vom Empfangsserver abgelehnt. Das ist die sicherste Konfiguration und diejenige, die den meisten Vertrauensbonus bei den Anbietern bringt.

Priorität 4: Reverse-DNS konfigurieren (+15 Punkte MX/PTR)

MX-Einträge: Wenn deine Domain keinen MX-Eintrag hat, füge einen hinzu, der auf deinen Empfangsserver zeigt:

captaindns.com.  IN  MX  10  mx1.captaindns.com.
captaindns.com.  IN  MX  20  mx2.captaindns.com.

Reverse-DNS: Melde dich im Administrationspanel deines Hosters an und konfiguriere den PTR deiner Versand-IP so, dass er auf den FQDN deines Mailservers zeigt:

# Nach der Konfiguration prüfen:
dig -x 203.0.113.10 +short
# Erwartet: mail.captaindns.com.

Blacklists: Wenn deine IP auf einer Blacklist steht, hängt das Delisting-Verfahren von der jeweiligen Liste ab:

Blacklist	Verfahren	Dauer
Spamhaus	Delisting-Formular auf spamhaus.org	24-48 Stunden nach Korrektur
Barracuda	Formular auf barracudacentral.org	12-24 Stunden
SORBS	Automatisches Delisting nach 48 Stunden ohne Spam	48 Stunden
SpamCop	Automatischer Ablauf nach 24 Stunden	24 Stunden

Priorität 5: Header bereinigen (+15 Punkte)

Header-Probleme werden oft durch benutzerdefinierte Versandskripte oder falsch konfigurierte Bibliotheken verursacht.

Header-Checkliste:

• Das From-Feld verwendet eine Adresse mit deiner Domain, keine generische Domain
• Die Message-ID ist vorhanden und im Format <unique-id@captaindns.com>
• Das Date-Feld ist vorhanden und korrekt (Zeitzone enthalten)
• Das Reply-To verwendet, falls vorhanden, eine Domain, die mit dem From konsistent ist
• Kein X-Mailer-Header, der auf ein bekanntes Spam-Tool verweist
• Der Content-Type gibt den Zeichensatz an (UTF-8 empfohlen)

Wenn du PHP mail() verwendest, wechsle zu einer Bibliothek wie PHPMailer oder SwiftMailer, die konforme Header erzeugt. Wenn du ein Framework (Laravel, Django, Rails) verwendest, sind die Header in der Regel standardmäßig korrekt.

Die häufigsten Fehler

SPF PermError: Die Grenze von 10 Lookups

Das ist der verbreitetste Fehler. Eine Domain, die Google Workspace (4 Lookups), SendGrid (2 Lookups), Mailchimp (2 Lookups) und einen internen Server (1 Lookup mit einem a:) nutzt, erreicht bereits 9 Lookups. Das Hinzufügen eines einzigen weiteren Dienstes löst den PermError aus.

Die Diagnose ist einfach:

dig TXT captaindns.com +short | grep "v=spf1"
# Zähle jedes include, a, mx, redirect, exists
# Folge den verschachtelten Includes rekursiv

Die Korrektur hängt von deiner Situation ab:

• Ungenutzte Dienste entfernen: Prüfe, ob jedes Include einem aktiven Dienst entspricht
• SPF-Flattening verwenden: Ersetze die Includes durch die finalen IPs (Achtung bei der Wartung)
• Eine Subdomain verwenden: Versende Marketing-Mails über news.captaindns.com mit eigenem SPF

Wenn deine E-Mails trotz dieser Korrekturen weiterhin im Spam landen, geht das Problem über SPF hinaus. Sieh dir den vollständigen Diagnose-Leitfaden für Spam an, um weitere Ursachen zu analysieren (Reputation, Inhalt, Engagement).

DKIM Fail: Body Hash did not verify

Dieser Fehler bedeutet, dass der Inhalt der E-Mail nach der Signierung verändert wurde. Die häufigsten Ursachen:

1. Zwischenrelay: Ein Server zwischen Versand und Empfang hat eine Fusszeile hinzugefügt, URLs umgeschrieben oder ein Tracking-Pixel eingefügt
2. Antivirus oder DLP: Eine Sicherheitssoftware hat den Nachrichtentext verändert
3. Mailingliste: Listenserver (Listserv, Sympa) fügen häufig eine Abmelde-Fusszeile hinzu, die die Signatur bricht

Die Korrektur besteht darin, zu identifizieren, welche Komponente deiner Versandkette die Nachricht nach der DKIM-Signierung verändert, und dann die Reihenfolge der Operationen so umzukonfigurieren, dass die Aenderung vor der Signierung erfolgt.

Für Mailinglisten ermöglicht das ARC-Protokoll (Authenticated Received Chain) die Bewahrung der Authentifizierungsergebnisse über Zwischenrelays hinweg. Gmail und Microsoft unterstützen ARC seit 2019.

DMARC Fail: Alignment-Fehler

Der subtilste Fehler. SPF besteht, DKIM besteht, aber DMARC schlägt trotzdem fehl. Die Ursache: Keiner von beiden ist mit der Domain des From-Felds aligned.

Typisches Szenario: Du versendest von contact@captaindns.com, aber dein Versanddienstleister signiert mit d=sendgrid.net (DKIM nicht aligned) und die SMTP-Envelope verwendet bounces@sendgrid.net (SPF nicht aligned). Ergebnis: Beide Authentifizierungen bestehen technisch, aber keine ist mit captaindns.com aligned.

Korrektur:

• Konfiguriere deinen Dienstleister so, dass er mit d=captaindns.com signiert (DKIM aligned)
• Konfiguriere den Return-Path (SMTP-Envelope) so, dass eine Subdomain deiner Domain verwendet wird (SPF aligned)

Die meisten Versanddienstleister (SendGrid, Mailgun, Brevo, Postmark) bieten eine Option "Domain Authentication" oder "Sender Authentication", die das DKIM- und SPF-Alignment automatisch konfiguriert.

IP auf einer Blacklist

Dein MX/PTR-Score sinkt wegen einer IP auf der Blacklist. Die Hauptursachen:

• Geteilte IP: Wenn du auf einer geteilten IP mit anderen Kunden deines Hosters bist, kann Spam eines anderen Kunden dich betreffen
• Kompromittierung: Ein Skript auf deinem Server versendet ohne dein Wissen Spam (ausgenutztes Kontaktformular, kompromittiertes E-Mail-Konto)
• IP-Historie: Die IP, die du gerade erhalten hast, wurde zuvor von einem Spammer verwendet

Die Prüfung ist sofort möglich:

# Spamhaus prüfen
dig +short 10.113.0.203.zen.spamhaus.org
# Wenn eine Antwort vom Typ 127.0.0.x erscheint, ist die IP gelistet

Beachte, dass die IP in der DNS-Abfrage umgekehrt wird (203.0.113.10 wird zu 10.113.0.203).

Wann testen? Die 5 kritischen Situationen

Ein Zustellbarkeitstest ist keine einmalige Prüfung. Hier sind die fünf Momente, in denen ein Test unverzichtbar ist.

1. Vor dem Start einer E-Mail-Kampagne

Jede Marketing-Kampagne sollte mit einem Test eingeleitet werden. Ein Authentifizierungsproblem bei einem Versand von 50.000 E-Mails bedeutet 50.000 potenziell verlorene E-Mails. Der Test dauert 30 Sekunden und kann eine ganze Kampagne retten.

Sende eine Test-E-Mail an die vom Mail-Tester bereitgestellte Adresse, sieh dir den Bericht an und behebe die Probleme vor dem Massenversand.

2. Nach einem Wechsel des Versanddienstleisters

Die Migration von einem Versanddienst zu einem anderen ist der riskanteste Moment für die Zustellbarkeit. Du musst den SPF aktualisieren (das alte Include durch das neue ersetzen), DKIM neu konfigurieren (neuer Selektor, neuer Schlüssel) und das DMARC-Alignment prüfen.

Checkliste für die Migration:

• SPF aktualisieren: altes Include entfernen, neues hinzufügen
• DKIM beim neuen Anbieter konfigurieren und den Schlüssel im DNS veröffentlichen
• DMARC-Alignment mit dem neuen Anbieter prüfen
• Zustellbarkeit testen, bevor du den Traffic umschaltest
• Altes SPF-Include 48 Stunden beibehalten (E-Mails im Transit)

3. Nach einer DNS-Aenderung

Jede Aenderung deiner DNS-Zone kann die Zustellbarkeit beeinträchtigen: TTL-Aenderung, Aktualisierung eines TXT-Eintrags, Registrar-Migration, DNSSEC-Aktivierung. Copy-Paste-Fehler in DNS-Einträgen sind häufig, und das Ergebnis ist ein defekter SPF oder DKIM ohne sichtbare Fehlermeldung.

4. Wenn die Öffnungsraten einbrechen

Ein plötzlicher Rückgang der Öffnungsraten (mehr als 10 % Abweichung innerhalb einer Woche) kann auf ein Zustellbarkeitsproblem hindeuten. Bevor du die Ursache im Inhalt oder im Betreff der E-Mails suchst, teste deine Authentifizierung. Ein SPF, der plötzlich die 10-Lookup-Grenze überschreitet (weil ein Anbieter ein verschachteltes Include hinzugefügt hat), kann einen abrupten Einbruch verursachen.

5. Regelmäßig monatlich, zur Prävention

DNS-Konfigurationen ändern sich, Anbieter aktualisieren ihre Einträge, DKIM-Schlüssel müssen erneuert werden. Ein monatlicher Test erkennt Regressionen, bevor sie deine Versendungen beeinträchtigen. Plane eine monatliche Erinnerung und prüfe, ob dein Score bei 100/100 bleibt.

Empfohlener Aktionsplan

1. Führe einen Zustellbarkeitstest durch mit dem Mail-Tester von CaptainDNS. Sende eine Test-E-Mail und erhalte deinen detaillierten Score Abschnitt für Abschnitt.

2. Behebe die Probleme nach Auswirkung sortiert: SPF zuerst (25 Punkte), dann DKIM (25 Punkte), dann DMARC (20 Punkte). Jede Korrektur erhöht sofort deinen Score und deine Zustellrate.

3. Prüfe deine Korrekturen, indem du den Test nach jeder DNS-Aenderung erneut ausführst. Warte auf die DNS-Propagierung (5 bis 60 Minuten je nach TTL), bevor du erneut testest.

4. Richte DMARC-Monitoring ein: Die aggregierten Berichte (rua=) benachrichtigen dich automatisch, wenn ein Authentifizierungsproblem auftritt. Analysiere sie mindestens einmal pro Woche während der Hochlaufphase, dann monatlich.

5. Plane einen monatlichen Test, um Regressionen zu erkennen. DNS-Konfigurationen ändern sich stillschweigend (Anbieter ändert seine Includes, DKIM-Schlüssel läuft ab, IP wechselt die Blacklist). Ein monatlicher Test kostet 30 Sekunden und kann Wochen verschlechterter Zustellbarkeit vermeiden.

FAQ

Was ist ein Mail-Tester und wie funktioniert er?

Ein Mail-Tester ist ein Tool, das die Zustellbarkeit deiner E-Mails analysiert, indem es deine DNS-Konfiguration (SPF, DKIM, DMARC), die Reputation deiner Versand-IP, deine E-Mail-Header und das eventuelle Vorhandensein deiner IP auf Blacklists prüft. Du sendest eine Test-E-Mail an eine vom Tool bereitgestellte Adresse, und dieses erstellt einen detaillierten Bericht mit einem Score auf 100 und den anzuwendenden Korrekturen.

Welchen Zustellbarkeits-Score sollte man anstreben?

Strebe einen Score von 100/100 an. Ein Score über 80/100 ist für die meisten transaktionalen Versendungen akzeptabel. Unter 70/100 haben deine E-Mails eine erhebliche Wahrscheinlichkeit, als Spam eingestuft zu werden. Unter 50/100 werden die meisten Anbieter (Gmail, Outlook, Yahoo) deine Nachrichten ablehnen oder filtern.

Sind SPF, DKIM und DMARC alle Pflicht?

Seit Februar 2024 verlangen Gmail und Yahoo mindestens SPF oder DKIM für alle Absender. Für Massenversender (mehr als 5.000 E-Mails pro Tag an Gmail) sind alle drei Pflicht: gültiges SPF und DKIM sowie ein veröffentlichter DMARC-Eintrag. In der Praxis wird die Konfiguration aller drei für alle Domains empfohlen, unabhängig vom Volumen.

Was ist die Grenze von 10 DNS-Lookups bei SPF?

Die RFC 7208 begrenzt die Anzahl der rekursiven DNS-Abfragen während der Auswertung eines SPF-Eintrags auf 10. Die Mechanismen include, a, mx, redirect und exists zählen jeweils als ein Lookup. Verschachtelte Includes addieren sich: Ein Include, das selbst 3 Includes enthält, verbraucht insgesamt 4 Lookups. Ueber 10 hinaus gibt der Server einen PermError zurück und dein SPF gilt als ungültig.

Warum schlägt mein DMARC fehl, obwohl SPF und DKIM bestehen?

DMARC prüft nicht nur, ob SPF und DKIM bestehen, sondern auch, ob sie mit der Domain des From-Felds der E-Mail aligned sind. Wenn dein Versanddienstleister mit seiner eigenen DKIM-Domain signiert und seine eigene Adresse in der SMTP-Envelope verwendet, ist weder SPF noch DKIM mit deiner From-Domain aligned. Konfiguriere deinen Anbieter so, dass er deine Domain verwendet (Domain Authentication), um dieses Problem zu lösen.

Wie lange dauert es, bis DNS-Korrekturen wirksam werden?

Die Dauer hängt vom TTL (Time To Live) deiner DNS-Einträge ab. Ein TTL von 300 Sekunden (5 Minuten) bedeutet, dass Empfangsserver deine Aenderung in weniger als 5 Minuten sehen. Ein TTL von 86400 (24 Stunden) kann bis zu 24 Stunden dauern. Bevor du einen kritischen Eintrag änderst, reduziere zuerst den TTL auf 300, warte auf die Propagierung dieses neuen TTLs und führe dann die Aenderung durch.

Wie finde ich heraus, ob meine IP auf einer Blacklist steht?

Frage die wichtigsten Blacklists über eine umgekehrte DNS-Abfrage ab. Um zum Beispiel die IP 203.0.113.10 bei Spamhaus zu prüfen: dig +short 10.113.0.203.zen.spamhaus.org. Wenn eine Antwort vom Typ 127.0.0.x zurückkommt, ist die IP gelistet. Ein Blacklist-Prüftool automatisiert diese Prüfung auf mehreren Dutzend Listen gleichzeitig.

Muss man vor jedem Kampagnenversand testen?

Ja, für Marketing-Massenkampagnen. Ein Test dauert weniger als eine Minute und kann verhindern, dass ein ganzer Versand verschwendet wird. Für transaktionale E-Mails (Bestätigungen, Rechnungen) reicht ein monatlicher Test, es sei denn, es gab eine DNS-Konfigurationsänderung oder einen Anbieterwechsel. Das Ziel ist, Regressionen zu erkennen, bevor sie die Zustellbarkeit beeinträchtigen.

Was ist der Unterschied zwischen Relaxed und Strict Alignment bei DMARC?

Im Relaxed-Modus (adkim=r, aspf=r) muss die Domain der DKIM-Signatur oder der SPF-Envelope dieselbe Organisationsdomain wie die From-Adresse teilen. Beispiel: Eine Signatur d=mail.captaindns.com ist aligned mit einer From-Adresse @captaindns.com. Im Strict-Modus (adkim=s, aspf=s) müssen die Domains exakt übereinstimmen. Der Relaxed-Modus wird für die meisten Deployments empfohlen, da er die Verwendung von Subdomains toleriert.

Was tun, wenn mein Score trotz Korrekturen nicht steigt?

Prüfe, ob die DNS-Propagierung abgeschlossen ist (warte mindestens den TTL deiner Einträge ab). Teste jede Komponente einzeln: SPF allein (dig TXT captaindns.com), DKIM allein (dig TXT selektor._domainkey.captaindns.com), DMARC allein (dig TXT _dmarc.captaindns.com). Wenn die DNS-Einträge korrekt sind, aber der Score sich nicht ändert, kann das Problem an der IP-Reputation (Blacklist) oder am Inhalt der Test-E-Mail liegen.

Glossar

• SPF (Sender Policy Framework): E-Mail-Authentifizierungsprotokoll, definiert durch RFC 7208, das die Server auflistet, die berechtigt sind, E-Mails für eine Domain zu versenden, über einen DNS-TXT-Eintrag, der mit v=spf1 beginnt.
• DKIM (DomainKeys Identified Mail): E-Mail-Authentifizierungsprotokoll, definiert durch RFC 6376, das jeder E-Mail eine kryptografische Signatur hinzufügt, die über einen im DNS veröffentlichten öffentlichen Schlüssel verifizierbar ist.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Protokoll, definiert durch RFC 7489, das das Alignment von SPF und DKIM mit der From-Domain prüft und die Richtlinie für die Behandlung von Fehlschlägen definiert (none, quarantine, reject).
• Alignment: Im DMARC-Kontext die Uebereinstimmung zwischen der von SPF oder DKIM verwendeten Domain und der im From-Feld der E-Mail sichtbaren Domain. Kann relaxed (gleiche Organisationsdomain) oder strict (exakte Uebereinstimmung) sein.
• PermError: Permanenter Fehler, der zurückgegeben wird, wenn ein SPF-Eintrag strukturell ungültig ist (zu viele Lookups, falsche Syntax, Duplikate). Der Eintrag kann nicht ausgewertet werden.
• PTR (Pointer Record): DNS-Eintrag, der eine IP-Adresse einem Hostnamen zuordnet (Reverse-DNS). Wird von Empfangsservern verwendet, um die Identität des Versandservers zu prüfen.
• FCrDNS (Forward-confirmed reverse DNS): Zweistufige Prüfung. Der Reverse-DNS der IP ergibt einen Hostnamen, und die Auflösung dieses Hostnamens muss die ursprüngliche IP zurückgeben.
• Blacklist (DNSBL): DNS-basierte Sperrliste, die IP-Adressen verzeichnet, die bekannt dafür sind, Spam zu versenden. Die wichtigsten sind Spamhaus, Barracuda, SORBS und SpamCop.
• DKIM-Selektor: Bezeichner (Zeichenkette), der es ermöglicht, den öffentlichen DKIM-Schlüssel im DNS zu finden. Der Eintrag wird unter selektor._domainkey.captaindns.com veröffentlicht.
• RFC 7208: Offizielle Spezifikation des SPF-Protokolls, die die Syntax der Einträge, die Grenze von 10 Lookups, die Void-Lookups und die möglichen Ergebnisse definiert.
• ARC (Authenticated Received Chain): Protokoll, das die E-Mail-Authentifizierungsergebnisse über Zwischenrelays hinweg bewahrt (Mailinglisten, Weiterleitungen). Unterstützt von Gmail und Microsoft.
• RFC 8058: Spezifikation des Ein-Klick-Abmeldemechanismus (One-Click Unsubscribe) über den List-Unsubscribe-Post-Header, seit 2024 von Gmail für Massenversender vorgeschrieben.

---

Teste jetzt deine Zustellbarkeit: Verwende den Mail-Tester von CaptainDNS, um deinen Score auf 100 und die genaue Liste der anzuwendenden Korrekturen zu erhalten. Ein Test dauert 30 Sekunden und kann deine Zustellraten transformieren.

---

Quellen

• RFC 7208 - Sender Policy Framework (SPF)
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Google - Email sender guidelines (2024)
• Yahoo - Sender best practices and requirements
• Validity - 2025 Email Deliverability Benchmark Report