Warum Ihre E-Mails im Spam landen: Der vollständige Diagnose-Guide

⚡TL;DR

• 5 Hauptursachen: Authentifizierung (SPF/DKIM/DMARC), IP-/Domain-Reputation, verdächtiger Inhalt, schlechtes Engagement, technische Konfiguration
• Prioritäre Überprüfung: Testen Sie Ihre IP auf den wichtigsten Blocklisten und prüfen Sie Ihre Authentifizierung
• Seit 2024: Gmail und Yahoo verlangen SPF, DKIM und DMARC für Massenversender
• Ablehnungen durch Outlook.com im November 2026 (AS9031519): Ohne anwendbaren DMARC-Record ist das Hinzufügen von p=none der gemeldete Workaround. Ablehnungen werden auch gemeldet, wenn die SPF-, DKIM- und DMARC-Prüfungen bestanden werden: Ist Ihre Authentifizierung bereits korrekt, schreiben Sie Ihre Records nicht um, sondern folgen Sie dem Meldeverfahren im Abschnitt zu Outlook.com
• Ab November 2026: Spamhaus führt schrittweise die Anforderung eines gültigen HELO sowie übereinstimmender PTR- und A-Records für jede Versand-IP ein, andernfalls riskiert die IP, gelistet zu werden
• Kritischer Schwellenwert: Eine Beschwerderate über 0,1% löst die Spam-Klassifizierung aus
• Schnelldiagnose: Analysieren Sie Ihre E-Mail-Header, um das genaue Problem zu identifizieren

Warum Ihre E-Mails als Spam klassifiziert werden

Jeden Tag werden Milliarden von E-Mails durch Anti-Spam-Systeme gefiltert. Jede sechste E-Mail erreicht nie den Posteingang des Empfängers. Für Unternehmen ist das kritisch: nicht erhaltene Rechnungen, verlorene Bestellbestätigungen, ignorierte Kundenkommunikation.

Die Spam-Klassifizierung ist nicht zufällig. E-Mail-Anbieter (Gmail, Outlook, Yahoo) nutzen Hunderte von Signalen, um über das Schicksal jeder E-Mail zu entscheiden. Diese Signale zu verstehen ist der Schlüssel zur Lösung des Problems: Sie lassen sich auf fünf messbare Säulen zurückführen (Authentifizierung, Reputation, Transportsicherheit, BIMI, Engagement), die unser Leitfaden zum E-Mail-Zustellbarkeits-Score einzeln aufschlüsselt.

Dieser Guide analysiert die 5 Hauptursachen für die Spam-Klassifizierung und gibt Ihnen einen konkreten Aktionsplan für jede Situation. Ob Systemadministrator, Marketing-Verantwortlicher oder Entwickler - hier finden Sie die Antworten auf Ihre Fragen.

---

Ursache 1: Fehlende oder fehlerhafte E-Mail-Authentifizierung

Die E-Mail-Authentifizierung ist seit 2024 obligatorisch. Gmail, Yahoo und Apple haben angekündigt, dass nicht authentifizierte E-Mails systematisch abgelehnt oder als Spam klassifiziert werden.

Die 3 Authentifizierungsprotokolle

Protokoll	Funktion	Auswirkung bei Fehlen
SPF	Listet die autorisierten Server für Ihre Domain	Ablehnung oder Spam
DKIM	Signiert jede E-Mail kryptografisch	Spam oder Misstrauen
DMARC	Definiert die Richtlinie bei SPF/DKIM-Fehlern	Kein Schutz vor Spoofing; seit November 2026 gemeldete Ablehnungen durch Outlook.com (nicht die einzige gemeldete Situation)

Ihre Konfiguration überprüfen

Nutzen Sie einen Domain-E-Mail-Audit, um sofort zu prüfen, ob Ihre Domain korrekt konfiguriert ist:

1. Geben Sie Ihren Domainnamen ein
2. Prüfen Sie die SPF-, DKIM- und DMARC-Ergebnisse
3. Folgen Sie den Korrekturempfehlungen

Häufige SPF-Fehler

Fehler	Konsequenz	Lösung
Kein SPF-Record	E-Mails werden als Spam klassifiziert	TXT-Record mit v=spf1 erstellen
Zu viele Includes (>10 Lookups)	SPF ungültig (PermError)	Optimieren oder Flattening-Service nutzen
Fehlende IP	SPF-Fehler bei bestimmten Sendungen	IP oder Include des Dienstes hinzufügen
~all vs -all	Zu permissive Richtlinie	-all in Produktion verwenden

Häufige DKIM-Fehler

Fehler	Konsequenz	Lösung
Keine Signatur	E-Mail nicht authentifiziert	DKIM auf dem Mailserver konfigurieren
Schlüssel zu kurz (<1024 Bits)	Signatur gilt als schwach	2048-Bit-Schlüssel generieren
Falscher Selektor	Verifizierung schlägt fehl	DNS und Serverkonfiguration prüfen
Body modifiziert	Signatur ungültig	Zwischenrelays überprüfen

DMARC: Die Richtlinie, die alles ändert

DMARC ist der Dirigent der Authentifizierung. Ohne DMARC können Ihre E-Mails selbst mit gültigem SPF und DKIM als Spam klassifiziert oder schon während der SMTP-Transaktion abgelehnt werden. Eine Ablehnung legt nichts im Junk-Ordner ab: Der Absender erhält einen Unzustellbarkeitsbericht, und die Nachricht wird nicht zugestellt. Seit Anfang November 2026 melden Betreiber solche Ablehnungen bei Outlook.com für Domains ohne DMARC-Record. Die Meldungen aus dem November betreffen auch Domains, deren SPF, DKIM und DMARC als korrekt angegeben werden: Ein fehlender DMARC-Record erklärt nicht alle Fälle (Details im Abschnitt zu Outlook.com weiter unten).

# DMARC-Record mit p=none und aggregierten Berichten
_dmarc.captaindns.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"

# Strikter DMARC-Record (empfohlen für Produktion)
_dmarc.captaindns.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com"

Richtlinie	Verhalten	Empfehlung
p=none	Nur Überwachung	Anfangsphase (2-4 Wochen)
p=quarantine	Verdächtige E-Mails in Spam	Übergangsphase
p=reject	Verdächtige E-Mails abgelehnt	Sichere Produktion

---

Ursache 2: Beeinträchtigte IP- oder Domain-Reputation

Selbst mit perfekter Authentifizierung können Ihre E-Mails im Spam landen, wenn Ihre Reputation schlecht ist. E-Mail-Anbieter führen Reputations-Scores basierend auf der Sendehistorie.

Reputation verstehen

Die Reputation besteht aus zwei Elementen:

1. IP-Reputation: Score der IP-Adresse, die E-Mails sendet
2. Domain-Reputation: Score der Absender-Domain (From)

Faktor	Auswirkung auf die Reputation
Spam-Beschwerderate	Sehr hoch (Schwellenwert: 0,1%)
Bounce-Rate	Hoch (Schwellenwert: 5%)
Engagement (Öffnungen, Klicks)	Mittel
Domain-Historie	Mittel
Blocklisten	Kritisch

Prüfen, ob Ihre IP auf einer Blockliste steht

Eine IP auf einer wichtigen Blockliste (Spamhaus, Barracuda) wird ihre E-Mails systematisch abgelehnt von Gmail, Outlook und Yahoo sehen.

Um zu prüfen, ob Ihre IP gelistet ist, testen Sie sie gegen die wichtigsten DNSBLs:

• Spamhaus ZEN: Wird von den meisten großen Anbietern genutzt
• Barracuda BRBL: Sehr verbreitet in Unternehmen
• SpamCop: Basiert auf Nutzerberichten

Blocklisten mit Priorität überwachen

Blockliste	Auswirkung	Genutzt von
Spamhaus ZEN	Kritisch	Gmail, Yahoo, Outlook
Barracuda BRBL	Kritisch	Unternehmen, Barracuda-Filter
SpamCop	Hoch	Zahlreiche Anbieter
UCEProtect	Mittel	Anti-Spam-Filter

Reputation verbessern

Aktion	Auswirkung	Zeitrahmen
Delisting bei Blocklisten beantragen	Sofort	24-72h
Beschwerderate reduzieren	Hoch	2-4 Wochen
Hard Bounces entfernen, die die Adresse betreffen (unbekannter Benutzer, Postfach existiert nicht). Eine Ablehnung, die die Domain, die IP oder die Authentifizierung betrifft, wird an der Ursache behoben, ohne den Empfänger zu entfernen	Hoch	Sofort
Neue IPs schrittweise aufwärmen	Präventiv	4-6 Wochen

---

Ursache 3: Problematischer Inhalt

Anti-Spam-Filter analysieren den Inhalt jeder E-Mail. Bestimmte Elemente lösen automatisch eine Spam-Klassifizierung aus.

Zu vermeidende Wörter und Ausdrücke

Anti-Spam-Filter verwenden Listen verdächtiger Wörter. Hier die riskantesten Kategorien:

Kategorie	Beispiele	Risiko
Übermäßige Dringlichkeit	"DRINGEND", "Jetzt handeln", "Letzte Chance"	Hoch
Finanzielle Versprechen	"Kostenlos", "Geld verdienen", "Keine Gebühren"	Hoch
Verkaufsdruck	"Begrenztes Angebot", "Nur noch 24h", "Ausverkauft"	Mittel
Verdächtige Ausdrücke	"Hier klicken", "100% garantiert", "Keine Verpflichtung"	Mittel

E-Mail-Struktur

Problem	Warum es gefiltert wird	Lösung
100% Bild-E-Mail	Versteckter Text, Spammer-Technik	Verhältnis 60% Text / 40% Bilder
Kurz-Links (bit.ly)	Verbergen das Ziel	Vollständige URLs verwenden
Zu viele Links	Typisches Spam-Verhalten	Maximum 3-5 Links pro E-Mail
Keine Textversion	Nur HTML = verdächtig	Immer text/plain einschließen
Integrierte Formulare	Phishing-Technik	Links zur Website

Optimales HTML/Text-Verhältnis

Empfohlener Inhalt:
- Text: 60-80%
- Bilder: 20-40%
- Links: maximal 3-5
- Gesamtgröße: < 100 KB

---

Ursache 4: Schlechtes Empfänger-Engagement

E-Mail-Anbieter messen, wie Empfänger mit Ihren E-Mails interagieren. Geringes Engagement signalisiert unerwünschte Inhalte.

Signale für negatives Engagement

Signal	Auswirkung	Kritischer Schwellenwert
Spam-Beschwerden	Sehr hoch	>0,1% löst Spam aus
Hard Bounces	Hoch	>5% schädigt die Reputation
Wiederholte Soft Bounces	Mittel	>10% über 30 Tage
Niedrige Öffnungsrate	Mittel	<10% bei aktiven Listen
Hohe Abmelderaten	Mittel	>1% pro Kampagne

Der Spam-Teufelskreis

Geringes Engagement → Spam-Klassifizierung → Noch weniger Engagement → Beeinträchtigte Reputation

Um diesen Kreislauf zu durchbrechen:

1. Bereinigen Sie Ihre Listen: Entfernen Sie Adressen, die seit mehr als 6 Monaten inaktiv sind
2. Segmentieren Sie: Senden Sie relevante Inhalte an jedes Segment
3. Respektieren Sie die Einwilligung: Double Opt-in obligatorisch
4. Erleichtern Sie die Abmeldung: Sichtbarer Link, 1-Klick-Prozess

Best Practices für Listenhygiene

Aktion	Häufigkeit	Auswirkung
Hard Bounces entfernen, die die Adresse betreffen (unbekannter Benutzer, Postfach existiert nicht). Betrifft die Ablehnung die Domain, die IP oder die Authentifizierung: Ursache beheben und erneut senden, ohne die Liste anzutasten	Sofort	Kritisch
Spam-Beschwerden entfernen	Sofort	Kritisch
Inaktive bereinigen (>6 Monate)	Monatlich	Hoch
Re-Engagement der Lauen	Vierteljährlich	Mittel
E-Mail-Validierung bei Anmeldung	Kontinuierlich	Präventiv

---

Ursache 5: Mangelhafte technische Konfiguration

Technische Konfigurationsprobleme können all Ihre Bemühungen zunichtemachen.

Checkliste für Serverkonfiguration

Element	Überprüfung	Befehl
Reverse DNS (PTR)	Die IP muss zu einem FQDN auflösen	dig -x <IP>
FQDN zu IP	Der FQDN muss zur IP auflösen	dig A <fqdn>
HELO/EHLO	Muss zur sendenden IP auflösen und gleich bleiben	Server-Logs
Port 25 offen	Keine ISP-Blockierung	telnet mail.server.com 25
TLS aktiviert	STARTTLS obligatorisch	Verbindungstest

Reverse DNS: Warum es kritisch ist

Der Reverse DNS (PTR-Record) wird von allen großen Anbietern geprüft. Ohne gültigen PTR sind Ihre E-Mails sofort verdächtig.

# PTR Ihrer IP überprüfen
dig -x 192.0.2.1

# Erwartetes Ergebnis
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.captaindns.com.

# Der FQDN muss zur selben IP auflösen
dig A mail.captaindns.com
# Ergebnis: 192.0.2.1

HELO/EHLO-Konfiguration

Der Mailserver identifiziert sich mit HELO oder EHLO. Der dabei genannte Name muss:

1. Ein gültiger FQDN sein (keine IP, nicht "localhost", kein Standardname des Hosting-Anbieters)
2. Zur IP auflösen, die die E-Mail sendet (A-Record)
3. Bei allen Verbindungen von dieser IP aus gleich bleiben

Der PTR dieser IP zeigt seinerseits auf einen FQDN, der zur selben IP auflöst: Das ist FCrDNS (forward-confirmed reverse DNS).

# Schlecht
EHLO localhost
EHLO [192.0.2.1]
EHLO server1

# Gut
EHLO mail.captaindns.com

Spamhaus, November 2026. Ab November 2026 führt Spamhaus schrittweise eine Anforderung für jede Versand-IP ein: ein gültiger HELO, ein Reverse DNS (PTR) und ein übereinstimmender A-Record. Eine IP, die sie nicht erfüllt, riskiert, gelistet zu werden. Spamhaus nennt weder einen genauen Tag noch einen Zeitplan. Bei IPv6 muss die Absenderadresse zu einem /64-Block oder einem größeren Block mit gültigem Reverse DNS gehören. Prüfen Sie schon jetzt den PTR und den A-Record jeder Versand-IP mit den dig-Befehlen oben und danach den im HELO genannten Namen in den Logs Ihres Servers. Für eine konkrete Kontrolle senden Sie eine Nachricht an ein externes Postfach und lesen Sie den Received-Header, den der empfangende Server hinzufügt: Der Name nach from ist in der Regel der Name, den Ihr Server im HELO/EHLO nennt. Je nach empfangendem Server steht er stattdessen in Klammern, nach helo= oder HELO. Der weiter unten vorgestellte E-Mail-Header-Analyzer zeigt ihn an. Wenn Ihre Versandserver auch Ihre MX sind, meldet der SMTP/MX-Tester ein Banner, dessen Name nicht mit dem des MX übereinstimmt.

---

Diagnose nach Anbieter

Jeder Anbieter hat seine Besonderheiten. So diagnostizieren Sie Probleme bei den wichtigsten.

Gmail

Diagnose-Tools:

• Google Postmaster Tools: Domain- und IP-Reputation
• Gmail-Header: Suchen Sie nach X-Gm-Spam und X-Gm-Phishy

Gmail-Anforderungen 2024:

Kriterium	Volumen <5.000/Tag	Volumen >5.000/Tag
SPF oder DKIM	Obligatorisch	Obligatorisch
DMARC	Empfohlen	Obligatorisch
Beschwerderate	<0,3%	<0,1%
TLS	Empfohlen	Obligatorisch
1-Klick-Abmeldung	-	Obligatorisch

Häufige Fehlercodes:

Code	Bedeutung	Aktion
421 4.7.0	Zu viele Verbindungen	Rate reduzieren
550 5.7.1	DMARC-Richtlinie	SPF/DKIM korrigieren
550 5.7.26	Authentifizierungsfehler	SPF, DKIM prüfen

Outlook.com und Microsoft 365: Diagnosen auseinanderhalten

Microsoft nimmt E-Mails über zwei getrennte Dienste entgegen, die nicht immer gleich reagieren. Outlook.com ist der E-Mail-Dienst für Privatkunden (Adressen auf outlook.com, hotmail.com, live.com, msn.com). Microsoft 365 hostet geschäftliche E-Mail unter der eigenen Domain jedes Kunden. Der Name des ablehnenden Servers im Unzustellbarkeitsbericht (NDR) hilft zu erkennen, welcher Dienst antwortet: MailRoute beschreibt die Outlook.com-Server als olc.protection.outlook.com, und die von Spam Resource getestete Microsoft-365-Domain lief über einen Server unter mail.protection.outlook.com.

Diagnose-Tools:

• SNDS (Smart Network Data Services): IP-Reputation
• JMRP: Feedback Loop

Outlook-Besonderheiten:

• Nutzt Spamhaus und proprietäre Blocklisten
• Aggressives Filtern neuer Domains (<30 Tage)
• SNDS-Programm zur Reputationsüberwachung

Outlook.com (Privatkunden)

Die von Microsoft veröffentlichte Regel zielt auf Absender mit hohem Volumen. Eine Domain, die mehr als 5.000 Nachrichten pro Tag an Outlook.com sendet, muss SPF und DKIM bestehen, einen DMARC-Record veröffentlichen (mindestens p=none) und DMARC über ein SPF oder DKIM bestehen, das auf die From-Domain ausgerichtet ist. Die Ankündigung auf der Postmaster-Website von Outlook.com setzt den Start auf den 5. Mai 2025, zunächst mit Einordnung in den Junk-Ordner, danach mit Ablehnungen; die zugehörige Ablehnung ist 550 5.7.515.

Die gemeldete Ablehnung hat diese Form (MailRoute meldet auch eine Variante ohne den Code in Klammern):

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Im Unzustellbarkeitsbericht, der am 6. November auf Microsoft Q&A veröffentlicht wurde, steckt diese Ablehnung in einem anderen Code. Die Zeile "Error Details" lautet, nachdem der Moderator personenbezogene Daten entfernt hat:

Error: 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records

Der Bericht zeigt 550 5.7.23 als Statuscode, unter der Überschrift "SPF validation error". Der zugehörige Hilfetext spricht nur von SPF: den Record prüfen, nur einen veröffentlichen, spf.protection.outlook.com darin aufnehmen. Die eigentliche Diagnose steht nach dem Pfeil: Es ist das 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records", das Hornblower409 dem AS9031519 zuordnet. Diese Vorlage beweist nicht, dass Ihr SPF falsch ist. Im selben Thread meldet Martin genau diese Hülle, obwohl SPF, DKIM und DMARC nach eigener Angabe seit Jahren korrekt sind.

Wenn Sie diese Ablehnung erhalten, lesen und sichern Sie zuerst den vollständigen Bericht: äußerer Code, innerer Text, ablehnender Server und gegebenenfalls AS9031519. Suchen Sie dann nach dem DMARC-Record unter _dmarc.<domain>. Bei einer Subdomain prüfen Sie auch den Record der übergeordneten Domain, dessen Richtlinie gelten kann. Sie können den veröffentlichten DMARC-Record prüfen, ohne die Kommandozeile zu nutzen. Eine DNS-Abfrage, die kein Ergebnis liefert (Zeitüberschreitung, Serverfehler), beweist nicht, dass kein Record existiert: Wiederholen Sie sie, bevor Sie einen Schluss ziehen. Diese Prüfung zeigt, was veröffentlicht ist, nicht das SPF- oder DKIM-Ergebnis einer bestimmten Nachricht.

Wenn für die Domain kein DMARC-Record gilt:

1. Veröffentlichen Sie einen TXT-Record unter _dmarc.<domain> mit dem Wert v=DMARC1; p=none. Viele DNS-Hoster hängen die Domain selbst an: Geben Sie dann nur _dmarc als Namen ein. Eine Domain hat nur einen DMARC-Record. Legen Sie also keinen zweiten unter demselben Namen an, und ersetzen Sie keine strengere Richtlinie, die bereits funktioniert.
2. Prüfen Sie, ob mindestens SPF oder DKIM besteht und auf die Domain der angezeigten Absenderadresse (From) ausgerichtet ist. Ein DMARC-Record ohne ausgerichtete Authentifizierung schlägt trotzdem fehl. Um das Alignment zu kontrollieren, senden Sie eine Nachricht an ein anderes Postfach und lesen Sie dort den Header Authentication-Results (siehe E-Mail-Header lesen).
3. Warten Sie, bis die DNS-Caches abgelaufen sind: Server behalten eine Zeit lang den alten Record im Speicher, oder die Information, dass keiner existierte. Bei einem alten Record entspricht diese Dauer seiner TTL, die in Ihrer DNS-Zone festgelegt ist. Gab es keinen Record, hängt die Dauer, während der Server dieses Fehlen speichern, vom SOA-Record Ihrer Zone ab (Negative Caching, RFC 2308), nicht von der TTL des neuen Records. Senden Sie die abgelehnten Nachrichten danach erneut. Ein 550 ist ein dauerhafter Fehler, Ihr Server wiederholt den Versand nicht.

Das Hinzufügen von p=none wird für einige Domains ohne DMARC als Workaround gemeldet (Hornblower409 und Cameron Scott im Microsoft-Q&A-Thread), nicht als Behebung des Problems im Microsoft-Dienst. p=none verlangt im Rahmen der DMARC-Richtlinie weder Quarantäne noch Ablehnung. Es garantiert jedoch weder die Annahme durch Outlook.com noch die Zustellung in den Posteingang.

Wenn SPF, DKIM und DMARC bereits korrekt sind und Ihre Nachrichten die Authentifizierung bestehen:

1. Schreiben Sie eine korrekte Konfiguration nicht um, nur um auf den Text des Berichts zu reagieren. Veröffentlichen Sie keinen zweiten SPF-Record: Zwei SPF-Records führen zu einem PermError (siehe den SPF-PermError-Leitfaden). Fügen Sie auch nicht include:spf.protection.outlook.com hinzu, nur weil der Bericht es vorschlägt: Ihr SPF muss die Dienste autorisieren, die tatsächlich für Ihre Domain senden.
2. Bewahren Sie den vollständigen Bericht und die technischen Angaben auf, und melden Sie die Ablehnung dann dem Microsoft Sender Support. Diesen Weg empfiehlt Hornblower409, wenn die mit AS9031519 abgelehnten Nachrichten die Authentifizierung bestehen.
3. Für Unternehmen bat Daniel-Vo am 9. November darum, dem Microsoft-365-Support aktuelle Network Message IDs, die Protokolle der betroffenen Nachrichten und Beispiele im .eml-Format zu übermitteln. Diese Angaben gehören an den Support, nicht in ein öffentliches Forum.
4. Versuchen Sie es später erneut, ohne Erfolgsgarantie. Die Ablehnungen werden als zeitweise auftretend gemeldet, aber ein 550 bleibt ein dauerhafter Fehler: Ihr Server wiederholt den Versand nicht, Sie müssen die Nachricht selbst erneut senden.

Ein Pass-Ergebnis bei einer anderen Nachricht oder bei einem anderen Empfänger hilft bei der Diagnose, beweist aber nicht das Urteil des Outlook.com-Servers, der Ihre Nachricht abgelehnt hat. Da die Ablehnungen nur einen Teil der Nachrichten betreffen, beweist ein angenommener erneuter Versand auch nicht, dass die Konfiguration korrekt ist, warnt MailRoute: Prüfen Sie die Records statt des Ergebnisses eines einzelnen Versands.

Microsoft 365 (Unternehmen)

Microsoft 365 wendet eigene Filtermechanismen an. Es fügt ein proprietäres compauth-Verdikt im Header Authentication-Results hinzu; ein compauth=fail erhöht das Risiko, im Junk-Ordner zu landen (siehe den Microsoft-365-Compauth-Leitfaden). Beim Test von Al Iverson (Spam Resource) am 7. November 2026 wurde die an outlook.com abgelehnte Nachricht von der getesteten Microsoft-365-Domain angenommen. Dieser einzelne Test zeigt weder, dass bei Microsoft 365 gehostete Empfänger geschützt sind, noch, dass sie von demselben Vorfall betroffen sind. Microsoft-365-Kunden können dagegen als Absender betroffen sein, wenn sie an Outlook.com schreiben: An sie richtet sich die oben zitierte Support-Anfrage von Daniel-Vo. Lesen Sie immer den vollständigen Text des NDR.

Fehlercodes von Outlook.com und Microsoft 365

Code	Bedeutung	Aktion
550 5.7.1	Generische Ablehnung: den vollständigen Text des NDR lesen	Delisting nur beantragen, wenn der Text eine IP-Sperre nennt, und dabei dem dort angegebenen Verfahren folgen
550 5.7.1 mit "Message lacks SPF/DKIM/DMARC Auth Records"	Seit November 2026 gemeldete Ablehnung durch Outlook.com bei Domains ohne DMARC, aber auch bei Domains, deren Authentifizierung erfolgreich ist	DMARC-Record und SPF- oder DKIM-Alignment prüfen, ohne allein aus dem Wortlaut auf einen Fehler zu schließen. Ohne DMARC: p=none veröffentlichen, dann erneut senden. Wenn alle Prüfungen bestanden werden: an Microsoft Sender Support melden
550 5.7.23, wenn er die Diagnose AS9031519 begleitet	SPF-bezogene Hülle um die Ablehnung 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records" (auf Microsoft Q&A veröffentlichte Berichte, November 2026). Allein signalisiert dieser Code einen SPF-Fehler und beweist diesen Vorfall nicht	Vor jeder SPF-Änderung die Diagnose nach dem Pfeil lesen, dann der passenden Situation folgen (DMARC fehlt oder Authentifizierung bereits korrekt)
550 5.7.515	Erforderliches Authentifizierungsniveau nicht erreicht (Absender mit hohem Volumen an Outlook.com)	Gültiges SPF und DKIM, veröffentlichtes DMARC, Alignment auf die From-Domain
550 5.7.606	IP mit niedriger Reputation	SNDS prüfen und dem im NDR angegebenen Delisting-Verfahren folgen. Die Ablehnung betrifft die IP: abgelehnte Empfänger nicht entfernen
421 4.7.0	Rate-Limit	Sendungen reduzieren

Yahoo / AOL

Diagnose-Tools:

• Yahoo Sender Hub: Reputation und Richtlinien
• Complaint Feedback Loop: Beschwerden in Echtzeit

Yahoo-Anforderungen 2024:

Kriterium	Erforderlich
SPF	Obligatorisch
DKIM	Obligatorisch
DMARC	Obligatorisch für >5.000 E-Mails/Tag
1-Klick-Abmeldung	Obligatorisch
Beschwerderate	<0,3%

---

Empfohlener Aktionsplan

Schritt 1: Sofortdiagnose (30 Minuten)

1. Testen Sie Ihre IP auf den wichtigsten Blocklisten
2. Überprüfen Sie die Authentifizierung (SPF, DKIM, DMARC) Ihrer Domain
3. Analysieren Sie eine problematische E-Mail anhand ihrer Header mit dem E-Mail-Header-Analyzer

Wenn Ihre Nachrichten abgelehnt statt als Spam eingestuft werden, gehen Sie vor jedem Delisting-Antrag vom genauen Text des NDR aus. Derselbe Code 550 5.7.1 deckt mehrere Ursachen ab. "Message lacks SPF/DKIM/DMARC Auth Records" zielt nicht auf Ihre IP: Prüfen Sie DMARC und das Alignment, ohne allein aus dem Wortlaut auf einen Fehler zu schließen. Ablehnungen werden auch bei bestandener Authentifizierung gemeldet; folgen Sie in diesem Fall dem Verfahren "Authentifizierung bereits korrekt" im Abschnitt zu Outlook.com. Ein Delisting ist nur gerechtfertigt, wenn der Text die IP oder eine Blockliste nennt.

Schritt 2: Prioritäre Korrekturen (1-2 Tage)

1. Beantragen Sie Delisting bei Blocklisten (Spamhaus, Barracuda als Priorität)
2. Korrigieren Sie erkannte Authentifizierungsfehler
3. Konfigurieren Sie Reverse DNS falls fehlend

Schritt 3: Kontinuierliche Verbesserung (2-4 Wochen)

1. Melden Sie sich bei Feedback Loops an (Gmail, Outlook, Yahoo)
2. Überwachen Sie die Beschwerderaten (Ziel <0,1%)
3. Bereinigen Sie Ihre Listen: Entfernen Sie Adressen, die seit mehr als 6 Monaten inaktiv sind, sowie Hard Bounces, deren Ablehnung die Adresse betrifft (unbekannter Benutzer, Postfach existiert nicht). Betrifft die Ablehnung Ihre Domain, Ihre IP oder Ihre Authentifizierung, beheben Sie die Ursache und senden Sie erneut, ohne den Empfänger zu entfernen
4. Richten Sie regelmäßiges Blocklisten-Monitoring ein

Schritt 4: Langfristige Prävention

1. Double Opt-in für alle Anmeldungen
2. Einfache Abmeldung (1-Klick, List-Unsubscribe-Header)
3. Automatisiertes Monitoring von Blocklisten und Reputation
4. Vierteljährliches Audit der E-Mail-Konfiguration

---

FAQ

Warum landen meine E-Mails im Spam, obwohl ich SPF und DKIM konfiguriert habe?

SPF und DKIM allein reichen nicht aus. Seit 2024 verlangen Gmail und Yahoo von Massenversendern auch DMARC. Bei Outlook.com werden seit Anfang November 2026 Ablehnungen von Domains ohne DMARC gemeldet, auch bei geringem Volumen, aber ebenso von Domains, deren Authentifizierung erfolgreich ist; am 9. November brachte ein Moderator von Microsoft Q&A sie mit einer Dienstbeeinträchtigung in Verbindung (siehe nächste Frage). Prüfen Sie außerdem, ob Ihre IP nicht auf einer Blockliste steht und ob Ihre Beschwerderate unter 0,1% liegt. Ein Fehler bei einem dieser Punkte kann Spam auslösen, selbst bei teilweiser Authentifizierung.

Warum lehnt Outlook.com meine E-Mails mit AS9031519 ab, obwohl SPF und DKIM gültig sind?

Seit Anfang November 2026 werden zwei Situationen gemeldet. Betreiber (Mailop-Liste, MailRoute, Spam Resource) beobachten diese Ablehnung bei Domains ohne DMARC-Record; Teilnehmer des Microsoft-Q&A-Threads "SPF Validation Error" melden sie außerdem zeitweise, obwohl SPF, DKIM und DMARC bestehen. Am 9. November 2026 beschrieb Daniel-Vo, in diesem Thread als "Microsoft External Staff" und Moderator ausgewiesen, ein Problem des Exchange-Dienstes bei Nachrichten an Outlook.com, Hotmail.com und Live.com, eingestuft als "service degradation", dessen Ursache noch untersucht wurde. Das ist weder ein Service-Health-Eintrag noch eine neu veröffentlichte Regel. Der Unzustellbarkeitsbericht kann 550 5.7.23 und die Überschrift "SPF validation error" zeigen: Lesen Sie die Diagnose nach dem Pfeil, bevor Sie SPF ändern. Gilt kein DMARC-Record, veröffentlichen Sie einen TXT-Record v=DMARC1; p=none unter _dmarc.<domain>, prüfen Sie, ob SPF oder DKIM besteht und auf die From-Domain ausgerichtet bleibt, und senden Sie die abgelehnten Nachrichten dann erneut: Ein 550 ist endgültig, Ihr Server wiederholt den Versand nicht. p=none ist ein gemeldeter Workaround ohne Garantie auf Annahme. Besteht die Authentifizierung bereits, schreiben Sie Ihre Records nicht um: Bewahren Sie den vollständigen Bericht auf, und melden Sie die Ablehnung dem Microsoft Sender Support.

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

Nutzen Sie einen Blocklisten-Checker, der Ihre IP gegen die wichtigsten Listen testet (Spamhaus, Barracuda, SpamCop). Der Test deckt über 25 Blocklisten gleichzeitig ab und liefert Delisting-Links für jede betroffene Liste. Testen Sie Ihre IP sofort, wenn Ihre E-Mails abgelehnt oder als Spam klassifiziert werden.

Wie lange dauert es, von einer Blockliste entfernt zu werden?

Die Fristen variieren je nach Blockliste: SpamCop entlistet automatisch in 24-48h ohne neue Meldung. Spamhaus bearbeitet manuelle Anfragen in 24-48h. Barracuda antwortet in 12-24h. UCEProtect hat eine Frist von 7 Tagen. In allen Fällen muss das ursprüngliche Problem behoben werden, bevor Sie Delisting beantragen.

Meine E-Mails landen nur bei Gmail im Spam, warum?

Gmail ist seit Februar 2024 besonders streng. Prüfen Sie folgende Punkte: (1) Ist DMARC mit mindestens p=none konfiguriert? (2) Liegt die Beschwerderate unter 0,1%? (3) Ist die 1-Klick-Abmeldung für Massen-E-Mails implementiert? Nutzen Sie Google Postmaster Tools, um Ihre Domain-Reputation bei Gmail zu sehen.

Wie kann ich meine Zustellrate schnell verbessern?

Sofortmaßnahmen: (1) Überprüfen Sie und korrigieren Sie Ihre SPF/DKIM/DMARC-Authentifizierung. (2) Testen Sie Ihre IP auf Blocklisten und beantragen Sie bei Bedarf Delisting. (3) Entfernen Sie aus Ihrer Liste die Hard Bounces, deren Ablehnung die Adresse betrifft (unbekannter Benutzer, Postfach existiert nicht), sowie Kontakte, die seit mehr als 6 Monaten inaktiv sind. Betrifft die Ablehnung Ihre Domain, Ihre IP oder Ihre Authentifizierung, beheben Sie die Ursache und senden Sie erneut, bevor Sie die Liste anfassen. (4) Reduzieren Sie Sendungen an Adressen, die nie öffnen. Diese Maßnahmen können die Zustellbarkeit in 1-2 Wochen verbessern.

Was ist eine akzeptable Beschwerderate?

Der kritische Schwellenwert liegt bei 0,1% (1 Beschwerde pro 1.000 E-Mails). Darüber beginnen Gmail und Yahoo, Ihre E-Mails als Spam zu klassifizieren. Google empfiehlt, unter 0,05% zu bleiben für optimale Zustellbarkeit. Überwachen Sie diese Rate über Feedback Loops und Google Postmaster Tools.

Mein Mailserver ist richtig konfiguriert, aber meine E-Mails landen trotzdem im Spam?

Wenn die technische Konfiguration korrekt ist, liegt das Problem wahrscheinlich an: (1) Der Reputation Ihrer IP oder Domain (prüfen Sie Blocklisten). (2) Dem Inhalt Ihrer E-Mails (Trigger-Wörter, Bild/Text-Verhältnis). (3) Dem Engagement der Empfänger (niedrige Öffnungsrate, Beschwerden). Analysieren Sie Ihre Header, um den auslösenden Faktor zu identifizieren.

Wie wärme ich eine neue IP für den E-Mail-Versand auf?

Das IP-Warming besteht darin, das Sendevolumen über 4-6 Wochen schrittweise zu erhöhen. Beginnen Sie mit 50-100 E-Mails/Tag an Ihre engagiertesten Empfänger, dann verdoppeln Sie das Volumen jede Woche. Überwachen Sie Bounces und Beschwerden. Gehen Sie niemals von 0 auf Tausende E-Mails/Tag, sonst lösen Sie Anti-Spam-Filter aus.

Was ändert die HELO/PTR-Anforderung von Spamhaus ab November 2026?

Ab November 2026 führt Spamhaus schrittweise eine Anforderung für jede Versand-IP ein: ein Reverse DNS (PTR), der auf einen FQDN zeigt, der seinerseits zur selben IP auflöst (A-Record), sowie ein HELO/EHLO-Name, der zur sendenden IP auflöst und von einer Verbindung zur nächsten gleich bleibt. Laut Spamhaus ist ein fehlender oder nicht übereinstimmender Reverse DNS einer der häufigsten Gründe, das Listing einer IP in Betracht zu ziehen. Spamhaus hat weder einen genauen Tag noch einen Zeitplan veröffentlicht: Es handelt sich um eine schrittweise Einführung, nicht um eine Abschaltung zu einem festen Datum. Bei IPv6 muss die Absenderadresse in einem /64-Block oder einem größeren Block liegen und einen gültigen Reverse DNS haben.

---

Glossar

• DNSBL (DNS-based Blackhole List): Blockliste von IPs, die per DNS-Abfrage konsultiert werden kann. Auch RBL (Realtime Blackhole List) genannt.
• SPF (Sender Policy Framework): DNS-Record, der die autorisierten Server für den E-Mail-Versand einer Domain auflistet.
• DKIM (DomainKeys Identified Mail): Kryptografische Signatur, die E-Mails hinzugefügt wird, um ihre Authentizität zu beweisen.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Richtlinie, die die Behandlung von E-Mails definiert, die bei SPF/DKIM durchfallen.
• Hard Bounce: Dauerhafter Zustellfehler (Code 5xx). Die Adresse existiert möglicherweise nicht, die Ablehnung kann aber auch Ihre Domain oder Ihre Authentifizierung betreffen. Der sendende Server versucht es nicht erneut: Senden Sie die Nachricht nach der Korrektur erneut. Bevor Sie eine Adresse aus Ihren Listen entfernen, prüfen Sie, ob die Ablehnung wirklich sie betrifft.
• Soft Bounce: E-Mail, die vorübergehend abgelehnt wurde (Postfach voll, Server nicht verfügbar).
• Feedback Loop: Programm, das Absendern ermöglicht, Spam-Meldungen der Empfänger zu erhalten.
• Reverse DNS (PTR): DNS-Eintrag, der eine IP-Adresse einem Domainnamen zuordnet.
• FQDN (Fully Qualified Domain Name): Vollständiger Domainname (z.B.: mail.captaindns.com).
• IP-Reputation: Score, der einer IP-Adresse basierend auf ihrer Sendehistorie zugewiesen wird.

---

Verwandte Blocklisten-Guides

• So entfernen Sie Ihre IP von einer Blockliste: Der vollständige Delisting-Guide: Detaillierte Verfahren für Spamhaus, Barracuda, SpamCop und mehr
• Spamhaus vs Barracuda vs SpamCop: Vergleich: Die 3 wichtigsten Blacklists erklärt

---

Quellen

• Google Email Sender Guidelines (2024) (offizielle Gmail-Anforderungen)
• Yahoo Sender Best Practices (Yahoo/AOL-Richtlinien)
• Microsoft 365 Anti-Spam Protection (Outlook-Dokumentation)
• Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com (offizielle Regel für Absender mit hohem Volumen an Outlook.com)
• Outlook.com Postmaster (Ankündigung der Anforderungen für Absender mit hohem Volumen, Start am 5. Mai 2025, eingesehen am 8. November 2026)
• Spam Resource - Microsoft newly rejecting mail lacking DMARC? (7. November 2026) (Beobachtungen und Tests von Al Iverson)
• Mailop - Microsoft requiring DMARC now or just us? (Erfahrungsberichte von Betreibern, November 2026)
• MailRoute - 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (6. November 2026) (Erfahrungsbericht eines Relay-Anbieters)
• Microsoft Q&A - SPF Validation Error (Thread eröffnet am 6. November 2026) (Support-Austausch, keine normative Dokumentation: Erklärung von Daniel-Vo, Microsoft External Staff und Moderator, vom 9. November 2026, Antwort des ehrenamtlichen Moderators Hornblower409 und Erfahrungsberichte von Nutzern; eingesehen am 10. November 2026)
• The Register - Outlook.com bounces legit emails as Microsoft's authentication crackdown goes sideways (9. November 2026) (Presseartikel)
• RFC 7489 - DMARC (technische Spezifikation)
• Spamhaus - Understanding DNSBLs (Funktionsweise von Blocklisten)
• Spamhaus Sender Guidelines (HELO-, PTR- und A-Anforderungen für Versand-IPs)