Warum Mails im Spam landen, und was wirklich hilft
Die üblichen Tipps drehen sich um Betreffzeilen. Über die Zustellung entscheiden drei DNS-Einträge, der Ruf deiner Domain und die Qualität deiner Liste.
Der Ablauf ist meistens derselbe. Die Formularbestätigung kommt beim Kunden nie an, der Newsletter landet bei der Hälfte der Empfänger im Werbe- oder Spam-Ordner, und die erste Suche nach einer Lösung führt zu einer Liste mit Wörtern, die man im Betreff vermeiden soll. Also wird das Ausrufezeichen gestrichen und "kostenlos" umformuliert. Danach ändert sich nichts.
Das liegt daran, dass diese Ratschläge am kleinsten Hebel ansetzen. Ein empfangender Mailserver stellt zuerst die Frage, wer da schreibt, und erst danach die Frage, was drinsteht. Die erste Frage beantworten drei DNS-Einträge und das Versandverhalten deiner Domain in den vergangenen Wochen. Beides steht nicht im Betreff.
Dieser Beitrag sortiert die Hebel nach Wirkung. Am Ende weißt du, welchen Eintrag du als Nächstes anfasst.
In dieser Reihenfolge lohnt sich die Arbeit
Die meisten Checklisten zum Thema Zustellbarkeit werfen zwanzig Punkte in einen Topf und gewichten nichts. Sortiert nach Wirkung sieht die Sache übersichtlicher aus:
- Authentifizierung. SPF, DKIM und DMARC sind eingerichtet und die Ausrichtung stimmt.
- Versandweg. Deine Mails verlassen einen Server, der laut deinen eigenen DNS-Einträgen für die Domain versenden darf.
- Listenqualität. Auf der Liste stehen Adressen mit dokumentierter Einwilligung, Bounces werden entfernt.
- Absenderruf. Menge und Frequenz passen zu dem, was diese Domain bisher verschickt hat.
- Inhalt. Betreff, Text, Verhältnis von Bild zu Text, Anzahl und Ziel der Links.
Punkt fünf ist der, über den am meisten geschrieben wird. Er wirkt erst, wenn die vier davor stehen. Wer die Reihenfolge umdreht, optimiert Formulierungen an einer Mail, die der Empfänger ohnehin nicht zuordnen kann.
Was SPF, DKIM und DMARC beim Empfänger tatsächlich prüfen
Die drei Verfahren werden ständig in einem Atemzug genannt und trotzdem regelmäßig verwechselt. Sie beantworten drei verschiedene Fragen.
SPF sagt, welche Server versenden dürfen
SPF ist in RFC 7208 beschrieben. Es ist ein TXT-Eintrag auf deiner Domain, in dem steht, welche Server im Namen dieser Domain Mails einliefern dürfen. Der empfangende Server vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste und hat damit eine Antwort auf die Frage, ob der Absatzweg erlaubt ist.
Der zweithäufigste Fehler der Praxis sitzt genau hier: Ein SPF-Eintrag darf beim Auswerten höchstens zehn DNS-Abfragen auslösen. Jeder eingebundene Dienst kostet mindestens eine davon. Wer nacheinander sein Postfach, einen Newsletter-Dienst, ein Buchhaltungswerkzeug und ein Ticketsystem einträgt, reißt die Grenze irgendwann. Das Ergebnis ist ein permerror, und ein SPF-Eintrag mit permerror ist wertlos. Er sieht im DNS trotzdem völlig unauffällig aus.
DKIM belegt, dass unterwegs nichts verändert wurde
DKIM steht in RFC 6376. Beim Versand wird eine kryptografische Signatur in den Kopf der Mail gesetzt, der passende öffentliche Schlüssel liegt im DNS deiner Domain. Der Empfänger prüft damit zwei Dinge auf einmal: Die Mail stammt wirklich von der Domain, und der signierte Teil ist auf dem Weg unverändert geblieben.
DMARC verbindet beides mit einer Anweisung
DMARC ist in RFC 7489 beschrieben und ist der Eintrag, der aus zwei Prüfergebnissen eine Entscheidung macht. Du legst darin fest, was der Empfänger tun soll, wenn die Prüfung scheitert. Es gibt drei Werte: none bedeutet nichts tun, quarantine bedeutet in den Spam-Ordner, reject bedeutet abweisen. Dazu richtet DMARC den Rückkanal ein, über den du Berichte darüber bekommst, wer in deinem Namen versendet.
Der mit Abstand häufigste Fehler im Feld: Der Eintrag steht auf p=none und bleibt dort für immer. Als Startpunkt ist das richtig, denn zuerst willst du sehen, was überhaupt in deinem Namen verschickt wird. Als Dauerzustand ist es eine Zeile im DNS ohne Wirkung. Ein Eintrag, der ernst gemeint ist, sieht am Ende so aus:
_dmarc.deinefirma.de. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@deinefirma.de"Die Ausrichtung ist der Punkt, an dem die meisten Einrichtungen scheitern
Hier steht die Sache, die fast jede Anleitung übergeht. DMARC prüft nicht nur, ob SPF oder DKIM bestanden haben. Es verlangt zusätzlich, dass die sichtbare Absenderdomain zu der Domain passt, die geprüft wurde. Das nennt sich Ausrichtung, im Englischen alignment.
In der Praxis passiert das hier: Du verschickst deinen Newsletter über einen Versanddienst. Im Absenderfeld steht deine eigene Adresse. Technisch liefert aber der Dienst ein, und der hat für seine eigene Domain einen sauberen SPF-Eintrag. SPF besteht also. Signiert wird ebenfalls mit der Domain des Dienstes. Für DMARC sieht das so aus: geprüft wurde eine fremde Domain, sichtbar ist deine. Die Ausrichtung scheitert, und damit scheitert DMARC, obwohl in jedem Prüfwerkzeug ein grünes SPF steht.
Die Lösung ist bei jedem ernsthaften Anbieter derselbe Ablauf: Du hinterlegst deine eigene Domain im Konto des Versanddienstes und trägst den DKIM-Schlüssel, den er dir dafür ausgibt, in dein DNS ein. Danach ist die Signatur auf deine Domain ausgestellt, die Ausrichtung stimmt, und DMARC besteht.
Was Google, Yahoo und Microsoft von Massenversendern verlangen
Seit Februar 2024 stellen Google und Yahoo Anforderungen an Massenversender, also grob an alle, die mehr als etwa 5.000 Nachrichten pro Tag an Gmail-Konten schicken. Verlangt werden SPF, DKIM und DMARC, eine funktionierende One-Click-Abmeldung im Mail-Header nach RFC 8058 sowie eine Spam-Beschwerdequote unterhalb von 0,3 Prozent. Microsoft hat 2025 vergleichbare Anforderungen für Outlook.com angekündigt und umgesetzt.
Wenn du weit unter dieser Menge liegst, giltst du formal nicht als Massenversender. Nur ändert das an der Einrichtung nichts: Die drei Einträge kosten dich einmal eine Stunde, die One-Click-Abmeldung setzt dein Versandwerkzeug, und die Beschwerdequote hängt bei jeder Menge am Zustand deiner Liste. Der einzige Unterschied ist, dass dich unterhalb der Schwelle niemand daran misst.
Finde deinen Fall in dieser Tabelle
| Symptom | Wahrscheinliche Ursache | Prüfschritt |
|---|---|---|
| Formularbestätigungen kommen nirgends an | Versand über den PHP-Standardweg vom Webserver, ohne SPF und ohne Signatur | Kopfzeilen einer Testmail ansehen, welcher Server eingeliefert hat |
| Gmail nimmt die Mails an, Outlook.com sortiert sie aus | DMARC fehlt oder steht auf p=none | TXT-Eintrag unter _dmarc abfragen und den Wert hinter p lesen |
| Newsletter landet im Spam, Rechnungsmails nicht | Zwei Versandwege, nur einer ist auf deine Domain signiert | DKIM-Signatur beider Mailarten im Kopf vergleichen |
| SPF besteht, DMARC scheitert trotzdem | Ausrichtung: die sichtbare Absenderdomain passt nicht zur geprüften | Zeile Authentication-Results ansehen, dort steht spf=pass neben dmarc=fail |
| Prüfwerkzeuge melden permerror bei SPF | Der Eintrag löst mehr als zehn DNS-Abfragen aus | Alle include-Angaben zählen und nicht mehr genutzte Dienste streichen |
| Erst gute Zustellung, dann plötzlich Spam | Menge zu schnell gesteigert oder Beschwerdequote gestiegen | Versandmengen der letzten Wochen und die Abmeldungen je Aussendung ansehen |
Warum die erste große Aussendung fast immer gebremst wird
Empfangende Systeme führen für jede versendende Domain eine Art Vorgeschichte. Eine Domain, die jahrelang nichts verschickt hat und dann an einem Dienstagvormittag 2.000 Mails auf einmal einliefert, sieht aus wie ein übernommenes Konto. Sie wird gebremst, und zwar unabhängig davon, wie sauber die DNS-Einträge sind.
Der Ausweg heißt Aufwärmen und ist unspektakulär. Fang klein an und steigere die Menge über mehrere Wochen. Beginne mit den Empfängern, die zuletzt geöffnet, geklickt oder gekauft haben, denn deren Reaktion ist das, was deinen Ruf aufbaut. Erst danach kommen die Kontakte dran, von denen du länger nichts gehört hast.
Wenn der jüngste Kontakt auf deiner Liste drei Jahre alt ist, hilft Aufwärmen allein wenig. Dann steht vor dem Versand die Arbeit an der Liste.
Eine gepflegte Liste bringt mehr als jede Textoptimierung
Gekaufte Listen, jahrealte Adressen und ignorierte Bounces kosten dich mehr Zustellbarkeit als jedes Reizwort, das du im Betreff je vermieden hast. Der Grund ist einfach: Jede Mail an eine tote Adresse und jede Beschwerde ist ein Signal an den Empfänger, das direkt gegen deinen Ruf zählt.
Die Regeln dazu sind kurz. Hard Bounces, also endgültig nicht zustellbare Adressen, gehören sofort aus dem Verteiler. Soft Bounces darfst du mehrfach versuchen und entfernst sie danach. Beschwerden führen sofort zur Abmeldung, ohne Rückfrage. Adressen, die seit Jahren nichts geöffnet haben, sind ein Risiko für alle anderen auf deiner Liste.
Am Anfang der Liste steht die Einwilligung. Wie ein sauberes Double-Opt-in aussieht, was protokolliert werden muss und warum das auch technisch hilft, steht im Beitrag über Double-Opt-in und DSGVO. Das ist an dieser Stelle eine fachliche Einordnung und keine Rechtsberatung, für die verbindliche Bewertung deines Falls brauchst du jemanden mit Zulassung.
WordPress verschickt standardmäßig auf dem falschen Weg
Ein eigener Punkt, weil er in kleinen Projekten die häufigste Einzelursache ist. WordPress verschickt Mails über wp_mail, und ohne weitere Einrichtung läuft das auf die PHP-Funktion mail() hinaus. Die gibt die Nachricht direkt an den Webserver weiter. Dieser Webserver steht in aller Regel in keinem SPF-Eintrag deiner Domain, und signieren tut er auch nichts. Die Mail geht also raus und scheitert an beiden Prüfungen gleichzeitig.
Der übliche Weg aus der Nummer ist, den Versand über SMTP oder die API deines Versandanbieters zu leiten, mit deiner eigenen verifizierten Domain. Das betrifft alles, was deine Website automatisch verschickt: Formularbestätigungen, Passwort-zurücksetzen-Mails, Bestellbestätigungen und Rechnungen. Diese Mails sind für den Kunden wichtiger als jeder Newsletter, und sie sind es, die am unauffälligsten verschwinden.
Woran du deine Zeit verschwendest
Bleibt die Frage, was von den üblichen Tipps übrig bleibt. Reizwörter im Betreff sind der Klassiker, und sie sind heute weitgehend Folklore. Filter bewerten das Verhalten des Absenders stärker als einzelne Wörter. Das Wort "kostenlos" im Betreff ist kein Problem, solange der Absender einen guten Ruf hat, und es rettet nichts, solange er keinen hat.
Damit ist Arbeit an der Betreffzeile nicht sinnlos. Sie zahlt nur auf die Öffnungsrate ein und nicht auf die Zustellung. Diese beiden Baustellen zu trennen erspart dir eine Menge fruchtloser Umformulierungen.
p=none, hast du Berichte und keine Wirkung. Steht dort gar nichts, hast du nicht einmal Berichte.Newsletter aus dem eigenen WordPress, mit Blick auf die Zustellung
Kurato verschickt über deinen eigenen Anbieter-Zugang und bringt One-Click-Abmeldung nach RFC 8058, Bounce- und Beschwerdebehandlung sowie eine Zustellbarkeits-Ampel für SPF, DKIM und DMARC mit. Die Kontaktdaten bleiben in deiner Datenbank.
Wenn du wissen willst, was die Free-Stufe abdeckt und wo Pro anfängt, steht das auf der Preisseite. Ehrlich dazu gehört: Verzweigte Automations-Sequenzen sind in Kurato noch in Arbeit.
Häufige Fragen
Was ist der Unterschied zwischen SPF, DKIM und DMARC?
SPF (RFC 7208) sagt, welche Server für deine Domain versenden dürfen. DKIM (RFC 6376) setzt eine kryptografische Signatur, mit der der Empfänger prüft, dass die Mail von deiner Domain stammt und unterwegs nicht verändert wurde. DMARC (RFC 7489) verbindet beide Ergebnisse mit einer Anweisung, was bei Fehlschlag passieren soll, und richtet die Berichte ein. Alle drei zusammen ergeben erst ein vollständiges Bild.
Mein DMARC-Eintrag steht auf p=none. Reicht das?
Als Startpunkt ja, als Dauerzustand nein. Bei p=none passiert bei einem Fehlschlag nichts, du bekommst lediglich Berichte. Der Sinn dieser Stufe ist, ein paar Wochen lang zu sehen, wer in deinem Namen versendet. Danach gehört die Anweisung auf quarantine und später auf reject, sonst ist der Eintrag eine Zeile ohne Wirkung.
SPF besteht, DMARC scheitert trotzdem. Wie geht das?
Das ist fast immer die Ausrichtung. DMARC verlangt, dass die sichtbare Absenderdomain zu der Domain passt, die SPF oder DKIM geprüft haben. Wer über einen Versanddienst schickt, ohne die eigene Domain dort zu verifizieren und zu signieren, besteht SPF für die Domain des Dienstes und scheitert an DMARC. Die Lösung ist der DKIM-Schlüssel für deine eigene Domain.
Hilft es, Reizwörter im Betreff zu vermeiden?
Kaum. Moderne Filter bewerten das Verhalten des Absenders stärker als einzelne Wörter. Ein Absender mit gutem Ruf kommt mit dem Wort kostenlos im Betreff problemlos durch, ein Absender ohne Ruf scheitert auch mit der bravsten Formulierung. Arbeit an der Betreffzeile lohnt sich für die Öffnungsrate, für die Zustellung bringt sie wenig.
Warum landen Formularbestätigungen aus WordPress im Spam?
Weil WordPress ohne weitere Einrichtung über die PHP-Funktion mail() versendet und die Nachricht damit vom Webserver ausgeht. Der steht meist in keinem SPF-Eintrag deiner Domain und signiert nichts, also scheitern SPF und DKIM gleichzeitig. Der übliche Weg ist, den Versand über SMTP oder die API deines Versandanbieters mit deiner eigenen verifizierten Domain zu leiten.
