E-Mails landen im Spam: Ursachen für Firmen finden
Wenn Angebote und Rechnungen im Spam-Ordner der Kunden verschwinden, liegt es selten am Inhalt. Welche technischen Ursachen dahinterstecken, wie Sie die Ursache im Mail-Header selbst ablesen – und warum das eigene Kontaktformular oft der Auslöser ist.
Warum Firmen-E-Mails im Spam landen
Firmen-E-Mails landen meist deshalb im Spam, weil der empfangende Server nicht nachprüfen kann, dass die Nachricht wirklich von Ihrer Domain stammt. Fehlen die Einträge für SPF, DKIM und DMARC oder passen sie nicht zueinander, behandeln Gmail, Outlook.com, GMX und Web.de die Mail wie jede andere ungeprüfte Nachricht – und ungeprüfte Nachrichten sind in der Masse Spam.
Die zweithäufigste Ursache ist der Ruf: der Ruf der sendenden IP-Adresse, der Ruf der Domain und das Verhalten der Empfänger. Wer Nachrichten verschickt, die viele Empfänger als Spam melden, verliert diesen Ruf für alle weiteren Nachrichten, auch für die Rechnung an den Stammkunden.
Inhaltliche Gründe wie Reizwörter oder viele Ausrufezeichen spielen heute eine kleinere Rolle, als die meisten Ratgeber nahelegen. Moderne Filter bewerten zuerst, wer sendet, und erst danach, was gesendet wird. Die Fehlersuche beginnt deshalb bei der Technik, nicht beim Betreff.
SPF, DKIM und DMARC: was die drei Einträge prüfen
SPF, DKIM und DMARC sind drei DNS-Einträge, die gemeinsam belegen, dass eine E-Mail von einem berechtigten Server Ihrer Domain kommt und unterwegs nicht verändert wurde. SPF (RFC 7208) listet die Server, die für Ihre Domain senden dürfen. DKIM (RFC 6376) versieht jede Nachricht mit einer Signatur, die der Empfänger mit einem öffentlichen Schlüssel aus Ihrem DNS prüft.
DMARC (RFC 7489) verbindet beides mit der Absenderadresse, die der Empfänger tatsächlich sieht. Ein SPF- oder DKIM-Ergebnis zählt für DMARC nur, wenn die geprüfte Domain zur sichtbaren From-Adresse passt – diese Übereinstimmung heißt Alignment. Zusätzlich legt DMARC fest, was mit durchgefallenen Nachrichten geschehen soll: nichts (p=none), in Quarantäne (p=quarantine) oder ablehnen (p=reject).
Ein typischer Fehler in gewachsenen Firmen ist ein SPF-Eintrag, der zu viele Dienste einbindet. Die Norm begrenzt die Mechanismen, die weitere DNS-Abfragen auslösen, auf zehn. Wer Microsoft 365, ein Newsletter-Tool, das CRM, den Shop und das Ticketsystem jeweils per include einträgt, überschreitet diese Grenze schnell – und dann scheitert SPF für alle Nachrichten, nicht nur für den zuletzt hinzugefügten Dienst.
Die Anforderungen von Google, Yahoo und Microsoft
Google und Yahoo verlangen seit dem 1. Februar 2024 von jedem Absender mindestens SPF oder DKIM, gültige Forward- und Reverse-DNS-Einträge für die sendenden Server und eine Spamrate unter 0,3 Prozent. Wer mehr als 5.000 Nachrichten pro Tag an Gmail-Konten schickt, gilt als Bulk-Sender und braucht SPF und DKIM gemeinsam, einen DMARC-Eintrag – p=none genügt – und eine Abmeldung mit einem Klick nach RFC 8058 für Marketingnachrichten.
Google empfiehlt in seiner Absender-FAQ, die Spamrate unter 0,1 Prozent zu halten und Abmeldungen innerhalb von 48 Stunden zu verarbeiten; Yahoo nennt zwei Tage. Seit November 2025 setzt Gmail die Regeln nach eigener Aussage verschärft durch: Nachrichten, die die Anforderungen nicht erfüllen, können vorübergehend oder dauerhaft abgelehnt werden, nicht mehr nur im Spam-Ordner landen.
Microsoft zog am 5. Mai 2025 für Outlook.com, Hotmail.com und Live.com nach. Domains mit 5.000 oder mehr Nachrichten pro Tag an diese Postfächer müssen SPF und DKIM bestehen und einen DMARC-Eintrag mit mindestens p=none veröffentlichen, der mit der From-Adresse übereinstimmt. Angekündigt war zunächst die Zustellung in den Junk-Ordner; in der Praxis weisen die Outlook-Server nicht konforme Nachrichten inzwischen mit dem Fehlercode 550 5.7.515 ab. Das erklärt einen Teil der Fälle, in denen „Outlook-Mails nicht ankommen" – sie landen nicht im Spam, sondern kommen als Unzustellbarkeitsnachricht zurück.
Das eigene Kontaktformular als unterschätzte Ursache
Kontaktformular-Mails landen im Spam, wenn die Website die Adresse des Besuchers als Absender einträgt. Viele Formulare tun genau das, damit man im Postfach direkt auf „Antworten" klicken kann. Technisch verschickt dann Ihr Webserver eine Nachricht im Namen von zum Beispiel max@yahoo.de – und Yahoo hat per DMARC erklärt, dass es so etwas abgelehnt sehen will.
Wie streng die großen Anbieter das handhaben, steht offen in deren DNS. Am 2. Oktober 2026 veröffentlichte yahoo.com die Richtlinie p=reject, gmx.de und web.de p=quarantine, gmail.com und t-online.de p=none. Eine Formularnachricht im Namen eines Web.de-Kunden landet also beim eigenen Postfach in Quarantäne, eine im Namen eines Yahoo-Kunden wird abgewiesen. Gerade die Anfragen von Privatkunden gehen damit still verloren.
Die Lösung ist schlicht: Die Website sendet immer von einer eigenen, authentifizierten Adresse wie formular@ihre-domain.de und setzt die Adresse des Besuchers ins Reply-To-Feld. Die Antwort-Funktion bleibt erhalten, und die Nachricht besteht SPF, DKIM und DMARC. Wer dasselbe Formular zusätzlich eine Bestätigung an den Besucher schicken lässt, sollte auch diese über einen Dienst mit sauberer Authentifizierung versenden.
Newsletter-Tools und Fremddienste ohne eigene Domain-Authentifizierung
Newsletter-Tools, CRM-Systeme und Buchungsplattformen verursachen Spam-Probleme, wenn sie in Ihrem Namen senden, ohne für Ihre Domain authentifiziert zu sein. Die Nachricht trägt dann Ihre Adresse im From-Feld, ist aber mit der Domain des Dienstleisters signiert. Für DMARC fehlt das Alignment, und mit einer strengen Richtlinie fällt die Nachricht durch.
Fast jeder seriöse Versanddienst bietet dafür eine Domain-Authentifizierung an: Er nennt CNAME- oder TXT-Einträge, die Sie in Ihrem DNS setzen, danach signiert er mit Ihrer Domain. Dieser Schritt wird bei der Einrichtung oft übersprungen, weil die ersten Testmails auch ohne ihn ankommen. Er wird erst sichtbar, wenn der Versand wächst oder die DMARC-Richtlinie verschärft wird.
Eine einfache Bestandsaufnahme hilft: Welche Dienste verschicken heute E-Mails mit Ihrer Domain im Absender? Die Liste ist in den meisten Betrieben länger als erwartet – Rechnungsprogramm, Terminbuchung, Shop, Bewerbermanagement. Jeder davon braucht entweder einen Eintrag im SPF und eine DKIM-Signatur mit Ihrer Domain oder eine eigene Subdomain.
So lesen Sie im Mail-Header, warum eine Nachricht im Spam landet
Der Header einer E-Mail verrät in der Zeile „Authentication-Results" (RFC 8601), ob SPF, DKIM und DMARC bestanden wurden. Schicken Sie sich dazu eine Testnachricht an ein Gmail- oder Outlook.com-Postfach und öffnen Sie dort die Originalansicht: In Gmail heißt der Menüpunkt „Original anzeigen", in Outlook „Nachrichtenquelle anzeigen".
Entscheidend sind drei Werte: spf=pass, dkim=pass und dmarc=pass. Steht bei DKIM zwar pass, aber hinter header.d eine fremde Domain, signiert ein Dienstleister mit seiner eigenen statt mit Ihrer Domain. Steht bei SPF permerror, ist der SPF-Eintrag fehlerhaft – häufig wegen der Grenze von zehn Abfragen oder wegen zweier SPF-Einträge für dieselbe Domain, was ebenfalls unzulässig ist.
Bestehen alle drei Prüfungen und die Nachricht landet trotzdem im Spam, liegt die Ursache beim Ruf oder beim Inhalt. Dann helfen die Postmaster Tools von Google, die für verifizierte Domains die gemessene Spamrate zeigen, und eine Abfrage der gängigen Blocklisten für die IP-Adresse Ihres Mailservers.
DMARC auf p=reject stellen: wann es sich lohnt
Eine DMARC-Richtlinie p=reject lohnt sich erst, wenn die Auswertungen über mehrere Wochen zeigen, dass alle legitimen Absender bestehen. Der Weg dorthin führt über p=none mit eingetragener Berichtsadresse (rua): Die großen Anbieter schicken dann täglich Sammelberichte, aus denen hervorgeht, welche Server in Ihrem Namen senden und ob sie die Prüfung bestehen.
Die Norm sieht für den Übergang den Parameter pct vor, mit dem eine strengere Richtlinie zunächst nur auf einen Teil der Nachrichten angewendet wird. Typisch ist die Abfolge p=none, dann p=quarantine, dann p=reject. Wer direkt auf p=reject springt, riskiert, dass das Rechnungsprogramm oder das Formular, das niemand auf der Liste hatte, ab sofort nichts mehr zustellt.
Eine Einschränkung nennt die Norm selbst: Weiterleitungen und Mailinglisten, die Nachrichten verändern, können DMARC brechen. Wer selbst Verteiler betreibt oder Mails automatisch an andere Postfächer weiterleiten lässt, sollte das vor der Verschärfung prüfen. Der Gewinn von p=reject liegt vor allem im Schutz vor Fälschungen in Ihrem Namen; die eigene Zustellung verbessert bereits ein sauber bestehendes p=none.
Was Authentifizierung nicht leisten kann
Saubere SPF-, DKIM- und DMARC-Einträge garantieren nicht, dass eine E-Mail im Posteingang ankommt. Sie sind die Voraussetzung dafür, dass ein Empfängeranbieter Ihre Nachricht überhaupt bewertet – das Urteil selbst fällt er nach Kriterien, die er nicht offenlegt: Ruf, Empfängerverhalten, Inhalt, Versandmuster.
Eine vollständig authentifizierte Domain, die an gekaufte Adressen schreibt, landet trotzdem im Spam, und zwar zu Recht. Ebenso bremst ein Anbieter eine neue Absenderadresse, die von null auf tausende Nachrichten am Tag springt. Wer eine Zustellquote zusichert, verspricht etwas, das außerhalb seiner Kontrolle liegt.
Was sich kontrollieren lässt, ist die eigene Seite: korrekte Einträge, ein Formular, das nicht fremde Absender vortäuscht, Fremddienste mit Domain-Authentifizierung und Verteiler, deren Empfänger die Nachrichten wirklich erwarten. Damit ist der größte Teil der Fälle gelöst, in denen Firmen-E-Mails im Spam verschwinden.
Rechtsgrundlagen
- RFC 7489 (DMARC)(öffnet in neuem Tab)Abschnitt 6.3 Richtlinien none, quarantine, reject; 6.6.4 schrittweise Anwendung per pct; 10.5 Weiterleitungen
- RFC 7208 (Sender Policy Framework, SPF)(öffnet in neuem Tab)Abschnitt 4.6.4 begrenzt DNS-abfragende Mechanismen auf zehn
- RFC 6376 (DomainKeys Identified Mail, DKIM)(öffnet in neuem Tab)Signatur der Nachricht, öffentlicher Schlüssel im DNS der Domain
- RFC 8058 (Abmeldung mit einem Klick)(öffnet in neuem Tab)Header List-Unsubscribe-Post: List-Unsubscribe=One-Click
- RFC 8601 (Authentication-Results-Header)(öffnet in neuem Tab)Kopfzeile, in der der Empfänger die Ergebnisse von SPF, DKIM und DMARC vermerkt