E-Mails landen nach Umzug zu Cloudflare im Spam: Checkliste, um E-Mails wieder in den 'Posteingang' zu bekommen

Nachdem die Website zu einem neuen Hosting migriert und die DNS zu Cloudflare übertragen wurde, landen transaktionale E-Mails – Registrierungsbestätigungen, Benachrichtigungen, Passwort-Resets – plötzlich im „Spam“-Ordner. Vor der Migration kamen alle E-Mails im „Posteingang“ an. Kommt Ihnen das bekannt vor? Lassen Sie uns Schritt für Schritt aufschlüsseln, warum das passiert und wie Sie es beheben können – dies ist eine sofort einsatzbereite Checkliste, die in 20-30 Minuten erledigt werden kann.

Warum das passiert

In den meisten Fällen liegt der Grund in einem Punkt: Beim Import der Zone in Cloudflare werden die Mail-Authentifizierungsdatensätze „wie sie waren“ übernommen – zusammen mit dem alten Hoster. Der automatische DNS-Import (und KI-Assistenten, die zunehmend bei der Migration helfen) überträgt Datensätze „eins zu eins“ und baut die SPF-Einträge für den neuen Absender nicht neu auf. Die Website funktioniert extern, aber die E-Mail-Zustellung bricht leise zusammen – E-Mails werden gesendet, landen aber im Spam, und niemand bemerkt es wochenlang.

Ein klassisches Beispiel: Der Haupt-SPF-Eintrag bleibt v=spf1 include:_spf.old-hoster.com ~all, obwohl die E-Mails tatsächlich von einem anderen Dienst gesendet werden – Amazon SES, Resend, SendGrid oder Postmark. Die Domain „erlaubt“ den alten Hoster, aber nicht den tatsächlichen Absender. Gmail sieht SPF: fail oder softfail und sendet die E-Mail in den Spam, auch wenn der Inhalt völlig legitim ist.

Schritt 1. Diagnose (Nicht raten)

• Senden Sie eine Test-E-Mail an mail-tester.com – der Dienst stellt eine einmalige Adresse zur Verfügung und zeigt einen Bericht mit einer Punktzahl von 10 und einer Aufschlüsselung jedes Datensatzes an.
• Öffnen Sie in Gmail die E-Mail → klicken Sie auf das Menü „⋮“ → „Original anzeigen“. Suchen Sie nach drei Zeilen: SPF, DKIM, DMARC. Alle drei sollten PASS lauten.

Wenn mindestens einer fail / softfail anzeigt – liegt das Problem bei den DNS, nicht beim E-Mail-Inhalt. Fahren Sie mit der Checkliste fort.

Schritt 2. Checkliste für DNS-Datensätze

Alles wird in Cloudflare korrigiert → DNS → Datensätze:

• SPF (Domain-Root). Muss den ECHTEN Absender autorisieren. Für Amazon SES / Resend lautet er v=spf1 include:amazonses.com ~all. ⚠️ Es darf nur ein v=spf1-Datensatz pro Domain vorhanden sein – wenn es zwei gibt, werden beide ungültig. Wenn E-Mails sowohl über einen externen Dienst als auch von Ihrem Postfach gesendet werden – fassen Sie alles in einer Zeile mit include: zusammen.
• DKIM. Ein Selektor-Datensatz (z. B. resend._domainkey) muss vorhanden sein. Dies ist eine kryptografische Signatur, die der Mail-Dienst verwendet, um zu bestätigen, dass die E-Mail tatsächlich von Ihnen stammt und nicht gefälscht wurde.
• DMARC. _dmarc-Datensatz. Für eine neue Domain ist es in Ordnung, mit p=none (nur Überwachung) zu beginnen; nach dem Aufwärmen erhöhen Sie ihn auf p=quarantine.
• MX und Return-Path. Müssen auf Ihren Sende-/Empfangs-Provider zeigen, nicht auf den alten Hoster.
• PTR (Reverse Record, rDNS). Nur relevant, wenn Sie E-Mails von Ihrem eigenen SMTP-Server senden – der Reverse-Datensatz der IP muss mit dem Namen des Servers übereinstimmen.
• Alten Hoster-Müll entfernen. Ein defekter Root-MX, ein veralteter DKIM-Selektor, zusätzliches include: in SPF – eine häufige Ursache, die nach der Migration vergessen wird.

Die Hauptregel: Führen Sie nach JEDEM DNS-Transfer eine Mail-Prüfung separat durch. Der Zonenimport kopiert Datensätze „wie sie waren“, und „wie sie waren“ ist die Konfiguration des alten Anbieters.

Schritt 3. Wenn E-Mails BEREITS im Spam gelandet sind

Sie haben die DNS korrigiert, aber alte E-Mails sind bereits im „Spam“-Ordner, und der Mail-Client hat sich die Domain als verdächtig „gemerkt“. Helfen Sie ihm, seine Entscheidung zu überdenken:

• Gehen Sie zu Ihrem Google Mail (Gmail), öffnen Sie eine E-Mail aus dem Ordner „Spam“ → klicken Sie auf die Schaltfläche „Kein Spam“. Dies ist das stärkste Signal auf Kontoebene: Gmail wird die Reputation des Absenders schneller überprüfen und seine E-Mails in den „Posteingang“ legen.
• Bitten Sie die ersten Empfänger, dasselbe zu tun – ein paar „Kein Spam“-Markierungen von echten Personen beschleunigen den Prozess erheblich.

Schritt 4. Berücksichtigen Sie den Faktor „Neue Domain“

Wenn die Domain kürzlich registriert wurde, fehlt ihr noch die Historie und Reputation. Selbst mit perfekt konfigurierten SPF-, DKIM- und DMARC-Einträgen können anfangs immer noch einige E-Mails im Spam landen – und das ist zu erwarten; es geht dann nicht mehr um DNS.

• Wärmen Sie die Domain auf: Beginnen Sie mit kleinen Versandvolumina und steigern Sie diese allmählich, nicht „tausend E-Mails am ersten Tag“.
• Überwachen Sie Beschwerden und Abmeldungen – scharfe Spitzen schaden der Reputation.
• „Kein Spam“-Markierungen von echten Empfängern wärmen die Domain in dieser Phase am schnellsten auf.

Sie reparieren die DNS einmal, und dann wird die Reputation durch Volumen und Empfängerverhalten aufgebaut.

Schritt 5. Ergebnis prüfen

• Wiederholen Sie den Test auf mail-tester.com → streben Sie 10/10 an.
• In den E-Mail-Headern (Gmail → „Original anzeigen“): SPF: PASS, DKIM: PASS, DMARC: PASS.
• Eine Test-E-Mail kommt im „Posteingang“ an, nicht im „Spam“.

Fazit

E-Mails, die nach der Migration im Spam landen, sind fast nie „Magie“, sondern eher der vom alten Hoster übernommene SPF-Eintrag, der den neuen Absender nicht autorisiert (ein häufiger Nebeneffekt der automatischen und KI-gestützten DNS-Migration zu Cloudflare). Der Behandlungsalgorithmus: SPF für den tatsächlichen Absender neu zusammenstellen → DKIM, DMARC, MX prüfen → alten Hoster-Müll bereinigen → auf mail-tester testen → wenn E-Mails bereits im Spam gelandet sind, manuell auf „Kein Spam“ setzen → für eine neue Domain, Aufwärmphase hinzufügen. Gehen Sie diese Checkliste einmal durch – und E-Mails werden konsequent wieder im „Posteingang“ landen.