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 Sie sie beheben

Sie haben 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 % Ihrer E-Mails haben den Posteingang nie erreicht. Keine Bounces. Keine sichtbaren Fehler. Ihre 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 Ihre DNS-Konfiguration (SPF, DKIM, DMARC), prüft die Reputation Ihrer IP, kontrolliert Ihre E-Mail-Header und erzeugt einen Gesamtscore auf 100. In 30 Sekunden wissen Sie genau, was funktioniert und was Ihre E-Mails blockiert.

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

Warum Sie die Zustellbarkeit vor jedem Versand testen sollten

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 Ihre E-Mails eine erhebliche Wahrscheinlichkeit haben, als Spam eingestuft zu werden. Unter 50/100 werden die meisten Anbieter Ihre Nachrichten ablehnen oder filtern.

Diese fünf Prüfungen betreffen Konfiguration und Authentifizierung; auch Absender-Reputation, Transportsicherheit und das Engagement Ihrer Empfänger wirken sich auf die Zustellung aus, wie unser Leitfaden zum E-Mail-Zustellbarkeits-Score im Detail zeigt.

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 Ihre 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 Ihrer 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 Ihre 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 Ihren 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 Ihr SPF gilt als ungültig.

# Prüfen, wie viele Lookups Ihr 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, UCEProtect, SpamCop). Ein Eintrag auf einer einzigen großen Blacklist kann ausreichen, damit die meisten Anbieter Ihre 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 lesen Sie jeden Abschnitt und identifizieren die prioritären Maßnahmen.

Abschnitt SPF (25 Punkte)

Ergebnis	Punkte	Bedeutung	Maßnahme
pass	25/25	Die Versand-IP ist durch Ihren 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 Ihren 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	Öffentlicher 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. Sehen Sie sich 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 Sie einen VPS oder Dedicated Server verwenden, konfigurieren Sie den PTR über das Panel Ihres Hosters. Wenn Sie einen Versanddienst (SendGrid, Mailgun, Brevo) verwenden, 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

Sie haben 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 Ihr SPF fehlt oder ungültig ist, bringt diese Korrektur sofort die meisten Punkte.

Fall 1: Kein SPF-Eintrag

Erstellen Sie einen DNS-TXT-Eintrag auf Ihrer Root-Domain:

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

Passen Sie die Mechanismen an Ihre 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:spf.brevo.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 Ihres 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 Sie nicht mehr nutzen

Für einen ausführlichen Leitfaden zum PermError sehen Sie sich 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 Sie zwei haben, 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ühren Sie 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ählen Sie Ihre Domain und klicken Sie auf "Neuen Eintrag generieren"
3. Wählen Sie eine Schlüssellänge von 2048 Bit
4. Kopieren Sie den bereitgestellten DNS-CNAME- oder TXT-Eintrag
5. Veröffentlichen Sie ihn in Ihrer DNS-Zone im Format google._domainkey.captaindns.com
6. Gehen Sie zurück zur Konsole und klicken Sie 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: Verwenden Sie 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: Überwachung (2 bis 4 Wochen)

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

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 Ihre Domain versendet haben.

Analysieren Sie 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; t=y; rua=mailto:dmarc-rua@captaindns.com"

Das t=y ist der Testmodus von DMARCbis: Empfänger melden die Fehlschläge, wenden die Quarantäne aber noch nicht an. Das ist ein Sicherheitsnetz: Wenn eine legitime Quelle noch nicht korrigiert wurde, kommen ihre E-Mails weiterhin durch. Entfernen Sie t=y, sobald die Berichte keine legitimen Fehlschläge mehr zeigen.

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"

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 Ihre Domain keinen MX-Eintrag hat, fügen Sie einen hinzu, der auf Ihren Empfangsserver zeigt:

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

Reverse-DNS: Melden Sie sich im Administrationspanel Ihres Hosters an und konfigurieren Sie den PTR Ihrer Versand-IP so, dass er auf den FQDN Ihres Mailservers zeigt:

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

Blacklists: Wenn Ihre 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
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 Ihrer 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 Sie PHP mail() verwenden, wechseln Sie zu einer Bibliothek wie PHPMailer oder SwiftMailer, die konforme Header erzeugt. Wenn Sie ein Framework (Laravel, Django, Rails) verwenden, 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 Ihrer Situation ab:

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

Wenn Ihre E-Mails trotz dieser Korrekturen weiterhin im Spam landen, geht das Problem über SPF hinaus. Sehen Sie sich 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 Fußzeile 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-Fußzeile hinzu, die die Signatur bricht

Die Korrektur besteht darin, zu identifizieren, welche Komponente Ihrer Versandkette die Nachricht nach der DKIM-Signierung verändert, und dann die Reihenfolge der Operationen so umzukonfigurieren, dass die Änderung 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: Sie versenden von contact@captaindns.com, aber Ihr 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:

• Konfigurieren Sie Ihren Dienstleister so, dass er mit d=captaindns.com signiert (DKIM aligned)
• Konfigurieren Sie den Return-Path (SMTP-Envelope) so, dass eine Subdomain Ihrer 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

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

• Geteilte IP: Wenn Sie auf einer geteilten IP mit anderen Kunden Ihres Hosters sind, kann Spam eines anderen Kunden Sie betreffen
• Kompromittierung: Ein Skript auf Ihrem Server versendet ohne Ihr Wissen Spam (ausgenutztes Kontaktformular, kompromittiertes E-Mail-Konto)
• IP-Historie: Die IP, die Sie gerade erhalten haben, 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

Beachten Sie, 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.

Senden Sie eine Test-E-Mail an die vom Mail-Tester bereitgestellte Adresse, sehen Sie sich den Bericht an und beheben Sie 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. Sie müssen 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 Sie den Traffic umschalten
• Altes SPF-Include 48 Stunden beibehalten (E-Mails im Transit)

3. Nach einer DNS-Änderung

Jede Änderung Ihrer DNS-Zone kann die Zustellbarkeit beeinträchtigen: TTL-Änderung, 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 Sie die Ursache im Inhalt oder im Betreff der E-Mails suchen, testen Sie Ihre 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 Ihre Versendungen beeinträchtigen. Planen Sie eine monatliche Erinnerung und prüfen Sie, ob Ihr Score bei 100/100 bleibt.

Empfohlener Aktionsplan

1. Führen Sie einen Zustellbarkeitstest durch mit dem Mail-Tester von CaptainDNS. Senden Sie eine Test-E-Mail und erhalten Sie Ihren detaillierten Score Abschnitt für Abschnitt.

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

3. Prüfen Sie Ihre Korrekturen, indem Sie den Test nach jeder DNS-Änderung erneut ausführen. Warten Sie auf die DNS-Propagierung (5 bis 60 Minuten je nach TTL), bevor Sie erneut testen.

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

5. Planen Sie 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 Ihrer E-Mails analysiert, indem es Ihre DNS-Konfiguration (SPF, DKIM, DMARC), die Reputation Ihrer Versand-IP, Ihre E-Mail-Header und das eventuelle Vorhandensein Ihrer IP auf Blacklists prüft. Sie senden 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?

Streben Sie einen Score von 100/100 an. Ein Score über 80/100 ist für die meisten transaktionalen Versendungen akzeptabel. Unter 70/100 haben Ihre E-Mails eine erhebliche Wahrscheinlichkeit, als Spam eingestuft zu werden. Unter 50/100 werden die meisten Anbieter (Gmail, Outlook, Yahoo) Ihre 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. Über 10 hinaus gibt der Server einen PermError zurück und Ihr 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 Ihr Versanddienstleister mit seiner eigenen DKIM-Domain signiert und seine eigene Adresse in der SMTP-Envelope verwendet, ist weder SPF noch DKIM mit Ihrer From-Domain aligned. Konfigurieren Sie Ihren Anbieter so, dass er Ihre 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) Ihrer DNS-Einträge ab. Ein TTL von 300 Sekunden (5 Minuten) bedeutet, dass Empfangsserver Ihre Änderung in weniger als 5 Minuten sehen. Ein TTL von 86400 (24 Stunden) kann bis zu 24 Stunden dauern. Bevor Sie einen kritischen Eintrag ändern, reduzieren Sie zuerst den TTL auf 300, warten Sie auf die Propagierung dieses neuen TTLs und führen Sie dann die Änderung durch.

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

Fragen Sie 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üfen Sie, ob die DNS-Propagierung abgeschlossen ist (warten Sie mindestens den TTL Ihrer Einträge ab). Testen Sie 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 Übereinstimmung 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 Übereinstimmung) 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, SpamCop und UCEProtect.
• 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.

---

Testen Sie jetzt Ihre Zustellbarkeit: Verwenden Sie den Mail-Tester von CaptainDNS, um Ihren Score auf 100 und die genaue Liste der anzuwendenden Korrekturen zu erhalten. Ein Test dauert 30 Sekunden und kann Ihre 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